TOGAF ADM And The Big Bang Theory

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.

togaf adm plain

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:

togaf adm marked

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?

7 Responses to “TOGAF ADM And The Big Bang Theory

  • Thanks for this very good article which explain verywell the use of ADM. I’ve read it last year and today I am designing a global IS target and try to use the ADM. I totaly agree when you write that it is open to too much interpretation. I think that it need to be “instanciated” and it is not useable as is. the number of iteration, the detail level on each phase are key in this implementation.

    ps : when did you write this article ?

    • Hi Aireau

      Thanks for the comment. Yeah, While I understand the necessity for flexibility within the framework, the case studies could be better by being more representative of real world projects and situations.

      This post was published around April- May time this year.

    • Aireau

      I was wondering how you were progressing with your project? Any interesting feedback/war stories to tell about it?

  • Thanks to this post, I have a much better understanding of the ADM from a practice standpoint. I completely get the fact that there is no value in iterating within the tranches of phases.

    In trying to compare this to the agile software development world, would you agree that the entire initiative would be an Epic (assuming it is complex enough) and every ADM cycle is a sprint is a transition state of the architecture? User stories are the deliverables of such a transition state.

    • Thanks for the comment Kaustav.

      I use the term iteration deliberately, but I mean it conceptually rather than in practical execution. I don’t think it should be executed exactly in the way as you do in agile dev projects, but rather to gain from the same benefits.

      Iterative development is often adopted on agile dev projects where user stories, epics, etc also happen to be used. These are not mutually inclusive however. Sprints are often used with packaged agile methodologies such as Scrum (what I term “Agile” or big Agile, as apposed to agile or small agile) and denote iterations typically in a very short, timebound sense.

      Personally, I’d stay away from trying to do a direct comparison, as I’m not sure on the value and also in my experience, what people’s expectations for user stories, epics, sprints, etc equate them with set timescales (rightly or wrongly). This would mean people who were familiar with 2-3 week sprints would automatically think you can transition from one architecture state to another within that time-frame. For most architectural projects, the timescales would be way bigger.

      In addition, usually your stakeholders for Enterprise Architecture projects are usually a different audience from those in a development project (strategic versus operational) so I’d suspect it would be of very little benefit to do such a direct comparison.

      I hope this makes sense.

      • Thanks for the clarification Aireau. I understand your context of using iteration. The reason, I was using that term, was trying to relate to how we are using a agile development tool (JIRA) to do our enterprise architecture work. I know it is not the appropriate tool, but we are trying to relate our ADM cycles to the engineering project cycles.

        • Kaustav

          Yeah, I’ve had the same issues. I used Trello to do my project tracking as I found it simple, unobstrusive and flexible. JIRA tends to have you jumping through their hoops and also using their terminology.

          As for actual EA tooling, I’ve only used Orbus iServer to-date, and my experience was mostly positive. It probably lacks that project mgt stuff you are concerned with though (hence combining it with Trello


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.