Thursday, November 27, 2008

Enterprise Architecture?

Now the reason why there is a question mark at the end, is not because I don't think Enterprise Architecture is not a worthy field in the IT landscape. The reason I am writing this article is to "vent my spleen" on the way that organizations "apply" Enterprise Architecture (or at least what they advocate as Enterprise Architecture). And, yes I know there is a maturity model, but I do expect that as soon as organizations start introducing an EA, they will steadily climb up the ladder of EA maturity.

Now I'm not sure that it is the "resistance of the organization" or the "incompetence of enterprise architects", both or just due to the fact that "EA is too hard to apply" in most organizations. I can't judge the truth of this matter, because I am not an Enterprise Architect (although it is my ambition to once fill that role), nor did the management of the organizations that I have worked in to date explained their "EA goals" to me (or my fellow "staff").

What I have found organizations call EA, is generally a whole lot of "Hot Air" and "No Substance".
Expressions such as:
- We are aligning IT to the Business
- We are establishing governance
- We are trying to get high ROI
do NOT convince me that there is an EA.

Usually, when I ask for at least an outline or a high level excerpt of the EA, I am told, that this cannot be dissiminated due to "high confidentiality". This really makes me wonder how an organization can achieve their "strategic IT direction" without disclosing to the people who will make it happen, what that direction IS. Frankly, it is like the captain NOT giving the crue any idea where they are going, but expect them to brief the passengers on this very same topic.
"Ladies and Gentlemen, this is your purser speaking... We welcome you to our flight to... well, don't know that yet, but the captain knows..."

I believe that if the strategic IT direction contains Business Secrets, than it cannot be the IT direction... frankly, it cannot even be a Business Direction.

Funnily enough, many (unfortunately not all) organizations that I have worked in, thoroughly cover the Strategic Business Direction. This makes me wonder even more how it becomes impossible to even outline a high level Strategic IT Direction as general IT Strategic Goals and Guidelines to achieve the Strategic Business Direction that is well known.

I have even seen an organization, where on my question where the Enterprise Architecture was documented so that I could make my Solution in line with it, the Enterprise Architect (yes you have read it correctly, not an IT Manager or a Project Manager or some other Manager, but the Enterprise Architect) handed me a tabulized list (a 1 pager) with technologies that were approved.

Now... how scary is that?

To this end, as an Application Architect, I am writing this blog, backed by my understanding of what an Enterprise Architecture should entail, so that the professionals that need to REALIZE the EA, know exactly how to define, build and implement their solutions.

1. A Mission Statement
An Enterprise Architecture MUST have a mission statement. This is a very short excerpt that summarizes the Strategic Business Direction, and outlines which type of IT solutions will be key to achieving this direction

2. An Architecture Landscape
A Graphical representation of all the high level IT components (i.e. applications running in networks on hardware) and their inter-relationships that make up the IT infrastructure. This graphical representation should be accompanied by a tabular data-dictionary that map each system to a set of Strategic Business Goals and highlight the level of importance in achieving the related goal

3. A "Gap Analysis"
An analisys of which Strategic Business Goals supporting components have been fully realized by IT, which ones have been partially realized, and which ones are yet to be realized.

4. A "Grand Plan"
That outlines which existing components will be reused, which components will need to be obtained (purchased or built) in order to achieve maximum capitalization on the Strategic Business Direction with the highest level of ROI possible in an agile way so that it can suit the "ever changing needs of the business".

5 A "Technology Plan"
A list of technologies that will be used within the organization in order to achieve the "Grand Plan", as well as a process for deprecation of existing technology and introduction of new technology (be it either hardware or software)

6 A "Tracability Matrix"
This would be a glorified checklist that identifies the Strategic Business Goals in association with the Strategic IT direction and how progress to meet these Strategic directives can be measured.

It is important that from a "high level", ALL IT STAFF, ALL MIDDLE and SENIOR MANAGEMENT and KEY BUSINESS STAKEHOLDERS are aware of the Enterprise Architecture.

I also believe that the road to a mature EA starts with:
- Understanding Strategic Business Needs
- Creating Strategic IT Awareness

Well, those were my 2 cents worth...

3 comments:

Prasad Chitta said...

Good one.
I have a similar Blog: http://technofunctionalconsulting.blogspot.com/
Please check it out...

Mohan Babu K said...

Brian,
I agree with your conclusion that that the road to a mature EA starts
- Understanding Strategic Business Needs
- Creating Strategic IT Awareness

This said, it is a Road to somewhere, and the governance of traffice on it is equally significant.

PeterM said...

Brian

A couple of quick comments.

Ask 12 people what EA is and you will probably get 15 different answers!!

In the work that I have been doing with clients, I split the EA consideration into two broad domains - business architecture and technical architecture. Your list seemed to be predominantly focussed on the technical architecture.

By establishing business ownership of the business architecture, a number of outcomes can be achieved:

a) Business can evaluate the extent to which the way they do business fulfills their business objectives and strategies
b) Business can start to articulate business changes, independent of the system changes they might need to support their intended business changes
c) The business architecture provides a better basis for assessing the completeness and suitability of your technical architecture