Using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11

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

Architecting the Enterprise Limited Copyright © 2010

Welcome!


Agenda

 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


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


The Situation

 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


A Potential Solution

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


TOGAF 9

 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


Architecture Development Method - ADM

Preliminary

A
Architecture
H Vision
Architecture B
Change Business
Management Architecture

CC
G Information
Information
Requirements System
Implementation System
Management Architectures
Governance Architectures

F D
Migration Technology
Planning Architecture
E
Opportunities
& Solutions


ADM mapped to FEA Reference Models

Preliminary PRM
PRM

A
Architecture BRM
H Vision
Architecture B
Change Business
SRM
CC
G Information
Information
Requirements System
DRM

F D
Migration Technology TRM
E
Opportunities
& Solutions


Mapping FEA Practice Guidance
to the TOGAF ADM

ADM Phases ADM Phase ADM Phases
Preliminary E – Opportunities and F- Migration Planning
A – Vision Solutions G – Implementation
B – Business Architecture Governance
C – Information Systems H – Change
Architecture Management
D – Technology Architecture
Requirements Management


FSAM to TOGAF ADM Mapping
Phase A
Vision Phase B
Business
Architecture
Phases C-D
Data,
Application,
Technology Phases E-F
Architectures Opportunities
and Solutions,
Migration
Planning

12 TOGAF ADM Phase FSAM Step

USDA Case Study Conclusions

“TOGAF and the FEA provided a good combination for planning a large
government-based modernization project.”

Greg Lettow, Jim Odrowski


Applying TOGAF to FEA/FSAM
Strategic Architecture
 Strategic ADM iteration
 Tailor FEA reference models Preliminary

A

 Develop strategic architecture H
Architecture
Change
Management
Architecture
Vision
B
Business
Architecture

 Mile wide, inch deep Segment Architecture(s) G
Requirements
CC
Information
Information
System

 To-be states in all domains
Preliminary F D

 Gaps Preliminary
Preliminary
Migration
Planning E
Opportunities
Technology
Architecture

A & Solutions
Architecture

 Transition Strategy H
Architecture
Change
H
Architecture
Management H
Vision
A
Architecture
Vision
A B
Architecture BusinessB
Vision Architecture
Change
Architecture Business B

 Subsequent ADM iterations
Change Business
Management C
Architecture
C
G Information
Information
C
Requirements System C
Implementation
G
Governance
Implementation
G
Management
Requirements
System
Information
Architectures C
Information
Architectures C
System
Information
System
Information
Capability Architectures
Management
Requirements Architectures
Governance System
Architectures

 Describe segments
F D
F D
Planning Architecture Preliminary
Migration
F E TechnologyD

 Describe other enterprise projects Migration Opportunities
Technology Preliminary
E
Planning & Solutions Architecture Preliminary
Opportunities
E
& Solutions
Opportunities A
& Solutions Architecture
H A
Vision

 Collectively describe rich EA
Architecture Architecture
A B
H
Change Vision
Architecture Business
Architecture
H B
Management
Change Vision Architecture
Business
Architecture B
Management
Change Architecture
Business
Management C
Architecture
C
G Information
Information
C
Implementation
Requirements System C
System
Information
G
Governance
Management
Requirements Architectures C
Information
Architectures C
Information
System
G Management Information
Governance Requirements Architectures
System
Architectures
F D
Migration TechnologyD
F
Planning E Architecture
Technology
Migration
F D
Migration Opportunities
Technology
Planning & Solutions E
Opportunities Architecture
& Solutions
Opportunities
& Solutions


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


Primacy of Business Architecture

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


Business
Footprint
Diagram –

Business
Architecture

CRM
ERP
Auto


Steps of Information Systems Architecture
Phase - Application

Preliminary

Select Reference Models, Viewpoints
A
H Architecture Develop Baseline Description
Architecture Vision B
Change Business Develop Target Description
Perform Gap Analysis
CC
G Information
Information
Requirements Define Roadmap Components
System
Resolve Impacts

Conduct Stakeholder Review
F D
Planning E Architecture Finalize the Architecture
Opportunities
& Solutions Create Architecture Definition Document


Application/Function Matrix –
Application Architecture

Enterprise Management
Supplier Collaboration

Sales & Marketing
Customer Service

Time-to-Market

Build-to-Order
System Functionx

& Support
CRM X X
ERP Auto
Commerce Engine X X

SLIDE 20 of 55 Architecting the Enterprise Limited Copyright © 2010

Application Communication Diagram –

CRM

Commerce
Engine

ERP Auto

• Depicts models and mappings related to communication between applications
• Shows application components and interfaces between components


