1. Home
  2. Training Library
  3. Module 3 : Implementing the ADM

ADM Intro and the Preliminary Phase

Developed with
QA
play-arrow
ADM Intro and the Preliminary Phase
Overview
DifficultyBeginner
Duration26m
Students2
Ratings
5/5
star star star star star

Description

Course Description 

This module takes a deep dive in to the different phases of the Architecture Development Method, focusing on the objectives and approaches to each of the 9 phases. 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  
  • Preliminary Phase  
  • Phase A: Architecture Vision  
  • Phase B: Business Architecture  
  • Phase C: Information Systems Architectures 
  • Phase D: Technology Architecture and Foundation Architecture  
  • Phase E: Opportunities and Solutions and Planning Techniques  
  • Phase F: Migration Planning and Techniques  
  • Phase G: Implementation Governance  
  • Phase H: Architecture Change Management  
  • ADM Requirements Management 

 

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

- Now that we've covered the assets and resources available to the architect, here is where we finally spend some time looking at the ADM and it's used in the TOGAF framework. At the foundation level, we'll concentrate on the objectives and approach for each phase. In this video we'll quickly review the ADM, consider briefly the documents used in the ADM known as deliverables, also looking at the preliminary phase. We've already looked at the full ADM before, it's represented by the crop circle image. So, we'll just have a quick recap. The ADM is divided into nine phases with all, bar one, interacting with requirements management. Here's a quick run through the phases. The preliminary phase initiates the architecting effort. It sets the context for the architecting effort by understanding organization context. Phase A is where the architecture vision is created and approved by the sponsor. Phases B, C, and D are the business information system and technology architecture phases where much of the work on target building blocks is done. Phases E and F are the opportunities and solutions and migration planning phases, both of which are concerned with planning the eventual implementation of the architecture. Phase G is where capabilities get built, or longer term strategic architectures are implemented, all subject to implementation governance, and finally, phase H is where changes are initiated and managed. Throughout these phases, documents called deliverables are produced, updated, and reviewed and then stored in the architecture landscape. They're regarded as contractual or formal work products and are used to capture many items of information, artifacts, building blocks, and migration plans to name a few. As we go through the phases, the most important deliverables will be highlighted. Let's look at the preliminary phase. It has two main objectives. The first is to determine the architecture capability desired by the organization, and the second is to establish the resultant architecture capability. Let's cover what needs to be done to meet these objectives. So, objective one, determine the architecture capability desired by the organization. Put simply, you need to understand the organizational and business environment, which parts of the organization are going to be included, what other frameworks we need to work with, and possibly the degree of maturity, which in this case is a measurement of how well you adopt the key architecture processes on a scale of zero to five. Objective two is to establish the resulting architecture capability. This means establishing the organizational model, comprising your team, scope of organizations covered, budgets, and constraints. The governance processes, the architecture principles, and finally, what approach and tools you'll use to capture architecture information and describe it to the stakeholders. As an architect, you will need to understand the organizational context which includes the commercial model for enterprise architecture activity, as well as the enterprise drivers and strategies. You'll also need to know who the main stakeholders are, as well as the organizational culture, skills, and capabilities. Understanding the context also requires knowing current architecture processes, and what's in the baseline architecture. Next, you'll need to establish what requirements for architecture work exist. These will provide an indication of the measures the architect can use to judge the effectiveness of the strategic architecture. Then, you'll need to define the architecture principles. We'll look later at a technique for doing this. The resultant principles will be captured in deliverable, simply called architecture principles. You'll have to understand what management frameworks are used within the enterprise. These frameworks could include Prince2, ITIL, or Agile. You'll also need to define the relationships between those management frameworks. A valuable diagram is produced in the framework that shows how enterprise architecture sits in the middle of other operational areas. Business planning, operations management, project management, and solution development. Much of the interactions with these areas will most likely take place in phases E to H. Finally, you'll need to evaluate the enterprise architecture maturity, and that's it for this video. Next, we'll be looking at Phase A, architecture vision.

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.