ADM Flashcards

1
Q

Guidelines for Adapting the ADM Process

A

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:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Guidelines - help us adapt the ADM

Techniques are used with the ADM phases

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Briefly explain the need for Architecture Principles and where they are used within TOGAF.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Describe the standard template for Architecture Principles.

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Explain what makes a good Architecture Principle.

A
A good set of principles will be founded in the beliefs and values of the organizations it mus be - 
Understandable
Robust
Complete
Consistant
Stable
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Describe the Business Transformation Readiness program.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

List the characteristics of Risk Management.

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Explain where Risk Management is used within the TOGAF ADM.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Explain the term interoperability.

A
  1. The ability to share information and services.
    1. The ability of two or more systems or components to exchange and use information.
    2. 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Explain how Interoperability Requirements are used within the TOGAF ADM.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Explain the purpose of Gap Analysis.

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Describe the Gap Analysis technique.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Risk Identification

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Capability-Based Planning.

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Adapting the ADM

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Request for Architecture Work

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Statement of Architecture Work

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Architecture Vision

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Communications Plan

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Architecture Definition Document

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Architecture Requirements Specification

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Architecture Roadmap

A

The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM

23
Q

Architecture Building Blocks

A

A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
Adherence to the principles, standards, and requirements of the existing or developing architectures
Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body

24
Q

Architecture Contract

A

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective Architecture Governance (see Part VI, 44. Architecture Governance). By implementing a governed approach to the management of contracts, the following will be ensured:

A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
Adherence to the principles, standards, and requirements of the existing or developing architectures
Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body

25
Q

Architecture Principles

A

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.

26
Q

Architecture Repository

A

The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties.

27
Q

Business Principles, Business Goals, and Business Drivers

A

Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. Many factors that lie outside the consideration of architecture discipline may nevertheless have significant implications for the way that architecture is developed.

28
Q

Capability Assessment

A

Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. This Capability Assessment can be examined on several levels:

What is the capability level of the enterprise as a whole? Where does the enterprise wish to increase or optimize capability? What are the architectural focus areas that will support the desired development of the enterprise?
What is the capability or maturity level of the IT function within the enterprise? What are the likely implications of conducting the architecture project in terms of design governance, operational governance, skills, and organization structure? What is an appropriate style, level of formality, and amount of detail for the architecture project to fit with the culture and capability of the IT organization?
What is the capability and maturity of the architecture function within the enterprise? What architectural assets are currently in existence? Are they maintained and accurate? What standards and reference models need to be considered? Are there likely to be opportunities to create re-usable assets during the architecture project?
Where capability gaps exist, to what extent is the business ready to transform in order to reach the target capability? What are the risks to transformation, cultural barriers, and other considerations to be addressed beyond the basic capability gap

29
Q

Change Request

A

During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions. Additionally, external factors - such as market factors, changes in business strategy, and new technology opportunities - may open up opportunities to extend and refine the architecture.

In these circumstances, a Change Request may be submitted in order to kick-start a further cycle of architecture work.

30
Q

Compliance Assessment

A

Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Periodic compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives.

31
Q

Implementation Governance Model

A

Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.

The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance.

32
Q

Organizational Model for Enterprise Architecture

A

In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different Enterprise Architecture practitioners and the governance relationships that span across these boundaries.

33
Q

Requirements Impact Assessment

A

Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.

34
Q

Solution Building Blocks

A

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.

35
Q

Statement of Architecture Work

A

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

36
Q

Tailored Architecture Framework

A

The TOGAF framework provides an industry standard for architecture that may be used in a wide variety of organizations. However, before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary.

Firstly, it is necessary to tailor the TOGAF model for integration into the enterprise. This tailoring will include integration with management frameworks, customization of terminology, development of presentational styles, selection, configuration, and deployment of architecture tools, etc. The formality and detail of any frameworks adopted should also align with other contextual factors for the enterprise, such as culture, stakeholders, commercial models for Enterprise Architecture, and the existing level of Architecture Capability.

Once the framework has been tailored to the enterprise, further tailoring is necessary in order to tailor the framework for the specific architecture project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.

37
Q

Briefly explain what the Enterprise Continuum is

A

The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.

The Enterprise Continuum enables the architect to articulate the broad perspective of what, why, and how the Enterprise Architecture has been designed with the factors and drivers considered. The Enterprise Continuum is an important aid to communication and understanding, both within individual enterprises, and between customer enterprises and vendor organizations. Without an understanding of “where in the continuum you are”, people discussing architecture can often talk at cross-purposes because they are referencing different points in the continuum at the same time, without realizing it.

38
Q

Briefly explain what the Enterprise Continuum is

A

The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures

39
Q

Explain how it is used in organizing and developing an architecture.

A

The simplest way of thinking of the Enterprise Continuum is as a view of the repository of all the architecture assets. It can contain Architecture Descriptions, models, building blocks, patterns, architecture viewpoints, and other artifacts - that exist both within the enterprise and in the IT industry at large, which the enterprise considers to have available for the development of architectures for the enterprise.

40
Q

Explain the purpose of the Enterprise Continuum.

A

The Enterprise Continuum classifies architecture assets that are applicable across the entire scope of the Enterprise Architecture. These assets, which may be referred to as building blocks, can represent a variety of elements that collectively define and constrain the Enterprise Architecture. They can take the form of business goals and objectives, strategic initiatives, capabilities, policies, standards, and principles.

41
Q

Describe the constituents of the Enterprise Continuum.

A

