Microsoft PowerPoint - 04 - Architecture Content Framework v1.1

TOGAF 9 Training
Architecture Content Framework

(ACF)
Version 1.1
Module Structure
Architecture Content Framework Overview
Purpose of a Content Framework, and How it Fits with the ADM
Deliverables, Artefacts and Building Blocks
Overview of the Content Framework
TOGAF Metamodel Overview
Core and Extension Content
The Core Metamodel Entities
Catalogs, Matrices and Diagrams
Viewpoints and Views
Stakeholders, Concerns, Viewpoints and Views
Guidelines for Developing Views
© 2009 Capgemini - All rights reserved 2

Module Description
The ACF defines a formal structure for organizing architectural content.
The ADM and ACF can be used together to define architectures, but are mutually exclusive.
The ACF uses Deliverables, Artefacts and Building Blocks for creating, updating, using, reusing and
maintaining architectural content.
For each ADM phase, TOGAF provides a list of recommended Deliverables.
An artefact represents an individual model of a system or solution.
There are both architectural building blocks and solution building blocks.
Architectural Deliverables, Artefacts and Building Blocks are all interrelated.
The Core Content Metamodel provides a basic model with the minimum feature-set.
Content Metamodel Extensions allow the Core Metamodel to be extended to provide additional views
and viewpoints.
The Full Content Metamodel is the Core Content Metamodel with ALL the extensions applied.
TOGAF provides a list of all content model Entities, Objects, Attributes and Relationships.
Building Blocks, Catalogs, Matrices and Diagrams are used to structure and communicate architecture
in a ordered way.
A view is what you see. A viewpoint is where you are looking from.
Standard artefacts (Catalogs, Matrices, Diagrams) are provided for each of the four key viewpoints.

(ACF) Overview
Overview Diagram
Architecture Principles, Information Systems
Vision, and Architecture artefacts
Requirements artefacts capture architecture
are intended to capture models of IT systems,
the surrounding looking at applications and
context of formal data in line with the TOGAF
architecture models. ADM phases.
Technology Architecture
Business Architecture artefacts capture procured
artefacts capture technology assets that are
architectural models used to implement and
of business operation realize information system
looking specifically at: solutions.
•factors that motivate
the enterprise.
•how the enterprise is
organizationally Architecture Realization
structured. artefacts capture change
•what functional roadmaps showing
capabilities the transition between
enterprise has. architecture states and
binding statements that are
used to steer and govern
an implementation of the
architecture.
Information Architecture artefacts can be included as part of the Function entity.
The ACF defines a formal structure for organizing and capturing architectural content.
Integration with the ADM
Each Phase of the ADM will produce various outputs. Many of
these outputs will be architectural content that can used to create
different viewpoints and reused
ADM
Content
•Deliverables
•Diagrams
•Matrices
•Reusable components
ACF
The ACF provides a structured mechanism for organising the content that is
produce during the ADM. The ACF defines architectural content into three
categories Deliverables, Artefacts and Building Blocks
ADM
The ADM and ACF can be used to together to delivery and define architectures, but are mutually
exclusive and can stand-alone and/or be used with other EA Frameworks or Delivery Methods that
require architectural outputs/inputs.
Deliverables, Artefacts & Building Blocks
Deliverable Artefact Building Block

A Deliverable is a work An Artefact is a more A Building Block represents a
product that is granular architectural work (potentially re-usable) component of
contractually specified, product that describes business, IT, or architectural capability
formally reviewed, agreed, architecture from a specific that can be combined with other
and signed off. viewpoint. building blocks to deliver architectures
and solutions.
The Architecture Content Framework uses Deliverables, Artefacts and Building Blocks for creating,
updating, using reusing and maintaining architectural content.
Architecture Deliverables
A Deliverable is a work product

that is contractually specified and
in turn formally reviewed,
agreed, and signed off by the
stakeholders.
An Architecture deliverable may
contain multiple Artefacts.
TOGAF can be used in
conjunction with the set of
deliverables of another
framework, where these have
been deemed to be more
appropriate for a specific
organisation.
For each phase within the ADM, TOGAF provides a lists of recommended Deliverables.

