Togaf 9.1 Foundation Bulleted

Front 1

TOGAF 9.1 Foundation Bulleted

Back 1

TOGAF flash cards with answers in bulleted form.
Completed on July 12, 2013.

Front 2

What is TOGAF?

Back 2

- Open industry standard
- framework and method
- for enterprise architecture

Front 3

TOGAF certification levels

Back 3

- Level 1: TOGAF 9 Foundation
- Level 2: TOGAF 9 Certified

Front 4

Why is certification important?

Back 4

- Incentive for organizations to standardize
- Open method for EA
- Avoids lock-in to proprietary methods
- Makes EA a well recognized discipline
- Introduces rigor

Front 5

Why become certified?

Back 5

Demonstrates:
- commitment to EA as a discipline
- possess core knowledge of TOGAF and EA
- Open Group publishes you as certified

Front 6

Program vision and principles:

Back 6

- Openness: all countries
- Fairness: You have to pass examinations
- Market relevance: 2 market driven levels
- Learning support: Training courses
- Quality: Open group accredited
- Best practices: In certification industry

Front 7

What is the basic content of TOGAF 9 Foundation

Back 7

- Validation candidate knows TOGAF and EA
- Terminology, basic concepts, core principles
- Purpose of The 7 parts of the TOGAF document
- The ADM cycle: Architecture Development Method

Front 8

What does TOGAF 9 Certified add to Foundation

Back 8

- Validate candidate can also
- analyze and apply TOGAF

Front 9

TOGAF foundation certification test characteristics

Back 9

- 11 topics
- 40 questions
- One hour
- Passing is 22 correct (55%)

Front 10

11 test components

Back 10

- Basic Concepts (2)
- Core Concepts (2)
- Introduction to the ADM (3)
- The enterprise Continuum and Tools (4)
- ADM Phases (9)
- ADM Guidelines and Techniques (6)
- Architecture Governance (4)
- Architecture Views, Viewpoints, and Stakeholders (2)
- Building Blocks (2)
- ADM Deliverables (2)
- TOGAF Reference Models (2)

Front 11

What is TOGAF

Back 11

- TOGAF = The Open Group Architecture Framework
- Methods and tools for enterprise architecture
- Acceptance, production, use, and maintenance
- Based on an iterative process model
- Supported by best practices
- A re-usable set of architecture assets.

Front 12

What is an Enterprise

Back 12

- Collection of organizations with common goals
- Highest organizational level
- Covers all missions and functions
- Can extend to partners, suppliers, customers
- Crosses multiple systems and groups

Front 13

Define Architecture (2 definitions)

Back 13

1. Formal system description
- or detailed system plan as components
- to guide a system's implementation
2. Structure of components
- their inter-relationships
- principles and guidelines governing design
- evolution over time

Front 14

Why do I need Enterprise Architecture

Back 14

- Optimize processes across the enterprise
- Integrated environment
- Responsive to change
- Exploits IT to support business strategy
- Strategic context for IT evolution to needs

Front 15

List business benefits of an EA

Back 15

- More efficient
- Lower cost, faster ROI
- More agile
- Shared capabilities and reuse
- Interoperability
- Security
- Reduced complexity
- Reduced risk of failure
- Better and faster procurement

Front 16

What is an architecture framework

Back 16

- Foundational structure(s) to develop architectures
- Describe a method for designing a target state
- Describes architecture using building blocks
- Provides set of tools and common vocabulary
- Includes recommended standards, compliant products
to implement building blocks

Front 17

Why do I need a framework for EA

Back 17

- Speed and simplify architecture development
- Ensure coverage of the designed solution
- Allow for future growth
- Assure solution responds to business needs
- Comply with regulations

Front 18

Why is TOGAF suitable as an EA framework

Back 18

- Developed by 300 leading IT companies
- TOGAF provides:
-- consistent architectures
-- reflect stakeholder needs
-- employ best practice
-- reduces risks
-- considers current and future needs

Front 19

List the 4 architecture domains

Back 19

- Business
- Data
- Application
- Technology

Front 20

Business Architecture domain covers

Back 20

- Business strategy
- Business Governance
- Business Organization
- Key business processes

Front 21

Data Architecture domain covers

Back 21

- Logical and physical data asset structure
- Data management resources.

Front 22

Application Architecture domain covers

Back 22

- Blueprint for deployed application systems
- Interactions of systems
- Relationships to core business processes

Front 23

Technology Architecture domain covers

Back 23

- Software and hardware capabilities
- Support for business, data, application services
- Includes
-- IT infrastructure
-- middleware
-- networks
-- communications
-- processing
-- standards

Front 24

TOGAF contains (list the 7 parts)

Back 24

1: Introduction
2: Architecture Development Method
3: ADM Guidelines and Techniques
4: Architecture Content Framework
5: Enterprise Continuum and Tools
6: TOGAF Reference Models
7: Architecture Capability Framework

Front 25

Name and describe TOGAF Part I

Back 25

1. Introduction
- Key concepts of enterprise architecture
- TOGAF approach
- definitions of terms
- release notes + version changes

Front 26

Name and describe TOGAF Part II

Back 26

2. Architecture Development Method (ADM)
- Process to derive an EA to address business needs
- The major component of TOGAF
- Architecture development phases in a cycle
- Describes each phase:
-- Objectives
-- Approach
-- Inputs
-- Steps
-- Outputs

Front 27

Name and describe TOGAF Part III

Back 27

3. ADM Guidelines and Techniques
- Guidelines: Address adapting the ADM to you
-- Adaptation of ADM for usage scenarios
-- E.g., Use of iteration, security
- Techniques: Tasks to support the use of the ADM
-- Defining principles
-- Business scenarios
-- Gap analysis
-- Migration planning
-- Risk management

Front 28

Name and describe TOGAF Part IV

Back 28

4. Architecture Content Framework
- Detailed model of architectural work products:
-- Stores the deliverables you create
-- Stores artifacts within deliverables
-- Stores Architectural building blocks (ABB)
-- Stores Solution building blocks (SBB)
- Provides an overview of typical deliverables

Front 29

Name and describe TOGAF Part V

Back 29

5. Enterprise Continuum & Tools
- Model for structuring a virtual repository
- Methods for classifying artifacts
- Shows evolution of artifacts
- Shows how artifacts are used and reused
- Based on industry and enterprise solutions in use

Front 30

Name and describe TOGAF Part VI

Back 30

6. TOGAF Reference Models (2)
- TRM - TOGAF Reference Model
-- A Foundation Architecture
-- Generic services foundations for ABBs
- IIIRM - Integrated Information Infrastructure Reference Model
-- Helps design architectures based on TRM
-- A Common Systems Architecture
-- Supports "Boundaryless information flow"

