Practical Enterprise Architecture

I was bewildered when I first started working with Enterprise Architecture (EA). To me, so far, the subject had belonged to some strange guys working somewhere in a remote part of the enterprise. Once in a while, a decision or model came in the mail or were posted on the intranet with regards from those guys. Rarely anybody knew how to interpret the much too abstract or detailed directives, and consequently these directives were never followed. If you turned to them for some kind of advice, their advice was always delivered too late or was not applicable to the problem at hand.

The little example above is representative for a common esoteric approach to EA where only the few cult members of the EA team are able to decode or appreciate the runic messages and unworldly divinations. What constitutes a more practical and productive approach? Below are some short statements I once set up to find an alternative approach to EA.

• Facilitate the continuous change of the business (do not model the past): EA is in essence about enabling business changes via supporting the evolution of key enterprise IT assets. Therefore, the business is the primary client for EA and it needs clear coaching in strategic planning, development and production. A common mistake is to try to model everything in detail. That will turn out a never ending mission.
• Collaborate closely with the stakeholders (do not do it without power): The business and IT managers are the ones who make strategic decisions. EA should be a natural part of their discussions and decisions. But, to really make a difference EA must be something more than an interesting speaking partner. EA must be a function with a formal role in the business or IT governance organization. Otherwise, all changes must be realized by tiresome pleading and lobbying, resulting in frustration and possible burnout.
• Manage stakeholders' expectations (do not do everything for everyone): Being successful in EA is related to if the stakeholders get what they require. Because of the vastness of the EA domain and the potentially many stakeholders, there is a need to prioritize to survive. Communicating clearly and openly about these priorities and what will be delivered will gain respect and realistic outlooks. If this is not done, the risk is that nobody will be happy with the deliverables, even if they are the results of heroic efforts.
• Engage early in the process (do not wait until the bitter end): Being part of the decision process in planning (making the reasonably right things) and project initiations (making it reasonably right) creates the most business value and reduces the impact of later costly project predicaments and alterations. Coming to a project manager, with an already set timetable and budget, and suggesting major changes is seldom appreciated and fruitful.
• Coach and communicate in accordance to maturity (do not do everything "by the book"): EA is about decision support. The supporting EA should make it easier for the stakeholders to make better decisions. So, make sure to use images and metaphors that are comprehensible for the stakeholders. Use and reuse simple illustrations that convey the essence needed to build trust in the stakeholders. Realize that it is a learning process and that transfer of knowledge will require a lot of time, effort and patience. Work from the top and down in small iterations and concentrate on showing the relationships between the core business processes and IT services.
• Establish a good network with domain architects (do not do it without good friends): Good and knowledgeable colleagues are essential for making fast inquiries and qualitative indications and estimations. A lot of the EA work is about sketching out scenarios that show the big picture of suggested changes. A merger of two companies, consolidation of platforms, and the addition of new sales channels are examples of changes that will affect the existing IT assets. The network can be used for running quick workshops and brainstorming sessions which support management with the adequate information.

The above tactical guidelines may be relevant if an enterprise is new to EA or suffer from failed EA initiatives. The key point I am trying to make is that many enterprises would benefit from a more agile approach that is better adapted to the stakeholders’ needs and capabilities.