Enterprise Architecture

TOGAF 9.1

FILKOM UB
 The Open Group

Is an international vendor - and technology

neutral consortium that organizations rely on to
lead the development of IT standards and
certifications
Provides guidance and open environment to
enable interoperability and vendor-neutrality
Membership is open to all enterprises, small,
medium and large, anywhere in the world
 The Open Group Vision

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.
 The Open Group Mission

The mission of The Open Group is to drive the creation

of Boundaryless Information Flow achieved by:
Working with customers to capture, understand and address
current and emerging requirements, establish policies, and
share best practices;
Working with suppliers, consortia and standards bodies to
develop consensus and facilitate interoperability, to evolve and
integrate specifications and open source technologies;
Offering a comprehensive set of services to enhance the
operational efficiency of consortia; and
Developing and operating the industry's premier certification
service and encouraging the procurement of certified products.
Themes
 Actitivies

Governing Board work groups

Open CA Work Group
Open CITS Work Group
UNIX Work Group
Member Forums
Architecture, ArchiMate
Enterprise Management, Platform
Real Time & Embedded, Security and Identity Management
Trusted Technology Forum, Jericho Forum
Work Groups
Business Architecture
Cloud Computing
Quantum Lifecycle
Semantic Interoperability, including Universal Data Element Framework (UDEF)
Service Oriented Architecture (SOA)
 What is an enterprise?

TOGAF defines "enterprise" as any collection of

organizations that has a common set of goals.
For example, an enterprise could be:
a government agency,
a whole corporation,
a division of a corporation, a single department, or
a chain of geographically distant organizations linked
together by common ownership.
 What is an enterprise?

The term "enterprise" in the context of

"enterprise architecture" can be used to denote
both an entire enterprise - encompassing all of
its information and technology services,
processes, and infrastructure - and a specific
domain within the enterprise.
In both cases, the architecture crosses multiple
systems, and multiple functional groups within
the enterprise.
 What is an enterprise?

Confusion often arises from the evolving nature

of the term "enterprise".
An extended enterprise nowadays frequently
includes partners, suppliers, and customers.
If the goal is to integrate an extended
enterprise, then the enterprise comprises the
partners, suppliers, and customers, as well as
internal business units.
 What is an enterprise?

The business operating model concept is useful

to determine the nature and scope of the
enterprise architecture within an organization.
Large corporations and government agencies
may comprise multiple enterprises, and may
develop and maintain a number of independent
enterprise architectures to address each one.
 What is an enterprise?

However, there is often much in common about

the information systems in each enterprise, and
there is usually great potential for gain in the
use of a common architecture framework.
For example, a common framework can provide
a basis for the development of an Architecture
Repository for the integration and re-use of
models, designs, and baseline data.
 Why do I need an enterprise
architecture?

Purpose:
to optimize across the enterprise the often fragmented
legacy of processes (both manual and automated) into
an integrated environment that is responsive to change
and supportive of the delivery of the business strategy
 Why do I need an enterprise
architecture?
Today's CEOs know that the effective
management and exploitation of information
through IT is a key factor to business success,
and an indispensable means to achieving
competitive advantage.
An enterprise architecture addresses this need,
by providing a strategic context for the
evolution of the IT system in response to the
constantly changing needs of the business
environment
 Why do I need an enterprise
architecture?
Furthermore, a good enterprise architecture
enables you to achieve the right balance
between IT efficiency and business innovation.
It allows individual business units to innovate
safely in their pursuit of competitive advantage.
At the same time, it ensures the needs of the
organization for an integrated IT strategy are
met, permitting the closest possible synergy
across the extended enterprise.
 Why do I need an enterprise
architecture?

Advantages:
A more efficient business operation:
A more efficient IT operation:
Better return on existing investment, reduced risk for future
investment:
Faster, simpler, and cheaper procurement
 What is an architecture
framework?
An architecture framework is a foundational
structure, or set of structures, which can be
used for developing a broad range of different
architectures.
It should describe a method for (1) designing a
target state of the enterprise in terms of a set of
building blocks, and for (2) showing how the
building blocks fit together.
 What is an architecture
framework?
It should contain a set of tools and provide a
common vocabulary.
It should also include a list of recommended
standards and compliant products that can be
used to implement the building blocks
 What is TOGAF?

TOGAF is an architecture framework.

TOGAF provides the methods and tools for
assisting in the acceptance, production, use, and
maintenance of an enterprise architecture.
It is based on an iterative process model
supported by best practices and a re-usable set
of existing architecture assets.
 What is architecture?

An architecture is the fundamental organization of a system embodied in

its components, their relationships to each other, and to the environment,
and the principles guiding its design and evolution. (ISO/IEC 42010:2007)