Front 31

Name and describe TOGAF Part VII

Back 31

7. Architecture Capability Framework
- Address staff and resource management
- Set of resources, guidelines, templates
- Helps architect establish architecture practice

Front 32

List some characteristics of the ADM

Back 32

- Core of TOGAF
- A method of deriving an organization's EA
- Develops content, transitioning, and governance
- An iterative cycle responding to business needs

Front 33

List the 10 ADM phases (P, R, A-H)

Back 33

- P: Preliminary phase
- R: Requirements management
- A: Architecture vision
- B: Business architecture
- C: Information system architectures
- D: Technology architecture
- E: Opportunities and solutions
- F: Migration planning
- G: Implementation governance
- H: Architecture change management

Front 34

Name and describe ADM Preliminary Phase

Back 34

P: Preliminary phase
- Prepare to create an Architectural Capability
- Customization + selection of TOGAF artifacts
- Determine other frameworks to use
- Definition of Architecture Principles

Front 35

Name and describe ADM Requirements Management

Back 35

R: Requirements Management
- Every stage is based on requirements
- Every stage validates requirements
- Requirements are fed in/out of each phase
- Phases address, dispose, and prioritize reqmts

Front 36

Name and describe ADM Phase A

Back 36

A: Architecture vision
- First phase of an ADM cycle
- Define scope, constraints, expectations
- Identify stakeholders
- Create and approve Architecture Vision
- Create Statement of Architecture Work
- Business, data, app, tech archs at 0.1 level

Front 37

Name and describe ADM Phase B

Back 37

B: Business architecture
- Develop architecture in the business domain
- Develop baseline, target architectures, gaps
- Select and develop Architecture Viewpoints
- Select relevant tools and techniques

Front 38

Name and describe ADM Phase C

Back 38

C: Information system architectures
- Develop architecture in the data, app domains
- Develop baseline, target architectures, gaps
- To support the business architecture

Front 39

Name and describe ADM Phase D

Back 39

D: Technology architecture
- Develop architecture in the technology domain
- Develop baseline, target architectures, gaps
- Physical realization of architectural solution:
- Map hardware+software for architectural components

Front 40

Name and describe ADM Phase E

Back 40

E: Opportunities and solutions
- Initial implementation plan, delivery vehicles
- Identify major implementation projects
- Group projects into work packages
- Organize solution building blocks (SBB)
- If incremental, identify transition architectures
- Delivers target architecture from phases A-D

Front 41

Name and describe ADM Phase F

Back 41

F: Migration planning
- Detailed Implementation and migration plans
- To move from baseline to target architecture\
- Map out transition architectures, if needed

Front 42

Name and describe ADM Phase G

Back 42

G: Implementation Governance
- Architectural oversight of implementation
- Prepare, issue, govern Architecture Contracts
- Govern implementation and deployment
- Ensure conformance with target architecture

Front 43

Name and describe ADM Phase H

Back 43

H: Architecture Change Management
- Continual monitoring and change management
- Ensure architecture responds to needs
- Ensure maximum business value of architecture
- Procedures for managing change to target

Front 44

Three categories of ADM work products

Back 44

- Deliverables
- Artifacts
- Building blocks

Front 45

Deliverables are

Back 45

- Work contractually specified
- Reviewed, agreed, signed off by stakeholders
- Archived or stored in an Architecture Repository
- Reference model, standard, or snapshot

Front 46

Artifacts are

Back 46

- Describes an aspect of the architecture
- Components of architectural deliverables

Front 47

Building blocks are

Back 47

- Components of business, IT, architecture
- Can be combined with other building blocks
- Deliver architectures and solutions
- Described by artifacts or building blocks

Front 48

List/summarize 3 kinds of artifacts

Back 48

- Catalogs: lists of things
- Matrices: Show relationships between things
- Diagrams: Pictures or illustrations

Front 49

List some examples of artifacts

Back 49

- Requirements catalog
- Business interaction matrix
- Use case diagram
- Network diagram
- Server specification

Front 50

List/summarize 2 kinds of building blocks

Back 50

- ABB: Architectural building block
-- Describes a required capability
- SBB: Solution building block
-- Implements an architectural capability

Front 51

Describe the Enterprise Continuum

Back 51

- A view of the Architecture Repository
- From generic to organization specific
- Contains Architecture and Solutions Continuum
- Foundational > Common > Industry > Organizational

Front 52

Describe the Architecture Repository

Back 52

- Supports + implements the Enterprise Continuum
- Stores architectural output of ADM work

Front 53

List the 6 mahor components of the Architecture

Back 53

- Architecture Metamodel:
-- Customizations of an architecture framework
- Architecture Capability:
-- Structures and processes to govern the repo
- Architecture Landscape:
-- View of architectural assets in use or planned
- Standards info Base (SIB):
-- Industry standards; selected products; services
- Reference library:
-- Guidelines, templates, patterns, references to use
- Governance log:
-- Record of governance activity

Front 54

What is the Architecture Capability Framework

Back 54

- References and guidelines to establish Architecture Capability
- Run EA capability like an operational unit

Front 55

Contents of the Architecture Capability Framework

Back 55

- Establishing an Architecture Capability
- Architecture Board
- Architecture Compliance
- Architecture Contracts
- Architecture Givernance
- Architecture Maturity models
- Architecture skills framework

Front 56

List some EA capabilities that are needed

Back 56

- Financial management
- Performance management
- Service management
- Risk management
- Resource management
- Communication, stakeholder management
- Quality management
- Supplier management
- Configuration management
- Environment management

Front 57

List some benefits of Architecture Governance

Back 57

- Increased transparency of accountability
- Informed delegation of authority
- Controlled risk management
- Maximum reuse of components and assets
- Proactive control, monitoring, management
- Monitoring, measurement, evaluation, feedback
- Increased visibility
- Greater shareholder value
- Integrates with existing processes
- Adds control capabilities to processes

Front 58

How does TOGAF work with other architectures

Back 58

- TOGAF can include the use of other frameworks
- ADM is framework agnostic

Front 59

Define Application

Back 59

- Deployed and operational IT system
- Distinct from its technology components

Front 60

Define Application Architecture

Back 60

- Major logical grouping of capabilities
- That manage and process business data

Front 61

Define Architecture (2 definitions)

Back 61

1. Formal system description
- or detailed system plan as components
- to guide a system's implementation
2. Structure of components
- their inter-relationships
- principles and guidelines governing design
- evolution over time

Front 62

Define Architecture Continuum

Back 62

- Part of the Enterprise Continuum
- Repository of elements in increasing detail
- Foundational > Common > Industry > Organizational

