Architecture Development Method (ADM) – Step By Step

Introduction to ADM
Why it is important for an enterprise to know what is the value the ADM provides to an enterprise? Why
it is significant?
Different phases of ADM?
0. Preliminary
A. Architecture Vision [Req. Manag.]
B. Business Architecture [Req. Manag.]
C. Information System Architecture [Req. Manag.]
a. Data Architecture [Req. Manag.]
b. Application Architecture [Req. Manag.]
D. Technology Architecture [Req. Manag.]
Security Architecture [Req. Manag.]
E. Opportunities and Solutions [Req. Manag.]
F. Migration Planning [Req. Manag.]
G. Implementation Governance [Req. Manag.]
H. Architecture Change Management [Req. Manag.]

Topics Covered:
- Introduction:
- Basic Principles:
- Detail of each Phase:
- Inputs, Outputs, Versioning:
- How to adapt the ADM:
- Governing piece of the ADM:
- Repository of the ADM:
- Significance of a Governance Model when you start implementing and executing the ADM?
 - Scoping constraints taking into consideration when moving ahead with architecture activities?
- How do all these pieces fit together from an enterprise architecture integration perspective?
Introduction:
- ADM is built on open standard that means it is not dependent on any tool, vendor, and
technology, etc.
- Avoid re-inventing the wheel. Don’t start from scratch. (Reuse before buy, buy before build).
- A proper and traceable alignment between business and IT
- It is based on the best practices.
- We can participate in the evaluation of the framework.
- It is tailorable to meet organizational and industry needs.
- ADM and TOGAF does not have any conflict with any other standard. It openly adopted the best
practices and supports them.
- ADM is a very comprehensive and general method.
Basic Principles:
- ADM is an iterative method and can iterate in between whole process, between phases and within
phases. We can go back and forth, skip, and repeat phases as required.
- For each iteration, new decisions need to be made or considered.
o We can iterate the ADM across the enterprise coverage.
o We can apply/iterate the ADM at what level of detail.
o We can apply/iterate the ADM at what point in time or how much time we want to give
under circumstances.
o Architectural assets (artifacts, deliverables, etc.) of ADM or other frameworks can re-use
in different iterations
- Decision should be made based on
o Competence / Resource availability
o Value accruing to the enterprise
- Every phase is validated against the current requirements of the business.
Detail of each Phase:
0. Preliminary – Foundational Phase
- Prepare the organization for the successful architecture project (at project, program, portfolio,
or capability level)
- Preparation and initiation activities for creating the architecture capability by understanding the
context of enterprise, business, or environment.
- Seek high level management commitment.
- High level scope for the architecture capability
- Establish the architecture principles.
- Establish the governance structure.
- based on you organization capacity and capability customized the framework itself
Maturity Assessment:

A. Architecture Vision  [Requirements Management]

- Based upon the architecture capability, we can decide how may iteration we need to run for
architecture vision projects either in parallel or sequentially depending on the capacity of the
organization.
- Set the scope, constraints and expectations
- Create architecture vision
- Validate the vision with the business context that sets in the preliminary phase
- Create State of Architecture Work
- Get Architecture Work approved by the stakeholders
- Can’t move forward without approved SoAW.

B. Business Architecture  [Requirements Management]

- Develop the baseline (current) business architecture by analyzing
1. Select reference models, viewpoints, and tools
2. Develop Baseline Business Architecture Description
3. Develop Target Business Architecture Description
4. Perform gap analysis
5. Define candidate roadmap components
6. Resolve impacts across the Architecture Landscape
7. Conduct formal stakeholders review
8. Finalize the Business Architecture
9. Create Architecture Definition Document

o Organization structure
o Business goals
o Business objectives
o Business functions
o Business services
o Business processes
 o Business roles
o Correlation of organization and functions
o Seek external reference models, viewpoints
- Develop the future (target) business architecture performing all above
- Identify gaps by perform gap analysis in between baseline and future business architecture
- Identify the candidate roadmap components required to fulfill the gaps
- Conduct formal review from all business stakeholder and do the required changes
- Finalize the business architecture after the required changes
- Incorporate all details in the Architecture Definition Document (DDD)

C. Information System Architecture (Data & Application) [Requirements Management]

- Perform all steps performed in the business architecture for both
o Data Architecture and
o Application architecture
- Incorporate all details in the Architecture Definition Document (DDD)

D. Technology Architecture  [Requirements Management]

- Perform all steps performed in the business architecture.
- Incorporate all details in the Architecture Definition Document (DDD)

Security Architecture  [Requirements Management]

- Perform all steps performed in the business architecture.
- Incorporate all details in the Architecture Definition Document (DDD)
- After performing phase A, B, C, D, & optional Security Architecture, define the Enterprise
Architecture for the organization

E. Opportunities and Solutions  [Requirements Management]

- Identify the major implementation projects as Work Packages
- Identify how you will run the multiple work packages either parallel or sequentially
- Determine the transition architectures as TA1, TA2, …
- Decide the approach how to want to get this done by either use existing, buy or build,
outsource, use open source, buy commercial products etc.
- Assess the priorities,
- Perform Initial implementation plan
- Set the scope, constraints and expectations
- Create architecture vision

F. Migration Planning  [Requirements Management]

- Perform cost benefits and risk analysis on Initial Implementation Plan and prepare the
Detailed Implementation and Migration Plan
- Set the scope, constraints and expectations
- Create architecture vision

G. Implementation Governance  [Requirements Management]

- Implement the Detailed Implementation and Migration Plan
 - Provide Architectural Oversight for the implementation being done
- Ensure that each Implementation project confirms to the architecture as per Architecture
Definition Document, Implementation Migration Plan as well as the architecture contract
between the implementation team and architecture team

H. Architecture Change Management  [Requirements Management]

- Provides Continual Monitoring and Change Management Process
- Any change in any phase will route to Architecture Change Management
- Governance will decide whether to approve or reject the change, or record for future
consideration

X. Requirements Management
- Involved in each phase for every iteration of all architecture projects
- Ensure that every stage of a TOGAF project is based on and validates the business requirements

How to adapt the ADM:

- Generic methodology intended for variable
o Categories
o Vertical sectors
o Industry types
- Usable with deliverables of other frameworks such as; PEAF, FEAF, DoDAF, Zachman, etc.
- It is used to modify or extend the ADM to suit specific needs

Governing piece of the ADM:

Repository of the ADM: - Inputs, Outputs, Versioning
- TOGAF defines number of inputs and output deliverables for each phase
- Use versioning for each document.
o 0.1 for minor and draft changes
o 1.0 for formally reviewed and accepted detailed deliverable

Significance of a Governance Model when you start implementing and executing the ADM?
Scoping the Architecture Activity (and Constraints) - Scoping constraints taking into
consideration when moving ahead with architecture activities?
- There are four dimension in which scope may be limited:
o Breadth (apply the method to across the enterprise or some part of the enterprise)
o Depth (level of detail like enterprise level or domain level or capability level)
o Time Period
o Architecture Domains (BDAT – Buss., Data, App. Tech.)
- Reasons to constrain the scope:
o The organizational authority of the team producing the architecture
o The objectives and stakeholders concerns to-be addressed within the architecture
o The availability of people, finance, and other resources
Enterprise Architecture Integration - How do all these pieces fit together from an enterprise
architecture integration perspective?