7/09/2020

Architecture Content Framework

Provides a detailed model of
architectural work products, including
Deliverables, Artifacts within
deliverables, and the Architecture
Building Blocks (ABBs) that deliverables
represent.
 It drives for greater consistency in
the outputs of TOGAF
 It provides a comprehensive
checklist of architecture outputs
 It promotes better integration of
work products
 It provides a detailed open standard
for how architectures should be
described
 It includes a detailed metamodel

2
 7/09/2020

Workproducts
 Artifacts
 Deliverables
 fine grained products that
 Formal products describe an architecture from a
specific viewpoint
 Contractually specified
 For example: use-case
 Outputs from a project specifications, architectural
requirements, network diagrams,
 A deliverable can contain many etc.
artifacts
 Classified as:
 Catalogs (lists of things),
 Building blocks  Matrices (showing relationships
between things) or
 components that can be
 Diagrams (pictures of things).
combined with other building
blocks to deliver architectures  Artifacts make up the content of
the Architecture Repository
and solutions

Deliverables, artifacts and

Building Blocks

4
 7/09/2020

Example – Architecture Definition

Document

The role of Architecture Deliverables

 The contractual or formal work products of an architecture project
 The definition of the set of deliverables provided by TOGAF is a baseline
 It is thus a starting point for tailoring

6
 7/09/2020

Architecture Deliverables
 Architecture Building Blocks  Implementation and Migration
 Architecture Contract Plan
 Architecture Definition Document  Implementation Governance
Model
 Architecture Principles
 Organizational model for
 Architecture Repository Enterprise Architecture
 Architecture Requirements  Request for Architecture Work
 Architecture Roadmap  Requirements Impact
 Architecture Vision Assessment
 Business Principles, Business  Solution Building Blocks
Goals and Business Drivers  Statement of Architecture Work
 Capability Assessment
 Tailored Architecture
 Change Request Framework
 Communications Plan

ADM: Key deliverables

Preliminary Phase A
Statement of Architecture Work
Request for Architecture Work Draft Architecture Definition Document
Governance, Team, Principles Architecture Vision,
EA Capability Communications Plan
Scope, High level Gap,
Enterprise Capability

Phase B
Phase H Architecture Requirements Specification
Request for Architecture Work Document
EA Governance, Detailed Business Gap
Change Decisions Candidate Components of Roadmap
Elaborated Business requirements
Phase C
Phase G Detailed Data & Application Gap
Architecture Contracts Candidate Components of Roadmap
Audit Assessments, Embed Elaborated IS requirements
deliverables into BAU
Phase D
Phase F Detailed Technology Gap
Detailed Road Map Candidate Components of Roadmap
Finalised Implementation & Migration Plan Elaborated Technology requirements
Cost/ Value assessment, agree
Implementation Governance,
Phase E
Lessons Learned, Business Users
Outline Road Map
Architecture Contract
Outline Implementation & Migration Plan
Review Enterprise Capability, ABB SBB

8
 7/09/2020

Enterprise Continuum
 The Enterprise Continuum consists of all architecture assets: models, patterns,
architecture descriptions, etc.
 Models, patterns, architecture descriptions
 Deliverables produced in this iteration of the ADM
 Deliverables produced in other iterations of the ADM
 Assets from the industry at large
 Showing how artifacts evolve

 A model for structuring a virtual repository and methods for classifying

architecture and solution artifacts
 Divided into Architecture and Solutions continuums
 Contents of the Architecture Continuum decided by the AGB (Architecture
Governance Board)

Enterprise Continuum
 Based on architectures and solutions:
 Models, patterns, architecture descriptions
 Deliverables produced in this iteration of the ADM
 Deliverables produced in other iterations of the ADM
 Assets from the industry at large
 Showing how artifacts evolve
 External assets include:
 Generic reference models (eg TOGAF’s TRM, Zachmann…)
 IT-specific models (eg a web services architecture)
 Information Processing-specific models (eg e-Commerce, supply chain management
…)
 Vertical-Industry-specific models (eg TMF, ARTS, POSC…)

10
 7/09/2020

The Enterprise Continuum

11

Building Blocks
 Systems are built from collections of building blocks
 Groupings at the functional such as a customer database are known as
Architecture Building Blocks
 Real products or specific custom developments are known as Solutions Building
Blocks

DB

12
 7/09/2020

The Architecture Continuum

 Arrows represent bi-directional relationship between the different
architectures
 Left to right: meeting enterprise needs and business requirements
 Enterprise needs and business requirements increase in detail from left to right
 Right to left: leveraging architectural components and building blocks
 The architectural elements furthest left are the most reusable
 Requirements for missing elements are passed to the left of the continuum for
inclusion.
 Enterprises can use the same continuum models, specialized for specific
businesses

13

Figure 2

 The most specific architectures are on the right:

 Foundation solutions help to create common systems solutions
 Common systems solutions are used to create industry solutions
 Industry Solutions are used to create organization-specific solutions
 The most generic concepts are on the left.

 The entire spectrum is important when balancing cost and value.

14
 7/09/2020

