This chapter will help you understand how each of the ADM phases contributes to the success of enterprise architecture.
Key Points Explained
This chapter will help you to answer the following questions:
• What are the objectives of each of the ADM phases?
• What are the key aspects to the approach taken in each phase for enterprise architecture development?
The Preliminary Phase includes the preparation and initiation activities to create an Architecture Capability. Key activities are as follows:
• Understand the business environment
• Ensure high-level management commitment
• Obtain agreement on scope
• Establish architecture principles
• Establish governance structure
• Customization of the TOGAF framework
(Syllabus Reference: Unit 6, Learning Outcome P.1: You should be able to describe the objectives of the Preliminary Phase.)
• Determine the Architecture Capability desired by the organization:
— Review the organizational context for conducting enterprise architecture
— Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
— Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
— Establish a Capability Maturity target
• Establish the Architecture Capability:
— Define and establish the Organizational Model for Enterprise Architecture
— Define and establish the detailed process and resources for architecture governance
— Select and implement tools that support the Architecture Capability
— Define the architecture principles (see Chapter 8 for more information on architecture principles)
(Syllabus Reference: Unit 6, Learning Outcome P.2: You should be able to briefly explain the seven aspects of the approach undertaken in the Preliminary Phase.) The Preliminary Phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned. The main aspects are as follows:
• Defining the enterprise
• Identifying key drivers and elements in the organizational context
• Defining the requirements for architecture work
• Defining the architecture principles that will inform any architecture work
• Defining the framework to be used
• Defining the relationships between management frameworks
• Evaluating the enterprise architecture’s maturity
Defining the Enterprise
One of the main challenges of enterprise architecture is that of enterprise scope. The scope of the enterprise, and whether it is federated, will determine those stakeholders who will derive most benefit from the new or enhanced enterprise architecture. It is imperative to appoint a sponsor at this stage to ensure that the resultant activity has resources to proceed and the clear support of the business management. The enterprise may include many organizations and the duties of the sponsor are to ensure that all stakeholders are included in defining, establishing, and using the Architecture Capability.
Identifying Key Drivers and Elements in the Organizational Context
It is necessary to understand the context surrounding the architecture. For example, considerations include:
• The commercial models and budget for the enterprise architecture
• The stakeholders
• The intentions and culture of the organization
• Current processes that support execution of change and operation of the enterprise
• The Baseline Architecture landscape
• The skills and capabilities of the enterprise
Review of the organizational context should provide valuable requirements on how to tailor the architecture framework, particularly the level of formality, the expenditure required, and contact with other organizations.
Defining the Requirements for Architecture Work
Business imperatives drive the requirements and performance metrics. One or more of the following requirements need to be articulated so that the sponsor can identify the key decision-makers and stakeholders involved in defining and establishing the Architecture Capability:
• Business requirements
• Cultural aspirations
• Organization intents
• Strategic intent
• Forecast financial requirements
Defining the Architecture Principles that will Inform any Architecture Work
The definition of architecture principles is fundamental to the development of an enterprise architecture. Architecture work is informed by business principles as well as architecture principles. The architecture principles themselves are also normally based in part on business principles.
Architecture principles are covered in further detail in Chapter 8.
Defining the Framework to be Used
The ADM is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. It can also be used with a wide variety of other enterprise architecture frameworks, if required. The TOGAF framework has to co-exist with and enhance the operational capabilities of other frameworks in use within an organization. The main frameworks that may need to be coordinated with the TOGAF framework are:
• Business Capability Management (Business Direction and Planning) which determine what business capabilities are required.
• Portfolio/Project Management Methods which determine how a company manages its change initiatives.
• Operations Management Methods which describe how a company runs its day-to-day operations, including IT.
• Solution Development Methods which formalize the way that business systems are delivered.
As illustrated in Figure 14, these frameworks are not discrete, and there are significant overlaps between them and the Business Capability Management. Consequently, an enterprise architect must be aware of the impact that the architecture has on the entire enterprise.
Figure 14: Management Frameworks to Coordinate with the TOGAF Framework
Defining the Relationships between Management Frameworks
Figure 15 shows a more detailed set of dependencies between the various frameworks and business planning activity. The enterprise architecture can be used to provide a structure for all of the corporate initiatives.
Figure 15: Interoperability and Relationships between Management Frameworks
The management frameworks are required to complement each other and work in close harmony for the good of the enterprise.
Evaluating the Enterprise Architecture Maturity
Capability Maturity Models (CMMs) are a good way of assessing the ability of an enterprise to exercise different capabilities. Capability Maturity Models typically identify selected factors that are required to exercise a capability. An organization’s ability to execute specific factors provides a measure of maturity and can be used to recommend a series of sequential steps to improve a capability. It is an assessment that gives executives an insight into pragmatically improving a capability.
Phase A is about project establishment and initiates an iteration of the Architecture Development Cycle, setting the scope, constraints, and expectations for the iteration.
It is required at the start of every architecture cycle in order to create the Architecture Vision, validate the business context, and create the approved Statement of Architecture Work.
(Syllabus Reference: Unit 6, Learning Outcome A.1: You should be able to describe the main objectives of Phase A.)
• Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture
• Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision
(Syllabus Reference: Unit 6, Learning Outcome A.2: You should be able to briefly explain the two main aspects of the approach for Phase A.)
Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization to the architecture organization. A key objective is to ensure proper recognition and endorsement from corporate management, and the support and commitment of line management for this evolution of the ADM cycle.
As the name of the phase suggests, creating the Architecture Vision is a key activity in this phase. This is discussed below, as is the business scenarios technique which can be used to develop the Architecture Vision.
Creating the Architecture Vision
The Architecture Vision provides the sponsor with a key tool to sell the benefits of the proposed capability to stakeholders and decision-makers within the enterprise. It describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.
Normally, key elements of the Architecture Vision – such as the enterprise mission, vision, strategy, and goals – have been documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise. In such cases, the activity in Phase A is concerned with verifying and understanding the documented business strategy and goals. Phase A may also integrate the enterprise strategy and goals with the strategy and goals implicit within the current architecture.
In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of the ADM initiation phase (Preliminary Phase).
Business scenarios (see below) are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements.
The Architecture Vision provides a first-cut, high-level description of the Baseline and Target Architectures, covering the Business, Data, Application, and Technology domains. These outline descriptions are developed in subsequent phases.
Once an Architecture Vision is defined and documented in the Statement of Architecture Work, it is critical to use it to build a consensus. Without this consensus it is very unlikely that the final architecture will be accepted by the organization as a whole. The consensus is represented by the sponsoring organization signing the Statement of Architecture Work.
The ADM has its own method (a “method-within-a-method”) for identifying and articulating the business requirements implied, and the implied architecture requirements. This technique is known as “business scenarios”, and is described in detail in Chapter 8. The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture.
Phase B is about development of a Business Architecture to support an agreed Architecture Vision.
This describes the fundamental organization of a business embodied in:
• Its business process and people
• Their relationships to each other and the people
• The principles governing its design and evolution and shows how an organization meets its business goals.
(Syllabus Reference: Unit 6, Learning Outcome B.1: You should be able to describe the main objectives of Phase B.)
• Develop the Target Business Architecture describing how the enterprise needs to operate to achieve the business goals, responds to the strategic drivers set out in the Architecture Vision, and addresses the Request for Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures
(Syllabus Reference: Unit 6, Learning Outcome B.2: You should be able to explain the main aspects of the approach in Phase B.)
In summary, the Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment.
A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken.
In practical terms, the Business Architecture is often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.
Developing the Baseline Description
If an enterprise has existing architecture descriptions, they should be used as the basis for the Baseline Description. Where no such descriptions exist, information will have to be gathered in whatever format comes to hand.
The normal approach to Target Architecture development is top-down. In the Baseline Description, however, the analysis of the current state often has to be done bottom-up, particularly where little or no architecture assets exist. In such a case, the architect simply has to document the working assumptions about high-level architectures, and the process is one of gathering evidence to turn the working assumptions into fact.
Business Modeling
Business models should be extensions of business scenarios developed during the Architecture Vision. A variety of modeling tools and techniques may be used. Such as Activity Models (also called Business Process Models), Use-Case Models, and Class Models. All three types of model can be represented in the Unified Modeling Language (UML), and a variety of tools exist for generating such models. The Defense sector also uses Node Connectivity Diagrams and Information Exchange Matrices.
Using the Architecture Repository
The architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository, in particular:
• Generic business models relevant to the organization’s industry sector; these are called “Industry Architectures”
• Business models relevant to common high-level business domains (for example, electronic commerce, supply chain management, etc.); these are called “Common Systems Architectures”
• Enterprise-specific building blocks (process components, business rules, job descriptions, etc.)
• Applicable standards
Phase C is about documenting the Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. This describes the major types of information and the application systems that process the information, and their relationships to each other and the environment.
There are two steps in this phase, which may be developed either sequentially or concurrently:
• Data Architecture
• Application Architecture
(Syllabus Reference: Unit 6, Learning Outcome C.1: You should be able to describe the main objectives of Phase C.)
• Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns.
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures.
Consistency of Phases B, C, and D
As noted in Section 5.2, the architectures developed in Phases B, C, and D follow a uniform step pattern, including development of Baseline and Target Architecture descriptions and analysis of the gaps. The details are out of scope for TOGAF 9 Foundation, and are covered instead in Level 2.
(Syllabus Reference: Unit 6, Learning Outcome C.2: You should be able to briefly explain the approach recommended by the TOGAF standard for Phase C.)
Phase C involves some combination of Data and Application Architecture, in either order. Advocates exist for both sequences, and the TOGAF standard leaves this to the user to decide. Consideration of the factors is outside the scope of the TOGAF 9 Foundation Syllabus. The syllabus covers the two topics below.
Key Considerations for the Data Architecture
Key considerations for the Data Architecture include:
• Data Management
When an enterprise has chosen to undertake large-scale architectural transformation, it is important to understand and address data management issues. A structured and comprehensive approach to data management enables the effective use of data to capitalize on its competitive advantages.
Considerations include:
— Defining application components which will serve as the system of record or reference for enterprise master data
— Defining enterprise-wide standards that all application components, including software packages, need to adopt
— Understanding how data entities are utilized by business functions, processes, and services
— Understanding how and where enterprise data entities are created, stored, transported, and reported
— Understanding the level and complexity of data transformations required to support the information exchange needs between applications
— Defining the requirement for software in supporting data integration with the enterprise’s customers and suppliers (e.g., use of ETL11 tools during the data migration, data profiling tools to evaluate data quality, etc.)
• Data Migration
When an existing application is replaced, there will be a critical need to migrate data (master, transactional, and reference) to the new application. The Data Architecture should identify data migration requirements and also provide indicators as to the level of transformation, weeding, and cleansing that will be required to present data in a format that meets the requirements and constraints of the target application. The objective is to ensure that the target application has quality data when it is populated. Another key consideration is to ensure that an enterprise-wide common data definition is established to support the transformation.
• Data Governance
Considerations for data governance should ensure that the enterprise has the necessary dimensions in place to enable the transformation, as follows:
— Structure: Does the enterprise have the necessary organizational structure and the standards bodies to manage data entity aspects of the transformation?
— Management System: Does the enterprise have the necessary management system and data-related programs to manage the governance aspects of data entities throughout its lifecycle?
— People: What data-related skills and roles does the enterprise require for the transformation? If the enterprise lacks such resources and skills, the enterprise should consider either acquiring those critical skills or training existing internal resources to meet the requirements through a well-defined learning program.
Using the Architecture Repository
As part of this phase, the architecture team should consider what relevant Data Architecture and Application Architecture resources are available in the organization’s Architecture Repository; in particular, generic models relevant to the organization’s industry “vertical” sector. For example:
• Data Architecture models:
— ARTS has defined a data model for the Retail industry.
— Energistics has defined a data model for the Petrotechnical industry.
• Application Architecture models:
— The TeleManagement Forum (TMF) – www.tmforum.org – has developed detailed applications models relevant to the Telecommunications industry.
— The Object Management Group (OMG) – www.omg.org – has a number of vertical Domain Task Forces developing software models relevant to specific vertical domains such as Healthcare, Transportation, Finance, etc.
— Application models relevant to common high-level business functions, such as electronic commerce, supply chain management, etc.
The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) that focuses on the application-level components and services necessary to provide an integrated information infrastructure.
Phase D is about documenting the Technology Architecture for an architecture project, in the form of the fundamental organization of the IT systems:
• Embodied in the hardware, software, and communications technology
• Their relationships to each other and the environment
• The principles governing its design and evolution
(Syllabus Reference: Unit 6, Learning Outcome D.1: You should be able to describe the main objectives of Phase D.)
• Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
(Syllabus Reference: Unit 6, Learning Outcome D.2: You should be able to briefly explain the approach to Phase D.)
Using the Architecture Repository
As part of Phase D, the architecture team must consider what relevant Technology Architecture resources are available in the Architecture Repository. In particular, consider:
• Existing IT services
• The TOGAF Technical Reference Model (TRM)
• Generic technology models relevant to the organization’s industry “vertical” sector; for example, in the telecommunications industry such models have been developed by the TeleManagement Forum (TMF)
• Technology models relevant to Common Systems Architectures; for example, the III-RM.
Phase E is the first phase which is directly concerned with implementation. It describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture identified in previous phases.
Key activities are as follows:
• Perform initial implementation planning
• Identify the major implementation projects
• Group changes into work packages
• Decide on approach:
— Make versus buy versus re-use
— Outsource
— COTS
— Open Source
• Assess priorities
• Identify dependencies
(Syllabus Reference: Unit 6, Learning Outcome E.1: You should be able to describe the main objectives of Phase E.)
• Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
• Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
(Syllabus Reference: Unit 6, Learning Outcome E.2: You should be able to briefly explain the approach to Phase E.)
Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages within the enterprise’s portfolios. This is an effort to build a best-fit roadmap that is based upon the stakeholder requirements, the enterprise’s business transformation readiness, identified opportunities and solutions, and identified implementation constraints. The key is to focus on the final target while realizing incremental business value.
Phase E is the initial step on the creation of a well considered Implementation and Migration Plan that is integrated into the enterprise’s portfolio in Phase F.
There are four key concepts in the transition from developing to delivering a Target Architecture:
• Architecture Roadmap
• Work Packages
• Transition Architectures
• Implementation and Migration Plan
The Architecture Roadmap lists individual work packages in a timeline that will realize the Target Architecture. Each work package identifies a logical group of changes necessary to realize the Target Architecture. A Transition Architecture describes the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures provide interim Target Architectures upon which the organization can converge. The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.
Phase F addresses detailed migration planning; that is, how to move from the Baseline to the Target Architectures.
Key activities include:
• For work packages and projects identified, perform a cost/benefit analysis and a risk assessment
• Finalize a detailed Implementation and Migration Plan
(Syllabus Reference: Unit 6, Learning Outcome F.1: You should be able to describe the main objectives for Phase F.)
• Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
• Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
• Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
(Syllabus Reference: Unit 6, Learning Outcome F.2: You should be able to briefly explain the approach to Phase F.)
The focus of Phase F is the creation of an Implementation and Migration Plan in co-operation with the portfolio and project managers. Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Request for Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are integrated with the enterprise’s other change activity. Activities include assessing the dependencies, costs, and benefits of the various migration projects. The Architecture Roadmap, and Implementation and Migration Plan, from Phase E will form the basis of the detailed Implementation and Migration Plan that will include portfolio and project-level detail. The architecture development cycle should then be completed, and lessons learned documented to enable continuous process improvement.
Phase G defines how the architecture constrains the implementation projects, monitors it while building it, and produces a signed Architecture Contract.
Key activities include:
• Provide architectural oversight for the implementation
• Define architecture constraints on implementation projects
• Govern and manage an Architecture Contract
• Monitor implementation work for conformance
(Syllabus Reference: Unit 6, Learning Outcome G.1: You should be able to describe the main objectives of Phase G.)
• Ensure conformance with the Target Architecture by implementation projects
• Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
(Syllabus Reference: Unit 6, Learning Outcome G.2: You should be able to briefly explain the approach to Phase G.)
In Phase G all the information for successful management of the various implementation projects is brought together. The actual development occurs in parallel with Phase G.
The approach in Phase G is to:
• Establish an implementation program that will enable the delivery of the agreed Transition Architectures
• Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
• Follow the organization’s standard for corporate, IT, and Architecture Governance
• Use the organization’s established portfolio/program management approach, where this exists
• Define an operations framework to ensure the effective long life of the deployed solution
A key aspect of Phase G is ensuring compliance with the defined architecture(s), not only by the implementation projects, but also by other ongoing projects.
Phase H ensures that changes to the architecture are managed in a controlled manner.
Key activities include:
• Provide continual monitoring and a change management process
• Ensure that changes to the architecture are managed in a cohesive and architected way
• Provide flexibility to evolve rapidly in response to changes in the technology or business environment
• Monitor the business and capacity management
(Syllabus Reference: Unit 6, Learning Outcome H.1: You should be able to describe the main objectives of Phase G.)
• Ensure that the architecture lifecycle is maintained
• Ensure that the Architecture Governance Framework is executed
• Ensure that the enterprise’s Architecture Capability meets current requirements
(Syllabus Reference: Unit 6, Learning Outcome H.2: You should be able to briefly explain the approach to Phase H.)
The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. Monitoring business growth and decline is a critical aspect of this phase.
The value and change management process, once established, will determine:
• The circumstances under which the enterprise architecture, or parts of it, will be permitted to change after deployment, and the process by which that will happen
• The circumstances under which the Architecture Development Cycle will be initiated to develop a new architecture
Drivers for Change
There are three ways to change the existing infrastructure that have to be integrated:
1. Strategic, top-down directed change to enhance or create new capability (capital)
2. Bottom-up changes to correct or enhance capability (operations and maintenance) for infrastructure under operations management
3. Experiences with the previously delivered project increments in the care of operations management, but still being delivered by ongoing projects
Enterprise Architecture Change Management Process
The enterprise architecture change management process needs to determine how changes are to be managed, what techniques are to be applied, and what methodologies used.
The TOGAF standard recommends the following approach based on classifying the required architectural changes into one of three categories:
• Simplification change: A simplification change can normally be handled via change management techniques.
• Incremental change: An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change (see Guidelines for Maintenance versus Architecture Redesign for guidance).
• Re-architecting change: A re-architecting change requires putting the whole architecture through the Architecture Development Cycle again.
Another way of looking at these three choices is as follows:
• A simplification change to an architecture is often driven by a requirement to reduce investment.
• An incremental change is driven by a requirement to derive additional value from existing investment.
• A re-architecting change is driven by a requirement to increase investment in order to create new value for exploitation.
To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:
1. Registration of all events that may impact the architecture
2. Resource allocation and management for architecture tasks
3. The process or role responsible for architecture resources has to make an assessment of what should be done
4. Evaluation of impacts
Guidelines for Maintenance versus Architecture Redesign
A good rule-of-thumb is:
• If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-entry to the ADM.
• If the change impacts only one stakeholder, then it is more likely to be a candidate for change management.
• If the change can be allowed under a dispensation, then it is more likely to be a candidate for change management.
For example:
• If the impact is significant for the business strategy, then there may be a need to re-do the whole enterprise architecture – thus a re-architecting approach.
• If a new technology or a standard emerges, then there may be a need to refresh the Technology Architecture, but not the whole enterprise architecture – thus an incremental change.
• If the change is at an infrastructure level – for example, ten systems reduced or changed to one system – this may not change the architecture above the physical layer, but it will change the Baseline Description of the Technology Architecture. This would be a simplification change handled via change management techniques.
In particular, a refreshment cycle (partial or complete re-architecting) may be required if:
• The Foundation Architecture needs to be re-aligned with the business strategy.
• Substantial change is required to components and guidelines for use in deployment of the architecture.
• Significant standards used in the product architecture are changed which have significant end-user impact; e.g., regulatory changes.
If there is a need for a refreshment cycle, then a new Request for Architecture Work must be issued (to move to another cycle).
(Syllabus Reference: Unit 6, Learning Outcome R.1: You should be able to briefly explain how Requirements Management fits into the ADM cycle.)
The process of managing architecture requirements applies to all phases of the ADM cycle. The Requirements Management process is a dynamic process, which addresses the identification of requirements for the enterprise, stores them, and then feeds them in and out of the relevant ADM phases.
As shown by its central placement in the ADM cycle diagram, this process is central to driving the ADM process.
(Syllabus Reference: Unit 6, Learning Outcome R.2: You should be able to describe the nature of the Requirements Management process.)
• Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
• Manage architecture requirements identified during any execution of the ADM cycle or a phase
• Ensure that the relevant architecture requirements are available for use by each phase as the phase is executed
(Syllabus Reference: Unit 6, Learning Outcome R.3: You should be able to describe the approach to Requirements Management.)
The ADM is continuously driven by the Requirements Management process. The ability to deal with changes in requirements is crucial, as architecture by its nature deals with uncertainty and change, bridging the divide between the aspirations of the stakeholders and what can be delivered as a practical solution.
Requirements Management Manages the Flow of Requirements
Note that the Requirements Management process itself does not dispose of, address, or prioritize any requirements; this is done within the relevant phase of the ADM.
It is recommended that a Requirements Repository is used to record and manage all architecture requirements. The TOGAF standard does not mandate or recommend any specific process or tool for requirements management; it simply states what an effective Requirements Management process should achieve, which could be thought of as “the requirements for requirements”.
The TOGAF standard suggests a number of resources in this area:
Business Scenarios
Business scenarios are an appropriate and useful technique to discover and document business requirements, and to describe an Architecture Vision that responds to those requirements. Business scenarios are described in detail in TOGAF 9 Part III: ADM Guidelines and Techniques, Chapter 26 (Business Scenarios).
Other Requirements Tools
There is a large and increasing, number of Commercial Off-The-Shelf (COTS) tools available for the support of requirements management. The Volere web site has a useful list of requirements tools (see www.volere.co.uk/tools.htm).
This chapter has described each of the ADM phases and how they contribute to the development of an enterprise architecture. This has included the key objectives for each phase, together with high-level considerations for the approach.
Q1: Which of the ADM phases includes the development of Application and Data Architectures?
A. Phase A
B. Phase B
C. Phase C
D. Phase D
E. Phase E
Q2: Which of the ADM phases includes the objective of establishing the organizational model for enterprise architecture?
A. Preliminary
B. Phase A
C. Phase B
D. Phase D
E. Phase E
Q3: Which one of the following is an objective of Phase A?
A. To review the stakeholders, their requirements, and priorities
B. To develop a high-level vision of the business value to be delivered
C. To generate and gain consensus on an outline Implementation and Migration Strategy
D. To formulate recommendations for each implementation project
E. To provide a process to manage architecture requirements
Q4: Complete the sentence: According to the TOGAF standard, all of the following are part of the approach to the Preliminary Phase, except ________________
A. Creating the Architecture Vision
B. Defining the enterprise
C. Defining the framework to be used
D. Defining the relationships between management frameworks
E. Evaluating the enterprise architecture maturity
Q5: Which one of the following is a recommended way to evaluate the enterprise architecture maturity?
A. Architecture Principles
B. Business Scenarios
C. Capability Maturity Models
D. Risk Management
Q6: Which of the ADM phases commences with receipt of a Request for Architecture Work from the sponsor?
A. Preliminary
B. Phase A
C. Phase E
D. Phase G
E. Phase H
Q7: Which of the following is a technique that can be used to discover and document business requirements in Phase A?
A. Business Scenarios
B. Business Transformation Readiness Assessment
C. Gap Analysis
D. Stakeholder Management
Q8: Which architecture domain is the first architecture activity undertaken in the ADM cycle?
A. Application
B. Business
C. Data
D. Technology
Q9: Which one of the following is considered a relevant resource for Phase B available from the Architecture Repository?
A. The ARTS data model
B. Business rules, job descriptions
C. The III-RM
D. The TOGAF Technical Reference Model
Q10: Which one of the following is a potential resource in Phase C and is a reference model focusing on application-level components and services?
A. The ARTS data model
B. Business rules, job descriptions
C. The III-RM
D. The TOGAF Technical Reference Model
Q11: In which ADM phase is an outline Implementation and Migration Strategy generated?
A. Phase E
B. Phase F
C. Phase G
D. Phase H
Q12: In which ADM phase are the Transition Architectures defined in Phase E confirmed with the stakeholders?
A. Phase E
B. Phase F
C. Phase G
D. Phase H
Q13: In which ADM phase is an Architecture Contract developed to cover the overall implementation and deployment process?
A. Phase E
B. Phase F
C. Phase G
D. Phase H
Q14: Which one of the following is an objective of Phase H: Architecture Change Management?
A. Finalize the Architecture Roadmap
B. Manage architecture requirements identified during execution of the ADM cycle
C. Perform Architecture Governance functions for the solution
D. Operate the Architecture Governance Framework
Q15: Which one of the following is a change that can always be handled by change management techniques?
A. Incremental change
B. Re-architecting change
C. Simplification change
Q16: Complete the sentence: The process of managing architecture requirements applies to _______________?
A. All ADM phases
B. The Preliminary Phase
C. Phase A: Architecture Vision
D. The Requirements Management phase
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part II: ADM, Chapters 6 through 17, Phases Preliminary to Phase H, and Requirements Management
_______________________
11 ETL is an abbreviation for Extract, Transform, and Load.
