Architecture Development Method (ADM) - Revision history

User at 23:01, 21 August 2023

2023-08-21T23:01:56Z

User at 22:52, 18 January 2023

2023-01-18T22:52:17Z

User at 15:44, 7 December 2022

2022-12-07T15:44:08Z

User at 15:36, 7 December 2022

2022-12-07T15:36:18Z

User at 15:35, 7 December 2022

2022-12-07T15:35:21Z

Show changes

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:50:37Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 16:13, 29 May 2020

2020-05-29T16:13:22Z

User: 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 all else can be mapped back to ADM

2018-12-03T23:08:57Z

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 all else can be mapped back to ADM

User: Created page with "'''Content Coming Soon'''"

2018-12-03T19:56:33Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

← Older revision		Revision as of 23:01, 21 August 2023
Line 73:		Line 73:

	===See Also===		===See Also===
−		+	#[[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.
		+	#[[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.
		+	#[[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.
		+	#[[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.
		+	#[[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.
		+	#[[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.
		+	#[[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.
		+	#[[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.

@@ Line 1: / Line 1: @@
-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 TOGAF documentation covers the ADM, and everything else in 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>
+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.<ref>What is the Architecture Development Method (ADM)? [https://www.orbussoftware.com/blog/video-series-what-is-the-adm/ ObusSoftware]</ref>
@@ Line 12: / Line 12: @@
 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
+*In conjunction with the well-known Zachman Framework, which is an excellent classification scheme, but lacks an openly available, well-defined methodology
@@ Line 19: / Line 19: @@
 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 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.
@@ Line 56: / Line 56: @@
 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.
+*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.
@@ Line 66: / Line 66: @@
 **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===
-*[[Enterprise Architecture Framework]]
-*[[Enterprise Architecture Life Cycle (EALC)]]
-*[[Enterprise Architecture Governance]]
-*[[Enterprise Architecture Management (EAM)]]
-*[[Architectural Risk]]

@@ Line 69: / Line 69: @@
 ===See Also===
+*[[Enterprise Architecture Framework]]
@@ Line 78: / Line 93: @@
 ===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]
+*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]
+*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]

@@ Line 55: / Line 55: @@
 '''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 the completion of the Information [[Systems Architecture]] or the Technology Architecture.
+*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:

@@ Line 1: / Line 1: @@
-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>
+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>
@@ Line 7: / Line 7: @@
 *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:
+*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)
+*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:
+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 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
+*In conjunction with the well-known [[Zachman Framework]], which is an excellent classification scheme, but which lacks an openly available, well-defined [[methodology]]
@@ Line 18: / Line 18: @@
 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 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 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 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 G: Implementation [[Governance]] provides an architectural oversight of the implementation.
-Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
+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.
@@ Line 35: / Line 35: @@
 *Develop Target Architecture Description
 *Perform gap analysis
-*Define candidate roadmap components
+*Define candidate [[roadmap]] components
 *Resolve impacts across the Architecture Landscape
-*Conduct formal stakeholder review
+*Conduct formal [[stakeholder]] review
 *Finalize the Architecture
 *Create the Architecture Definition Document
@@ Line 54: / Line 54: @@
 '''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.
+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.
+*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.
+*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 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 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):
@@ Line 65: / Line 65: @@
 **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.
+**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.
@@ Line 92: / Line 92: @@
 ===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]
+*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]
+*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]

← Older revision		Revision as of 16:13, 29 May 2020
Line 1:		Line 1:
−	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>	+	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>

← Older revision		Revision as of 23:08, 3 December 2018
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	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]