Architectural Artefacts
An artefact is a architectural
work product that describes an
architecture from a specific
viewpoint.
Examples are a network diagram,
a server specification, and a list
of architectural requirements.
Artefacts are generally classified
as Catalogs (lists of things),
Matrices (showing relationships
between things) or Diagrams
(pictures of things).
Artefacts will form the content
of the architecture repository.
An artefact represents an individual model of a system or solution, which could potentially be re-
used in a variety of contexts.

Building Blocks
Represent a reusable component
of business, IT or architectural
capability.
Can be combined with other
building blocks to deliver
architectures and solutions.
Essentially, building blocks are
the things that artefacts depict.
For example, a network diagram
is an artefact that describes the
network (building block) of the
organization.
Building blocks are hierarchical in
nature (i.e. a building block can
contain other building blocks).
There are both architectural building blocks and solution building blocks.

Architecture Patterns
Architecture Patterns and Design Patterns
The term "design pattern" is often used to refer to any pattern which addresses issues of software architecture, design,
or programming implementation.
In Pattern-Oriented Software Architecture: A system of patterns, the authors define these three types of patterns.
Design Pattern An Idiom

Architecture Pattern
Provides a scheme for Low-level pattern specific
Expresses a fundamental refining the subsystems or to a programming
structural organization or components of a software language.
schema for software system, or the relationships
systems. between them. Describes how to
implement particular
Provides a set of Describes a commonly aspects of components or
predefined subsystems, recurring structure of the relationships between
specifies their communicating components them using the features of
responsibilities, that solves a general design the given language.
Includes rules and problem within a particular
guidelines for organizing context.
the relationships between
them.

ACF Content Metamodel
Core Content Metamodel
Principle Constraint Assumption Requirement Gap Work

Package
Organisation Unit Core Content Metamodel
Actor Function
• Describes the core
Metamodel entities and
relationships that should be
Role
considered when capturing
and defining content during
Process the ADM.
• Provides a minimum set of
architectural content to
Business Service support traceability across
artefacts.
Data Application Technical Platform
Entity Component Component Service
The Core Content Metamodel provides a basic model with the minimum feature-set that can
support the inclusion of optional extensions.
Content Metamodel Extensions
Additional Metamodel concepts to support more specific or more in-depth modelling are contained
within a group of extensions that logically cluster extension catalogs, matrices and diagrams,
allowing focus in areas of specific interest.
Content Metamodel Extensions allow the Core Metamodel to be extended to provide additional
views and viewpoints as required by the architecture engagement.
Full Content Metamodel
When all extensions

are applied to the Core
Content Metamodel, a
number of new
Metamodel entities are
introduced to form the
Full Content
Metamodel
The Full Content Metamodel is the Core Content Metamodel with ALL the extensions applied.

Metamodel Entities & Relationships
The TOGAF 9.0 specification provides a list of all content model Entities, Objects, Attributes
and Relationships.
Building Blocks, Catalogs, Matrices & Diagrams
Interactions between the Metamodel, Building Blocks, Diagrams, and Stakeholders.
Other Concepts:
• Diagrams are renderings of
architectural content in a graphical
format to allow stakeholders to
retrieve the required information.
Diagrams can also be used as a
technique for graphically populating
architecture content or for checking
the completeness of information that
has been collected.
• Catalogs are lists of Building Blocks of
a specific type, or of related types,
that are used for governance or
reference purposes (for example, an
organization chart, showing locations
and actors).
• Matrices are used to represent
relationships that are list-based rather
than graphical in their usage.
Building Blocks, Catalogs, Matrices and Diagrams are concepts used to structure and communicate
architecture in a ordered way.
ACF Viewpoints and Views
Stakeholders, Concerns, Viewpoints & Views
Stakeholders are people who have key roles in, or Concerns are the key interests that are crucially important to
concerns about, the system; for example, as users, the stakeholders in the system, and determine the
developers, or managers. Different stakeholders acceptability of the system. Concerns may pertain to any
with different roles in the system will have aspect of the system's functioning, development, or operation,
different concerns. Stakeholders can be individuals, including considerations such as performance, reliability,
teams, or organizations (or classes thereof). security, distribution, and ability to evolve.
A viewpoint defines the A view is a representation of a whole system from the perspective of a related set of
perspective from which concerns.
a view is taken. More
specifically, a viewpoint
defines: how to
construct and use a
view (by means of an
appropriate schema or
template); the
information that should
appear in the view; the
modeling techniques for
expressing and
analyzing the
information; and a
rationale for these
choices (e.g. by
describing the purpose
and intended audience
of the view).
A view is what you see. A viewpoint is where you are looking from.