Front 63

Define Architecture Building Block (ABB)

Back 63

- Constituent of Architecture Model
- Describes a single aspect of overall model

Front 64

Define Architecture Development Method (ADM)

Back 64

- Core of TOGAF
- Step by step approach to develop/use an EA

Front 65

Define Architecture domain

Back 65

- Architectural area being considered
- Business, Data, Application, Technology

Front 66

Define Architectural Framework

Back 66

- Conceptual structure to develop, implement, sustain
- an architecture

Front 67

Define Architectural Principles

Back 67

- Qualitative statement of intent to be met
- Has supporting rationale and importance

Front 68

Define Architecture Vision

Back 68

- Describes an architecture's business value
- Benefits from a successful deployment
- Aspirational vision and boundary

Front 69

Define Baseline

Back 69

- Formally reviewed specification
- Basis for further formal development

Front 70

Define Building Block

Back 70

- Component of business, IT, architectural capability
- Combines with other building blocks
- To deliver architectures and solutions

Front 71

Define Business Architecture

Back 71

- Description of structure and interaction between
- strategy, organization, functions, processes, needs

Front 72

Define Business Governance

Back 72

- Ensuring business processes deliver outcomes
- And adhere to regulations

Front 73

Define Capability

Back 73

- Ability of organization, system, person
- Requires org, people, processes, technology
- E.g., telemarketing dept

Front 74

Define Concerns

Back 74

- Interests important to stakeholders
- Determine acceptability of a solution
- E.g., performance, reliability, security

Front 75

Define Constraint

Back 75

- External factor that prevents an approach or goal
- E.g., Customer data is not consistent

Front 76

Define Data Architecture

Back 76

- Logical and physical data assets
- Structure and interaction
- Data management resources.

Front 77

Define Deliverable

Back 77

- Work contractually specified
- Reviewed, agreed, signed off by stakeholders
- Archived or stored in an Architecture Repository
- Can be: Reference model, standard, or snapshot

Front 78

Define Enterprise

Back 78

- Collection of organizations with common goals
- Highest organizational level
- Covers all missions and functions
- Can extend to partners, suppliers, customers

Front 79

Define Enterprise Continuum

Back 79

- Classifies architecture and solution artifacts
- Contains architecture and solution continuum
- Shows evolution of related architectures

Front 80

Define Foundation Architecture

Back 80

- Generic building blocks
- Principles and guidelines
- Provide foundation for specific architectures

Front 81

Define Gap

Back 81

- Difference between two states
- E.g., Baseline vs Target Architecture

Front 82

Define Governance

Back 82

- Monitoring, managing, steering a business
- Enforces delivery of required business outcome

Front 83

Define Information

Back 83

- Facts, data, opinions in any medium or form

Front 84

Define IT (4 definitions)

Back 84

1. Lifecycle management of info + technology
2. Umbrella including computer industry areas
3. Department assigned to provision IT areas
4. Information Services; Information Management

Front 85

Define Logical Architecture

Back 85

- Implementation-independent definition
- Logical grouping of related physical entities

Front 86

Define Metadata

Back 86

- Data about data
- Describes characteristics of an entity

Front 87

Define Metamodel

Back 87

- Model to describe structure of an architecture

Front 88

Define Method

Back 88

- Defined repeatable approach for a problem

Front 89

Define Methodology

Back 89

- Defined repeatable steps to address a problem
- Defines a process and/or content

Front 90

Define Model

Back 90

- A representation of a subject of interest

Front 91

Define Modeling

Back 91

- Construction of models of a subject
- Enables reasoning, insight, and clarity

Front 92

Define Objective

Back 92

- Time-bound milestone of progress to a goal

Front 93

Define Physical

Back 93

- Description of a real-world entity

Front 94

Define Reference Model (RM)

Back 94

- Abstract framework of entities and relations
- Based on small number of unifying concepts
- Common semantics across implementations

Front 95

Define Repository

Back 95

- System that manages data in an enterprise
- Includes data, processes, other information

Front 96

Define Requirement

Back 96

- Statement of need that must be met

Front 97

Define Segment Architecture

Back 97

- Formal description of areas within enterprise
- E.g., program or portfolio level

Front 98

Define Solution Architecture

Back 98

- Descr of a discrete and focused business operation
- Applies to a single project, release, solution

Front 99

Define Solution Building Block (SBB)

Back 99

- A concrete, physical Building block
- Conforms to an Architectural building block

Front 100

Define Solutions Continuum

Back 100

- Part of the Enterprise Continuum
- Implementations of Architecture Continuum
- Reusable solutions for future implementations

Front 101

Define Stakeholder

Back 101

- Individual, team, or organization
- Interests in or concerns about an architecture

Front 102

Define Strategic Architecture

Back 102

- Formal summary of an entire enterprise
- Framework for operational activity
- Executive level, long term view

Front 103

Define Target Architecture

Back 103

- Description of future state of architecture
- Roadmap of several future states
- Shows evolution/path toward a target state

Front 104

Define Technical Reference Model

Back 104

- Structure that describes components consistently

Front 105

Define Technology Architecture

Back 105

- Logical and physical technology components
- Structure and interaction of components
- Specification of what kinds of hardware is needed

Front 106

Define Transition Architecture

Back 106

- State of an architecture at a point in time
- One or more between baseline and target

Front 107

Define View

Back 107

- Representation of a related set of concerns
- Representation of a model from a viewpoint
- Shows content of concerns to a stakeholder
- A model viewed using a viewpoint (instance)

Front 108

Define Viewpoint

Back 108

- Perspective from which a view is taken (template)
- Specification of presentation of a view
- Filtering of a model from a perspective

Front 109

List ADM iteration levels (3)

Back 109

- Around: Cycle through the phases in order
- Between: E.g., return to B Business from D Tech
- Within: Repeated execution of a phase activities

Front 110

List ADM Phase B-D steps needed per each domain (BDAT) (9)

Back 110

- 1. Select reference models, viewpoints, tools
- 2. Develop baseline __ Architecture Description
- 3. Develop target __ Architecture Description
- 4. Perform gap analysis (target vs baseline)
- 5. Define candidate roadmap components
- 6. Resolve impacts across Architecture landscape
- 7. Conduct formal stakeholder review
- 8. Finalize the __ Architecture
- 9. Create Architecture Definition Document

Front 111

ADM + Enterprise Continuum + Architecture Repository

Back 111

- Continuum categorizes entities created using the ADM
- Repository stores work created using the ADM
- Repository has reference architectures, models, patterns
- ADM phase dictates the types of assets used
- Repo contains Architecture Landscape per iteration
- Reusable components are more generic in the continuum

Front 112

