The Slow Extinction of Enterprise Architecture

The "Enterprise Architecture" community has been buzzing lately over the implosion of the Zachman training and certification industry. If you haven't seen the news then have a look at this post on the Gartner blogs site http://blogs.gartner.com/philip-allega/2010/09/01/john-zachman-is-dead-long-live-john-zachman/.
The real news is just how little impact this news had. In spite of a proliferation of blogs and online media reporting on IT and business related matters this news is so obscure and irrelevant to mainstream industry it barely  registered a few posts.
 
Outside of a few consulting companies, analyst organisations and self serving professional associations the idea of Enterprise Architecture is virtually extinct. And the advent of cloud computing is likely to hammer in the final nail. The only question is how architecture practitioners can relaunch their profession to be more relevant for business as technology platforms and applications become increasingly commoditised.

I expect that most Enterprise Architects would object to my prognostication of doom. Of course there are some active web communities, but in this age of  mass social networking the success of a profession is hardly assured by a few hundred (or even a few thousand) active practitioners.  One of the  paradoxes of social networking is that  in spite of the fact that communities are so publically open and accessible the narrow focus of many groups can tend to insulate members and reinforce parochialism.

Consider the broader picture. If we believe the objective of Enterprise Architecture is to help  business develop strategy and governance then consider how strategy and governance is usually taught. The answer of course is in business schools, in MBA programs. How many traditional MBA programs cover Enterprise Architecture as a topic, let alone a subject or unit? Practically none, with notable exceptions of MIT and U.C. Berkeley. Granted there are Master Programs that offer  combined MBA and IT Architecture programs, but these degrees are targeted at IT professionals rather than broader business disciplines. Tertiary education's meagre interest in EA seemed to have peaked around 2004, and has subsequently  waned in favour of far trendier topics such as sustainability.

Now I'm not suggesting that interest amongst academia is either an infliction or a cure, but merely a symptom. No matter what you may think of the validity of business schools it is fair to recognise that they do reflect current business trends, irrespective of whether they are trend setters or merely trend followers. And once a particular fad passes it is virtually unknown for them to return to prominence.
So why has EA fallen out of favour with academia? It seemed like such a good idea, and academia is always more fascinated by good ideas rather than practical application. My theory is that the reason EA has no traction in business is because the entire practice has never advanced beyond IT-based systems thinking. And the reason why EA cannot break the shackles of IT systems thinking is because most of the practitioners have a background in software development.

The question is why software development has become the core pillar of Enterprise Architecture practitioner development? Why not broader IT functions such as operations, infrastructure or IT management, which are much closer to the business and IT users to begin with? I mean, seriously, how could anyone believe that EA can gain traction with broader business disciplines when it invents a language such as Archimate intending it to be a common language?  Do we really expect the accountants and lawyers  to find value in learning Archimate? There is such a systems development focused myopia in this approach that it would be incredibly funny if it wasn't so tragic.

The justification for developers being critical to the strategy setting process is explained beautifully by David Chappell in a couple of TechEd 2010 presentations on innovation and architecture in IT.

http://www.msteched.com/2010/NorthAmerica/ARC203

http://www.msteched.com/2010/NorthAmerica/DPR202

Chappell argues masterfully that business strategy is focused on gaining competitive advantage. And competitive advantage is based on gaining unique capabilities. And unique capabilities require unique systems. Therefore in order to execute a competitive business strategy you need to develop custom software.

Of course I am oversimplifying Chappell's presentations, and they are truly brilliant and insightful talks. However the underlying logic of the argument is pretty much as I've presented it if you really drill into it. The talk also touches on the subject of the proportion of IT budgets dedicated to development as opposed to operations, something that Microsoft has been harping on about for years. Of course for most organisations the proportion is irrelevant, it is the total amount spent on technology that counts. But I digress.

The fallacy in the strategic advantage argument is that unique capabilities include more than just technical innovation. Capabilities such as flexibility, low-cost, speed to market and commoditisation can provide significant competitive advantage, and would all favour a packaged software approach. It's not just about scale and time to market, otherwise the other 95% of companies would not exist.

There is nothing particularly insightful or controversial in this observation. Nicholas Carr once wrote that IT Doesn't Matter. Of course it does matter, and there will continue to be strategic opportunities that arise from improving IT capabilities for the foreseeable future. It's just that it doesn't matter as much as most Enterprise Architects seem to think. We are walking a tightrope between IT innovation at one end and cost saving at the other, while ignoring all other  capabilities that deliver business value.

As business starts to move technology capabilities into the cloud the role of the Enterprise Architect "strategist" diminishes even further. The cloud has the potential to provide both IT innovation and business cost saving in a standardised and commodity package, free from the strategic delusions of Enterprise Architects. Of course the demand for technology architects with skills in integration and cross enterprise collaboration will become more critical. The successful architects of the future will include specialised technologists or broad business technology generalists. I suspect there will be no place for practitioners who specialise in "Architecture" as a discipline.