Disdain for legacy systems, lack of business focus... some of us were disappointed at the disorganised, unstandardised and disintegrated IT landscape that emerged from the move away from mainframe to client/server and web-based systems. Has anything changed?
When we first learned about the concept of enterprise architecture, it appeared to be just what the IT world had been waiting for. Tackling a business's IT portfolio from a strategic, centralised perspective appeared to be the only way forward.
Our disquiet over where enterprise architecture (EA) was taking us began in 2004 when we were attending a presentation on enterprise security by the EA team for a major government department.
When it dawned on us what was being proposed we asked 'Does this mean that we can make no progress on security until everything has been rewritten in Java?' To which the stunning answer came: 'We can’t make progress on anything until we're rewritten everything in Java.'
On the same project, in another presentation, the legacy application estate was described as 'the slime'.
The same year we saw the EA for another major public sector body that showed everything across the enterprise composed of sea of Java components. The thing that struck us was that it would have been impossible to tell to which sort of organisation the proposed EA applied. There was simply no business-focused element to it at all.
As we had been working for that body for over a year, we had formed some ideas of what an EA ought to look like and that it ought to reflect at least five significant business areas, with very different business, technical and operational characteristics: from real-time, mission-critical, safety-critical systems to standard HR, payroll and finance systems, to public-facing informational websites. If EA was proposing that these things were all homogeneous, then surely something was badly wrong.
In the main, we put these early observations down to the EA practitioners in question: they had not understood EA properly, at the very least from the point of view of proposing an EA that was practically achievable.
But, we have to say that we’re not sure we've yet seen an EA strategy that is anything other than impractical, unachievable and, even if it could be achieved, unsustainable. Yet, EA seemed to have gained ground as a hugely beneficial concept and has perhaps reached an apotheosis in the much debated National Programme for IT in the NHS.
So, perhaps unfairly, how would we characterise EA (given that EA strategists usually have nothing but contempt for legacy systems):
- Technology-led, with standardisation of applications, systems and technologies used as driver for enforced business change;
- Dogmatic, in the sense that nominal standardisation at an enterprise level is seen as a more important goal than meeting end users' real requirements;
- Over-ambitious, in the sense that few EA strategies seem to be able to stop short of an idealised, perfect scenario;
- Unverified, in that no one has properly analysed the achievability or sustainability of the proposed EA;
- Divorced from the current state, in the sense that although the current state is usually shown, there is no analysis of how the first steps can be taken from the current to the idealised future state;
- Futuristic, in the sense that the EA strategy plans are so far in advance that they don't sensibly guide the immediate next IT strategy steps;
- Politicised, in the sense that things are reduced to sound-bites and perceptions and not judged on hard analysis of benefits and weaknesses.
In summary, we would characterise the EA strategist as a chess player who has a long-term strategic view of the perfect position, but who disregards his current position and dismisses with contempt (as a short-term tactical necessity) each and every move that can practically be made.
In other words, there is simply no way to reach the desired position given the starting point and the possible next moves at one's disposal. And, perhaps to go further, the EA strategist blames the current position and the moves available without considering that their strategy itself might be wrong. With the same given starting position and using the available moves as a guide, one could construct a viable and beneficial EA strategy.
A deeper problem
The question must be asked of how practical it is for one EA team to think, work and operate at an enterprise level and to make decisions that are beneficial to the business without working on specific business problems.
Not only do analogies with the centrally planned economy come to mind, but also questions about whether the scope of the problem is just too broad. How is it possible to judge the viability and suitability of an EA when it is by its nature abstracted to a very high level? It's tempting to say that the devil is in the detail and EA strategies are prone to proposing an architecture that proves impractical.
One example of this can be seen in the NHS, where the strategy for sharing digital medical images (X-rays, MRI scans and so on) across the NHS assumed that if all the images could be stored in a central image database, then the problem would be solved.
Once the problem is tackled from a practical 'how can digital medical images actually be shared effectively', it does not take long for the architect to realise that more than just the raw images are needed and that, in fact, a range of related patient information must be coordinated along with the images.
One could argue that the above is simply an example of a mistake. But, it seems to us that EA has deliberately avoided any contact with the real world, partly though the extreme high level at which EA works and partly though the de facto principles that govern EA.
Technical architects at the project level do, in our experience, concern themselves with the next level of detail and, as far as possible, propose an architecture that will survive the detailed design process.
On the other hand, enterprise architects do not do this, in our experience. Instead, the onus is placed 100 per cent on the project architects to deliver within an EA that may be flawed, impractical, constantly changing or even internally inconsistent.
Moreover, an EA can be generated relatively quickly. A five-year IT strategy can be generated by an EA team in 3-6 months, perhaps. What happens then? Do the EA's start to test their EA by monitoring its adoption by various projects? In our experience, they do not.
Another problem
Another issue we see with EA, as it is practised today, is the sustainability of the target architecture, which often involves a massive and unrealistic amount of consolidation and homogenisation.
We have started to ask of EA strategies: if that were achieved, how could it be developed or upgraded? And often the answer is that it would be problematic, to say the least. Often business functions and applications are consolidated into multi-faceted integrated systems, directly used by many thousands of disparate end users.
Even to consider how an upgrade might be approached is not an easy question. Increasingly, we can see these integrated, enterprise-wide components becoming inert, stuck at their initial implementation and just too big and too all-encompassing to be upgraded.
Finally, there may be a case that diversity in IT systems is a good thing. Standardisation assumes, to some extent, that functional richness and specificity can be achieved within a pre-defined standard framework. But is this true?
In the same way that a large organisation is staffed by diverse human beings, why shouldn't the IT systems display a degree of diversity? In terms of IT systems, we are not talking here about commodity products, we are talking about applications that work hand-in-glove with the business users who carry out diverse business processes. This would imply, in our view, the EA recognising diversity across business or departmental boundaries much more than any EA we have seen to date.
If one business process involves a real-time, safety-critical activity where lives are at stake and another involves the backroom processing of overtime payments, then why should these applications be constrained by the arbitrary platform, technology and user interface standards invented by an EA without any real knowledge of the business requirements and any specific analysis of the business benefits that could be gained from deployment of this or that IT system?
In conclusion, we don't have an answer to how beneficial an EA approach can be to a business or government department.
In many ways, having an enterprise-wide view of things can only be an advantage. We are, however, increasingly concerned that EA concepts are being pushed beyond what can be justified by a business-wide cost-benefit analysis.
We believe that enterprise architects should be asked to justify their strategies in terms of overall concrete business benefit much more and to provide far more assurance that the proposed EA is viable and does not unnecessarily constrain the ability of the business to benefit from IT systems and technology innovation.