Architecture has two meanings depending upon its contextual usage:

(1) A formal description of a system, or a detailed plan of the system at
component level to guide its implementation;
(2) The structure of components, their interrelationships, and the principles
and guidelines governing their design and evolution over time
(TOGAF)
Architecture Types
 The Importance of Governance

An Enterprise Architecture is only as good as the

decision making framework that is established
around it -> governance framework
The Governance Framework depends on
Clear authority structure
The right participants
The Importance of Governance
What do we mean by Governance?

The way in which decisions are made

Who is responsible?
Who is involved?

Who is accountable?
 Governance vs Management
of Enterprise IT (COBIT 5)
Governance ensures that stakeholders needs,
conditions and options are evaluated to determine
balanced, agreed-on enterprise objectives to be
achieved; setting direction through prioritisation and
decision making; and monitoring performance and
compliance against agreed-on direction and objectives
(EDM).
Management plans, builds, runs and monitors activities
in alignment with the direction set by the governance
body to achieve the enterprise objectives (PBRM).
Understand the context of EA and IT Governance!
 What kind of architecture does
TOGAF deal with?
There are 4 architecture domains that are
commonly accepted as subsets of an overall
enterprise architecture, all of which TOGAF is
designed to support:
Business Architecture
Data Architecture
Application Architecture
Technology Architecture
 What kind of architecture does
TOGAF deal with?

Business Architecture defines the business

strategy, governance, organization, and key
business processes.
Data Architecture describes the structure of an
organization's logical and physical data assets
and data management resources.
Application Architecture provides a blueprint
for the individual applications to be deployed,
their interactions, and their relationships to the
core business processes of the organization.
 What kind of architecture does
TOGAF deal with?
The Technology Architecture describes the
logical software and hardware capabilities that
are required to support the deployment of
business, data, and application services.
This includes IT infrastructure, middleware,
networks, communications, processing,
standards, etc.
 Structure of the TOGAF
Document

The structure of the TOGAF documentation

reflects the structure and content of an
Architecture Capability within an enterprise
Structure of the TOGAF Document
 TOGAF 9.1 Components

Architecture Development Method (ADM)

An iterative sequence of steps to develop an
enterprise-wide architecture
ADM Guidelines and Techniques
Guidelines and techniques to support the application
of the ADM
Architecture Content Framework
A detailed model of architectural work products,
including deliverables, artifacts within deliverables,
and the Architecture Building Blocks (ABBs) that
deliverables represent.
 TOGAF 9.1 Components

The Enterprise Continuum

A model for structuring a virtual repository and
methods for classifying architecture and solution
artifacts
TOGAF Reference Models:
The TOGAF Technical Reference Model (TRM)
The Integrated Information Infrastructure Model (III-
RM).
The Architecture Capability Framework
A structured definition of the organizations, skills,
roles and responsibilities to establish and operate an
Enterprise Architecture.
Architecture Development Cycle
(ADM)
 ADM Basic Principles
An iterative method, over the whole process,
between phases and within phases
Each iteration = new decisions:
Enterprise coverage
Level of detail
Time horizon
Architecture asset re-use:
previous ADM iterations
other frameworks, system

models, industry models,

Decisions based on:

Competence / resource availability
Value accruing to the enterprise.
 ADM Basic Principles
Every phase is validated
against and validates the
current requirements of the
business
 Steps within Phases
The phases of the ADM cycle are further divided into steps;
for example, the steps within the architecture development
phases (B, C, D) are as follows:
1. Select reference models, viewpoints and tools
2. Define Baseline Architecture Description
3. Define Target Architecture Description
4. Perform gap analysis
5. Define candidate roadmap components
6. Resolve impacts across the Architecture Landscape
7. Conduct formal stakeholder review
8. Finalize the Architecture
9. Create Architecture Definition Document
 ADM Preliminary Phase
This phase includes the preparation and
initiation activities to create an Architecture
Capability:
Understand business environment
High level management commitment
Agreement on scope
Establish principles
Establish governance structure
Customization of TOGAF
 ADM Phase A
Architecture Vision
Initiates one iteration of the
architecture process
Sets scope, constraints, expectations
Required at the start of every
architecture cycle
Create the Architecture Vision
Validates business context
Creates Statement of Architecture
work
 ADM Phase B
Business Architecture
The fundamental organization of
a business, embodied in
its business processes and people,
their relationships
to each other and the environment,
and the principles governing its
design and evolution
Shows how the organization
meets its business goals
 ADM Phase B
Business Architecture - Contents
Organization structure
Business goals and objectives

Business functions

Business services

Business processes

Business roles

Correlation of organization and

