1. Home
  2. Training Library
  3. Module 2: TOGAF Core Components

Introduction to the ADM

Developed with
QA
play-arrow
Introduction to the ADM
Overview
DifficultyBeginner
Duration28m
Students3
Ratings
5/5
starstarstarstarstar

Description

Course Description

This module looks at some of the concepts introduced in the last module, namely the Architecture Development Method, Building Blocks and the Enterprise Continuum. This module is supported by videos and a PDF, and is followed by a quiz to help support your understanding.

Learning Objectives

This module will cover:  

  • The Architecture Development Method  
  • Building Blocks  
  • The Enterprise Continuum  
  • Applying the Enterprise Continuum 

 Intended Audience  

This course is intended for anyone looking to understand Enterprise Architecture.  It is helpful however to have several years' experience in IT in a variety of roles, or to have an understanding of Enterprise or IT Architecture. 

Prerequisites of the Certifications 

There are no formal pre-requisites for this course.  

Feedback 

We welcome all feedback and suggestions - please contact us at qa.elearningadmin@qa.com to let us know what you think. 

 

Transcript

- The initial architecture frameworks created in the early 80s concentrated on how to understand and describe the architecture of a system. To this day, some of the most long lived frameworks, which happened to be in the defense sector are still primarily focused on this, but equally important are the activities related to creating, documenting and governing architecture. So how do you go about doing architecture well? The Architecture Development Method or ADM, describes the standard of developing enterprise architecture in the TOGAF framework. So let's drill into this. Each time a new request for architecture work is issued, a new instance of the ADM is created. Just like when a new project is started, you can say a new project instance has been created. So if the organization is very dynamic, with multiple project instances on the go at the same time, the same can happen with ADM instances. Importantly, the ADM is also iterative. The main diagram might indicate that iterations can occur across all the phases, except for requirements management. Iterations can occur between specific phases, or even within a single phase. The term ADM cycle is used to describe the act of iterating across both the ADM phases, and then more detailed steps to conduct the phase. Each ADM instance has its own scope, level of detail, time period to achieve the architecture and its own architecture assets and building blocks. No matter the location or industry sector, the ADM can be tailored and used alongside other frameworks for project or program management. Like ITIL, Agile or PRINCE2. This means the ADM is adaptable and can meet your needs and workflow, regardless of the scale or size of the system or enterprise you're architecting. There are also many integration points between the ADM and other features of the framework. Let's consider an example of iteration between phases. This diagram shows phases A to D, during the architecture process, it's entirely possible to revisit these phases multiple times. This introduces the need to ensure the architecture documentation can be versioned. And having a tool with versioning capability is useful. Initially, the high level early architecting would constitute version 0.1. But eventually, maybe after several iterations, the formal recommended architecture will be complete and could be referred to as version 1.0. All the ADM phases consist of their own steps, although with phases B, C, and D, it just so happens the steps are identical, which is to select the reference models, viewpoints, and tools, then to develop the baseline business, information security and technology architecture description depending on which of the three phases is current. Next to develop target business, information security and technology architecture description using building blocks. Then to perform a gap analysis. After that is to create and define potential roadmap components, then to resolve impacts across the architecture landscape, other building blocks. Next is to conduct a formal stakeholder review. Fully document then validate the building blocks against goals, requirements, standards, models, risks and gaps. And then the last step is to create or modify an architecture definition document and increment version if necessary. So we've covered the core of the ADM. However, it does get more support from other areas of the TOGAF framework. We'll cover these in the next video.

About the Author

In a varied career that began in 1974, John Coleshaw has trodden a relatively unusual path whereby his roles have split evenly between Business and IT. In the early 80s he was the Credit Manager for a multi-national electronics company, and at the same time built a computerised financial and credit analysis tool using the original version of the IBM PC. In the mid-80s, whilst performing the role of senior underwriter in the Credit Insurance industry, he managed the IT system, as well as developed an innovative risk analysis tool. At the start of the 90s, as a manager in a financial information company, he developed an early form of expert system whose purpose was to predict corporate failure.

His current career as an IT trainer began in 1998, specialising at the time in Object Oriented programming languages. In 2002 he started developing and delivering IT Architecture training and has now had the opportunity to meet and discuss architecture matters with over a thousand architects. The courses he trains now span both The Open Group (TOGAF and ArchiMate), and BCS.

He has a book to his name, one written in the late 80s on Credit Risk Analysis.