Architecture Development Method (ADM)

The Architecture Development Method (ADM) is right at the heart of TOGAF and comprises a detailed step-by-step process for developing or changing an enterprise architecture. Much of the TOGAF documentation covers the ADM, and everything else in TOGAF can be mapped back to the ADM. [1]

Key Points About the Architecture Development Method (ADM) [2]
The ADM is iterative over the whole process, between phases, and within phases; for each iteration of the ADM, a fresh decision must be taken on:

• The breadth of coverage of the enterprise to be defined
• The level of detail to be defined
• The extent of the time horizon aimed at, including the number and extent of any intermediate time horizons
• The architectural assets to be leveraged in the organization's Enterprise Continuum, including:
• Assets created in previous iterations of the ADM cycle within the enterprise
• Assets available elsewhere in the industry (such as other frameworks, systems models, and vertical industry models)

These decisions must be made on the basis of a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work. As a generic method, the ADM is intended to be used by enterprises in a wide range of different geographies and applied in different vertical sectors/industry types. As such it can be - but does not necessarily have to be - tailored to specific needs. For example, it can be used:

• In conjunction with the set of deliverables of another framework, where these are more appropriate for a specific organization; many US federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs
• In conjunction with the well-known Zachman Framework, which is an excellent classification scheme, but lacks an openly available, well-defined methodology

Phases of Architecture Development Method (ADM) [3]
Phases within the ADM are as follows: The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles. Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development. Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision. Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision. Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision. Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase F: Migration Planning addresses how to move from the Baseline to the Target Architecture by finalizing a detailed Implementation and Migration Plan. Phase G: Implementation Governance provides architectural oversight of the implementation. Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. Requirements Management examines the process of managing architecture requirements throughout the ADM.

The phases of the ADM cycle are further divided into steps; for example, the steps within the architecture development phases (B, C, D) are as follows:

• Select reference models, viewpoints, and tools
• Develop Baseline Architecture Description
• Develop Target Architecture Description
• Perform gap analysis
• Define candidate roadmap components
• Resolve impacts across the Architecture Landscape
• Conduct formal stakeholder review
• Finalize the Architecture
• Create the Architecture Definition Document

Though the TOGAF ADM diagram has 10 phases, it is essentially a 4-step process:
Step 1. Tailor TOGAF to suit your needs: This is a one-time activity to be done before you start adopting TOGAF for your organization.
Step 2. Define the scope of work and prepare for rollout: This activity is made of 6 distinct steps, all of which are covered in our TOGAF training course.
Step 3. Oversee architecture development and implementation: How the actual architecture development and implementation is done within the scope of TOGAF.
Step 4. Manage post-implementation change: Any major change can trigger off another cycle of the ADM. [4]

source: The Open Group

Adapting the Architecture Development Method (ADM) [5]
The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an "enterprise-specific" ADM.

