Using togaf™ in government_enterprise_architecture_to_describe_the_business_architecture_02_nov11

Architecting the Enterprise Limited Copyright © 2010

Using The Open Group Architecture Framework (TOGAF) in

Government Enterprise Architecture to Describe the

Business Architecture –

US Government Federal Enterprise Architecture / Federal Segment

Architecture Methodology (FEA/FSAM) as an Example

Presented by

John Polgreen, Ph.D.

Architecting the Enterprise


Welcome!


Introductions

Presentation

Introduction to TOGAF with FEA/FSAM

Setting the Stage by Visioning

Conducting the Business Architecture

Steps

Artifacts created

Case Studies

Panel Discussion / Q&A

Agenda


Who’s Who

Presenter

John Polgreen Architecting the Enterprise

Moderator

Simon Lofthouse The Open Group

Panelists

Judith Jones Architecting the Enterprise

Ed Harrington Architecting the Enterprise

Rafal Jablonka Architecting the Enterprise

Greg Lettow ComponentWave

Jim Odrowski ComponentWave

Aleks Buterman Senseagility

Robert Weisman Build the Vision

David Epperly ArchangelIT


Our Approach

Descriptive, not Critical

Not in Scope Nature of EA – do we

Align IT with Business

Architect the Enterprise

Nature of Business Architecture – is it

A separate domain

Holistic sum of all domains

Status of the Business Architecture Profession – is it

Part of EA

Part of Strategic Planning


Business-led architecture is more successful in meeting

strategic goals, responding to changing mission needs,

and serving citizens’ expectations than technology- or

budget- driven architecture.

FEA Practice Guidance

Primacy of Business Architecture


FEA/FSAM very business driven

FEA has well defined reference architecture for business

OMB, CIO Council has provided guidance on process

FSAM provides guidance for segment architectures

But architects may need…

More granular process information

More templates, examples of outputs

Common language

The Situation


Augment Practice Guidance, FEA, FSAM with TOGAF

TOGAF ADM has a well defined process for business architecture

Templates and formats for outputs available

Accepted globally – provides common language

Popular EA tools have FEA and TOGAF modules

TOGAF maps well to FEA, FSAM and FEA Guidance

TOGAF is meant to to be tailored – don’t throw anything away

TOGAF ADM can also map to DoDAF

A Potential Solution


The Open Group Architecture Framework, v 9

Developed by consensus in The Open Group

Federal roots - DoD’s TAFIM

Architecture Development Method is well proven

80% of Fortune 50 use TOGAF

Wide public sector use

UK Government

New York State

Well accepted among Federal contractors

TOGAF 9


Developing EA with TOGAF

AB

C

D

EF

G

H

Requirements

Management

Preliminary

Architecture Development Method

Enterprise Continuum


FEA Reference Architectures

Busin

ess-D

riven

Appro

ach

Performance Reference Model (PRM)

Business Reference Model (BRM)

Service Component Reference Model (SRM)

Data Reference Model (DRM)

Technical Reference Model (TRM)

Com

ponent-B

ased

Arc

hite

ctu

re


Mapping FEA Practice Guidance to the TOGAF ADM

ADM PhasesPreliminary

A – Vision

B – Business Architecture

C – Information Architecture

D – Technology Architecture

Requirements Management

ADM PhaseE – Opportunities and

Solutions

ADM Phases F- Migration

G – Implementation

Governance

H – Change

Management


US Federal Segments and Services


FSAM to TOGAF ADM Mapping

Phase A

Vision Phase B

Business

ArchitecturePhases C-D

Data,

Application,

Technology

Architectures

Phases E-F

Opportunities

and Solution,

Migration

Planning

FSAM StepTOGAF ADM Phase


USDA Case Study Conclusions

“TOGAF and the FEA provided a good combination for planning a large

government-based modernization project.”

Greg Lettow, Jim Odrowski


Strategic ADM iteration

Tailor FEA reference models

Develop strategic architecture

Mile wide, inch deep

To-be states in all domains

Gaps

Transition Strategy

Subsequent ADM iterations

Describe segments

Describe other enterprise projects

Collectively describe rich EA

Applying TOGAF to FEA/FSAM

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

Planning E

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

Strategic Architecture

Segment Architecture(s)

Capability Architectures


Grants Architecture for Agency X

Agency X gives grants to qualified residents

They need to improve all aspects of their grants program

They wish to use Grants.gov as a template

Immediate need is to improve grant disbursement capability


A

B

C

D

E

F

G

H

Preliminary

Requirements

Management

Steps of the Vision Phase

Identify Stakeholders Concerns & Requirements

Confirm Business Goals, Drivers & Constraints

Evaluate Business Capabilities

Assess Readiness for Business Transformation

Define Scope

Confirm Principles

Develop Architecture Vision

Define Target Architecture Value Proposition

Establish Architecture Project

Identify Business Transformation Risks

Develop Statement of Architecture Work


Example Stakeholder Map

SLIDE 19 of 34


A

B

C

D

E

F

G

H

Preliminary

Requirements

Management

Steps of Vision Phase





Define Scope

Confirm Principles







Business Transformation Readiness Assessment