ADM + Foundation Architecture

Back 112

- ADM populates Foundation Architecture with
- Reusable common models, policy, governance

Front 113

ADM + ADM Guidelines and Techniques

Back 113

- G+T is resources, guidelines, templates, techniques
- G+T directly support the use of the ADM
- Separated from the ADM to reduce clutter
- E.g., Iteration, security, gap analysis, principles list

Front 114

Guidelines vs techniques

Back 114

- Guidelines: How to adapt ADM, e.g., iteration
- Techniques: Support specific tasks, e.g. gap analysis

Front 115

Reasons to adapt the ADM to fit your enterprise

Back 115

- Change phase order based on org's maturity
- Change order based on fixed/dictated constraints
- Tailor ADM to use another framework
- Reflect dependencies of other processes
- Adapt ADM to match a vendor/customer's process
- Smaller enterprise might skip phases
- Large enterprises may intertwine ADM

Front 116

What information areas are in Governance Repository

Back 116

- Reference data: Other repo info; e.g., ITIL
- Process status: e.g., compliance assessments
- Audit info: A record of completed governance actions

Front 117

Reasons to scope (constrain) architecture activity

Back 117

- Limits in organizational authority
- Objectives/concerns addressed within architecture
- Resource availability (staff, funds)
- In summary - feasibility

Front 118

Dimensions for limiting architecture scope:

Back 118

- Breadth: Enterprise, segment, capability
- Depth: Level of detail (simple = shallow)
- Time period: Resources vs time, transitions
- Domains: (Business, data, app, tech) vs subset

Front 119

Why do we need integration of architecture domains

Back 119

- Need a consistent frame of reference
- So integrations can be considered as a group

Front 120

Key ADM points

Back 120

- ADM is iterative
- Decisions are made at each iteration
- Reuse from: Previous ADM iterations or other models

Front 121

Enterprise Continuum

Back 121

- Classifies both architecture and solution artifacts
- Contains architecture and solution continuum
- Relationships between generic and org-specific assets

Front 122

How is Enterprise Continuum used to develop architecture

Back 122

- Articulates broad perspective what, why, how designed
- Defines "where in the continuum you are"
- Provides a context-specific consistent language

Front 123

How does the Enterprise Continuum promote component reuse

Back 123

- Organizes reusable components by classifying them
- Is a virtual repository referencing all assets from ADM
- Assets can exist in the enterprise or from outside
- References generic industry reference models (Retail ARTS)
- References patterns specific to IT aspects (web services)

Front 124

List 3 axes Enterprise Continuum uses for classification

Back 124

- Generic (foundation) to specific (organization)
- Abstract (architecture) to concrete (solution)
- Logical to physical

Front 125

List the 2 major components of the Enterprise Continuum

Back 125

- Architecture Continuum
- Solutions Continuum

Front 126

Summarize the Architecture Continuum

Back 126

- A structuring of Architectural building blocks (ABB)
- Guides and selects elements in Solutions Continuum
- Defines derivations from general and relationships
- Allows one to discover commonality and reuse

Front 127

List 4 major models in the Architecture Continuum

Back 127

- Foundation Architectures
- Common system architectures
- Industry architectures
- Organization specific architectures

Front 128

Describe Foundation Architecture

Back 128

- Generic components, relationships, principles, guidelines
- Includes TOGAF Foundation Architecture

Front 129

Describe Common Systems Architecture

Back 129

- Common solutions across relevant domains
- E.g., security, management, network
- Integrated Information Infrastructure Reference Model
- III-RM - relates to boundaryless information flow

Front 130

Describe Industry Architecture

Back 130

- Guides integration of common with industry solutions
- Specific architectures within an industry
- E.g., Retail "Active Store" architecture

Front 131

Describe Organization Specific Architecture

Back 131

- Components specific to your organization

Front 132

Summarize the Solutions Continuum

Back 132

- A structuring of Solution building blocks (SBB)
- Implements the Architecture Continuum

Front 133

List 4 major models in the Solutions Continuum

Back 133

- Foundation Solutions
- Common system Solutions
- Industry Solutions
- Organization specific Solutions

Front 134

Describe Foundation Solutions

Back 134

- Generic solution components, products, services, tools
- E.g., programming languages, operating systems, EDI, ITIL

Front 135

Describe Common Systems Solutions

Back 135

- Implements Common Systems Architectures
- E.g., HA transaction service, security product, SAAS

Front 136

Describe Industry Solutions

Back 136

- Reusable packages specific to an industry
- Products, services, systems, solutions for industry
- E.g., physical database schema, POS device

Front 137

Describe Organization Solutions

Back 137

- Solutions that are unique to the organization
- Structured to support specific SLAs and key metrics

Front 138

Relationship between Architecture and Solutions Continuum

Back 138

- The 4 architectures guide selection of Solutions
- The 4 solutions support and reify the architectures

Front 139

Relationship between Enterprise Continuum and ADM

Back 139

- ADM describes process of moving from
- Foundation architecture toward industry/organization

Front 140

What is the Architecture Repository

Back 140

- A physical instance of the Enterprise Continuum
- Stores architectural output created by the ADM
- Provides a formal taxonomy to classify assets

Front 141

Describe 6 Architecture Repository Components

Back 141

- Architecture Metamodel:
-- Customizations of an architecture framework
- Architecture Capability:
-- Structures and processes to govern the repo
- Architecture Landscape:
-- View of architectural assets in use or planned
- Standards info Base (SIB):
-- Industry standards; selected products; services
- Reference library:
-- Guidelines, templates, patterns, references to use
- Governance log:
-- Record of governance activity

Front 142

List the 3 levels of the Architecture landscape

Back 142

- Strategic architectures: enterprise wide
- Segment architectures: program, dept, portfolio
- Capability architectures: Project, program level

Front 143

What is Enterprise Architecture Capability

Back 143

- Provides reference materials and guidelines

Front 144

List Enterprise Architecture Capability components

Back 144

- Architecture board
- Architecture compliance
- Architecture contracts
- Architecture governance
- Architecture maturity models
-- Evaluate organization's EA maturity
- Architecture skills framework
-- Role, skill, experience norms for EA staff

Front 145

Establishing an Operational Architecture Capability

Back 145

- Run architecture as a business
- Management capabilities in business areas
- Well-defined + effective architectural governance

Front 146

Key elements of any architectural framework

Back 146

- Definition of deliverables
- Description of method to produce

Front 147

ADM Preliminary Phase objectives

Back 147

- Where, what, why, who, how we do architecture
- Determine desired architectural capability
-- Scope who and what in organization is affected
-- Identify existing frameworks and processes
-- Establish capability maturity target
- Establish architecture capability and model
-- Define governance processes
-- Select tools that support the capability
-- Define architectural principles