The Solutions Continuum:

 Represents the implementations of the architectures at the corresponding
levels of the Architecture Continuum
 Is a population of the architecture with Solution Building Blocks, either
purchased products or built components, that represent a solution to the
enterprise's business need
 Forms a Solutions Inventory or Reuse Library, which adds significant value to
the task of managing and implementing improvements to the IT environment

15

TOGAF Reference Models

 TOGAF provides two reference models which can be used as a starting point
to define an Enterprises Architecture:

 The TOGAF Technical Reference Model (TRM)

 The Integrated Information Infrastructure Reference Model (III-RM)

Architecture Continuum

16
 7/09/2020

The 2 TOGAF Reference Models

 Technical Reference Model (TRM)
 A Foundation Architecture
 A model and a taxonomy of generic platform services

 Integrated Information Infrastructure Model (III-RM)

 A model for business applications and infrastructure applications
 Specifically aimed to support the vision of Boundaryless Information Flow™

 Both Reference Models have two main components:

 A taxonomy that defines terminology and provides a coherent description of the
components and conceptual structure of an information system
 An graphic that provide a visual representation as an aid to understanding

17

Boundaryless Information FlowTM

Boundaryless Information Flow™

 achieved through global interoperability
 in a secure, reliable and timely manner

Boundaryless does not mean

there are no boundaries – it
means that boundaries are
permeable to enable
business.

Vision

18
 7/09/2020

Quick Quiz

Q Which of the following best describes the purpose of the TRM?

A. To provide a framework for IT governance

B. To provide a visual model and taxonomy for an information system
C. To provide a list of standards
D. To provide a software development method
E. To provide a system engineering viewpoint in a possible solution

19

Architecture Repository

Part V, Enterprise Continuum and Tools, Chapter 41

20
 7/09/2020

Purpose

 Effective management and leverage of architectural output requires a formal

taxonomy for different types of architectural asset
 TOGAF provides a structural framework for an Architecture Repository
 This is one part of a wider Enterprise Repository

This Architecture Repository is one part of the wider Enterprise Repository.

While the Architecture Repository holds information concerning the enterprise
architecture and associated artifacts there are a number of enterprise
repositories that support the architecture. These include the Requirements
Repository for requirements and the Solutions Repository for Solution Building
Blocks (SBBs) as shown in Figure 28. The Architecture Repository also provides
the capability to link architectural assets to components of the Detailed Design,
Deployment, and Service Management Repositories.

21

Architecture Repository
Describes the architecture
framework in use within the
Enterprise
Contains re-usable
architecture work products

Shows the state of the

operating enterprise at
particular points in time
Defines the compliance
criteria for work governed by
architecture
Captures results of the
governance activity

Describes the organisation,

roles, skills and
responsibilities of the EA
practice

22
 7/09/2020

Architecture Landscape

1. Strategic Architectures:
 show a long-term summary view of the entire enterprise.
 provide an organizing framework for operational and change activity and allow for
direction setting at an executive level.
2. Segment Architectures:
 provide more detailed operating models for areas within an enterprise
 can be used at the program or portfolio level to organize and operationally align more
detailed change activity.
3. Capability Architectures:
 show in a more detail how the enterprise can support a particular capability.
 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.

23

Reference Library

 A repository area to hold best practice or template materials that can be

used to construct architectures within an enterprise.
 Reference materials held in the Reference Library are typically obtained
from a variety of sources, including:
 Standards bodies
 Product and service vendors
 Industry communities or forums
 Corporately defined templates
 Best practice resulting from project implementation

24
 7/09/2020

Standards Information Base

 A repository area to hold a set of specifications, to which

architectures must conform.
 Establishment of a Standards Information Base provides an
unambiguous basis for architectural governance since:
 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

25

Standards Information Base

 Types of Standard  Standards Lifecycle
 Legal and Regulatory  Trial
 Industry  Active
 Organizational  Deprecated
 Obsolete

26
 7/09/2020

Standards Classification
 Business Standards:  Applications Standards:
 Standard shared business functions  Standard/shared applications
 Standard role and actor definitions supporting specific business
functions
 Security and governance standards
for business activity  Standards for application
 Data Standards: communication and interoperation

 Standard coding and values for  Standards for access, presentation,

data and style
 Standard structures and formats  Technology Standards;
for data
 Standard hardware products
 Standards for origin and ownership
of data  Standard software products
 Restrictions on replication and  Standards for software
access
development

27

Governance Log
 A repository area to hold shared information relating to the ongoing
governance of projects.
 Maintaining a shared repository of governance information is important,
since:
 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.
 Many stakeholders are interested in the outcome of project governance (e.g.,
other projects, customers of the project, the Architecture Board, etc.).

28
 7/09/2020

Governance Log Contents

29

Relationship to other Parts of TOGAF

 The TOGAF ADM has reminders when to use assets from the Architecture
Repository
 The Architecture Repository is a model for a physical instance of the
Enterprise Continuum

30
 7/09/2020

Summary
 TOGAF provides a structural framework for a repository that is one part
of a wider Enterprise Repository

 The Architecture Repository is a logical information store for ADM

