What is Enterprise Architecture about again?

Friday, February 23, 2007

I was quite confused by a recent post from James McGovern on two camps of enterprise architects, which he based on a blog post by Jeremy Miller. While Jeremy is clearly speaking of two camps of coding philosophies (never knew there was something philosophical about coding. I thought coding was a pretty straightforward thing. At least it was when I was still coding. Besides, Socrates and Aristotle would turn in their graves if they heard that something as down-to-earth as coding was associated with philosophy), James is extending it to the question "what enterprise architect are you?". The two camps Jeremy identifies are:

Camp #1: Coding is too hard, so let's not write code anymore. Model Driven Architecture, Executable UML, Business Rules engines, Rapid Application Development
Camp #2: Coding is too hard, so let's make coding easier and more productive. Refactoring tools, dynamic languages, TDD, Continuous Integration, Ruby on Rails, etc.

If we are really dealing with enterprise architecture as James suggests, we should add a third camp as far as I am concerned:

Camp #3: Coding is only a very small part of the EA picture, so let's focus not only on coding but also on other important stuff which makes that I am different from a senior developer and which justifies that I can call myself an architect. Portfolio management, IT governance, business strategy, IT strategy, etc.

I am definately in the third camp, although I have decided not to call myself an architect anymore. Like I wrote in a recent post on standardization: more and more I feel alienated from this group of professionals, even though a large part of my consulting work concerns architecture.

Too many people are calling themselves enterprise architects, while they are not at all doing architecture in the first place. I do agree that having a background in coding and the real IT work gives some architects an advantage over others, but it takes more than being a great developer or designer to be a good architect. Peter's principle applies here at this level as well. The key to good architecture is that it should provide insight to decide. This means 2 aspects are important for architecture: Insight for your audience, which should always be the business if you are claiming to be doing enterprise architecture. When you are doing software architecture, you are providing insight to your development team.
The other aspect is decide: all your efforts are worthless if you are not somehow preparing a decision that would otherwise be very hard to make. If all of your hard work as an architect is not going to end up as the foundation of decisions in your enterprise (at a level appropriate to the domain of your architecture efforts), it has been useless and a waste of time. If no decisions are taken based on the insight you have provided, you have been doing architecture for the sake of architecture. This is the most important barrier for acceptance of EA as an enterprise IT discipline: too often it fails to deliver the goods. If your audience does not "get" your architecture, it is not their fault, it is yours. It has not provided the required insight. You have not connected with your audience. The same is true for software architectures that are not correctly implemented by your development team: you as an architect are to be blamed. You were unable to provide the insight to developers to make right decisions in their coding.

That, is what I think EA is all about. James, Jeremy and others, I will be glad to hear your opinions.