Software Engineering Diagram –

CRM

ERP Auto


Steps of Information Systems Architecture
Phase - Data

Preliminary

A
CC
G Information
Information
System
Resolve Impacts

F D
Opportunities


Data Entity/Business Function Matrix –
Data Architecture
Data Entities Complaint Common Customer Complaint
Faults Details Resolution

Business Functions
Service(s) - Log Service(s) - Log
Complaint Complaint
Owner(s) - Owner(s) -
Customer Complaint Customer Service Customer Service
Operation - CRUD Operation - CRUD
Service Management Log Complaint
Service(s) - Service(s) -
Warranty Report, Warranty Report,
Recalls Log Recalls Log
Owner(s) - Owner(s) -
Customer Complaint Process Customer Service Customer Service
Operation - CRUD Operation - CRU
Service Management Complaint
Services() - Log
Action, Review
Action
Owner(s) -
Customer Complaint Respond to Customer Service
Operation - CRU
Service Management Compaint


Application/Data Matrix – Data Architecture

System Data Complaint Common Customer Complaint Order
Entities Faults Details Resolution

CRUD CRUD CRUD CRUD
CRM
CRUD CRUD
ERP Auto
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

Commerce
Engine

CRM

• Allows effective sizing to be carried out
• Indicates business criticality of application components


Class Diagram – Data Architecture


Steps of Technology Architecture Phase

Preliminary

A
CC
G Information
Information
System
Resolve Impacts

F D
Opportunities


Application/Technology Matrix – Technology
Architecture

Warehouse
Commerce
ERP Auto
Technology Systemx

Engine
CRM
Web Server - Node 1 X
App Server - Node 1 X
Database Server (production) X
Database Server (staging) X
Web Server X
App Server X


Environments and Locations Diagram –
Technology Architecture

Commerce
CRM ERP Auto Engine

Source: Avolution


Communications Engineering Diagram –
Technology Architecture


Complete the ADM

Preliminary

A
H Architecture
Change Business

CC
G Information
Information
Requirements System

F D
Opportunities
& Solutions


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

Dept Head Service
IT spend
spend count quality

2004 2007 2008

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


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

Branch Local
Authorities

New
Phone Enrollments Driver
Licensing

DWP Users Citizen Record (s)
PKI
Paper Others
Citizens
One Hour Service?
Internet and TV 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


USDA Agency B – Modernizing the
 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 Domain
FEA-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.

FEA-SRM Service Components

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?



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?

Business Analytical Services
Analysis and Statistics
Back Office Services
Penalty
Calculator
Financial Management
Penalty Calculator
Accounts
Payable

Accounts Payable Tracking and Workflow

Workflow Manager
Workflow
Manager

Workflow Manager

Business Management Services
Customer Service

Customer Preferences Management of Process
Policy Evaluation
Profile
Management Policy
Evaluation
Profile Management



Enabling Reuse of Service Components – Communicate!
Service Component Specification
Service Component Specification - Purpose
1.0 Overview
For each Service Component it answers the following 1.1 <Component Name>
questions: 1.2 Description
1.3 Identifier
► What is the design specification for the component? 1.4 Version
► Is this component a candidate for reuse in my 1.5 Status
1.6 Profile Type
application? 1.7 Contexts
► How do I use the component? 1.8 Descriptors
1.9 Related Assets
► How do I extend / modify the component?
2.0 Consumer View
2.1 Requirements Met
Contact and Profile
2.2 Design Specification
Contact and Profile
Management Management 2.3 Platform Considerations
2.4 Usage Instructions

3.0 Producer View
3.1 Logical View
3.2 Implementation View
Service Center 3.3 Deployment View
Information
Management 3.4 Process View
System Component Realization Diagram
(SCIMS) 3.5 Detailed Design Model Reference
3.6 Source Code Reference
3.7 Test Plan Reference


Value Proposition: TOGAF IT Architecture

 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


Next Steps

 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


Questions?

Panelist Contact Information

John Polgreen johnpolgreen@architecting-the-enterprise.com
Judith Jones judith@architecting-the-enterprise.com
Greg Lettow glettow@componentwave.com
Jim Odrowski jodrowski@componentwave.com
Serge Thorn serge.thorn@architecting-the-enterprise.com
Ed Harrington ed.harrington@architecting-the-enterprise.com
David Epperly david.epperly@avolutioncorp.com


Using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

Semelhante a Using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11

Semelhante a Using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11 (20)

Último

Último (20)

Using togaf™ in government_enterprise_architecture_to_describe_the_it_architecture_31_jan11