Ever heard of TOGAF? TOGAF is The Open Group Architecture Forum with which architects can become a member and get certified as an enterprise architect. TOGAF subscribes to a number of EA Frameworks, but also offers an ADM – Architecture Development Method(ology). I have found the ADM a very useful and structured way of approaching EA, whether it’s just a single new solution or a complete EA programme that is required.
The components of an EA can also be summarised as follows:
– Context (basic requirements, guidelines, constraints)
– Framework(s) that enable a multi-layered EA development in stages
– Actual components (processes, systems, rules)
– Inter-relationships (links, flows, data dictionaries, database indices)
What are the typical outputs of Enterprise Architecture?
Views and models that describe the “current environment”, based on one of the EA frameworks already discussed. This is required to enable a grasp of the gap that exists considering the desired future environment (another output of EA, also described with models and perhaps the same framework). The next set of outputs – design guidelines and patterns – are used in the activities to govern IT work along the most efficient and shortest path towards the future environment.
I briefly discussed before how EA teams are typically structured, but what are some of the other roles on an EA Programme? Apart from the specific domain architects, e.g. Application, Information and Security architects, other important roles to be considered are the Architecture Sponsor (could be from within the business), any other Architecture Board members required to ensure the success of an EA programme, and – don’t forget – project/programme members, solution designers and developers. Any EA programme will not succeed if there is no buy-in from the IT Development community, especially an understanding of how and why EA governance plays a role in Solution Development.
What are some of the key Critical Success Factors of Enterprise Architecture?
– Planning the EA programme
– Developing an Infrastructure for EA (tools, frameworks, methodologies)
– Documenting the EA – current and future
– Standardisation of Design Patterns, Development Processes and Application Architectures
– Architecture Governance in place and working
– Stakeholder participation
Is SOA the same as Enterprise Architecture?
No – SOA is rather an Architecture STYLE. If BSOA is seen as the Business View of SOA, then EA = SOA + BSOA. SOA is a useful vehicle to apply re-use of solution components and govern design of components according to design patterns.
What can go wrong with Enterprise Architecture?
1. It is too much “in the face” of Business and day-to-day operational activities (message: keep EA in the background)
2. It starts anywhere but with the Business (message: Business goals should drive it all)
3. It gets launched with a “big bang” (message: Start small)
4. Work grinds to a halt because Architects expect someone else to do it
5. Communicate too little or nothing (message: Communicate small wins and achievements soon)
6. It is so thorough that it takes a long time (message: Focus on small wins)
7. It is parked (message: EA is forever evolving)
What should be the goals of practising Enterprise Architecture?
1. Successful and timely Business transformation
2. Bringing models and views together by implementing universal compatibility between them (integrating everything and using a common language)
3. Going on-line, e.g. by using a portal
4. Maintaining a balance between strategic enterprise-wide goals and the operational and tactical needs of individual business units or segments
5. Focusing on short- and medium-term Business benefits
6. Focusing on 20% of major threats and opportunities that will have an 80% impact on the Business
Architecture Governance is a challenge in larger organisations where IT is not centralised. In my experience
in such an environment there are always business units within the organisation that will want their way with
the technologies they deploy and the way they design their solutions. Compromises are possible, though. If
its technologies and designs do not jeopardise the organisation’s IT fufure, the business unit can be
“ring-fenced”. Another option could be that only certain technologies and designs are targeted for
governance, leaving the rest flexible – once again, as long as the organisation’s future is not put at risk.
Once the future state vision for the organisation’s IT and Business (with suitable principles) is in place, it becomes necessary for day-by-day design guidance to be given to development projects. This is required on 2 levels — guidelines to be employed by the business process designers, and in turn the IT solution designers. The benefit is that the entire process and system creation and enhancement effort should comply with sound practices and design methods from the architecture, rather than each step being taken as a single event with design on an ad hoc design approach.
Architecture Governance in a large organisation is not always easy, especially if IT is not centralised.