Front 148

ADM Preliminary Phase approach (7)

Back 148

- Define enterprise, scope, sponsor
- Identify key drivers in organization context
- Define requirements for architecture work
- Define architecture principles
- Define the framework(s) to be used
- Define relationship between frameworks
- Evaluate enterprise's architecture's maturity (CMM)

Front 149

ADM Key driver considerations

Back 149

- Commercial models and budget available
- Stakeholders
- Organization intentions and culture
- Current processes
- Baseline architecture landscape
- Skills and capabilities of the enterprise

Front 150

What frameworks might be coordinated with TOGAF

Back 150

- Business capability/planning management (direction)
- Portfolio/project management methods (staff)
- Operations management methods (delivery)
- Solutions development methods (implementation)

Front 151

ADM Phase A objectives

Back 151

- High-level vision of capabilities needed
- Vision of business value to be delivered
- Approval of Statement of Architecture Work

Front 152

ADM Phase A approach

Back 152

- Create Architecture Vision document
-- Based on Request for Architectural Work
-- Requirements as business scenarios
-- For Business, Data, App, and Technology domains
-- High level baseline + target architectures
- Create/approve Statement of Architecture Work
-- Documents the Architecture Vision
-- Tool for obtaining commitment and consensus

Front 153

Key elements of Architecture Vision

Back 153

- Enterprise mission
- Vision
- Strategy
- Goals

Front 154

ADM Phase B objectives

Back 154

- Develop target business architecture
-- How to operate to achieve business goals
-- How to respond to strategic drivers
-- Address Request for Architecture Work
-- Response to strategic drivers + concerns
- Candidate Architecture Roadmap components
-- Based on gaps between Baseline - Target

Front 155

ADM Phase B approach

Back 155

- Develop the Baseline description
-- Document working assumptions
- Business modeling
-- Extend business scenarios using modeling

Front 156

List some business modeling tools-techniques

Back 156

- Business process models (activity models)
- Use case models
- Class models
- Node connectivity diagrams
- Information exchange matrices

Front 157

List Architecture Repository resources for B

Back 157

- Common systems architectures - generic business
- Generic industry business models
- Enterprise specific building blocks
- Applicable standards

Front 158

ADM Phase C objectives

Back 158

- Develop target Information systems architecture
-- Data architecture
-- Application architecture
-- Enable Business Architecture + vision
-- Address Request for Architecture Work + concerns
- Candidate Architecture Roadmap components
-- Based on gaps between Baseline - Target

Front 159

ADM Phase C approach

Back 159

- Develop Baseline and target descriptions
-- For data and application architecture

Front 160

List 3 key considerations for data architecture

Back 160

- Data management
- Data migration
- Data governance

Front 161

List some data management considerations / tasks

Back 161

- System of record/enterprise master data
- Enterprise standards for components
- How data used by processes, functions, services
- How data created, stored, transported, reported
- Transformations needed to exchange data
- Software requirements (e.g. ETL, data profiling)

Front 162

List Architecture Repository resources for C

Back 162

- Data architecture models
-- E.g., ARTS retail; Energistics Petrochem
- Application architecture models
-- OMG healthcare, finance, etc.
-- Electronic commerce, EDI

Front 163

ADM Phase D objectives

Back 163

- Develop technology architecture
-- Enables data + application architecture
-- Address Request for Architecture Work + concerns
- Candidate Architecture Roadmap components
-- Based on gaps between Baseline - Target

Front 164

ADM Phase D approach

Back 164

- Develop Baseline and target descriptions
-- For technology architecture
-- Physical realization of architectural solution
-- Map hardware+software for architectural components

Front 165

List Architecture Repository resources for C

Back 165

- Existing IT resources
- TOGAF Reference Model (TRM)
- Generic industry reference models
- Technology models for common architectures

Front 166

ADM Phase E key activities

Back 166

- Initial implementation planning
- Define major implementation components
- Group changes into work packages
- Decide on how to implement

Front 167

List choices for how to implement technology

Back 167

- Make
- Buy
- Reuse
- Outsource
- COTS - Commercial off the shelf
- Open source

Front 168

ADM Phase E Objectives

Back 168

- Generate initial Architecture Roadmap
-- Based on gap analysis
-- Based on components from phases B,C,D
- Determine if incremental approach
-- If so, define transition architectures

Front 169

ADM Phase E approach

Back 169

- Concentrates on how to deliver the architecture
- Considers gaps in all architecture domains
- Groups changes into work packages in portfolios
- Define roadmap based on requirements
- Focus on target, realize incremental value
- First-cut implementation and migration plan

Front 170

Key concepts in delivering Phase E target architecture (4)

Back 170

- Architecture roadmap: timeline of work packages
- Work packages: group of logical changes
- Transition architectures: baseline to target
- Implementation and migration plan: schedule

Front 171

ADM Phase F objectives

Back 171

- Finalize the Architecture Roadmap
- Finalize Implementation and Migration Plan
- Ensure plan complies with enterprise's approach
- Ensure cost and business value are understood

Front 172

ADN Phase F approach

Back 172

- Finalize the Architecture Roadmap
- Finalize Implementation and Migration Plan
- Integrate plan with enterprise change activity
- Assess dependencies, cost, benefits of choices

Front 173

ADM Phase G key activities

Back 173

- Architecture oversight for implementation
- Define architecture constraints
- Create, govern and manage Architecture Contract
- Monitor implementation for conformance

Front 174

ADM Phase G Objectives

Back 174

- Ensure conformance of implementation with architecture
- Perform architecture governance functions

Front 175

ADM Phase G approach

Back 175

- Implementation plan to deliver transition architectures
- Phased deployment schedule for architecture roadmap
- Follow organization's governance standards
- Use organization's change management approach
- Define operations framework to deploy solution
- Ensure implementation's compliance with architecture

Front 176

ADM Phase H key activities

Back 176

- Continual monitoring
- A change management process
- Ensure changes are managed as architected
- Provide flexibility to evolve in response to changes
- Monitor the business and capacity management

Front 177

ADM Phase H Objectives

Back 177

- Ensure architecture achieves business value
- Ensure architecture lifecycle is maintained
- Operate the Architecture Governance Framework
- Ensure Architecture Capability meets requirements

Front 178

ADM Phase H approach

Back 178

- Establish a value and change management approach
-- Determines when architecture is permitted to change
-- Determines when a new ADM cycle is initiated

Front 179

List 3 ways to classify approaches to change

Back 179

- Simplification: handle via change management
- Incremental: Change mgmt or partial re-architect
- Re-architect: Repeat the ADM cycle

Front 180