functions.
 ADM Phase B
Business Architecture - Steps
1. Select reference models, viewpoints and
tools
2. Define Baseline Architecture Description
3. Define Target Architecture Description
4. Perform gap analysis
5. Define candidate roadmap components
6. Resolve impacts across the Architecture
Landscape
7. Conduct formal stakeholder review
8. Finalize the Architecture
9. Create Architecture Definition Document
 ADM Phase C
Information Systems Architecture
The fundamental organization of
an IT system, embodied in
The major types of information and
applications that process them
relationships to each other and the
environment, and the principles
governing its design and evolution
Shows how the IT systems meets
the business goals of the
enterprise
 ADM Phase C
Data or Applications first?

It is usually necessary to address both

Not always the case, depending on
project scope and constraints
May be developed in either order, or in
parallel
Theory suggests Data Architecture
comes first
Practical considerations may mean
that starting with Application
Architecture may be more efficient
There will need to be some iteration to
ensure consistency
 ADM Phase C
Technology Architecture
The fundamental organization of
an IT system, embodied in
its hardware, software and
communications technology
their relationships to each other and
the environment,
and the principles governing its
design and evolution
 ADM Phase E
Opportunities and Solutions
Perform initial implementation planning
Identify the major implementation
projects
Determine if an incremental approach is
required, if so define Transition
Architectures
Decide on approach
Make v Buy v Re-Use
Outsource
COTS
Open Source
Assess priorities
Identify dependencies
 ADM Phase F
Migration Planning
For work packages and projects
identified in Phase E perform
Cost/benefit analysis
Risk assessment
Finalize a detailed
Implementation and Migration
Plan
 ADM Phase G
Implementation Governance
Provide architectural oversight
for the implementation.
Defines architecture constraints
on implementation projects
Govern and manage an
Architecture contract
Monitors implementation work
for conformance
Produce a Business Value
Realization.
 ADM Phase H
Architecture Change Management
Provide continual monitoring and a
change management process
Ensures that changes to the
architecture are managed in a
cohesive and architected way
Establishes and supports the
Enterprise Architecture to provide
flexibility to evolve rapidly in response
to changes in the technology or
business environment
Monitors the business and capacity
management.
 Deliverables, Artifacts, and
Building Blocks

Architects executing the ADM will produce a

number of outputs as a result of their efforts,
e.g. process flows, architectural requirements,
project plans, project compliance assessments,
etc.

The TOGAF Architecture Content Framework

provides a structural model for architectural
content that allows major work products to be
consistently defined, structured, and presented.
 Deliverables, Artifacts, and
Building Blocks

The Architecture Content Framework uses the

following three categories to describe the type
of architectural work product within the
context of use:
Deliverable
Artifact
Building block
 Deliverable

A 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.
 Artifact

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
 Building block
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.
Building blocks can be defined at various levels of
detail, depending on what stage of architecture
development has been reached.
For instance, at an early stage, a building block can
simply consist of a name or an outline description.
Later on, a building block may be decomposed into
multiple supporting building blocks and may be
accompanied by a full specification
Relationships between Work
Products
Example of Architecture
Definition Document
ADM Version Numbering
 Scoping the Architecture

Reasons to constrain the scope of architecture:

The organizational authority of the team producing
the architecture
The objectives and stakeholder concerns to be
addressed within the architecture
The availability of people, finance, and other
resources
 Scoping the Architecture

Four dimensions are typically used in order to

define and limit the scope of an architecture:
Breadth
Depth
Time period
Architecture domains
 Breadth

What is the full extent of the enterprise, and

what part of that extent will this architecting
effort deal with?
Many enterprises are very large, effectively
comprising a federation of organizational units that
could validly be considered enterprises in their own
right.
The modern enterprise increasingly extends beyond
its traditional boundaries, to embrace a fuzzy
combination of traditional business enterprise
combined with suppliers, customers, and partners.
 Depth

To what level of detail should the architecting

effort go?
How much architecture is enough?

What is the appropriate demarcation between

the architecture effort and other, related
activities (system design, system engineering,
system development)?
 Time Period

What is the time period that needs to be

articulated for the Architecture Vision, and does
it make sense (in terms of practicality and
resources) for the same period to be covered in
the detailed architecture description?
If not, how many Transition Architectures are to
be defined, and what are their time periods?
 Architecture Domains

A complete enterprise architecture description

should contain all four architecture domains
(business, data, application, technology), but
the realities of resource and time constraints
often mean there is not enough time, funding,
or resources to build a top-down, all-inclusive
architecture description encompassing all four
architecture domains, even if the enterprise
scope is chosen to be less than the full extent of
the overall enterprise.