This post tackles a common assumption of the TOGAF Architecture Development Framework (ADM), and suggests a more practical approach that is familiar to those with a software development background.
For those not intimately familiar with the TOGAF enterprise architecture framework, the ADM is a core component which prescribes a development methodology for architecture projects. While this methodology itself is quite in depth, the ADM methodology diagram (shown below) is a good overall starting point.
Without going into too much detail about the methodology, the breakdown is commonly perceived a bit like this:
- the first 2 phases (Prelim & Architecture Vision) are about establishing your architecture practice and setting up your architecture initiative (programme of work)
- the next 3 phases (Business, Information Systems and Technology Architectures) are about capturing the baseline architecture (as-is), analysing this, and finally designing the target architecture (to-be) from the perspectives of business, applications & data and infrastructure respectively.
- the next 2 phases (Opportunities & Solutions & Migration Planning) are the implementation planning phases
- the last 2 phases (Implementation Governance & Architecture Change Management) deals with the execution and management of the suggested architecture changes
- and last but not least, Requirements Management is not a cyclical phase but at the centre of the the full methodology where any decisions taken at during any phase of the initiative can be measured against the requirements of the initiative.
For a more descriptive, technical explanation, see here.
The Open Group’s documentation goes to great lengths to state that this methodology is iterative, and at any point (typically via the requirements, hence why Requirements Management phase is at its epicentre) you can return to an earlier phase and reiterate through. While this is true, the typical iterative approach I see and read about online is best demonstrated by this diagram:
Now what typically happens is that iterations are contained within these tranches of phases. For example, you may iterate through phases B, C & D multiple times in order to establish baseline, transition (1..n) and target architectures, and then move on to iterate multiple times round the transition planning phases next and so on.
Based on the bulleted descriptions I provide above, it is easy to see why this is a common approach.
Personally I think it is also the wrong approach and here are the reasons why:
Disciplines Not Feedback Loops
Sure, the groupings are logical but only because the activities are in the same discipline. I use discipline here deliberately because it suggests similar behaviour but not timing or process order. (Actually come to think of it, Phase is perhaps a bad name within this methodology as it implies process order for some.) Grouping these phases as iteration cycles here is a complete a misnomer.
By iterating through subsets of these phases before then moving on to the next cycle we are making the same mistake software developers made for many years by intertwining the disciplines of the software development lifecycle with the linear, sequential steps of the waterfall methodology.
Now this is a big statement, and so I’m going to break it down to try and justify it.
1 – The Iterative Cycles Just Don’t Make Sense
Taking any of the tranches of phases and then cyclically iterating through these just doesn’t make sense.
Why would working through the architecture phases for example and then iteratively repeating these benefit anyone? Sure, you will go through the cycle of business – information systems – technology at least twice for baseline and target architectures, but repeating the phases are not necessarily iterative cycles but the logical steps of gap analysis.
With the transition planning cycle, why anyone would iterate through identification of solutions and opportunities and then plan implementation projects for these solutions and opportunities only to go back to identifying the solutions and opportunities again is beyond me.
The whole point of iterative cycles is to incorporate the feedback learned during subsequent phases. You are not going to learn much about the business architecture by mapping out the infrastructure or applications architectures. Similarly, you are not going to benefit by planning your architecture migrations and then going back to review for opportunities and solutions.
2 -The Big Bang Theory
The ADM diagram incorporating the suggested iterative cycles also has a key term which I think nicely summarises my main issue with approaching architectural initiatives in this way – “Architecture Delivery”. The name suggests that you deliver the architecture first, and then you move on to the next stages to plan and implement. This is tantamount to upfront design.
The difference is this is design on an architectural level, where the stakes are higher and the mistakes are more expensive.
This is where I think The Open Group are culpable in this misunderstanding. While TOGAF states that you should tailor your process for your environment, I don’t think they do enough of a job of emphasising this, especially when it comes to the architectural plateaus of baseline, transition(s) and target. By presenting the ADM in the official TOGAF documentation is such a way that you tackle all architectural plateaus together, almost encourages this upfront design approach.
An Alternative To The Big Bang Theory
OK, so the abdication of thorough guidance (masquerading as flexibility of approach) leaves the framework open to too much interpretation. So how should architecture initiatives be tackled exactly?
Well, for what its worth what comes next is my approach (again, to those from a software development background this shouldn’t really come as a surprise):
Taking all phases of the ADM together, I think executing sequentially through the majority of these phases before iterating back round and repeating the full cycle as many times as required is a preferred approach.
Of particular note however, are the following phases
Preliminary & Architecture Vision Phases
Per architecture initiative, I can’t see why the Prelim or Architecture Vision phases need to be iterated more than once. Sure every initiative, whether at strategic, segment or capability level should go through these phases, but there is very little value in doing so within an initiative. If the scope or vision or the initiative were to change, the goalposts have moved and as such, I’d suggest it was a complete rethink of the initiative itself and therefore a reboot of your programme of work.
Business, Information Systems and Technology Architectures
On the first cycle of the ADM these architectures would be captured and mapped for the baseline (as-is) architecture. Thereafter, each cycle would focus on design of the next transitional architecture only, iterating through cycles (perhaps multiple iterations per transitional plateau until the target architecture was reached.
Taking this approach, my execution diagram would look like the following:
This approach provides the following (familiar) benefits:
- Obtain valuable feedback on the architectural changes once transitional architectures are in place before iterating again. This allows the incorporation of this feedback to be factored into the subsequent architectures.
- Learn valuable lessons through the actual execution of the architectural cycle. These lessons (note these are not architectural lessons but methodology, planning, implementation, governance and change management techniques) can then be learned before repeating the full cycle again, increasing your chances of success.
- By executing through the implementation of a transitional architecture before designing and planning additional transitional and target architectures means that your enterprise can benefit from improvements way earlier.
- By rolling out a transitional architecture you may find that the feedback from your enterprise is that this architecture, while originally transitional, is actually fit for purpose and no additional architectural transitions are required. This avoids further architecture design, planning and implementation, reducing the effort, cost and risk.
As I say, this is my take on this. Any feedback on this approach is welcomed. What are your war stories on executing architectural initiatives following the ADM?