Developing Enterprise Architecture

TOGAF
Introduction
In the previous presentation, we explored the Zachman
Framework to identify that an enterprise architecture
can be expressed in terms of perspective, metamodels,
and components.

While informative, the Zachman Framework does not

describe how these concepts can be applied to the
development of specific enterprise-based systems. To
resolve this dilemma, we will be exploring The Open
Group Architecture Framework (TOGAF).
TOGAF
TOGAF provides a means of consistently developing,
organizing, and managing multiple architectures
used by an enterprise.

In TOGAF, architecture is defined as:

A formal description of a system
A structure of components, their relationships, and
governing principles and guidelines related to their
design and use
Architectures
TOGAF recognizes four architecture domains:
Business Architectures
Data Architectures
Application Architectures
Technology Architectures
Key Concepts of TOGAF
This presentation will briefly highlight the following
TOGAF concepts:
ArchitecturalArtifacts
Architecture Principles
Enterprise Continuum
Architecture Continuum
Architecture Repository
Architecture Content Framework
Technical Reference Model (TRM)
Architecture Development Method (ADM)
Artifacts
Architectural artifacts are used to describe a solution’s or
system’s architecture. They are the logical and physical
components of the system.

Artifacts can be classified into one of the following:

Catalogs
Matrices
Diagrams

TOGAF identifies 56 different core artifacts recommended

for the Core Content Metamodel. Artifacts may be identified
through the view one takes of a system; thus, they may not
be visible from another view.
Views
Stakeholders are people who have an interest
in a system.

Concerns represent the communicated

interests of a stakeholder.

Requirements can be ascertained from

stakeholder concerns.

A view represents the system from a related

set of concerns.

A viewpoint is a reusable definition of a view.

The definition includes the stakeholder, their
concerns, and other relevant information.
Principles
Architectural Principles are rules and guidelines used to
support decision-making in creating, maintaining, and using
an enterprise architecture.

All principles have reason(s) for their existence (rationale),

which is typically related to achieving business objectives
and understanding impact (implication) for adopting the
principle in system architectures.

Principles are influenced by:

Strategies and plans of the enterprise
Constraints from markets, customers, and legislation
Systems and technologies
Industry and global trends
 Architecture Continuum
The Architecture Continuum is used to define the rules,
representations, and relationships within an architecture.
Architectures evolve as they address needs and
requirements.

Common Organization
Foundation Industry
System Specific

Architectural components Enterprise needs

Building Blocks Business Requirements
Architecture Repository
The development of an organizational-specific architecture
requires the use of, and even generates, significant amount
of information.

This information can be stored in the Architecture

Repository.

The Architecture Repository will hold six classes of

information:
Architecture Metamodel
Architecture Capability
Architecture Landscape
Standards Information Base
Reference Library
Governance Log
Architecture Content Framework
A content framework is a structural model which allows an
architecture to define, structure, and present major work
products in a consistent models.

Architectural work products consist of:

Deliverables – contractually required outputs of a process
or project
Artifacts – catalogs, matrices, and diagrams
Building Blocks – reusable components of a business, IT,
or architecture

The Architecture Content Framework comprises a large

portion of the Architecture Repository.
Content Metamodel
Technical Reference Model
Architecture Development Method
ADM – Preliminary
Objective: To determine and establish the
organization’s capability to accept an
Preliminary
architecture (Architecture Capability)

Impact on Architecture: Defines the

Architecture Principles for all architecture work done by the
organization

External Influences: Other management frameworks such as

Business Planning, Project Management, IT Operations, and
Solution Development (ITIL, COBIT, etc.)

Outputs: Business principles, goals, and drivers

ADM – Architecture Vision
Objective: To develop a vision of the
business value and capabilities to be Architecture
Vision
delivered by the enterprise architecture

Impact on Architecture: Defines the scope of the

architecture effort

External Influences: Stakeholders, their concerns and

requirements

Outputs: Approved statement of architecture work,

architecture definition document, stakeholder maps, value
chains, and solution concepts
ADM – Business Architecture
Objective: To develop an appropriate business
architecture
Business
Architecture
Impact on Architecture: Demonstrates how
business value is obtained from all architecture
work

Outputs: Business models, several catalogs, matrices and

diagrams relevant to the Business Architecture

Business Architecture is the foundation from which the

Data, Application, and Technology Architectures are
derived.
ADM – Information System Architectures

Objective: To develop appropriate data

and application architectures Information
System
Architecture
Impact on Architecture: Defines the
architecture capabilities for data management,
data migration, data governance, and application-based
functionality for the organization

Outputs: several catalogs, matrices, and diagrams

ADM – Technology Architecture

Objective: To develop an appropriate

technology architecture Technology
Architecture
Impact on Architecture: Utilizes any IT
Service Catalog, the Technical Reference
Model, and Technology Models to create a technology
architecture capable of supporting the Business, Data,
and Application architectures

Outputs: several catalogs, matrices, and diagrams

ADM – Opportunities and Solutions

Objective: To realize the architectures and

deliver business value Opportunities
and Solutions
Impact on Architecture: Transitions from
concept to actuality through the development
of an architecture roadmap, work packages, transition
architectures, and implementation/migration planning

External Influences: Project Management disciplines

Outputs: Architecture Roadmap (project plan)

ADM – Migration Planning
Objective: To create/finalize an implementation
and migration plan Migration
Planning
Impact on Architecture: Defines how a target
architecture will be realized from its current
baseline

Outputs: Finalized architecture documents,

implementation and migration plan
 ADM – Implementation Governance
Objective: To ensure that all implementation
projects conform with architecture
Implementation
requirements Governance

Impact on Architecture: Transfers knowledge

from architecture to solution

External Influences: Other management frameworks such as

Solution Design, Application Development, Release and
Deployment Management, Transition Planning and Support,
Change Management

Outputs: Assessments, change requests, and solutions

complaint to the architecture
ADM – Architecture Change Management
Objective: To manage changes to and resulting Architecture
Change
from an architecture Management

Impact on Architecture: Ensures that the intended

benefits and advantages of an architecture
are realized

Outputs: Changes, updates, new architecture work

ADM – Requirements Management
Objective: To manage architecture
requirements throughout the ADM Requirements
process Management

Impact on Architecture: Defines and manages

all functional and non-functional requirements

Influences: Requirements can be generated from

assumptions, constraints, principles, policies, standards,
guidelines, or specifications

Outputs: Requirements on the architecture

Making TOGAF Work
Be sure to consider all governance and management
frameworks used by your organization.
Align architectural work with IT service management,
specifically any control processes (change,
configuration, and release management).
Ensure everyone is using the same language (i.e.
what is an artifact?).
Identify and classify all components of an
architecture and a solution.
Clearly establish and reuse viewpoints.
The Toolkit
To support the efforts of adopting enterprise architecture
at this point, the Toolkit provides the following aids and
templates:
 Customizable procedures for each ADM phase
 Architecture Definition Document
 Architecture Principles
Moving Forward
Use the aids and templates to create an effective
conversation for enterprise architecture in your
organization.
The template, Architecture Definition Document, is
intended to provide a consistent method of identifying
and documenting the existing and new architectures in
your organization.

Once the process for developing enterprise architecture has

been established and your first working architecture is in
place, the next presentation to view is ‘Managing Enterprise
Architecture’.