• One reason for wanting to adapt the ADM, which it is important to stress, is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise. For example, if the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work. In other cases a slightly different order may be preferred; for example, a detailed inventory of the baseline environment may be done before undertaking the Business Architecture. The order of phases may also be defined by the [^Architectural-Principles|Architecture Principles] and business principles of an enterprise. For example, the business principles may dictate that the enterprise be prepared to adjust its business processes to meet the needs of a packaged solution so that it can be implemented quickly to enable a fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow the completion of the Information Systems Architecture or the Technology Architecture.
• Another reason for wanting to adopt the ADM is if the TOGAF framework is to be integrated with another enterprise framework (as explained in Part I, 2.10 Using the TOGAF Standard with Other Frameworks). For example, an enterprise may wish to use the TOGAF framework and its generic ADM in conjunction with the Zachman Framework, or another Enterprise Architecture framework that has a defined set of deliverables specific to a particular vertical sector: Government, Defense, e-Business, Telecommunications, etc. The ADM has been specifically designed with this potential integration in mind.
• Other possible reasons for wanting to adapt the ADM include:
  • The ADM is one of the many corporate processes that make up the corporate governance model: It is complementary to and supportive of, other standard program management processes, such as those for authorization, risk management, business planning, budgeting, development planning, systems development, and procurement.
  • The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation and needs to be tailored to achieve a suitable compromise between the contractor's existing practices and the contracting enterprise's requirements
  • The enterprise is a small-to-medium enterprise and wishes to use a "cut-down" method more attuned to the reduced level of resources and system complexity typical of such an environment
  • The enterprise is very large and complex, comprising many separate but interlinked "enterprises" within an overall collaborative business framework, and the architecture method needs to be adapted to recognize this: Different approaches to planning and integration may be used in such cases, including the following (possibly in combination):
  • Top-down planning and development - designing the whole interconnected meta-enterprise as a single entity (an exercise that typically stretches the limits of practicality)
  • Development of a "generic" or "reference" architecture, typical of the enterprises within the organization, but not representing any specific enterprise, which individual enterprises are then expected to adapt in order to produce an architecture "instance" suited to the particular enterprise concerned
  • Replication - developing a specific architecture for one enterprise, implementing it as a proof-of-concept, and then taking that as a "reference architecture" to be cloned in other enterprises
  • In a vendor or production environment, a generic architecture for a family of related products is often referred to as a "Product Line Architecture", and the analogous process to that outlined above is termed "(Architecture-based) Product Line Engineering". The ADM is targeted primarily at architects in IT user enterprises, but a vendor organization whose products are IT-based might well wish to adopt it as a generic method for Product Line Architecture development.

  See Also

  1. The Open Group Architecture Framework (TOGAF): ADM is a central component of TOGAF. It provides the methodology to develop and refine the enterprise architecture using TOGAF principles.
  2. Enterprise Architecture: EA refers to the conceptual blueprint that defines the structure and operation of an organization. ADM provides a structured approach to evolve or define this architecture.
  3. Zachman Framework: Like TOGAF, the Zachman Framework is another methodology for developing enterprise architectures. While both frameworks have their methods (like ADM in TOGAF), they aim to achieve the same end goals in enterprise architecture development.
  4. Federal Enterprise Architecture Framework (FEA): FEAF is another enterprise architecture methodology, primarily adopted by federal governments. It's an alternative to TOGAF and Zachman, yet it similarly employs structured approaches akin to ADM.
  5. Business Architecture: While enterprise architecture looks at the entire organization, business architecture focuses on the business strategy, governance, and key business processes. ADM can be used to develop or refine the business architecture layer within an EA.
  6. ITIL (Information Technology Infrastructure Library): ITIL is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of the business. Though ITIL is more service-oriented and ADM is architecture-oriented, both are strategic tools in IT governance.
  7. Solution Architecture: While EA provides a strategic vision (macro-level), solution architecture deals with individual projects or initiatives (micro-level). As part of TOGAF, ADM often looks at how enterprise and solution architectures interrelate.
  8. Application Portfolio Management (APM): APM is about managing an organization's software applications and software-based services. While APM is more application-centric, its alignment with enterprise-wide strategies and architectures is crucial, a domain where ADM plays a role.

  References

  1. ↑ What is the Architecture Development Method (ADM)? ObusSoftware
  2. ↑ Key Points About the Architecture Development Method (ADM) Sparx Systems
  3. ↑ What are the phases within the Architecture Development Method (ADM)? APG
  4. ↑ The four Step Process of Togaf ADM EA Learning
  5. ↑ Adapting the Architecture Development Method (ADM) opengroup.org

  Further Reading

  • Introduction to the Architecture Development Method The Open Group
  • TOGAF usage in outsourcing of software development Aziz Ahmad Rais, Rudolf Pecinovsky
  • A Framework for Evaluation of Enterprise Architecture Implementation Methodologies Waset
  • The Architecture Development Method griffith.edu.au
  • Approaches to Architecture Development Mitre