Standard TOGAF Architecture Viewpoints
Each viewpoint addresses the

architecture from a distinct
perspective:
Business Architecture
viewpoint for users, planners,
and business management.
Applications Architecture
viewpoint for system and
software engineers.
Data Architecture viewpoint for
database designers, database
administrators, and system
engineers.
Technology Architecture
viewpoint for acquirers,
operators and administrators.
Baseline and Target Views
Standard artefacts (Catalogs, Matrices, Diagrams) are provided for each of these four key
viewpoints. We will look at these in more detail as part of Phases B, C, D.
Module Summary
The Architecture Content Framework is a tool that will ensure consistency and traceability within
the ADM and also to provide guidance for organizations that wish to implement their
architecture within an architecture tool.
The ACF is a Enterprise The Core Metamodel can be

Architecture Framework that extended to meet the
can used with delivery modelling requirements of an
methods such as the ADM organisations through the use
of extensions
Architectural Content is
described through three For the full Content Metamodel
major constructs, TOGAF defines entity, objects,
Deliverables, Artefact and attributes and relationships.
Building Blocks
Views and viewpoints can Building Blocks, Catalogs,

be created for each area of Matrices and Diagrams are
an architecture, using concepts used to structure and
building blocks, catalogs, communicate architecture in a
matrices and diagrams ordered way.
The ACF consist of five major aspect areas Architecture Principles & Requirements, Business
Architecture, Information System Architecture, Technology Architecture and Architecture
Realisation

Supporting Slides
The Architecture Content Framework
The Architecture Content Framework provided Enterprise Architecture

here is intended to allow TOGAF to be used as Frameworks
a stand-alone framework for architecture Delivery Methods
within an enterprise.
Also, the content framework provides a useful
reference and starting point for TOGAF content Zachman
to be mapped to other frameworks such as DELIVER
Zachman and the Integrated Architecture
Framework v4.
Integrated Rational Unified
Architecture Process (RUP)
Framework (IAF)
It can be used in conjunction with an delivery
method, such as the formalised Architecture
Delivery Method or can less formalise methods
TOGAF – TOGAF –
that also require/use architecture deliverables, Architecture
Architecture
artefacts and building blocks. Content Framework Delivery Method
(ACF) (ADM)
Like other enterprise architecture frameworks, ITIL

it provides the foundation in which architecture
can be applied, derived, maintained and
reused.
The ACF is a stand-alone framework for architecture within an enterprise.

Deliverables, Artefacts & Building Blocks
Relationships
Architectural Deliverables, Artefacts and Building Blocks are all interrelated.
• A Deliverable will consist of one or many artefacts (catalogue, matrix, diagram).
• Artefacts may be used to describe architectural and/or solution building blocks that can reused over time.
For example, an Architecture Definition Document is a deliverable that documents an architecture description. This
document will contain a number of complimentary artefacts that are views of the building blocks relevant to the
architecture. For example, a process flow diagram (an artefact) may be created to describe the target call handling
process (a building block). This artefact may also describe other building blocks, such as the actors involved in the
process (e.g., a Customer Services Representative).

Characteristics of a Building Block
A building block is a package A building block has a type that

of asset or capability defined corresponds to the TOGAF content
to meet the business needs metamodel (such as actor, business
across an organization. service, application or data entity).
A building block may A building block has a defined

interoperate with other Building boundary and is generally
interdependent building recognizable as “a thing” by
blocks. Blocks domain experts.
A good building block has the following characteristics:

It considers implementation and usage, and evolves to exploit technology and standards.
It may be assembled from other building blocks.
It may be a subassembly of other building blocks.
Ideally a building block is reusable and replaceable, and well specified.
TOGAF defines building blocks as architectural and solution

Architectural Building Blocks &
Solution Building Blocks
Architecture Building Blocks (ABBs) typically Solution Building Blocks (SBBs) represent
describe required capability and shape the components that will be used to implement the
specification of Solution Building Blocks (SBBs). required capability.
Architectures will consist of one Solution architectures will consist

or many architectural building of one or many solution building
blocks. blocks.
Architectures Solution
(Business, Data, Applications, Technology) Architectures
ABB ABB ABB SBB SBB SBB
SBB are built against ABB

Architectural Building Blocks &
Solution Building Blocks
SBB Characteristics
• Define what products and components will implement the
functionality
ABB Characteristics
• Define the implementation
• Capture architecture requirements; e.g., business, data,
applications, and technology requirements • Fulfil business requirements
• Direct and guide the development of SBBs • Are product or vendor-aware
ABB Content SBB Content
• Fundamental functionality and attributes: semantic, • Specific functionality and attributes
unambiguous, including security capability and • Interfaces; the implemented set
manageability
• Required SBBs used with required functionality and names of
• Interfaces: chosen set, supplied the interfaces used
• Interoperability and relationship with other building blocks • Mapping from the SBBs to the IT topology and operational
• Dependent building blocks with required functionality and policies
named user interfaces • Specifications of attributes shared across the environment (not
• Map to business/organizational entities and policies to be confused with
• functionality) such as security, manageability, localizability,
scalability
• Performance, configurability
• Design drivers and constraints, including the physical
architecture
• Relationships between SBBs and ABBs
Architecture Building Blocks (ABBs) relate to Solution Building Blocks (SBBs) relate to the
the Architecture Continuum, and are defined Solutions Continuum (The Solutions
or selected as a result of the application of Continuum), and may be either procured or
the ADM. developed.
Architecture Content Framework Building
Blocks in the ADM
The process of identifying building blocks includes looking for

collections of capabilities or assets that interact with one
another and then drawing them together or making them
different Classes of building block
Consider three classes of building blocks:
1 2 3
Reusable building blocks Building blocks to be the Building blocks to be the
such as legacy items subject of development, subject of purchase; i.e.
such as new applications Commercial Off-The-Shelf
(COTS) applications
Benefits for developing building blocks:

•Work allocation
•Presentation
•Deliverable specification

Architecture Content Framework Building
Blocks in the ADM
Building Blocks are identified, defined, created, updated throughout the ADM cycle.
The process of building block

definition takes place gradually
as the ADM is followed, mainly in
Phases A, B, C, and D.
The major work in these steps

consists of identifying the ABBs
required to meet the business
goals and objectives.
ABBs is then refined in an

iterative process to arrive at a set
of SBBs which can either be
bought off-the-shelf or custom
developed.
The specification of building blocks using the ADM is an evolutionary and iterative process.

Architecture Content Framework Core Content
Metamodel Concepts
There are three major concepts that make up the Content Metamodel
Core Content & The Core Metamodel The catalogue, matrix

Extension Content Entities and diagram concept
Provides an introduction to Introduces the core TOGAF Describes the concept of
the way in which TOGAF Metamodel entities, catalogs, matrices, and
employs a basic core showing the purpose of diagrams.
metamodel and then each entity and the key
applies a number of relationships that support
extension modules to architectural traceability.
address specific
architectural issues.

Content Model Extensions
Content Model Extensions allow the Core Metamodel to be extended to provide additional views and
viewpoints as required by the architecture engagement.
The process modelling
The motivation extension is extension is intended to
intended to allow additional allow detailed modelling of
structured modelling of the process flows by adding
drivers, goals and objectives that events, products and
influence an organization to controls to the
provide business services to its metamodel.
customers.
The governance extension