outputs with six repository areas defined:
 Architecture Metamodel: describes the architecture framework in use within the
Enterprise
 Architecture Landscape: shows the state of the operating Enterprise at particular
points in time
 Reference Library: contains re-usable architecture work products
 Standards Information Base: defines the compliance criteria for work governed by
architecture
 Governance Log: captures results of governance activity
 Architecture Capability: describes the organisation, roles, skills and responsibilities
of the Enterprise Architecture practice

31

Summary
Enterprise @ 2014 Enterprise @ 2010
Business Enterprise @ 2011
Staff App DB Computer
Process
Enterprise @ 2012
Enterprise Continuum
Storage
Catalogue

Catalogue

Diagram
Diagram

Storage
Matrix
Matrix

Repository
artifacts

View View

Viewpoint Viewpoint
Concerns
Concerns
Concerns
Concerns
Concerns
Concerns

Physical
Storage

Stakeholders
Content framework

32
 7/09/2020

Capability Framework

33

Establishing the Architecture Capability

as an Operational Entity
 The Architecture Capability Framework provides guidance on establishing an
operational enterprise architecture practice
 It recommends they include capabilities such as:
 Financial Management
 Performance Management
 Service Management
 Risk Management
 Resource Management
 Communications and Stakeholder Management
 Quality Management
 Supplier Management
 Configuration Management
 Environment Management

34
 7/09/2020

Quick Quiz

Q: Which of the following is not considered one of the main parts of TOGAF?

A. Architecture Development Method

B. Enterprise Continuum
C. TOGAF Reference Models
D. TOGAF Resource Base

35

Interoperability

 Interoperability is ‘‘the ability to share information and services’’

 Defining the degree to which information and services are to be shared is

very important, especially in a complex organization and/or extended

enterprise.

36
 7/09/2020

Interoperability and the ADM

The determination of interoperability occurs throughout the ADM:

 Architecture Vision: the nature and security considerations of

information and service exchanges are found using business
scenarios.
 Business Architecture: information and service exchanges are defined
in business terms.
 Data Architecture: the content of information exchanges is detailed
using the corporate data and/or information exchange model.
 Application Architecture: the way applications are to share
information and services is specified.
 Technology Architecture: appropriate technical mechanisms to
permit information and service exchanges are specified.
 Opportunities & Solutions: actual solutions are selected.
 Migration Planning: interoperability is implemented logically.

37

The Business Transformation Readiness

Assessments
 Enterprise architecture often involves considerable change so
understanding the readiness of an organization to accept change,
identifying the issues, and dealing with them in the Implementation and
Migration Plans is key to a successful implementation.
 An initial assessment of the Enterprises ability to accept the change is
carried out in Phase A
 A re-assessment takes place in Phase E
 This is a joint effort between corporate (especially human resources)
staff, lines of business and IT planners.

38
 7/09/2020

Capability based planning

 Capability-based planning is a technique that focuses on the
planning, engineering and delivery of strategic business
capabilities.

 It frames all phases of the architecture development in the

context of business outcomes, clearly linking the IT vision,
architectures (ABBs and SBBs), and the Implementation and
Migration Plans with the corporate strategic, business, and
line of business plans.

39

Capabilities

40
 7/09/2020

Capability based planning

Capabilities are directly derived from the corporate
strategic plan. They must satisfy the enterprise goals,
objectives, and strategies. Most organizations will
also have an annual business plan.
 All of the architectures are expressed in terms of business outcomes and
value.
 Phase A: Driven by the corporate strategic direction
 Phases B, C, and D: specific capabilities are targeted for completion.
 Phase E: Driven by capability increments

41

Capability based planning

42
 7/09/2020

Deliverables, Artifacts,
and Building Blocks

 DELIVERABLE is a work product that is

contractually specified and in turn formally
reviewed, agreed, and signed off by the
stakeholders. Deliverables represent the output of
projects and those deliverables that are in
documentation form will typically be archived at
completion of a project, or transitioned into an
Architecture Repository as a reference model,
standard, or snapshot of the Architecture
Landscape at a point in time.

 An ARTIFACT is an architectural work product that describes an aspect of the architecture. Artifacts are
generally classified as catalogs (lists of things), matrices (showing relationships between things), and
diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a
use-case diagram. An architectural deliverable may contain many artifacts and artifacts will form the
content of the Architecture Repository.
 A BUILDING BLOCK represents a (potentially re-usable) component of business, IT, or architectural
capability that can be combined with other building blocks to deliver architectures and solutions. 43

43

Example - Architecture Definition Document

Building blocks can be defined at various levels of detail, depending on what stage of
architecture development has been reached
•Architecture Building Blocks (ABBs) typically describe required capability and shape the
specification of Solution Building Blocks (SBBs). For example, a customer services capability may be
required within an enterprise, supported by many SBBs, such as processes, data, and application
software.
•Solution Building Blocks (SBBs) represent components that will be used to implement the
required capability. For example, a network is a building block that can be described through
complementary artifacts and then put to use to realize solutions for the enterprise.

44

44
 7/09/2020

Part I
revisit-

45

45