Guidelines for re-architecting vs simplification

Back 180

- If involves more than one stakeholder: re-architect
- If significant to business: re-architect
- If substantial change: re-architect
- If one stakeholder: change management
- Allowed under a dispensation: change management

Front 181

Requirements Management objectives

Back 181

- Ensure Requirements Management in all relevant phases
- Management requirements identified in an ADM phase
- Make requirements available for each ADM phase

Front 182

Requirements management approach

Back 182

- Requirements management process drives ADM
- RM Deals with changes in requirements
- RM does not manage requirements, the ADM does
- Add, dispose, prioritize is done in the ADM, not RM
- Use a Requirements Repository of your choice (COTS)
- Use Business Scenarios

Front 183

What is TOGAF part III again?

Back 183

- ADM Guidelines and Techniques

Front 184

What areas are covered in Part III foundation

Back 184

- Architecture principals
- Stakeholder management
- Architecture patterns
- Business scenarios
- Gap analysis
- Migration planning techniques
- Interoperability requirements
- Business transformation readiness assessment
- Risk management
- Capability based planning

Front 185

Briefly describe guidelines vs techniques

Back 185

- Guidelines document how to adapt the ADM
- Techniques are used when applying the ADM

Front 186

List 4 items included in the guidelines

Back 186

- Ways to apply iteration to the ADM
- Applying ADM at different levels in enterprise
- Security considerations
- Using TOGAF to define SOAs

Front 187

Characteristics of Architecture Principles

Back 187

- A set of rules and guidelines for architecture
- Seldom amended
- Guides the way mission is accomplished
- Guides values, actions, results
- Initial output of Preliminary phase

Front 188

Describe the 2 domains of principles

Back 188

- Enterprise principles
-- Guides and harmonizes decision making
-- Includes principles for business units (HR)
- Architecture principles
-- Reflect enterprise architecture consensus
-- Govern architecture process and its use

Front 189

List the TOGAF principles template elements (4)

Back 189

- Name: Descriptively names the principle
- Statement: Communicates the fundamental rule
- Rationale: Business benefits, precedence
- Implications: Resources, activities, tasks, impact

Front 190

What 5 criteria make an architecture principle good

Back 190

- Understandability: Easily grasped, unambiguous
- Robustness: Precise for consistent decisions
- Completeness: Cover every situation
- Consistency: Does not contradict other principles
- Stability: Enduring, accommodates change

Front 191

What does a business scenario describe

Back 191

- Business process, application, or applications
- Business and technology environment
- Actors (people and components) involved
- Desired outcome

Front 192

List 7 steps used to create business scenarios

Back 192

- Problem: Identify, document, and rank
- Environment: Business and technical
- Objectives: Successful outcomes
- Human actors: Positions and roles
- Computer actors: Elements and roles
- Roles and responsibilities: For each actor
- Refine: If necessary

Front 193

Characteristics of a good business scenario (5)

Back 193

- S: Specific: Defines what needs to be done
- M: Measurable: Clear metrics for success
- A: Actionable: Provides the solution
- R: Realistic: Within time and cost constraints
- T: Time bound: When the opportunity expires

Front 194

Where are business scenarios used in the ADM

Back 194

- A: Architecture Vision - build requirements
- B: Business Architecture - derive BA
- Referenced in all phases - validate reqs

Front 195

What is Gap Analysis

Back 195

- Shortfall between baseline and target architectures
- Validates an architecture being developed
- Considers what is forgotten or missing
- Lists stakeholder concerns not addressed
- Lists ABBs added, updated, deleted

Front 196

List some business domain gaps

Back 196

- People: cross training
- Process: inefficiencies
- Tools: duplicate or missing
- Information
- Measurement
- Financial
- Facilities: buildings, office space

Front 197

List some data domain gaps

Back 197

- Not current
- Not located where needed
- Wrong data
- Not created
- Not consumed
- Relationship gaps

Front 198

Steps to creating a Gap Analysis

Back 198

- Matrix of ABBs: vertical=baseline; Horiz: Target
- Add final row: "New ABBs"
- Add final column: "Eliminated ABBs"
- Fill in "Included", "Eliminated", or add details

Front 199

In what phases is Gap Analysis used

Back 199

- B, C, D, and E

Front 200

Explain the term "Interoperability"

Back 200

- Ability to share information and services

Front 201

List 3 categories of interoperability

Back 201

- Operational/business: shared processes
- Information: Shared information
- Technical: Sharing or connection of services

Front 202

Describe IT interoperability in the 4 domains:

Back 202

- Business: Common look/feel, portal
- Data: Identity, common ontology, shared services
- Application: Common components, reuse
- Technical: Shared methods, systems, services

Front 203

In what ADM phases is interoperability considered

Back 203

- A: Nature and security of information exchange
- B-D: Defined for each domain
- E: Actual solutions are selected
- F: Logical interoperability

Front 204

Describe Business Transformation Readiness Assessment

Back 204

- Technique to understand readiness to accept change
- Identifies issues and solutions in Migration Plan
- Based on Canadian Government BTEP E=Enablement

Front 205

In what ADM phases is Bus Transformation Readiness Assessment used

Back 205

- A: Initial assessment readiness/CMM
- E,F: Selection and implementation

Front 206

What are the 2 levels of risk for Risk Management

Back 206

- Initial: Prior to implementing mitigation
- Residual: After implementing mitigation

Front 207

Process for managing risk (5 steps)

Back 207

- Risk classification
- Risk identification
- Initial risk assessment
- Mitigation and residual risk assessment
- Risk monitoring

Front 208

Where is Risk Management used in the ADM

Back 208

- A: Risk+ mitigation in Statement of Arch Work
- G: Risk ID and mitigation worksheets

Front 209

Describe Capability Based Planning

Back 209

- Business driven: Focuses on business outcomes
- Combines efforts of business lines to achieve
- Useful when a latent capability needed (DR)

Front 210

How is Capability based planning related to the ADM

Back 210

- A: Corporate strategic plan
- B-D: Define corporate projects and ABBs
- E,F: Define transition architectures (increments)

Front 211

What is Architecture Governance (2 verbs)

Back 211

- Practice for managing and controlling architectures

Front 212

What 4 tasks are included in Architecture Governance

Back 212

- Controls for creation and monitoring architectures
- Ensure standards and regulatory compliance
- Processes to support management of processes
- Practices to ensure accountability to stakeholders

Front 213

Governance should embody these 6 characteristics

Back 213

- Discipline: Commitment to adhere and enforce
- Transparency: Viewable implementation/decisions
- Independence: Minimize conflict of interest
- Accountability: Groups accountable and authorized
- Responsibility: Parties responsible to stakeholders
- Fairness: No unfair advantages to parties