is intended to allow
The services extension is additional structured data
intended to allow more to be held against
sophisticated modelling of objectives and business
the service portfolio by services.
creating a concept of IS
Services in addition to the
core concept of Business The infrastructure
Services. consolidation extension is
intended to be used in
landscapes where the
The data extension is application and technology
extended include the portfolios have become
concept of an Data fragmented and the
Component. Data architecture seeks to
Components form a consolidate the business as
Logical or Physical usual capability into a
encapsulation of abstract smaller number of locations,
Data Entities into units applications or technology
that can be governed and components.
deployed into
applications.
Content Model Extensions allow the Core Metamodel to be extended to provide additional views
and viewpoints as required by the architecture engagement.
Core Metamodel Entities
Organization. A self contained unit Actor. A person, organization or
of resources with line management system that is outside the
responsibility, goals, objectives and consideration of the architecture
measures. Organizations may model, but interacts with it.
include external parties and
business partner organizations.
Role. An actor assumes a role to

perform a task.
Business Service. Supports business
capabilities through an explicitly
defined interface and is explicitly Application Component. An
governed by an organization. encapsulation of application
functionality that is aligned to
implementation structuring.
Function. Delivers business
capabilities closely aligned to an
organization, but not explicitly Technology Component. An
governed by the organization. encapsulation of technology
infrastructure that represents a
class of technology product or
specific technology product.
Data Entity. An encapsulation of
data that is recognized by a
business domain expert as a
discrete concept. Data entities can Platform Service. A technical
be tied to applications, capability required to provide
repositories and services and may enabling infrastructure that
be structured according to supports the delivery of
implementation considerations. applications.
Business services support Application Process Business

Function describes components are should
organizational objectives and services are
units of business deployed onto normally be
are defined at a level of deployed onto
capability at all technology used to
granularity consistent with the application
levels of granularity components describe flow
level of governance needed components

Guidelines for developing Architecture Views
The choice of which particular architecture views to develop is one of the key decisions that the
architect has to make.
The architecture must It must satisfactorily The choice has to be

adequately address all reconcile the constrained by
the pertinent concerns conflicting concerns considerations of
of its stakeholders of different practicality, and by
stakeholders, the principle of
showing the trade- fitness-for purpose –
offs made in so i.e. develop only to
doing (as between the point at which it
security and is fit-for purpose,
performance, for and not reiterated
example). ad infinitum as an
academic exercise).
Only produce what is relevant and necessary.

Architecture Patterns in Use
The uses of Architecture Patterns in Industry:
The US Treasury Architecture Development Guidance (TADG):

Provides a number of explicit architecture patterns.
Explanation of a rationale, structure, and taxonomy for architectural patterns
related to the US Treasury.
The IBM Patterns for e-Business web site

gives a series of architecture patterns that go from the business problem to
specific solutions, firstly at a generic level and then in terms of specific IBM
product solutions.
A supporting resource is IBM’s set of Red Books.
Examples of where architecture patterns are in use.

Defining & Specifying Interoperability
Requirements
Defining the degree to which the information and services are to be shared is a very useful
architecture requirement.
The determination of interoperability is present throughout Defining Interoperability
ADM as follows: Many organisations find it useful to categorise
interoperability as follows:
Phase A: The nature and security
considerations of the information and
service exchanges.
Operational &
Phase B: The information and service Business Technical
exchanges are further defined in Interoperability Interoperability
business terms.
Phase C: (Data) the content of the Information
information exchanges are detailed Interoperability
using the corporate data and/or
information exchange model. Defines how Defines how
the business technical
Phase C: (Applications) the way the processes are services are to
various applications are to share the to be shared be shared
information and services is specified. Defines how
Phase D: The appropriate technical information is
mechanisms to permit the information to be shared
and service exchanges are specified.
Phase E: The actual solutions (e.g., From an IM/IT perspective others to consider are:
Commercial Off-The-Shelf (COTS)
packages) are selected. Technical Integration Application Integration
Phase F: The interoperability is
logically implemented. Information Integration Presentation Integration
Interoperability is the ability to share information and services.