SLIDE 21


A

B

C

D

E

F

G

H

Preliminary

Requirements

Management






Define Scope

Confirm Principles







Value Chain Diagram


Solution Concept Diagram


A

B

C

D

E

F

G

H

Preliminary

Requirements

Management






Define Scope

Confirm Principles







Business Reference Model Definition

The BRM provides a framework facilitating a functional (rather than organizational) view of the federal government’s lines of business (LoBs), including its internal operations and its services for citizens, independent of the agencies, bureaus and offices performing them.

Consolidated Reference Models

In many governments, horizontal interoperability and shared services are

emerging as cornerstones of their e-Government implementations and

capability-based management is also prominent although under many guises.

TOGAF 9


BRM Overview


A

B

C

D

E

F

G

H

Preliminary

Requirements

Management

Business Architecture

• Describe As-is BRM

• Describe To-be BRM

• Conduct Gap Analysis

• Populate PRM Indicators

Business Architecture Phase


A

B

C

DE

F

G

H

Preliminary

Requirements

Management

Business

Steps of the Business Architecture Phase

Develop Baseline Description

Develop Target Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts

Conduct Stakeholder Review

Finalize the Architecture

Create Architecture Definition Document

Select Reference Models, Viewpoints


Taxonomy of Artifacts

part of the

Content

Framework


Commonalities – TOGAF Artifacts with FSAM

Many artifacts are common to both business function model

business value chain

business process model

conceptual data model

business data mapped to key business processes


Business Unit

Actors3rd Party

Actors

Implementation

Actors

ActivityBusiness

Project Team

Architecture

Team

Procurement

Commercial

Solution

Provider

Technical

Design

Authority

Service

Introduction

Service

Management

Publish functional requirements AR C

Publish non-functional

requirements AR C C C I

Publish logical architecture A C R I

Provide reference architecture &

guidelines AR

Issue RFP or specification (as

appropriate) R C A I C

Complete QG2 checklist C C I C AR I

Actor/Role Matrix


Providing Organisation Unit

Cu

sto

mer

Ser

vice

Sale

s, P

rocu

rem

ent

and

M

anu

fact

uri

ng

Engi

nee

rin

g

Hu

man

Res

ou

rces

Gen

eral

Co

un

sel

Co

nsu

min

g O

rgan

isat

ion

Un

it

Customer Service Time-to-Market Enterprise Management &

Support

Enterprise Management &

SupportSales, Procurement and

ManufacturingCustomer Service Sales & Marketing Build-to-Order Enterprise

Management & Support


SupportEngineering Time-to-Market

Supplier CollaborationEnterprise


Supplier Collaboration


SupportHuman Resources Enterprise


General Counsel Enterprise Management &

Support

Business Interaction Matrix


Logical Data Components Map to Business

Functions

Business Function 1 Business Function 2 Business Function 3 Business Function 4

Logical Data Entity 1






Data Entity / Business Function Matrix


Business

Footprint

Diagram


Service/Information Diagram


ManageEngineering

Changes

Support Primary

Human

Resources

BusinessPlanning

Engineering Manufacturing Distribution

Manage Public

Relations

Provide Legal

Services

Perform

Audit

& Controls

Manage

Transportation

Maintain

Facilities

ProvideAdministrative

Services

Develop & Track

Financial Plan

Appropriate

Funds

Manage

Payables

Manage

Receivables

Manage Assets

Plan Human

Resources

Acquire

HumanResources

Develop

Employees

ProvideEmployeeServices

Manage Union

Activities

Terminate Active

Employment

Formulate

Strategy

Develop andMaintain

Business Plan

EstablishCustomer

Requirements

Obtain Sales

Commitments

ProvideCustomerSupport

Research andDevelop

Technology

Engineer and

Design Products

Engineer andDesign

Processes

Design Tools

and Equipment

Plan Material

Requirements

ProcureEquipment

Material & Tools

Manage

Suppliers

PlanManufacturingRequirements

Perform Quality

Engineering

ConvertResourcesto Product

Control

Production

Maintain PlantEquipment &

Tools

ManageWarranty

Activities

Engineer

Packages

Develop &ManageProduct Cost

Develop New

Business

Manage

Inventory

Ship

Products

Marketing &

Sales

Admin Finance Inventory

Functional Decomposition Diagram


A

B

C

DE

F

G

H

Preliminary

Requirements

Management

Business

Steps of the Business Architecture Phase

Develop Baseline Description

Develop Target Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts

Conduct Stakeholder Review

Finalize the Architecture

Create Architecture Definition Document

Select Reference Models, Viewpoints


TOGAF ADM Business Phase maps well to FEA/FSAM provides needed process detail

TOGAF supplies templates and examples

TOGAF is an open standard technology and vendor neutral

intended to be tailored

Inexpensive to use

Value Proposition: TOGAF Business Architecture


TOGAF is industry standard

Consulting resources are available 10,000+ TOGAF Certified Architects globally

Many among large Federal contractors

Small firms also available

TOGAF simplifies communication with Architecture teams

Vendors

Consultants

Value Proposition: TOGAF Business Architecture


