Does SOA fit into old TOGAF ADM?
TOGAF 9.0 has preserved the Architecture Development Method (ADM) from previous version. This confirms that service orientation is still not adopted in TOGAF because service orientation changes the method of constructing enterprise architecture. To be fair, we have to admit that new version includes a large mapping table explaining what has to be done for SOA following old ADM. Unfortunately, this does not really help proper SOA positioning in the Enterprise Architecture. The SO concept and principles demand serious revision of the TOGAF 8 method of architecture development while represented mapping table seems to aim to the balance of interests between business-led and developer-led 'SOA' camps.
In particular, it is not clear why the ADM has a step 'G' - the Implementation Governance, but no step for Architecture Governance. Also, it is not clear why step 'E' - Opportunities & Solutions (which defines the characteristics of the change to be made) combines possibilities with resolution, but there is no step for Analysis. We should not forget that ADM represents sequential phases of the architectural method, and if Opportunities situate after Business or Technical Architecture but before implementation aspects, it applies to the implementation first and only on the next spiral cycle touches Business and Technical Architecture. Thus, would not it be logical to combine Opportunities with Analysis and put Solutions at the end of the analysis process? If we take this suggestion and position Opportunities & Analysis step right after step 'A' - the Architecture Vision, this may create a logical path through the Business Architecture (step 'B'), Information System Architecture (step 'C'), and Technology Architecture (step 'D') to step 'E', which becomes the appropriate step for Solutions.
Some time before TOGAF 9.0 was released, The Open Group made an announcement about SOA/TOGAF Practical Guide project stating: 'The project is bounded by the current version of TOGAF 8. The intent is to provide "preliminary phase adjustments" to TOGAF. The focus will be on phases A-D of the TOGAF Architecture Development Method (ADM), providing the required views, attributes, artefacts, and process change descriptions.'
This sounded like a great idea but, as appears, it was just another example of putting the cart before the horse. We should have learned by now that in modern enterprise culture SOA must start with governance and not with architectural solutions. After all, the foremost subject of governance is the architecture itself. On the one hand, the architecture vision should be compliant with the governing policies and regulations, and on the other hand the vision contributes to the governance changes. In other words, governance has to be changed first so that it can give the 'green light' for the rest of the architecture, i.e. it would make more sense for SOA/TOGAF Practical Guide to start with 'G' instead of 'A-D'.
Applying Service Orientation Paradigm to the enterprise architecture, we recognise following constraints:
- Opportunities and Analysis contribute to Architectural Vision and vice versa;
- Architectural Vision does not change every time the Architecture changes;
- Governance regulates the Architecture development process.
In the ADM diagram inherited by TOGAF 9.0, it is not possible to place all ADM elements into a flat pane in the presence of SOA. The modified ADM becomes a three-dimensional structure with cross-dimensional relationships and influences. It is not a simple sequential flow around a circle any more. The diagram now has the shape of a pyramid with the SO Paradigm on the top. The next layer comprises Architectural Vision, Analysis & Opportunities, and Architecture Governance steps, and the remaining ADM elements form the bottom of the pyramid (where Solutions replaces Opportunities & Solutions).
Is such diagram too complex for the architects? I may be wrong, but I see a reasonable non-equivalence in the A-H steps in the ADM of TOGAF 8, especially when SO is added to the picture. Adding a third dimension increases complexity but reflects different priorities and makes the whole picture more comprehensive. The diagram reflects the fact that for several years we have understood the special roles of Enterprise Architecture and cross-LOB Solution Architecture. Enterprise Vision, Analysis, and Governance drive changes dictated by the external environment through different areas of architecture, related solutions and realisation (low level design).
If we are serious about realising service orientation in the Enterprise Architectural Framework, its Architecture Development Method has to address the dynamism of service orientation. The Framework has to distinguish more clearly between the roles of influencing, driving and following phases in the ADM. The pace of changes in modern external environment does not leave much time to Enterprise Architecture for correcting the roles in the architecture development process 'on the fly'.
(for Part 3, click here)
Leave a comment