Front 214

What should an Architecture Governance Framework do

Back 214

- Ensures integrity/effectiveness of architectures
- Identifies processes to manage architecture
- Elucidates, communicates, manages responsibilities
- Splits content from process

Front 215

List 6 key Architecture Governance processes

Back 215

- Policy management and take-on
- Compliance
- Dispensation
- Monitoring/Reporting
- Business control
- Environment management

Front 216

List 6 key components of architecture governance content

Back 216

- Requirements
- SLAs and OLAs (operational)
- Authority structures
- Organizational standards
- Solutions
- Architectures

Front 217

List benefits of Architecture Governance

Back 217

- Links IT to organizational objectives
- Integrates IT best practices
- Aligns with industry frameworks (e.g., COBIT)
- Enables org to take full advantage of IT assets
- Protects digital assets of organization
- Supports regulatory and best practice requirements
- Visible risk management

Front 218

Why do you need an architecture board

Back 218

- Executive oversight of governance strategy
- Provides political backing needed to succeed

Front 219

List the responsibilities of an Architecture Board

Back 219

- Provides a basis for all architecture decision making
- Enforce consistency among sub-architectures
- Targets for reuse of components
- Flexibility of enterprise architecture to meet needs
- Enforcement of architecture compliance
- Improve architecture maturity
- Ensure architecture-based development
- Visible escalation for out of bounds decisions
- Monitoring/control of Architecture Contracts

Front 220

What is the role of an Architecture Contract

Back 220

- Agreements between development and sponsors
- Architecture deliverables, quality, fitness
- References principles, standards, requirements
- Enables monitoring of adherence to these

Front 221

6 levels of Architecture Compliance of impl to requirements

Back 221

- Irrelevant: No features in common
- Consistent: Some features impl, some missing, in common
- Compliant: All impl compliant, some missing
- Conformant: All impl compliant, some extra
- Fully conformant: Exact match
- Non-conformant: Some impl do not conform to req

Front 222

Describe an Architecture Compliance strategy

Back 222

- Ensures compliance of projects within enterprise
- Prepare project architectures (project views of EA)
- Illustrate impact of projects on EA
- Formal Architecture Compliance Review process
- Involved in service provision and product purchases

Front 223

Purposes of Architecture Compliance Reviews

Back 223

- Catch architecture errors early
- Reduce cost and risk of fixes, faster delivery
- Ensure best practices
- Overview of compliance with standards
- Identify where standards need modification
- Identify services that can be reused
- Document collaboration strategies
- Take advantages of technology advances
- Identify criteria for COTS procurement
- Identify gaps to product and service providers

Front 224

Describe the Architecture Compliance Review Process (12)

Back 224

- 01: Request architecture review
- 02: Identify project principals
- 03: Identify lead and architects
- 04: Determine scope of review
- 05: Tailor checklists
- 06: Schedule review meeting
- 07: Interview project principals
- 08: Analyze completed checklists
- 09: Prepare Architecture Compliance Report
- 10: Present review findings
- 11: Accept review and sign-off
- 12: Send assessment to review coordinator

Front 225

How can you use the ADM to establish an Architecture Capability

Back 225

- ADM cycle to architect/govern an Architecture Capability
- Establish an architecture practice iteratively
- Implement the capability in all 4 BDAT domains

Front 226

Define System

Back 226

- Collection of components
- Organized to accomplish a function(s)

Front 227

Examples of systems

Back 227

- Applications
- Hardware
- Subsystems
- Systems of systems
- Product lines
- Enterprises
- Other aggregations

Front 228

Define Stakeholder

Back 228

- People having key roles or concerns about a system

Front 229

Define Concern

Back 229

- Key interests important to a stakeholder
- Determine acceptability of a system

Front 230

Examples of concerns

Back 230

- Performance
- Reliability
- Security
- Distribution
- Evolvability

Front 231

Define View

Back 231

- Representation of a system from the
perspective of a related set of concerns
- What a stakeholder sees/is interested in
- An instance templated by a viewpoint

Front 232

Define Viewpoint

Back 232

- Defines the perspective of a view
- How to construct, information, models
- Vantage point you are looking from
- A template for a view
- Might involve a specialized language

Front 233

What should an architecture view provide

Back 233

- Should address stakeholder concerns
- Views should be connected to each other
- Conflicting concerns should be reconciled
- Trade-offs made should be documented

Front 234

Recommended steps to create architecture views

Back 234

- Refer to a library of viewpoints (e.g., TOGAF)
- Select key stakeholders
- Analyze their concerns and document them
- Select appropriate viewpoints for concerns
- Generate views using selected viewpoints

Front 235

What is a building block

Back 235

- Functionality that meets a business need
- Has published interfaces to access function
- Interoperates with other building blocks

Front 236

What are characteristics of a good building block

Back 236

- Considers implementation and usage
- Exploits technology and standards
- May be assembled from other building blocks
- May be a subassembly of a building block
- Reusable and replaceable
- Well specified with stable interfaces
- Specification loosely coupled to implementation
- Should conform to standards

Front 237

List and describe 2 types of building blocks

Back 237

- Architecture Building Blocks (ABB)
-- Functional groupings
- Solution Building Blocks (SBB)
-- Real products or custom development

Front 238

List characteristics of ABBs

Back 238

- Define what functionality to be implemented
- Capture architecture requirements (BDAT)
- Direct and guide development of SBBs

Front 239

ABB specifications should contain

Back 239

- Functionality and attributes
- Security, capability, manageability
- Interfaces supplied
- Interoperability and relationships to BBs
- Dependent building blocks
- Mapping to business entities and policies
- List of reusable ABBs

Front 240

List characteristics of SBBs

Back 240

- Define implementing products and components
- Define the implementation
- Fulfill business requirements
- Product and vendor aware

Front 241

SBB specifications should contain

Back 241

- Specific functionality and attributes
- Interfaces implemented
- Required SBBs and interface names
- Mapping from SBBs to IT topology and policies
- Security, capability, manageability
- Performance, configurability
- Design drivers and constraints
- Physical architecture
- Relationships between ABBs and SBBs

Front 242

How does the ADM use building blocks

Back 242

- A: High level model of candidate ABBs
- B-D: Define ABBs for BDAT domains in 9 steps
- E: Select and/or associate SBBs with ABBs.

Front 243

What are the 9 steps in ADM phases B-D

Back 243

- 1: Select reference models, viewpoints, tools
- 2: Develop baseline architecture description
- 3: Develop target architecture description
- 4: Perform gap analysis
- 5: Define candidate roadmap components
- 6: Resolve impacts across Arch landscape
- 7: Formal stakeholder review
- 8: Finalize the architecture
- 9: Create Architecture Definition Document

