Enterprise Architecture is not Software Architecture (and it's not Technical Architecture Either)

In what I do day to day, I often get asked to explain what Enterprise Architecture (EA) is. Rather than give a long and complicated answer describing frameworks and methodologies, or processes and information, I long since learnt that it's often best to introduce it really simply. This might be by stating that EA was really the application of the discipline of Architecture, as it has evolved in the physical world of construction, into the business world of Enterprise IT. Therefore it fundamentally was the discipline of translating what 'the owner' (or the client) wants (or what they actually need), into things that can be designed and built by 'the builders'.

In many ways architecture in the physical world, and the Enterprise IT world, is the bridge between strategy and delivery. Covering the gap between the big picture of what you want or need to do (your strategies), and actually what gets done when the rubber hits the road (the delivery).

But that is just the green-field view. Architecture also includes the lifecycle maintenance view. That is, how what was originally built can be adapted, changed and maintained over its lifetime, as the context or needs of the owner change. After all, change is inevitable.

John Zachman explains this well by pointing at a wall and announcing that if you needed to change your building for some new purpose or challenge, and wanted to (for example) remove a wall, you'd have three options.
*- You could knock down the wall and see what happens. (Hmmm...)
*- You could employ engineers to spend significant time drilling holes in the wall trying to work out how it's constructed and how it can be removed. (Sound familiar?)
*- Or you could dust off the plans for the building and do the necessary calculations ... (That is if you had the plans of course ...)

But that's still not the whole of it, there's another dimension to this. The dimension of Enterprise vs Solution. If Solution Architecture is like the building and maintaining of a large (commercial) building or complex, then Enterprise Architecture is more akin to City Planning.

A City Planner has to control and guide the evolution of a City where there are many different groups of stakeholders, with mostly independent objectives and priorities, and each with its own legacies. So there are buildings already in place being maintained and extended by separate groups, each with their own objectives and motivations. At the same time there are many projects designing and building new buildings, all again staffed by separate independent groups, each with their own objectives and motivations. Then there are various shared robust infrastructures for roads, water, electricity, gas and sewerage to maintain and keep cost efficient. And finally, in addition to all of this there are all of the abstract aspects of the City that affect quality of life and require management, such as safety, community, atmosphere, aesthetics etc.

The parallels between this analogy and Enterprise Architecture in IT are simple and intuitive.
*- IT projects run in parallel each with their own business case, competing for common resources, sharing strategic infrastructures. Each needing control and guidance to ensure they strike the balance between the quickest and cheapest route for the project and it's individual business case, versus the most responsible and acceptable route for the Enterprise as a whole (looking beyond the completion of the project).

So that's a thumbnail sketch of Enterprise Architecture. Design Enterprise Solutions for new builds, and maintain design through life. Plus, design for projects to build new solutions, but also for the Enterprise making sure that all the projects play nicely together and all contribute positively towards taking the Enterprise as a whole where it needs to go.

All that explanation and there hasn't been a single mention of Business Processes, Applications, Information or Data, Software, or Hardware. Well of course they all are parts of Enterprise Architecture, that's the next level down. And precisely there is where the complication the title of this post suggests comes from. All the various IT legacies and imbalances bias what has so far in this description been a simple set of concepts.

The complication I'm referring to is that lots of the content about IT Architecture to be found on the internet is actually about Software Architecture. That's fine, and Software Architecture is a very valuable discipline (how to best design software systems and platforms), but it is only one piece of one layer of the Enterprise IT Architecture.

To make things more complicated, when you mention Enterprise Architecture to someone in Enterprise IT, for example a Programme Manager, they often assume you are talking about Infrastructure (the hardware, networks, platforms etc) and start talking about how your Technical Architecture will be very useful for their big application implementation project.

Technical Architecture is also a very valuable discipline, and certainly pretty much any project is going to need a suitable one to be successful when live, but again it is only one piece of Enterprise IT Architecture.

The point is that, apart from confusing what is Enterprise Architecture, and potentially mis-setting people's expectations of what it will deliver, it misses the fact that the discipline of EA is based around the linking of the software architecture with the technical architecture, and the applications architecture, as well as all the other 'aspects'. These very linkages are where a significant amount of the value of architecture lies. Without the linkages between the different type of architecture, there is a risk that each area becomes its own little fiefdom of technical 'best-practice', and each time has to reinvent the wheel, which doesn't help IT's credibility with the business. Indeed, the linking of the areas together holistically in one mature managed discipline, with the specifics of the Enterprise (rather than generic IT concepts), are key to making EA such a powerful approach.

For those that are interested, of course there are some very good overviews of true Enterprise Architecture approaches on the web. Being slightly biased I might point towards Andrew Macaulay's piece on EA from the first Microsoft Architect's Journal, for an example of one that goes into the next level of detail. But you can't really beat John Zachman's introductions to the subject to articulate it the best. ZIFA is the Zachman Institute for Framework Advancement where you can find many of his articles. Or even better see if you can make it to one of his seminars which you should be able to find via Google fairly easily (in Europe they're run by IRM UK). I'm sure this discussion will run and run.

Technorati Tags: enterprise architecture IT Governance