TOGAF ADM Revised

Intro

TOGAF defines its process or method in something called the ADM: the Architecture Development Method.

It is usually represented by the illustration below, with the familiar arrangement of circles around Requirements Management, which has come to be the iconic representation of TOGAF.

Waterfall mindset

The Open Group itself is clear on the ADM in that it is not necessarily a waterfall-like process (although it can be executed in such a fashion). It is supposed to be iterative and incremental, as any process nowadays should be.

The ADM is iterative, over the whole process, between phases, and within phases (see Part III, 18. Applying Iteration to the ADM)

(from The TOGAF^® Standard, Version 9.2, chapter 4.2.1)

The picture does not really help in conveying that message, since:

1. The circles are named “phases”
2. They are sequentially numbered (letters A to H)
3. The A to H phases are linked with directional arrows suggesting a flow from A to H
4. The description of the various inputs and outputs of the phases further emphasises the sequential dependency between phases (output of one is input for the next)

Mixed perspectives

ADM “phases” are quite heterogeneous.

1. Phases B to D are the actual architecture development phases, realising architectures in the different architecture domains, Business, Software and Infrastructure.
2. E and F are quite different since they focus on planning.
3. G is an altogether different beast again, since it focusses on governance, especially in relation to running implementation or solution projects. As long as implementation projects are running that are an outcome of planning in one TOGAF ADM cycle this phase is active.
4. And then there is phase H which is the least sequential of all, since it is a continuous monitoring and analysing activity with everything to do with change, inside and outside of the organisation.

Of course there is the central “phase”, Requirements Management, somehow positioned as the linking pin between all the other. In my experience this is completely fine since all work impacts requirements and vice-versa. Positioning the Requirements activities in this way is a helpful aid to maintain a focussed mindset.

Superfluous ADM phases

Two phases are somewhat problematic in my view, and those are Preliminary and Architecture Vision. They further emphasise a waterfall interpretation of the ADM.

The Preliminary phase is not actually part of the process — it instead is there as a placeholder to prepare for the process. Why include it in the ADM at all? Of course we need to do some stuff before a TOGAF cycle, iteration, or sprint for that matter, can start. But it is only confusing to include it as if it is a step or phase.

The Architecture Vision phase is the same. In a waterfall interpretation of TOGAF, sometimes referred to as “comprehensive” this phase may make sense, but again this pushes our understanding in the waterfall direction. If we interpret the various ADM “phases” as disciplines, workflows, or EA capabilities (this last has my preference), these can (and will!) be executed in parallel in whatever fashion. This will make Architecture Vision a superfluous phase altogether. It will be just some work done in some time period across different disciplines, later to be extended, to lay the groundwork resulting in a formal approval for a TOGAF cycle by the sponsoring organisation. It is then just a comprehensive ADM cycle.

A new representation

All in all this leads to the following illustration of what I believe the TOGAF ADM could be pictured in, mitigating issues I mentioned related to the waterfall suggestion of the traditional representation. By the way, this representation of the TOGAF ADM is 100% compliant to TOGAF (TOGAF is meant to be tailored/customised), it is just a different visualisation that might be more helpful.

This illustrates nicely that we have

• one triangle: three disciplines focussing on the architecture domains (Business, Information Systems, and Technology),
• and another triangle: three disciplines that are less about architecture content but more about the link with the rest of the organisation, while still maintaining the central role of the third aspect:
• requirements management.

Architecture Development

If we see the three disciplines: Business, Information Systems, and Technology, as disciplines or workflows, we can mitigate a fundamental issue with TOGAF, namely the BDAT-stack (Business-Data-Application-Technology). A few remarks in this context.

Information should be more prominently included in the Business Architecture discipline (as one of the four cornerstones of Business Architecture: Capabilities, Value Streams, Information and Organisation, as defined by the Business Architecture Guild).

