View source for Architecture Development Method (ADM)

The '''Architecture Development Method (ADM)''' is right at the heart of [[The_Open_Group_Architecture_Framework_(TOGAF)|TOGAF]] and comprises a detailed step-by-step process for developing or changing an enterprise architecture. Much of the [[The_Open_Group_Architecture_Framework_(TOGAF)|TOGAF]] documentation covers the ADM, and everything else in [[The_Open_Group_Architecture_Framework_(TOGAF)|TOGAF]] can be mapped back to the ADM.<ref>What is the Architecture Development Method (ADM)? [https://www.orbussoftware.com/blog/video-series-what-is-the-adm/ ObusSoftware]</ref>


'''Key Points About the Architecture Development Method (ADM)'''<ref>Key Points About the Architecture Development Method (ADM) [http://sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/the_togaf_adm.html Sparx Systems]</ref><br />
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 which lacks an openly available, well-defined methodology


'''Phases of Architecture Development Method (ADM)'''<ref>What are the phases within the Architecture Development Method (ADM)? [http://www.aprocessgroup.com/atpl/togaf9.intro/guidances/concepts/adm_FC668FDF.html APG]</ref><br />
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 Architectures by finalizing a detailed Implementation and Migration Plan.
Phase G: Implementation Governance provides an 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.

[[File:ADM.png|300px|Architecture Development Method (ADM)]]<br />

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:<br />
Step 1. Tailor TOGAF to suit your needs: This is a one-time activity to be done before you start adopting TOGAF for your organisation.<br />
Step 2. Define 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.<br />
Step 3. Oversee architecture development and implementation: How the actual architecture development and implementation is done within the scope of TOGAF.<br />
Step 4. Manage post-implementation change: Any major change can trigger off another cycle of the ADM.<ref>The four Step Process of Togaf ADM [https://www.ealearning.com/info-centre/togaf-adm.html EA Learning]</ref>


[[File:ADM1.png|500px|Architecture Development Method (ADM) 1]]<br />
source: [http://www.togaf.info/togaf8/togafSlides/TOGAF-V8-M3-Intro-ADM.PDF The Open Group]


'''Adapting the Architecture Development Method (ADM)'''<ref>Adapting the Architecture Development Method (ADM) [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html opengroup.org]</ref><br />
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 fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow completion of the Information Systems Architecture or the Technology Architecture.
*Another reason for wanting to adapt 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 and 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 adapt it as a generic method for a Product Line Architecture development.


===See Also===
[[Architectural_Risk|Architectural Risk]]<br />
[[Architectural_Pattern|Architectural Pattern]]<br />
[[Architectural_Principles|Architectural Principles]]<br />
[[Architecture|Architecture]]<br />
[[Architecture_Description_Language_(ADL)|Architecture Description Language (ADL)]]<br />
[[Service_Oriented_Architecture_(SOA)|Service Oriented Architecture (SOA)]]<br />
[[Software_Architecture|Software Architecture]]<br />
[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
[[Architecture_Driven_Modernization|Architecture-Driven Modernization]]<br />
[[Design_Pattern|Design Pattern]]<br />
[[Enterprise_Architecture|Enterprise Architecture]]<br />
[[Zachman_Framework|Zachman Framework]]<br />
[[Department_of_Defense_Architecture_Framework_(DoDAF)|Department of Defense Architecture Framework (DoDAF)]]<br />
[[Technical_Architecture_Framework_for_Information_Management_(TAFIM)|Technical Architecture Framework for Information Management (TAFIM)]]<br />
[[Federal_Enterprise_Architecture_Framework_(FEA)|Federal Enterprise Architecture Framework (FEA)]]


===References===
<references/>


===Further Reading===
*Introduction to the Architecture Development Method [http://www.togaf.info/togaf8/togafSlides/TOGAF-V8-M3-Intro-ADM.PDF The Open Group]
*TOGAF usage in outsourcing of software development  [https://aip.vse.cz/pdfs/aip/2013/02/06.pdf Aziz Ahmad Rais, Rudolf Pecinovsky]
*A Framework for Evaluation of Enterprise Architecture Implementation Methodologies [https://waset.org/publications/10000078/a-framework-for-evaluation-of-enterprise-architecture-implementation-methodologies Waset]
*The Architecture Development Method [http://www.ict.griffith.edu.au/~bernus/taskforce/archive/togaf/togaf4/section4.htm griffith.edu.au]
*Approaches to Architecture Development [https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/system-architecture/approaches-to-architecture-development Mitre]