Monday, January 15, 2007
A contrarian perspective on enterprise architecture...
Rainy Sunday in his blog asked if EA is just a nice "framework" for non-technical folks to understand?
I would first like to challenge how the question is asked. First, you really can't put the words non-technical and understand in the same sentence as if you are a contrarian you would be of the perspective that non-technical folks may buy-in but will truly never understand.
My second thought is that the four step process you outlined is pretty accurate for folks within the Federal Government who practice enterprise architecture as the only thing they have accomplished is creation of lots of documentation that no one will ever use. This same pattern is sometimes found in corporate environments who hire insulting firms to also do enterprise architecture. Many IT executives haven't yet figured out that a consulting firm that offers enterprise architecture services can't really do enterprise architecture for you. It is something you have to do for yourself.
Several additional thoughts says that real EA starts with more focus on people, then process, then tools in that order. EA must address cultural issues before anything else. One of the bigger cultural things that should be on the plate of every EA is how to encourage change. If you simply document and run around presenting them, then shit happens. EAs that do their jobs understand that working anything is more important than comprehensive documentation and therefore need to encourage a culture where shift happens.
Of course there are other dimensions of EA that need attention. For example, how to you encourage innovation? How do you recognize top talent and reward them appropriately? How do you consolidate servers, applications, services and so on. All of these things require more than just documentation. They require thoughtful detailed analysis of which can be performed only by a select few.
The one thing that I will say that EA definetely is not is the practice of distilling things down to ordinary understanding. This common practice is a trap. In the same way, you wouldn't expect someone to attend a major university for their MBA to have the entire subject matter presented in five Powerpoint bullets, you should never set the expectation that all the work of EA is to take hard things and make them easy. Hard things are always hard. Respect this notion.
Staying true to my own advice, I can honestly say that it is difficult at best to explain enterprise architecture in a single blog, a single analyst report or even a single book. If you find someone who believes they can, then run in the opposite direction because while the label of enterprise architecture is present, they are really giving you something else...
| | View blog reactionsI would first like to challenge how the question is asked. First, you really can't put the words non-technical and understand in the same sentence as if you are a contrarian you would be of the perspective that non-technical folks may buy-in but will truly never understand.
My second thought is that the four step process you outlined is pretty accurate for folks within the Federal Government who practice enterprise architecture as the only thing they have accomplished is creation of lots of documentation that no one will ever use. This same pattern is sometimes found in corporate environments who hire insulting firms to also do enterprise architecture. Many IT executives haven't yet figured out that a consulting firm that offers enterprise architecture services can't really do enterprise architecture for you. It is something you have to do for yourself.
Several additional thoughts says that real EA starts with more focus on people, then process, then tools in that order. EA must address cultural issues before anything else. One of the bigger cultural things that should be on the plate of every EA is how to encourage change. If you simply document and run around presenting them, then shit happens. EAs that do their jobs understand that working anything is more important than comprehensive documentation and therefore need to encourage a culture where shift happens.
Of course there are other dimensions of EA that need attention. For example, how to you encourage innovation? How do you recognize top talent and reward them appropriately? How do you consolidate servers, applications, services and so on. All of these things require more than just documentation. They require thoughtful detailed analysis of which can be performed only by a select few.
The one thing that I will say that EA definetely is not is the practice of distilling things down to ordinary understanding. This common practice is a trap. In the same way, you wouldn't expect someone to attend a major university for their MBA to have the entire subject matter presented in five Powerpoint bullets, you should never set the expectation that all the work of EA is to take hard things and make them easy. Hard things are always hard. Respect this notion.
Staying true to my own advice, I can honestly say that it is difficult at best to explain enterprise architecture in a single blog, a single analyst report or even a single book. If you find someone who believes they can, then run in the opposite direction because while the label of enterprise architecture is present, they are really giving you something else...
