The Power of ONE ( to cloud clear thinking)
James McGovern goes off on one about his various theories on why IT in Enterprises isn't agile. I think he forgets to mention a key reason for this - and that is self induced by the EA community. Perhaps it is because it answers the following question : Why is Enteprise Architecture not agile ?
EA these days suffers from an overwhelming malaise that has gradually crept up and dominated all the problem solving that is occurring in the area. This is the drive towards centralisation as a solution to every problem that an Enterprise ( and an Enterprise Architect) faces. This is the school of thought that drives initiatives such as the push to have ONE (insert term here) of everything across any domain an architect that conceive of within their organisational boundaries. The term in the blank can be any technology ( database, ESB, development environment etc) or process ( governance, QA, funding etc). It is this process that causes architectural teams in large organisations to occasionally wake up and commission well intentioned unification initiatives. The underlying premise is that simplification and unification is so obviously a good thing that simplifying the mess that is a typical organisation's IT by standardising on ONE framework, database etc etc is a worthy goal. The reason this reasoning is flawed is twofold.
Firstly, every move towards 'simplification' of an IT estate has associated transition costs - both in raw spend as well as the risk introduced in the landscape. Very few people actually calculate the relative cost and benefits of sweating existing assets ( which normally work pretty well but are extremely ugly to look at) as opposed to ripping them out in the interests of an idealised simpler picture. Things are complex for a reason and the biggest reason is that complexity is a function of time. Most IT decisions are made by intelligent people solving problems in optimal ways at points in time. Complexity and 'spaghettiness' is an emergent quality of interacting systems and modules that are subjected to unpredictable 'shocks' ( aka business requirements/cost cuts etc) over time. The fact that this happens in the best of organisations across all industry domains over and over again is proof that this is simply the nature of software evolution. Changing the system without being able to change the environment is not going to change this basic tendency towards entropy in systems.
Secondly, what's the evidence that this adds business value ? Given that having a single product or framework that solves every problem that even the simplest of subdomains that an architect has to deal with is self-evidently impossible, why do people keep assuming that a move towards unification is a good thing ? Why are sources of value in a heterogenous environment overlooked ? Some of these in my view are the ability to have multiple options for solving a problem ( eg. for database storage have the ability to choose from 5 different solutions) which in most other areas leads to better and not worse decision making.
My theory on why this happens is that centralisation is easier to manage. While it doesn't lead to better IT decision making, it empowers IT managers, it appeals to the first order 'simpler is better' though processes that govern IT decision making and is generally unquestioned.
Wouldn't it be better if there was more acceptance of the idea that more energy needs to be spent on improving the manageability of complex heterogenous system sets than the time burnt up in frequent unification initiatives ( which I suspect take up more than 60% of all EA work done in industry) ?
EA these days suffers from an overwhelming malaise that has gradually crept up and dominated all the problem solving that is occurring in the area. This is the drive towards centralisation as a solution to every problem that an Enterprise ( and an Enterprise Architect) faces. This is the school of thought that drives initiatives such as the push to have ONE (insert term here) of everything across any domain an architect that conceive of within their organisational boundaries. The term in the blank can be any technology ( database, ESB, development environment etc) or process ( governance, QA, funding etc). It is this process that causes architectural teams in large organisations to occasionally wake up and commission well intentioned unification initiatives. The underlying premise is that simplification and unification is so obviously a good thing that simplifying the mess that is a typical organisation's IT by standardising on ONE framework, database etc etc is a worthy goal. The reason this reasoning is flawed is twofold.
Firstly, every move towards 'simplification' of an IT estate has associated transition costs - both in raw spend as well as the risk introduced in the landscape. Very few people actually calculate the relative cost and benefits of sweating existing assets ( which normally work pretty well but are extremely ugly to look at) as opposed to ripping them out in the interests of an idealised simpler picture. Things are complex for a reason and the biggest reason is that complexity is a function of time. Most IT decisions are made by intelligent people solving problems in optimal ways at points in time. Complexity and 'spaghettiness' is an emergent quality of interacting systems and modules that are subjected to unpredictable 'shocks' ( aka business requirements/cost cuts etc) over time. The fact that this happens in the best of organisations across all industry domains over and over again is proof that this is simply the nature of software evolution. Changing the system without being able to change the environment is not going to change this basic tendency towards entropy in systems.
Secondly, what's the evidence that this adds business value ? Given that having a single product or framework that solves every problem that even the simplest of subdomains that an architect has to deal with is self-evidently impossible, why do people keep assuming that a move towards unification is a good thing ? Why are sources of value in a heterogenous environment overlooked ? Some of these in my view are the ability to have multiple options for solving a problem ( eg. for database storage have the ability to choose from 5 different solutions) which in most other areas leads to better and not worse decision making.
My theory on why this happens is that centralisation is easier to manage. While it doesn't lead to better IT decision making, it empowers IT managers, it appeals to the first order 'simpler is better' though processes that govern IT decision making and is generally unquestioned.
Wouldn't it be better if there was more acceptance of the idea that more energy needs to be spent on improving the manageability of complex heterogenous system sets than the time burnt up in frequent unification initiatives ( which I suspect take up more than 60% of all EA work done in industry) ?
posted by Piyush Pant at 1:56 pm
3 Comments:
In 100% agreement. I did mention that most EAs are asleep at the helm...
Isn't it horses for courses? That sometimes unification/consolidation is right, sometimes managing heterogeniality is? It depends on the context? Geoffrey Moore has recently done some interesting analysis on this.
Either way, it is important to differentiate between the consolidation of technology under an unchanged business process/service (i.e. refactoring) vs the standardisation of the business process/service in tandem with a technology consolidation (i.e. technology-enabled business transformation). Quite different exercises and objectives.
Sam,
I agree with you that the same solution does not fit every situation. The point I was making was that the judgement should be based on objective analysis of costs and benefits. Too often I see enterprises get carried away by the 'unification' theme and commission grand architectural initiatives without having evaluated how they stack up against the other alternatives.
Post a Comment
<< Home