Example of Defining & Specifying Interoperability
Requirements
Example of defining Interoperability Refining Interoperability
The Canadian Government have a high-level definition of the three classes Implementing Interoperability requires the
of interoperability and identify the nature of the information and creation, management, acceptance, and
services they wish to share. enforcement of realistic standards that are
SMART.
Operational &
Business
Architecture is the key for identifying
standards and facilitated sessions will
Interoperability examine potential pragmatic ways to achieve
Information the degree of interoperability.
Interoperability
Technical Example: The Degrees of Interoperability

Interoperability used within the Canadian Government:
Degree 1: Unstructured Data Exchange

Delivery Networks
e-democracy Degree 2: Structured Data Exchange

Knowledge Management
e-business
Business Intelligence
Enterprise Resource Degree 3: Seamless Sharing of Data
Management Information Management
IT Infrastructure
Relationship and Case Trusted Identity
Management Degree 4: Seamless sharing of information
The degrees are very useful for specifying the way that the information has to be exchanged
between the various systems and provide critical direction to the projects.
Metamodel Extension - Motivation
An external or internal
condition that motivates the
organization to
define its goals. An example
of an external driver is a
change in
regulation or compliance
rules which, for example,
require changes
to the way an organisation
operates; i.e., Sarbanes-
Oxley in the US.
A high-level statement of
intent or direction for an
organization.
Typically used to measure
success of an organisation.
A time-bounded
milestone for an
organisation used to
demonstrate
progress towards a goal;
for example, ‘‘Increase
capacity utilization
by 30% by the end of
2009 to support the
planned increase in
market
share’’.

Phase B - Function vs. Service
A Service is just a special kind of function – one where you have gone
to the extra trouble to define detail about Service Levels

Microsoft PowerPoint - 04 - Architecture Content Framework v1.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft PowerPoint - 04 - Architecture Content Framework v1.1

Uploaded by

Copyright:

Available Formats

TOGAF 9 Training

Architecture Content Framework

© 2009 Capgemini - All rights reserved 2

© 2009 Capgemini - All rights reserved 3

Deliverable Artefact Building Block

A Deliverable is a work product

© 2009 Capgemini - All rights reserved 8

© 2009 Capgemini - All rights reserved 9

© 2009 Capgemini - All rights reserved 10

Design Pattern An Idiom

© 2009 Capgemini - All rights reserved 11

Principle Constraint Assumption Requirement Gap Work

Organisation Unit Core Content Metamodel

When all extensions

© 2009 Capgemini - All rights reserved 15

© 2009 Capgemini - All rights reserved 19

Each viewpoint addresses the

The ACF is a Enterprise The Core Metamodel can be

Views and viewpoints can Building Blocks, Catalogs,

© 2009 Capgemini - All rights reserved 21

The Architecture Content Framework provided Enterprise Architecture

Like other enterprise architecture frameworks, ITIL

The ACF is a stand-alone framework for architecture within an enterprise.

© 2009 Capgemini - All rights reserved 24

A building block is a package A building block has a type that

A building block may A building block has a defined

A good building block has the following characteristics:

TOGAF defines building blocks as architectural and solution

Architectures will consist of one Solution architectures will consist

ABB ABB ABB SBB SBB SBB

SBB are built against ABB

The process of identifying building blocks includes looking for

Benefits for developing building blocks:

© 2009 Capgemini - All rights reserved 28

The process of building block

The major work in these steps

ABBs is then refined in an

© 2009 Capgemini - All rights reserved 29

Core Content & The Core Metamodel The catalogue, matrix

© 2009 Capgemini - All rights reserved 30

The governance extension

Role. An actor assumes a role to

Business services support Application Process Business

© 2009 Capgemini - All rights reserved 32

The architecture must It must satisfactorily The choice has to be

Only produce what is relevant and necessary.

The uses of Architecture Patterns in Industry:

The US Treasury Architecture Development Guidance (TADG):

The IBM Patterns for e-Business web site

Examples of where architecture patterns are in use.

Interoperability is the ability to share information and services.

Technical Example: The Degrees of Interoperability

Degree 1: Unstructured Data Exchange

e-democracy Degree 2: Structured Data Exchange

© 2009 Capgemini - All rights reserved 37

© 2009 Capgemini - All rights reserved 38

You might also like