TheEnterprise Continuum
TheArchitecture Continuum
TheArchitecture Continuu

42
Q

List the stages of architecture evolution defined in the Architecture Continuum.

A

Foundation Architecture - Common Systems Architectures

Industry Architectures-Organization-Specific Architectures

43
Q

Explain the purpose of the Solutions Continuum.

A

TheSolutions Continuum - provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum
The Solutions Continuum defines what is available in the organizational environment as re-usable Solution Building Blocks (SBBs). The solutions are the results of agreements between customers and business partners that implement the rules and relationships defined in the architecture space. The Solutions Continuum addresses the commonalities and differences among the products, systems, and services of implemented systems.

44
Q

The Architecture Continuum

A

offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships (e.g., to show that an Organization-Specific Architecture is based on an industry or generic standard)
The Architecture Continuum represents a structuring of Architecture Building Blocks (ABBs) which are re-usable architecture assets. ABBs evolve through their development lifecycle from abstract and generic entities to fully expressed Organization-Specific Architecture assets. The Architecture Continuum assets will be used to guide and select the elements in the Solutions Continuum (see below). The Architecture Continuum shows the relationships among foundational frameworks (such as the TOGAF framework), common system architectures (such as the III-RM), industry architectures, and Enterprise Architectures. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy.

45
Q

Describe the classes of information held in the Architecture Repository.

A

The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content
The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository
The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time
The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization
The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise
The Governance Log provides a record of governance activity across the enterprise
The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
The Solutions Landscape presents an architectural representation of the Solution Building Blocks (SBBs) supporting the Architecture Landscape which have been planned or deployed by the enterprise

46
Q

Explain the purpose of the Standards Information Base within the Architecture Repository

A

The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for
Standards are stated in a clear and unambiguous manner, so that compliance can be objectively assessed

Business Standards:
Standard shared business functions
Standard role and actor definitions
Security and governance standards for business activity
Data Standards:
Standard coding and values for data
Standard structures and formats for data
Standards for origin and ownership of data
Restrictions on replication and access
Applications Standards:
Standard/shared applications supporting specific business functions
Standards for application communication and interoperation
Standards for access, presentation, and style
Technology Standards;
Standard hardware products
Standard software products
Standards for software development

47
Q

Describe the Architecture Repository.

A

The Governance Log provides a repository area to hold shared information relating to the ongoing governance of projects. Maintaining a shared repository of governance information is important, because:

Decisions made during projects (such as standards deviations or the rationale for a particular architectural approach) are important to retain and access on an ongoing basis
For example, if a system is to be replaced, having sight of the key architectural decisions that shaped the initial implementation is highly valuable, as it will highlight constraints that may otherwise be obscured

48
Q

Describe the classes of information held in the Architecture Repository.

A

The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content
The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository
The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time
The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization
The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise
The Governance Log provides a record of governance activity across the enterprise
The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
The Solutions Landscape presents an architectural representation of the Solution Building Blocks (SBBs) supporting the Architecture Landscape which have been planned or deployed by the enterprise

49
Q

List the three levels of the Architecture Landscape.

A
Strategic Architectures (see Part I, 3.74 Strategic Architecture) show a long-term summary view of the entire enterprise. Strategic Architectures provide an organizing framework for operational and change activity and allow for direction setting at an executive level.
Segment Architectures (see Part I, 3.64 Segment Architecture) provide more detailed operating models for areas within an enterprise. Segment Architectures can be used at the program or portfolio level to organize and operationally align more detailed change activity.
Capability Architectures (see Part I, 3.31 Capability Architecture) show in a more detailed fashion how the enterprise can support a particular unit of capability. Capability Architectures are used to provide an overview of current capability, target capability, and capability increments and allow for individual work packages and projects to be grouped within managed portfolios and programs.
50
Q

Foundation Architecture

A

A Foundation Architecture consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built. The TOGAF ADM is a process that would support specialization of such Foundation Architectures in order to create organization-specific models.

The TOGAF TRM is an example of a Foundation Architecture. It is a fundamental architecture upon which other, more specific architectures can be based. See the TOGAF® Series Guide: The TOGAF® Technical Reference Model (TRM) for more details.

51
Q

Explain the role of the TRM as a Foundation Architecture.

A

The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture is embodied within the TRM, which provides a model and taxonomy of generic platform services. The TRM is universally applicable and, therefore, can be used to build any system architecture

52
Q

Briefly explain the basic concepts of the III-RM.

A

A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated information infrastructure  An associated III-RM graphic, which provides a visual representation of the taxonomy, and the inter-relationship of the components, as an aid to understanding

53
Q

Briefly explain the relationship of the III-RM to the concept of Boundaryless Information Flow.

A

Integrated information so that different and potentially conflicting pieces of information are not distributed throughout different systems  Integrated access to that information so that staff can access all the information they need and have a right to, through one convenient interface

54
Q

Explain why Architecture Governance is beneficial.

A

Best practices for the submission, adoption, re-use, reporting, and retirement of architecture policies, procedures, roles, skills, organizational structures, and support services
Organizational responsibilities and structures to support the Architecture Governance processes and reporting requirements
Integration of tools and processes to facilitate the take-up of the processes, both procedurally and culturally
Criteria for the control of the Architecture Governance processes, dispensations, compliance assessments, SLAs, and OLAs
Internal and external requirements for the effectiveness, efficiency, confidentiality, integrity, availability, compliance, and reliability of all Architecture Governance-related information, services, and processes