ADM Flashcards
Guidelines for Adapting the ADM Process
The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Guidelines included within this part are as follows:
The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Guidelines included within this part are as follows:
Guidelines - help us adapt the ADM
Techniques are used with the ADM phases
Guidelines - help us adapt the ADM - Applying Iteration to the ADM (see 18. Applying Iteration to the ADM) discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM
Applying the ADM across the Architecture Landscape (see 19. Applying the ADM Across the Architecture Landscape) discusses the different types of architecture engagement that may occur at different levels of the enterprise - this section then also discusses how the ADM process can be focused to support different types of engagement
Preliminary Phase
Architecture Principles - principles for the use and deployment of IT resources across the enterprise - describes how to develop the set of general rules and guidelines for the architecture being developed
Phase A
Stakeholder Management - describes stakeholder management, an important discipline that successful architecture practitioners can use to win support for their projects
Architecture Patterns-provides guidance on using architectural patterns
Migration Planning Techniques-describes a number of techniques to support migration planning in Phases E and F
Business Transformation Readiness Assessment- describes a technique for identifying business transformation issues
Risk Management - describes a technique for managing risk during an architecture/business transformation project
Capability-Based Planning
describes the technique of capability-based planning
Phase B
Gap Analysis -describes the technique known as gap analysis; it is widely used in the TOGAF ADM to validate an architecture that is being developed
Phase E
Interoperability Requirements - describes a technique for determining interoperability requirements
Briefly explain the need for Architecture Principles and where they are used within TOGAF.
Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.
Enterprise Principlesprovide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission
Architecture Principlesare a set of principles that relate to architecture work
Describe the standard template for Architecture Principles.
Name - Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: “support”, “open”, “consider”, and for lack of good measure the word “avoid”, itself, be careful with “manage(ment)”, and look for unnecessary adjectives and adverbs (fluff).
Statement- Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement is unambiguous.
Rationale-Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications-Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: “How does this affect me?”. It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.
Explain what makes a good Architecture Principle.
A good set of principles will be founded in the beliefs and values of the organizations it mus be - Understandable Robust Complete Consistant Stable
Describe the Business Transformation Readiness program.
Determine the readiness factors that will impact the organization
Present the readiness factors using maturity models
Assess the readiness factors, including determination of readiness factor ratings
Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
Work these actions into Phase E and F Implementation and Migration Plan
List the characteristics of Risk Management.
Initial Level of Risk: risk categorization prior to determining and implementing mitigating actions
Residual Level of Risk: risk categorization after implementation of mitigating actions (if any)
Explain where Risk Management is used within the TOGAF ADM.
Risk is pervasive in any Enterprise Architecture activity and is present in all phases within the Architecture Development Method (ADM).
Risks are normally classified as time (schedule), cost (budget), and scope but they could also include client transformation relationship risks, contractual risks, technological risks, scope and complexity risks, environmental (corporate) risks, personnel risks, and client acceptance risks.
Another way of delegating risk management is to further classify risks by architecture domains. Classifying risks as business, information, applications, and technology is useful but there may be organizationally-specific ways of expressing risk that the
Explain the term interoperability.
- The ability to share information and services.
- The ability of two or more systems or components to exchange and use information.
- The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together
1- Operational or Business Interoperability defines how business processes are to be shared
2-Information Interoperability defines how information is to be shared
3- Technical Interoperability defines how technical services are to be shared or at least connect to one another
Explain how Interoperability Requirements are used within the TOGAF ADM.
1- Phase A the nature and security considerations of the information and service exchanges are first revealed within the business scenarios
2-Phase B the information and service exchanges are further defined in business terms
3- (Phase C), the content of the information exchanges is detailed using the corporate data and/or information exchange model
Same - Phase C), the way that the various applications are to share the information and services is specified
Phase D- (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are specified
Phase E - the actual solutions (e.g., Commercial Off-The-Shelf (COTS) packages) are selected
Phase F - the interoperability is logically implemented
Explain the purpose of Gap Analysis.
The technique known as gap analysis is widely used in the TOGAF Architecture Development Method (ADM) to validate an architecture that is being developed. The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.
Describe the Gap Analysis technique.
1-Draw up a matrix with all the Architecture Building Blocks (ABBs) of the Baseline Architecture on the vertical axis, and all the ABBs of the Target Architecture on the horizontal axis
2- Add to the Baseline Architecture axis a final row labeled “New”, and to the Target Architecture axis a final column labeled “Eliminated”
3- Where an ABB is available in both the Baseline and Target Architectures, record this with “Included” at the intersecting cell
4-Where an ABB from the Baseline Architecture is missing in the Target Architecture, each must be reviewed
5-Where an ABB from the Target Architecture cannot be found in the Baseline Architecture, mark it at the intersection with the “New” row as a gap that needs to filled, either by developing or procuring the building block
Risk Identification
Phase A Risk are identified in phase A as part of the initial business transformation readness assessment
Phase G - The risk identification worksheet is maintained as a governance artifact anFcad are kept up to date in phase G implemention governance where risk monitoring conducted
Capability-Based Planning.
Capability based planning is a technique that focuses on the planning,focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It frames all phases of the architecture development in the context of business and outcomes, clearly linking IT vision, architecture and the implementation and migration plans with the corporate strategic, business and line of business plans.
Capability-based planning is a versatile business planning paradigm that is very useful from an Enterprise Architecture perspective. It assists in aligning IT with the business and helps focus IT architects on the continuous creation of business value.
Adapting the ADM
Generic Methodology intended for variable :
Geographies
Vertical sectors
Inudstry Types
Usable with deliverable of other frameworks such as zachman, DoDAF
It is usual to modify or extend the ADM to suit specific needs
Request for Architecture Work
output from -Preliminary, F, H
input to -A, G
This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Requests for Architecture Work can be created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning.
Statement of Architecture Work
The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services.
Output from-A, B, C, D, E, F, G, H
input to -B, C, D, E, F, G, H, Requirements Management
Architecture Vision
The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. Early agreement on the outcome enables the architects to focus on the detail necessary to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing a summary version of the full Architecture Definition.
out put A, E
input to - B, C, D, E, F, G, H, Requirements Management
Communications Plan
Enterprise Architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.
Architecture Definition Document
The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).
A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.
The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:
The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects
The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture
Architecture Requirements Specification
The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.
As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective:
The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect
The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture