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 systemA structure of components, their relationships, and governing principles and guidelines related to their design and use

Architectures

TOGAF recognizes four architecture domains:Business ArchitecturesData ArchitecturesApplication Architectures Technology Architectures

Key Concepts of TOGAF

This presentation will briefly highlight the following TOGAF concepts:Architectural Artifacts Architecture PrinciplesEnterprise ContinuumArchitecture ContinuumArchitecture RepositoryArchitecture 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:CatalogsMatricesDiagrams

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 enterpriseConstraints from markets, customers, and legislationSystems and technologiesIndustry 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.

FoundationCommon System

IndustryOrganization

Specific

Enterprise needsBusiness Requirements

Architectural componentsBuilding Blocks

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 MetamodelArchitecture CapabilityArchitecture LandscapeStandards Information BaseReference LibraryGovernance 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 diagramsBuilding 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

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

Preliminary

ADM – Architecture Vision

Objective: To develop a vision of the

business value and capabilities to be

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

Architecture Vision

ADM – Business Architecture

Objective: To develop an appropriate 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.

Business Architecture

ADM – Information System Architectures

Objective: To develop appropriate data

and application architectures

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

Information System

Architecture

ADM – Technology Architecture

Objective: To develop an appropriate

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

Technology Architecture

ADM – Opportunities and Solutions

Objective: To realize the architectures and

deliver business value

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)

Opportunities and Solutions

ADM – Migration Planning

Objective: To create/finalize an implementation

and migration plan

Impact on Architecture: Defines how a target

architecture will be realized from its current baseline

Outputs: Finalized architecture documents, implementation and migration plan

Migration Planning

ADM – Implementation Governance

Objective: To ensure that all implementation

projects conform with architecture

requirements

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

Implementation Governance

ADM – Architecture Change Management

Objective: To manage changes to and resulting

from an architecture

Impact on Architecture: Ensures that the intended

benefits and advantages of an architecture

are realized

Outputs: Changes, updates, new architecture work

Architecture Change

Management

ADM – Requirements Management

Objective: To manage architecture

requirements throughout the ADM

process

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

Requirements Management

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’.