TOGAF’s ADM

TOGAF’s ADM consists of the following stages:
- Preliminary phase (deciding the framework to be used and principles, getting commitment, planning)
- Architecture Development (vision, Business architecture, Systems architecture, Technology architecture)
- Business Transformation planning (solution opportunities and options, migration planning)
- Architecture Deployment (governing the implementation)
- Architecture Realisation (managing change)

TOGAF

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.

EA Components

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)
- Models
- Architects

Outputs of EA

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.

EA Programme Roles

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.

EA Critical Success Factors

What are some of the key Critical Success Factors of Enterprise Architecture?
Primary CSFs:
- 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
Secondary CSFs:
- Architecture Governance in place and working
- Stakeholder participation

What about SOA?

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?

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)

Goals of EA

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

Governance Challenges

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.