For the Community Study federal EA business architecture problems – is TOGAF a fit?

For Agencies Visit www.opengroup.org – download TOGAF

Get someone on your EA team trained/certified

Tailor the FEA/FSAM using TOGAF

Develop, implement and manage your business architecture

Next Steps


USDA Agency A Vision Development

USDA recognizes TOGAF alongside FEA

Agency A needed to begin an EA program to satisfy OMB

CIO was very supportive – supported ADM – started Vision Phase

went with me to 10 Offices

Had me conduct interviews

Held Vision Workshop

Supported development of Vision Document

Vision very well received

Vision immediately used by CPIC for purchase decisions

Some difficulty moving past Vision

Vision was ‘slick’ - confused with full EA

Business owners reluctant to detail Business Architecture


USDA Agency B – Bus Arch Driving IT Modernization

Key Catalogs Driver / Goal / Objective (based on FEA-PRM)

Bus Svc / Function Catalog (based on FEA-BRM)

Current Systems Catalog

Requirements Catalog

Key Matrices Performance Objectives (FEA-PRM) to Business Functions (FEA-BRM)

Current Systems to Business Functions (FEA-BRM)

Target Requirements to Business Functions (FEA-BRM)

Insights / Benefits Bus Arch is foundation for scoping and Bus / IT alignment

Current to Target matrices facilitated migration planning

Answered key questions: Bus. areas under-supported? Areas most important? High IT costs / duplication? System migration targets? Commonality across domain?

► Jim Odrowski & Greg Lettow - ComponentWave, Inc.


Business Architecture at GSA

Context: ONE GSA EA developed by Data Access Technologies, Inc.

Mile wide – inch deep view of the entire agency

Based primarily on a “Value Chain” perspective modeled in accordance with the OMG Model Driven Architecture (MDA) at the highest (CIM) level

Equivalent to a TOGAF 9’s Business Architecture at the Strategic level

Resulted in the definition on numerous Business Segments

Vertical - the Businesses of the Agency: PBS and FSS

Horizontal – supporting the Agency: Finance, HR, Acquisition, etc.

Next were “deep dives” into a number of the segments (still ongoing)

Always initially from a top-down Business perspective (MDA – CIM)

Then developed a platform independent model (OMG PIM) equivalent to TOGAF 9’s Data and Applications Architecture

Finally a platform specific model (OMG PSM) equivalent to TOGAF 9’s Technical Architecture

Key benefit: “Line of Site”: from Business to Technology and back


Poland Government Example

One attempt to create a government EA framework based on TOGAF in 2006, abandoned after the nearest ellections...

Some top-level regulations touching EA matters exist – resulting from European Interoperability Framework – with not so visible impact in real-world

Currently – in terms of EA and TOGAF - ‘bottom-up’ approach works pretty OK – several ministries using fragments of TOGAF on the project / system level.

A few trying to implement bits of EA governance, content framework and adapt ADM – in conjunction with Prince2 and ITIL

The most active departments: Min. of Finance (tax and customs), Min. of Health, Min. of Labour&Social Security, Min. of Interior

No formal recognition of TOGAF as mandated framework, but...

Proven TOGAF knowledge and excpectation of its „appropriate use” start to be a default requirements in majority of big tenders for systems delivery

Main goal is to harmonise e-government initiatives and enable them to utilise a cross-government integration platform (which is being built by the Ministry of Interior), in a common, unified way


Poland Government Example

Messages:

Even without centralised, top level FEAF–like framework and organisation, usage of TOGAF brings similar perspective, language and understanding into otherwise isolated initiatives

Suppliers appreciate when administration “speaks” TOGAF – this means that chances for “civilsied” co-operation and fruitful project completion are bigger

Start small, grow when you can! Starting from defining principles, fixed set of well-defined artifacts and products (consistently requested in every new project, and in a form of a repository!), and nominating 2-4 people devoted to EA and TOGAF can make a huge difference...

Ministeries “borrow” from each other eagerly... When something works fine in one place, others will follow without waiting for the command from the top (usually...)


Business ArchitectureProviding a Context for Business Value for the Enterprise

Government Outcomes

Strategic Departmental Outcomes

Core Program Outcomes

Mandated Programs

Critical Enablers

Internal Services

Info Mgt Info Tech HR, Fin, …

Enabling

Programs

Business

Architecture

FocusDefining

Business

Value

Business

Value

Business

Value

Business

Value

Business

Value

Business

Value

Business

Value

Detailed Business

Requirements


Questions?

Panelist Contact Information

John Polgreen [email protected]

Judith Jones [email protected]

Ed Harrington [email protected]

Rafal Jablonka Rafal [email protected]

Greg Lettow [email protected]

Jim Odrowski [email protected]

Aleks Buterman [email protected]

Robert Weisman [email protected]

David Epperly [email protected]

mailto:[email protected]















mailto:Rafal [email protected]










Using togaf™ in government_enterprise_architecture_to_describe_the_business_architecture_02_nov11

Business

enterprise limited copyright

togaf togaf adm

defined reference architecture

fea guidance togaf

togaf preliminary

togaf modules togaf

business driven fea

business omb