ADM is probably the most important part of the TOGAF framework. It is core to TOGAF and is referred to throughout the TOGAF Standard. The ADM is a method for developing and managing Enterprise Architecture projects. It has eight phases that are one after another worked on. In addition, the Architecture Development Method suggests a couple of possible cycles and iterations. Each phase has an objective, an approach, inputs, outputs, and is broken down into more detailed steps. Inputs are always developed in one of the earlier phases and often in the phase just before the current one. Also, every phase provides concrete outputs that the following steps use as input. All phases are named from A to H. In addition, the ADM has a requirements management phase in the center of the circle.

 

 

 

The ADM has the following steps:

– Preliminary Phase: Consideration and management of everything that has to be done before the actual development method can start. This includes for instance how the ADM should exactly look like, what tools should be used to support the project (e.g. which enterprise architecture tool should be used for modelling?), and assessing and managing budget and resources.

– Architecture Vision (A): The vision provides the overall scope of the architecture work. Therefore, the vision is defined, constraints and expectations are assessed. Also, stakeholders are determined and approval from them to start the architecture work is requested. In this phase, the Statement of Architecture Work is created, which is further enhanced and elaborated in the subsequent phases.

– Business Architecture (B): The Business Architecture usually deals with processes, business capabilities, or user journeys. Here, the As-Is and the To-Be of the business architecture is defined and the results are used to amend the Statement of Architecture Work from the Architecture Vision phase. The structure of the phases B, C, and D are alike.

– Information Systems Architecture (C): The Information Systems Architecture includes applications and data architecture. Here, the As-Is and the To-Be of the data and applications architecture is defined and the results are used to amend the Statement of Architecture Work from the Architecture Vision phase. The structure of the phases B, C, and D are alike.

– Technology Architecture (D): Technology Architecture includes the technologies that are underlying the application architecture, such as servers, middleware, and clients. Here, the As-Is and the To-Be of the technology architecture is defined and the results are used to amend the Statement of Architecture Work from the Architecture Vision phase. The structure of the phases B, C, and D are alike.

– Opportunities & Solutions (E): In this phase, the architectural pieces of the previous phases are brought together and analyzed according to their opportunity to improve the architecture and how possible solutions could look like. Those are called solution architectures. This is also the phase in which dependencies, benefits, and costs of the potential solutions are assessed and where the decision for a particular solution is taken if there are several possible choices. Lastly, it is the Opportunities and Solutions phase in which an overall implementation and migration strategy and plan is drafted, which serves as major input for the next phase.

– Migration Planning (F): What has been assessed in high-level in the previous phase, is now done in more details. Therefore, dependencies and timelines are used to detail the migration and implementation strategy into a detailed plan. This also includes all other aspects of migration planning, such as planning the go-live, considering current solutions and contingency plannings, as well as cultural impacts.

– Implementation Governance (G): The governance phase deals with architectural contracts and committee decisions. Governance is typically ensured via regular governance body meetings, such as an “Implementation Governance Board”. The major goal is to ensure that the project development conforms to the architecture.

– Architecture Change Management (H): This phase addresses the continuous monitoring of the progress and especially of changed or adapted requirements, constraints or other circumstances.

– Requirements Management: This phase is not part of the actual cycle but is positioned in the center of all phases. It ensures that all ADM phases consider the corresponding business requirements.

The ADM ensures that an architect can address all architectural areas in a structured manner.

 

ADM iterations

The ADM is structured in a way that it supports several iterations of either the whole method, a couple of phases, or a single phase. In particular, the iterations can be the following:

1. The overall iteration passes through all eight ADM phases. Starting at the preliminary phase, moving on to the vision phase (A), and ending at the Architecture Change Management Phase (H). After that, the iteration should restart again with phase A.

2. There can also be iterations around a set of phases, such as an iteration for the architecture context, which includes an iteration of the preliminary phase and the vision phase (A). Another common iteration around a set of phases is the architecture definition iteration, which includes the phases in which the actual architecture for each layer is defined. This is done in the phases Business Architecture (B), Information Systems Architecture (C), and Technology Architecture (D). Other common iterations include the transition planning iteration including Opportunities and Solutions (E) and Migration Planning (F), as well as the Architecture Governance Iteration including the phases Implementation Governance (G) and Architecture Change Management (H).

3. Last but not least, an iteration can also just include a single phase. This can be the case if a project has a broad scope and requires an iterative approach within single phases.

 

TOGAF highlights that the ADM should not just be taken and applied as it is. It should rather always be validated whether it has to be adapted to the specifics of an organization. Although this is a valid point and it puts some discussions into perspective, I still believe that the standard ADM, as defined in the TOGAF Standard, should be adapted. Although I do not proclaim that my version is the best version for all, I believe that it generally has a better fit as a starting point for organizations.

 

What would I adapt?

What I do like of the ADM is that it strongly promotes to think in iterations and cycles. The ADM is much older than most agile approaches, yet, it already considers an important aspect of it. Also, the overall approach to improve something is quite straight-forward. If you want to change something, you need to know where to start and you need to be able to measure what you do. This seems alright and timeliness to me.

What I do not like of the ADM model is the separation of the architecture into old-fashioned layers. In the beginnings of IT, there was a large gap between the IT and the Business Departments. Also, there were fewer techniques that helped to align both worlds. Nowadays, there is a strong emphasize on business capabilities, user journeys, customer-centric views and other concepts. It therefore seems just right to elaborate a bit more on the business architecture phase (B). Some artefacts of a business architecture that should be considered are mentioned in this article.

Another change that took place in the last 20 to 30 years is that the importance of data that is transferred between different systems, applications, and ecosystems has strongly increased. Moreover, there is a broad scope of approaches and tools that address either the application landscape of a company or the organization´s data. Both are very different topics nowadays that should also be emphasized accordingly. In the current ADM, however, applications and data are both part of the Information Systems Architecture (C). The ADM should therefore change in such a way that this phase is separated into two different phases: One to manage the architecture of the application portfolio and its lifecycle and one to manage the data architecture including data models, master data, and interfaces.

Next, the ADM has been developed in a world in which the Internet was something new and where there was very little cyber security threats and only a few areas that architecture could do in order to block attacks or mitigate their effects. Nowadays, however, security and especially cyber security must be at the forefront of each new architectural design. Technologies such as the cloud, trends such as digital ecosystems and partnerships with many different third parties have led to a tremendous increase in possible risks and ways to attack. In order to consider this fundamental change, it should also be reflected by an additional ADM phase called Security Architecture (between phases D and E).

Lastly, if you have already some experience with the Architecture Development Method, you might have noticed that many inputs, outputs, steps, and artefacts sound a little bit outdated nowadays. If you grew up using TOGAF, this might not be the case for you. However, from today´s perspective, there are quite some terms that could be revised in order to facilitate the understanding and interpretation of the artefacts mentioned. In the end, this would very likely increase the usability of the ADM! In this article, I talk more about adapting Enterprise Architecture Frameworks to today´s environment.

Are you using the Architecture Development Method or an adapted version of it within your organization? What have been your experiences with it? Feel free to use the comments section below to share your experiences!