lustratus LiteBytes

I have to confess up front that I have never been desperately comfortable with Enterprise Architecture (EA) frameworks and disciplines, and therefore the opinions I am about to express should be taken in that light.

However, I do worry that EA may be handcuffing some companies to the point where potential benefits are strangled at birth.

I was recently reading an interesting article by Nagesh Anipindi, entitled “Enterprise Architecture: Hope or Hype?”, which discusses the lengthy presence of EA as an innovation and considers the reasons for its failure to move into the mainstream of acceptance. As Nagesh writes,

For 2009, Greta has predicted that more than half the existing EA programs are at risk and will be discontinued in the near future. Remaining ones that survive this economy, per Greta, will struggle with framework and information management problems.

Nagesh goes on to postulate that the current pressures on IT budgets will result in a lot of EA efforts being abandoned, not because they are unworthy but because they fall below other more critical areas such as Operations and development of new business solutions. He then goes on to say that once the industry realizes the massive benefits that EA can deliver, he believes this situation will turn around and EA will become an essential part of every corporate IT organization.

I think Nagesh may have missed the point slightly, although I agree with a lot of what he says. Look at one of the many definitions of Enterprise Architecture, as Nagesh records it -

Gartner defines EA as: “Enterprise Architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

This definition epitomizes the problem as far as I am concerned. The basic purpose of EA is there, but clouded with the sort of mumbo-jumbo that frightens off potential decision-makers. What is EA REALLY about? It is about tying the IT architecture and implementation to the business vision and needs, both now and in the future. It is about making sure IT really serves the business. Does this require communication? Of course. Does it require principles and practices – yes. But the complex phrasing of this definition is typical of ‘EA Experts’. These people talk of EA Frameworks, of EA Models, and of rigid procedures. From an intellectual point of view, this is all absolutely fine. If you were writing a thesis on how to architect an enterprise IT system to match business needs and to be able to continue to do so, it might be perfectly acceptable to introduce loads of models, a single tool-driven interface, definition language and frameworks.

However, this is the real world. The danger I see is that this over-enthusiastic approach can tie the hands of professionals and organizations so tightly that they cannot achieve anything. There is also the danger that when this approach is considered over time, it introduces a real skills problem, with the need to train new people on all these tools and methods which do not actually contribute to delivering new business value. In effect, the mechanisms to deliver the effective enterprise architecture develop a life of their own and start to consume development resources for their own purposes as opposed to business needs.

A small example may illustrate my point. In the old days, when I worked with IBM, a purist movement pointed out that because we wrote our design documentation in English, we were impacting quality and accuracy by introducing the potential for misunderstandings as to what a passage of English might actually mean. As a result, IBM worked with Oxford University to develop a mathematically-based specification language to eliminate the problem. This made complete sense at an intellectual level. However, although this language was adopted for a time, there were always new people coming onto the team who didn’t understand it, and training began to be a real overhead. Eventually, the language was dropped. Although it made intellectual sense to use it, it did not work at a practical level.

I am all for Enterprise Architecture – at least in spirit. I believe the role of an Enterprise Architect is exactly to ensure that the technology correctly delivers on the business needs, and is architected in such a way to enable new business changes to be implemented quickly and effectively. But I don’t think this requires a complex framework of models and requirements tools and so on. In fact, I think a strong EA edicts the minimum, but offers a loose framework that allows departmental innovation. In truth, there is nothing new about EA – it is all about doing things sensibly and remembering that IT is there purely to serve the business and not itself. All the rest of the formal EA clutter is a set of handcuffs that can hold organizations back.

Steve