The Project View versus The Enterprise View
Project view and Enterprise view - Must we always fight? There is a long-standing struggle between those who throw their lot in with a project or a programme as a pragmatic vehicle ‘which gets things done’, and those who align themselves with some larger enterprise objectives claiming that they have the bigger picture in mind.
It’s come up many times over the relatively short history of Enterprise IT. For example, in the early days of data management years ago there was great resistance against the practical and non-ideal compromises of Data Warehouses. In the 90s the rush for new enterprise application implementations, and of course the time-limited rush for y2k definitely made good project people ‘king’ in many companies. Since the slowdown after the turn of the millennium when thoughts turned to contemplation of the mistakes, failures and excesses of the previous decade, the quantity of (non-delivery) enterprise roles (including high-ranking ones), and their kudos, has increased. It has been almost as if there had been a recognition that there is a need to do things smarter and in a more mature way next time around. And then more recently again there are signs the up-swing in spending may shift the balance back the other way again.
In many industries (possibly exemplified by some consumer product companies in the late 90s, and many retailers slightly more recently) companies seemed to try to 'factor out' the differential between the granularity and motivation differences of project and enterprise by simply making the project into phases within a programme, and then making the programmes bigger, potentially right up to the point of it being almost all IT activities in the enterprise. It's almost as if the thought is to attempt to make the programme actually the enterprise IT itself, and therefore making the differential disappear and represent both viewpoints.
But of course it can't. It might force economies of scale which appear to work, after all the 'mega-programme' is one hell of a political force and can ensure reuse and convergence, but it's still driven by the interests of the stakeholders of the programme, who very rarely are the entire set of stakeholders of the Enterprise, so you get imbalances, and optimisation of their viewpoints to the detriment of others'.
Additionally, if you've outsourced the delivery of the programme to a third party, particularly if through contractual mechanisms where the third party is now carrying the risk, they will undoubtedly be looking to fulfil the terms of the contract whilst optimising their delivery and the solution to minimise the risk and cost to them. Potentially to the detriment of risk and cost positions (that their decision will have) elsewhere in other parts of the enterprise, outside of their contract. This is not necessarily the type of optimisation that is desirable for the client organisation to have to say the least, let alone a pleasant business experience for either side if specific examples comes to everyone’s attention during the project.
But on the other hand, executive power can’t of course lie in the hands of the Enterprise roles. Apart from inevitable conflicts with the programme leaders, the Enterprise team are not delivery focused (and the types of individuals aren’t necessarily always 'completer-finishers'!) and the service to the business relies on keeping the wheels of delivery turning. In fact, generally enterprise teams who are not delivery-focused if left to their own devices without a pragmatic mindset and the right kind of broad-focus and incentivisation, can tend be drawn towards idealist or intellectually-driven goals.
There is no perfect answer to this dynamic, but it is gratifying to see that there is now a more mature and widespread appreciation of a fuller set of roles required in both viewpoints. The best solutions that I have seen or been part of, have the system itself designed around the very conflict of this dynamic. They are designed to encourage healthy confrontation between the viewpoints (which one IT director I worked with liked to call ‘creative conflict’), with balanced and circumspect incentivisation vehicles, and parallel and even-handed escalation mechanisms. The goal being, by design, to foster new balanced and creative solutions to the scenarios encountered.
Technorati Tags: Enterprise IT IT Management IT Excellence IT Governance
It’s come up many times over the relatively short history of Enterprise IT. For example, in the early days of data management years ago there was great resistance against the practical and non-ideal compromises of Data Warehouses. In the 90s the rush for new enterprise application implementations, and of course the time-limited rush for y2k definitely made good project people ‘king’ in many companies. Since the slowdown after the turn of the millennium when thoughts turned to contemplation of the mistakes, failures and excesses of the previous decade, the quantity of (non-delivery) enterprise roles (including high-ranking ones), and their kudos, has increased. It has been almost as if there had been a recognition that there is a need to do things smarter and in a more mature way next time around. And then more recently again there are signs the up-swing in spending may shift the balance back the other way again.
In many industries (possibly exemplified by some consumer product companies in the late 90s, and many retailers slightly more recently) companies seemed to try to 'factor out' the differential between the granularity and motivation differences of project and enterprise by simply making the project into phases within a programme, and then making the programmes bigger, potentially right up to the point of it being almost all IT activities in the enterprise. It's almost as if the thought is to attempt to make the programme actually the enterprise IT itself, and therefore making the differential disappear and represent both viewpoints.
But of course it can't. It might force economies of scale which appear to work, after all the 'mega-programme' is one hell of a political force and can ensure reuse and convergence, but it's still driven by the interests of the stakeholders of the programme, who very rarely are the entire set of stakeholders of the Enterprise, so you get imbalances, and optimisation of their viewpoints to the detriment of others'.
Additionally, if you've outsourced the delivery of the programme to a third party, particularly if through contractual mechanisms where the third party is now carrying the risk, they will undoubtedly be looking to fulfil the terms of the contract whilst optimising their delivery and the solution to minimise the risk and cost to them. Potentially to the detriment of risk and cost positions (that their decision will have) elsewhere in other parts of the enterprise, outside of their contract. This is not necessarily the type of optimisation that is desirable for the client organisation to have to say the least, let alone a pleasant business experience for either side if specific examples comes to everyone’s attention during the project.
But on the other hand, executive power can’t of course lie in the hands of the Enterprise roles. Apart from inevitable conflicts with the programme leaders, the Enterprise team are not delivery focused (and the types of individuals aren’t necessarily always 'completer-finishers'!) and the service to the business relies on keeping the wheels of delivery turning. In fact, generally enterprise teams who are not delivery-focused if left to their own devices without a pragmatic mindset and the right kind of broad-focus and incentivisation, can tend be drawn towards idealist or intellectually-driven goals.
There is no perfect answer to this dynamic, but it is gratifying to see that there is now a more mature and widespread appreciation of a fuller set of roles required in both viewpoints. The best solutions that I have seen or been part of, have the system itself designed around the very conflict of this dynamic. They are designed to encourage healthy confrontation between the viewpoints (which one IT director I worked with liked to call ‘creative conflict’), with balanced and circumspect incentivisation vehicles, and parallel and even-handed escalation mechanisms. The goal being, by design, to foster new balanced and creative solutions to the scenarios encountered.
Technorati Tags: Enterprise IT IT Management IT Excellence IT Governance
posted by Sam Lowe at
11:19 pm
4 Comments:
look at your language Sam, it is just FULL of words that simply have no meaning anywhere except among a very few people who already have their minds made up, i work in an organization that has an 'architecture' group - we use them as a threat, "if you're not good we will throw you to the architecture group" (and then whatever it is that you are trying to accomplish will NEVER get done)
and calling what you do 'architecture'?? - what hubris! check out a real architect, even corbusier, and you will see that you just ain't one! sorry ...
truly, sorry to be so negative, i wish there were some other way to tell you ...
By
David Wilson, at 6:24 pm
David, thanks for your comment.
Sounds like the 'architecture group' in your organisation is not exactly ideal to say the least. This was similar to one of the points I was trying to put down in the last posting on project vs enterprise (although this was wider than just architects, relating to all senior roles in Enterprise IT). Anyway, a dysfunctional relationship between an enterprise-level group and a project delivery group, epitomised by the delivery people perceiving the architecture group being a threat to stop you accomplishing anything, is certainly not a situation I would be in favour of. My view is certainly that a practical view from the enterprise-level groups (along with a big picture view from the person trying to accomplish whatever) is necessary for it to work and add value.
But not all architecture groups are like you describe. It's probably not wise to tar everyone with the same brush.
As for the naming, yes that is always a contentious point, the worlds of buildings is very different to the world of Enterprise IT and it's difficult to draw parallels. Indeed, real-world architect friends of mine don't like IT using the name. Certainly 'architect' is a very over-used word in IT, and I believe that many architect roles in IT are actually lead-engineer roles. But Enterprise Architecture is a discipline that actually tries to differentiate that - in it the actual architect roles do share several characteristics with real-world architecture in terms of the remit of the role in its relative context the relative relationship up-stream and down-stream to 'clients', 'engineers' and 'builders', approach to the whole system, accountability for the solution 'fitness-for-purpose' for its usage, etc.
Some organisations refers to the type of role I do as a Chief Technologist role, and that's fine but I prefer Chief Enterprise Architect (despite its flaws), precisely because of the key differences. I feel that it stresses the need for relevance to client/the business, and the mandate (rather than the 'tools' and best-practice around them), and it implies a need to deliver results and therefore be pragmatic (whilst still providing content and discipline leadership of course, and challenging where necessary).
But I suspect most of your bad-feelings/experiences may stem more from the Enterprise-level governance type of role rather than Project-specific design roles. Suggest you check out the paragraphs in the posting on what EA is not (http://sol1.blogspot.com/2005/08/enterprise-architecture-is-not.html) which talks about how that is rather different, and more akin to city planning than architecture in the physical world.
Regards,
Sam.
By
Sam Lowe, at 9:59 pm
one of my colleagues, who graduated as a quantum chemist (whatever THAT is) and wound up seriously in IT - neural nets and whatnot, has recently begun a blog which deals mostly with architecture and city planning, the mind-set of individuals doing these things can be similar no doubt, but wishes are not horses (if you know the old nursery rhyme)
when i began as a programmer thirty five years ago, i worked for a large insurance company, and about half of the programmers there were clerks who had managed to make the shift somehow, so for many years i put 'clerk' on my income tax form, because really that is what programmers ARE
however, girls in bars and the proverbial man-on-the-street began to look up to us, thought we were smart, and i have known many people who got sucked into that one, nonsense of course, nothing about a computer that a mediocre brain cannot pick up in an hour or so
but what you can do (and what the timid little bureaucrats have most effectively done, turf war you see, job security ...), by a process i would call gross-over-complexification - basically keep removing the actual work from the reality of what it touches by a series of indirect references, and fragment it wherever possible, and hide it, until you wind up with something that requires 100% focus to stay on top of even a small part of - and THEN you begin to need the phony priests giving themselves airs and calling themselves 'architects'
but it does NOT result in better systems by a long shot
extremely badly designed classes in object models which are kept soooo well hidden, i would say it comes down to a failure to teach geometry anymore and the resulting inability to think, an inability to spell and the resulting failure to communicate, coupled with a good dollop of american anti-intellectualism
i had a guy working for me recently who could write, from scratch, SQL constructs that looked like concrete blocks, square arrays of letters and symbols, no carriage returns anywhere to be seen, marvellous! but when i showed him that these wondrous things were impossible to maintain, he took a fit and went back to head office in england, specialist you know ...
tell you what, try this on - i bet that some of your work is done for the military, when was the last time you refused to take on a job or even thought about it in moral terms?
all those years ago we built systems because they were going to remove drudgery and liberate, it's true, and that is simply not what is up anymore Sam, that is not what windows and google and oracle and the rest are up to
and what you call architecture is nothing but false and unnecessary mystification that serves their cheezy power games
i am in the same line of work by the way, but i like to think that at least i know why i am doing it - to eat and have enough to get to brasil now and then
and there is hope there, presidente lula kicked windows out in favour of open systems, time will tell
best regards, david.
By
David Wilson, at 12:16 am
David, a lot of interesting stories, amusingly written, and some nice social comment, but quite a lot of it seems more relevant to avoidance of bad practice of various types rather than comment specifically on architecture in IT (and its value).
For example, of course I would agree with you that the bad classes and SQL are pure bad practice for reasons you state, but they are not really related to the presence or not of an architecture initiative in an IT organisation. The presence of an architecture initiative might be a vehicle for design standards and governance procedures which aim to prevent that sort of practice getting through, but it certainly wouldn’t create it.
But regarding your implication that architecture is a process of 'gross-over-complexification', I would propose to you that what you describe is actually not architecture, but rather it is bad architecture. Of course, unfortunately this does exist in the Enterprise IT world, just like in the more traditional architecture of the physical world…
If a particular Enterprise Architecture initiative does not do one or more of:-
-create ‘better’ systems, data, and/or technical infrastructure
-create a ‘better’ portfolio of them as a whole
-better position them and the enterprise for future strategies, or future pressures/challenges
-(or facilitate delivery of whatever other design objectives have been defined with the 'owners')
… then I would propose that that architecture initiative is probably not adding value, and that that architecture initiative probably needs to be redesigned or reconsidered.
But does this mean that Enterprise Architecture as a whole is flawed, or does it mean that to maximise the value it has to offer, Enterprise Architecture needs to be pragmatic, clear and visible, outcome-focused, relevant to delivery etc? It’s a shame that the ones that you describe don’t seem to have been.
Regards,
Sam.
By
Sam Lowe, at 11:05 pm
Post a Comment
via Haloscan
<< Home