Front 244

Define Architecture Patterns

Back 244

- An idea that is useful in practical contexts
- A way of putting building blocks into context
- Describe reusable solutions to a problem
- Describe how, when, why, what tradeoffs
- Help architect identify combinations of BBs

Front 245

What is an Architecture Deliverable

Back 245

- Formal work of an architecture project
- Produced as outputs of ADM phases/cycles

Front 246

List some Architecture Deliverables

Back 246

- Architecture building blocks (ABB)
- Architecture contract
- Architecture definition document
- Architecture principles
- Architecture requirements specification
- Architecture roadmap
- Architecture vision
- Business principles, goals, drivers
- Capability assessment
- Request for architecture change
- Communications plan
- Compliance assessment
- Implementation and migration plan
- Implementation governance model
- Organizational model for EA
- Request for architecture work
- requirements impact assessment
- Solution building blocks (SBB)
- Tailored architecture framework

Front 247

Purpose of Architecture building blocks (ABB)

Back 247

- Documentation and models from architecture repo

Front 248

Purpose of Architecture contract

Back 248

- Agreements between development and sponsors
- Deliverables, quality, fitness of purpose
- Produced in Phase G Architecture Governance

Front 249

What is ensured by governing contracts

Back 249

- Continuous monitoring of architecture activities
- Adherence to principles, standards, requirements
- Identification of risks
- Processes and practices to ensure accountability
- Understanding of authority and scope of governance

Front 250

Purpose of Architecture definition document

Back 250

- A qualitative view of architecture intent
- Contains core architecture artifacts BDAT
- Examines baseline, transition, target states
- Created in phase A
- Detailed in phase B-D (BDAT)
- Transition architecture specified in phase E

Front 251

Purpose of Architecture principles

Back 251

- General rules and guidelines
- Inform and support fulfilling mission
- Initial output in Preliminary Phase

Front 252

Purpose of Architecture repository

Back 252

- Stores architecture projects and artifacts

Front 253

Purpose of Architecture requirements specification

Back 253

- A qualitative view of solution with measurement
- What an implementation must do to comply

Front 254

Purpose of Architecture roadmap

Back 254

- Lists work packages to realize target architecture
- Developed in phase E,F, informed by B-D

Front 255

Purpose of Architecture vision

Back 255

- High level summary of changes to target
- Agreement on desired outcome
- Uses Business Scenarios
- Created in Phase A

Front 256

Purpose of Business principles, goals, drivers

Back 256

- Describes needs and ways of working
- Have significant effect on architecture

Front 257

Purpose of Capability assessment

Back 257

- Capability level of enterprise
- Capability maturity of IT
- Define style, formality, and detail
- Capability level of architecture group
- Business readiness to reach target state
- What architecture assets exists/maintained

Front 258

Purpose of Request for architecture change

Back 258

- Start a further ADM cycle of architecture work
- Request a dispensation

Front 259

Purpose of Communications plan

Back 259

- Plan to communicate to stakeholders
- Developed in Phase A

Front 260

Purpose of Compliance assessment

Back 260

- Assure that architecture vision is realized
- Performed in Phase G

Front 261

Purpose of Implementation and migration plan

Back 261

- Schedule of implementation projects
- Includes implementation and migration strategy
- Created in Phase E, finalized in F

Front 262

Purpose of Implementation governance model

Back 262

- Defines how transition architecture is governed
- Produced in Phase F

Front 263

Purpose of Organizational model for EA

Back 263

- Specifies roles and responsibilities in enterprise
- Delivered in preliminary phase

Front 264

Purpose of Request for architecture work

Back 264

- Input to architects to start an ADM cycle
- A result of an approved change request
- Created in preliminary phase

Front 265

Purpose of requirements impact assessment

Back 265

- Assesses current architecture requirements
- Identifies changes and implications of changes

Front 266

Purpose of Solution building blocks (SBB)

Back 266

- Implementation specific building blocks

Front 267

Purpose of Tailored architecture framework

Back 267

- TOGAF needs to be tailored
- Integration with project and process frameworks
- Customization of technology, presentation, tools
- Tailoring for specific projects
- Selection of artifacts and deliverables

Front 268

What is a foundation architecture

Back 268

- An architecture of building blocks
- Supports the complete computing environment

Front 269

What is TOGAF's Technical Reference Model

Back 269

- It is TOGAF's foundation architecture reference model

Front 270

Characteristics of a foundation architecture

Back 270

- Reflects general computing requirements
- Reflects general building blocks
- Defines technology standards for the BBs
- Provides direction for products and services
- Reflects directions and strategies
- Can be used to build any architecture

Front 271

List 2 main components of the TRM

Back 271

- Taxonomy: Coherent description of components
- Model: Visual representation of taxonomy

Front 272

List 3 main parts with 2 interfaces between them:

Back 272

- Applications
- Applications platform interface
- Application platform
- Communication infrastructure interface
- Communications infrastructure

Front 273

What are the two top boxes of TRM for applications

Back 273

- Infrastructure applications
- Business applications

Front 274

List some boxes in the TRM Application Platform

Back 274

- Graphics and image
- Data management
- Data interchange
- User interface
- International operations
- Location and directory
- Transaction processing
- Security
- Software engineering
- System and network management

Front 275

What does III-RM stand for

Back 275

- Integrated Information Infrastructure Reference Model

Front 276

List basic concepts of the III-RM

Back 276

- Focuses on the application software space
- Is a "Common Systems Architecture" in Continuum
- Expands TRM in business and infrastructure apps
- Provides infrastructure for integrated systems
- Enables "Boundaryless information flow"

Front 277

List 2 main components of the III-RM (same as TRM)

Back 277

- Taxonomy: Coherent description of components
- Model: Visual representation of taxonomy

Front 278

List the top, 3 middle, and bottom boxes of III-RM

Back 278

- Top: Information consumer applications
- Mid1: Development tools
- Mid2: Brokering applications
- Mid3: Management utilities
- Bottom: Information provider applications

Front 279

Relationship of III-RM to "Boundaryless Information Flow"

Back 279

- Getting right information to right people
- To support operations of the extended enterprise
- Makes boundaries permeable
- Enables agile interaction of cross-functional teams

Front 280

III-RM provides 2 main benefits

Back 280

- Integrated information: a combined, consistent source
- Integrated access: through one user interface

Front 281

Characteristics of Boundaryless Information Flow

Back 281

- Trademark of the Open Group
- Provides access to integrated information
- Open standards to provide services to extended enterprise
- Combine multiple sources of information
- Securely deliver to where it is needed
- In the right context for the user