using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11

Architecting the Enterprise Limited Copyright © 2010

Using TOGAF™ in Government Enterprise Architecture

to Describe the IT 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

Conducting the IT Architecture

Phases and Steps

Artifacts created

TOGAF for the Cloud

Case Study – USDA Agency

Case Study – UK Government

Value Proposition

Panel Discussion / Q&A

Agenda


Panelists

Judith Jones CEO, Architecting the Enterprise

David Epperly VP, US Operations, Avolution

Ed Harrington Chief Consultant, Architecting the Enterprise

Serge Thorn CIO, Architecting the Enterprise

Greg Lettow Executive Partner, ComponentWave

Jim Odrowski Executive Partner, ComponentWave


Our Approach

Descriptive, not Critical

Use US Government EA as example, much pertains to

Other governments

Corporations

Other organizations

IT Architecture development process described

Application (Service Component)

Data

Technology

Examples from Abacus, courtesy of Avolution Software

Not an endorsement of this or any other product


FEA has well defined reference architectures

OMB, CIO Council FSAM have provided guidance on process

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 - well defined process

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

A Potential Solution


The Open Group Architecture Framework, v 9

Federal roots - DoD’s TAFIM

80% of Fortune 50 use TOGAF

Wide public sector use

UK Government

New York State

Well accepted among Federal contractors

TOGAF 9


Architecture Development Method - ADM

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

PlanningE

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary


ADM mapped to FEA Reference Models

H

Architecture

Change

Management

G

Implementation

Governance

F

Migration

PlanningE

Opportunities

& Solutions

D

Technology

Architecture

C

Information

System

Architectures

C

Information

System

Architectures

Requirements

Management

B

Business

Architecture

A

Architecture

Vision

Preliminary

BRM

SRM

DRM

TRM

PRMPRM


Mapping FEA Practice Guidance to the TOGAF ADM

ADM PhasesPreliminary

A – Vision

B – Business Architecture

C – Information Systems

Architecture

D – Technology Architecture

Requirements Management

ADM PhaseE – Opportunities and

Solutions

ADM Phases F- Migration Planning

G – Implementation

Governance

H – Change

Management


FSAM to TOGAF ADM MappingPhase A

Vision Phase B

Business

ArchitecturePhases C-D

Data,

Application,

Technology

Architectures

Phases E-F

Opportunities

and Solutions,

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


Taxonomy of Artifacts


Architecture Capability Development Example

Example is from industry – mirrors government

Company ABC provides Vehicles for government agencies

Their goals Reduce Sales & Marketing department by 4 FTE

Improve complaint handling capability


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


Business

Footprint

Diagram –

Business

Architecture

CRMERP Auto


Steps of Information Systems Architecture Phase - Application

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

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


Application/Function Matrix –Application Architecture

SLIDE 20 of 55

System \ Functionx

Cu

sto

mer

Ser

vice

Tim

e-to

-Mar

ket

Sup

plie

r C

olla

bo

rati

on

Bu

ild-t

o-O

rder

Sale

s &

Mar

keti

ng

Ente

rpri

se M

anag

emen

t &

Su

pp

ort

CRM X X

ERP Auto

Commerce Engine X X

Architecting the Enterprise Limited Copyright © 2010SLIDE 21 of 55

Application Communication Diagram –Application Architecture

CRM

ERP Auto

Commerce

Engine

• Depicts models and mappings related to communication between applications

• Shows application components and interfaces between components


Software Engineering Diagram –Application Architecture

SLIDE 22 of 55

CRM

ERP Auto


Steps of Information Systems Architecture Phase - Data





Resolve Impacts





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


Data Entity/Business Function Matrix –Data Architecture

SLIDE 24 of 52

Business Functions

Data Entities Complaint Common Faults

Customer Details

Complaint Resolution

Customer Service

Complaint Management Log Complaint

Service(s) - Log ComplaintOwner(s) -

Customer ServiceOperation - CRUD

Service(s) - Log ComplaintOwner(s) -


Customer Service

Complaint Management

Process Complaint

Service(s) -Warranty Report,

Recalls LogOwner(s) -


Service(s) -Warranty Report,

Recalls LogOwner(s) -

Customer ServiceOperation - CRU

Customer Service

Complaint Management

Respond to Compaint

Services() - Log Action, Review

ActionOwner(s) -

Customer ServiceOperation - CRU


Application/Data Matrix – Data Architecture

SLIDE 25 of 52

System \ Data Entities

Complaint Common Faults

Customer Details

Complaint Resolution

Order

CRM

CRUD CRUD CRUD CRUD

ERP Auto

CRUD CRUD

Commerce Engine CRUD


Data Dissemination Diagram –Data Architecture

► Allows effective sizing to be carried out

► Indicates business criticality of application components

► May show data replication

► Can include services that encapsulate data and reside in applications

SLIDE 26 of 52

CRM

Commerce

Engine

• Allows effective sizing to be carried out

• Indicates business criticality of application components


Class Diagram – Data Architecture

SLIDE 27 of 52


Steps of Technology Architecture Phase





Resolve Impacts





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


Technology \ Systemx

CR

M

ERP

Au

to

Co

mm

erce

En

gin

e

War

eho

use

Web Server - Node 1 X



App Server - Node 1 X



Database Server (production) X

Database Server (staging) X

Web Server X

App Server X

Application/Technology Matrix – Technology Architecture


Environments and Locations Diagram –Technology Architecture

Source: Avolution

Commerce

EngineCRM ERP Auto

Application Architecture