It seems the Open Group already embraced this approach, and my expectation is that we will see this take form in the next release of the TOGAF standard. The 9.2 version of the standard has taken steps to include these in the Content Metamodel and the artefacts to be produced in the Business Architecture phase: Business Capability Map, Value Stream Map and Organisation Map. Information as a cornerstone Business Architecture concept is not really positioned well in the 9.2 version of the standard. It is summarily discussed in the Business Model Diagram and really should be given more depth.

The Business Architecture part of TOGAF is under intense development and The Open Group now even provides a credential specifically focussed on Business Architecture: https://www.opengroup.org/certifications/togaf-business-architecture-level1

Just in: the Open Group just published Information Mapping in the TOGAF Series Guides. This article is an important step in maturing the business architecture discipline in the ADM.

The Information Systems Architecture should no longer be separated into Application/Data. In fact both terms (Application and Data) are outdated. Data is meaningless without context, and that is precisely what we add in the concept of Information as defined in the Business Architecture as mentioned above. This discipline is about realising automated, smart, and evolving systems on the software level (as opposed to the Technology Architecture discipline that thinks about how to run all that on platforms, physical or virtual).

The Information Systems Architecture should put more focus on “mirroring” the business. As you can read in many articles on this site (for example The Mirrored World) this approach is crucial in gaining alignment with the real world. We have recently seen a “rediscovery” of this concept (although I have been writing about this since 1995) in the form of the concept of Digital Twins. Recently picked up by Gartner this is getting quite a lot of attention lately.

Trend No. 5: Digital Twin

Within three to five years, billions of things will be represented by digital twins, a dynamic software model of a physical thing or system. Using physics data on how the components of a thing operate and respond to the environment as well as data provided by sensors in the physical world, a digital twin can be used to analyze and simulate real world conditions, responds to changes, improve operations and add value. Digital twins function as proxies for the combination of skilled individuals (e.g., technicians) and traditional monitoring devices and controls (e.g., pressure gauges). Their proliferation will require a cultural change, as those who understand the maintenance of real-world things collaborate with data scientists and IT professionals.  Digital twins of physical assets combined with digital representations of facilities and environments as well as people, businesses and processes will enable an increasingly detailed digital representation of the real world for simulation, analysis and control.

(from Gartner)

The parallel execution implies that it is meaningless to do “just” software architecture. To align it with business it needs to be developed in sync with the business domains, and the business architecture in the center (see my article Business-Centred ArchiMate, or The Live Domain). I believe that this will help in mitigating the Business-IT divide.

Planning

Planning is done all over the place. To define it as a separate capability means that we can use it

1. to plan TOGAF cycles or iterations
2. to plan projects (agile or waterfall)
3. to plan doing architecture.

The difference between Opportunities and Solutions (diverging and focussing on exploring all possible approaches) and Migration Planning (converging and finalising the approach) is not clear in the current standard, and is also less applicable in more agile approaches to architecture, so why not bundle these into one?

Parallel execution

Requirements Management will remain positioned as it was.

Since we now have less of a suggestion of sequentiality, and we no longer have the need to talk about iterations of the ADM since it will be requirements that drive the amount of attention needed from any ADM discipline, and activities in any discipline can be executed in parallel with any other discipline.

Over time the execution of the disciplines can be visualised as follows (example, also showing a more or less constant resource utilisation):

This is partly inspired by how the Rational Unified Process (RUP) talked about disciplines:

Summary

To summarise, I would like to change the ADM visualisation as shown above, and change the following:

1. No longer use the term “phases” but change to “disciplines” or “capabilities”.
2. Merge Migration Planning and Opportunities and Solutions to “Planning”, which includes planning of the TOGAF ADM cycle itself.
3. Remove Preliminary and Architecture Vision and move the activities in those phases in the new structure.
4. We are then left with the following disciplines:
   1. Business Architecture
   2. Information Systems Architecture
   3. Technology Architecture
   4. Planning
   5. Governance
   6. Change Management
   7. Requirements Management