Communications Engineering Diagram –Technology Architecture

SLIDE 31 of 49


Taxonomy of Artifacts


Complete the ADM

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


And Over to our Cloud Expert…

Used with permission


Cloud Implications in TOGAF

Cloud use → depends on Service Orientation → Depends on good EA

Is Cloud Computing appropriate for our agency?

Preliminary Phase

Which applications are best candidates?

Vision, E and F Phases

How do we determine interrelationships between systems

business processes

data

Phases B-D

Cloud systems may create re-siloing – what are the data aspects?

What’s the best way to assess and manage our risk profile?

All Phases

What are our actual costs of applications operations today?

Phases E&F

How will cost and performance change?

Phases D, E&F


DWP - we have to achieve – more for less

5% pa real additional cuts from 2008 to 2011: can we do even better with IT running costs?

Dept

spend

Head

count

Service

qualityIT spend

2004 20082007


UK Government Business Vision

GovChannels

Phone

Branch

Internet and TV

Paper

Citizen Record (s)PKI

Other UKGovernment

Systems

DriverLicensing

LocalAuthorities

DWP Users

Citizens

One Hour Service?

NewEnrollments

Others

National ID Register (Future)

Cross Government Initiatives to gain more value, reduce costs and

Improve the UK Citizen’s Quality of Service across the UK and beyond

Business Vision: The Citizen and Government – multi-channel, 365x7x24, one stop shop, trusted, value adding


USDA Agency B – Modernizing the Application Architecture

Key Catalogs Current Systems Catalog

Application / Service Component Portfolio Catalog

Data Component Catalog

Key Matrices Current Systems to Business Functions (FEA-BRM)

System-to-System Dependencies

Target Requirements (Use Cases & Features) to Service Components (FEA-SRM)

Service Component (FEA-SRM) to Data Component (FEA-DRM)

Insights / Benefits Current systems were “silo’d” and lacked data integration, didn’t want to just

replace one “silo” with another “silo”

Established a deliberate plan for reuse / defined common interfaces & shared data –utilized FEA-SRM to find commonality (but need to manage dependencies!)

► Jim Odrowski & Greg Lettow - ComponentWave, Inc.


Tailoring the FEA Service Component Reference Model (SRM)


Description: The SRM provides a component-based framework identifying service components that can be leveraged for reuse.

Source: Federal Enterprise Architecture Service Component Reference Model (FEA-SRM).

Actions Taken: Selected a subset of the FEA-SRM based on relevance to USDA requirements.

FEA-SRM Service DomainFEA-SRM Service Type (Subsystem)

Customer Preferences - defines the set of capabilities that allow

an organization's customers to change a user interface and the way that

data is displayed.

Personalization – defines the set of capabilities to change a user interface

and how data is displayed.

Alerts and Notifications – defines the set of capabilities that allow a

customer to be contacted in relation to a subscription or service of

interest.

Subscriptions – allow a customer to join a forum, listserv, or mailing list.

Questions Answered:

What subsystem boundaries can be established?

What service components can be leveraged from the SRM?

FEA-SRM Service Components


Identifying Dependencies Between Service Components


Service Component Architecture – Questions Answered:

What components exist to support delivery of a particular initiative?

What is the relative complexity of delivering a particular initiative?

What are the overall dependencies between components?

What “core” components should be designed / developed in initial modernization releases / iterations?

Customer Service

Accounts Payable

Accounts

Payable

Financial Management

Penalty Calculator

Penalty

Calculator

Analysis and Statistics

Workflow Manager

Workflow

Manager

Workflow Manager

Management of Process

Policy Evaluation

Policy

Evaluation

Business Management Services

Tracking and Workflow

Back Office Services

Business Analytical Services

Profile Management

Profile

Management

Customer Preferences


Service Component Specification - Purpose

For each Service Component it answers the following questions:

► What is the design specification for the component?

► Is this component a candidate for reuse in my application?

► How do I use the component?

► How do I extend / modify the component?

Service Component Specification

1.0 Overview

1.1 <Component Name>

1.2 Description

1.3 Identifier

1.4 Version

1.5 Status

1.6 Profile Type

1.7 Contexts

1.8 Descriptors

1.9 Related Assets

2.0 Consumer View

2.1 Requirements Met

2.2 Design Specification

2.3 Platform Considerations

2.4 Usage Instructions

3.0 Producer View

3.1 Logical View

3.2 Implementation View

3.3 Deployment View

3.4 Process View

3.5 Detailed Design Model Reference

3.6 Source Code Reference

3.7 Test Plan Reference

Contact and Profile

ManagementContact and Profile

Management

Service Center

Information

Management

System

(SCIMS)

Component Realization Diagram

Enabling Reuse of Service Components – Communicate!



TOGAF ADM IT Architecture 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 IT Architecture


TOGAF is industry standard

Consulting resources are available 13,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 IT Architecture


Study government IT architecture problems – is TOGAF a fit?

Visit www.opengroup.org – download TOGAF

Download earlier webinars in this series: opengroup.org/events/webinars.htm

Get someone on your EA team trained/certified

Tailor the FEA/FSAM using TOGAF

Develop, implement and manage your IT architecture

Next Steps

http://www.opengroup.org/events/webinars.htm


Questions?

Panelist Contact Information

John Polgreen [email protected]

Judith Jones [email protected]

Greg Lettow [email protected]

Jim Odrowski [email protected]

Serge Thorn [email protected]

Ed Harrington [email protected]

David Epperly [email protected]

mailto:[email protected]























using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11

Education