District of ColumbiaCitywide Enterprise Architecture

Tom Mowbray, Keane Federal Systems

DC OCTO Enterprise Architect

April 13, 2005Tom.Mowbray@DC.Gov

Mowbray@Keane.com

(202)727-9580

2

Outline

1. The EA Challenge2. Key EA Principles3. EA Framework4. To-Be EA Process5. As-Is EA Process6. EA Notation7. EA Views8. EA Governance9. Lessons Learned

ACRONYMSARB ::= Architecture Review BoardBPR ::= Business Process EngineeringCONOPS ::= Concept of OperationsEA ::= Enterprise ArchitectureOCTO ::= Office of the CTOSMP ::= Services Modernization Program

SERVICES MODERNIZATION PROGRAMS• Administrative (ASMP)• Customer (CSMP)• Education (EdSMP)• Enforcement (ESMP)• Financial (FSMP)• Human (HSMP)• Motorist (MSMP)• Property (PSMP)• Transportation (TSMP)

3

The District’s EA Challenge

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

Agency Systems

9 Multi-Agency Services Modernization Programs (SMP)

68 A

genc

ies,

Nee

d T

rans

pare

ncy

Und

ocum

ente

d, I

sola

ted

Pro

ejec

ts

380+ Legacy Systems

ASMP CSMP ESMP EdSMP FSMP HSMP MSMP PSMP TSMP

Strong Disincentives to Share, Need for Data Integrity

4

Key EA PrinciplesOCTO’s Architecture Philosophy is Focused on Results

1. RESULTS DRIVEN – Tactically Implementation Oriented– Architecture results should be simple, practical, feasible, and useful

2. VISUAL– Priority for visual architecture models

3. SELF-CONTAINED– Docs must be self-explanatory and standalone

4. BEST PRACTICES– Use best practices of BPR and EA

5. FACT-BASED and ACTIONABLE– Generate rigorously engineered information that is actionable

6. LONG TERM VIEW WITH SHORT TERM BENEFITS– Define target architecture and cost benefits– Show long term architectural fit; Conduct Benefits Realization

Overall: Information Transparency Breeds Behavioral Correction

5

DC Enterprise Architecture Framework (DC-EAF)

SMP Concepts of OperationsSMP Concepts of OperationsTo-Be

To-Be EA Process

Understand the Problem,Define Business Solution

Devise Target Architectures,Craft Transformation Plans,

Initiate Cost-Benefits Realization

7

Process for “To Be” Concept of Operations

Project:Root Causes

& Best Practices(i.e. Business Conops)

Approx 2 MBA X 4-6 weeks

Project: Business Operating Model(i.e. Program Planning)

Approx 2 MBA/Agency X 12-14 Weeks

SubProject: IT Architecture EnvisioningApprox 1 Arch X 8-12 Weeks

Identifies Scope of

BusinessSolution

Drives TechnicalSolutionEnables

BusinessPriorities

DetermineSolutionDirection

Strategic Implementation PlanningProcess Improvement Planning

Natural Role for BPR Group

Natural Role for Enterprise Architecture Team

Natural Role for Team of MBA/Business Analysts

Best Practices Combination of BPR and EA

• District Experiences with “To Be” Process: ASMP, CSMP, ESMP, HSMP• Cost of Concept of Operations is approx ½ Percent of Development Cost• Resulting Business Case: Cost-Benefits of Exceed Development Cost with Strong Stakeholder Buy-In/Ownership

8

“To Be” CONOPS 3X5 Matrix

TechnologyEnterprise

Architecture

ApplicationEnterprise

Architecture

Concept ofOperations

BusinessEnterprise

Architecture

InformationEnterprise

Architecture

EnterpriseArchitecure Plans

GuaranteedClosure

Single Pointof Entry

Mission

Stakeholders

BenignServiceDelivery

Mechanism

Concept ofOperations

EnterpriseArchitecture

Plans

CostBenefitsAnaysis

BestPracticesAnalysis

BusinessProcessAnalysis

Implement-ation Plans

BusinessOperations Model

EXECUTIVE PERSPECTIVE BUSINESS/PROGRAM PERSPECTIVE GENERAL PERSPECTIVE

9

ARB Milestone 1: CONOPS Checklist

CV-1

CV-2

CV-3

CV-4

CV-5

CV-6

CV-7

CV-8

CV-9

CV-10

CV-11

We have many real examples of these deliverables

10

EA FY05KickoffMeeting

One-on-OneInformationModelingSessions

InformationArchitectureDay•X-Brief•X-Linkage

One-on-OneBusiness ArchModelingSessions

BusinessArchitectureDay•X-Brief•X-Linkage

One-on-OneApplication ArchModelingSessions

ApplicationArchitectureDay•X-Brief•X-Linkage

One-on-OneInfrastructureModelingSessions

InfrastructureArchitectureDay•X-Brief•X-Linkage

Review, Publicize, Finalize

Next Year…EA FY06 Kickoff (October 2005)- X-Brief FY05 “As Built” Models- FY05 Lessons Learned

6/4/04 6/18/04

7/2/04 7/16/04

“As Is” Enterprise Architecture Process

8/6/04

11

EA Notation Conventions

MODELING PRINCIPLES

• Simple

• Pragmatic

• Useful

• Self Explanatory

• In Laymans’ Terms

• Priority Driven

• Shows Relationships

• Readable Constraints

• Visio 2000 (5 Facet UML)

• Holistic View of SMP’s and Common Services

General Incident Information

General incident information is common header data on many MPDC forms, including: system generated case numbers, party

identification, and incident locations.

BV-ESMP MPDC Event

AV-ESMP Records Management System

NV-ESMP RMS Production DB ServerNV-ESMP RMS Backup DB Server

Bold Object Name(Abbreviation)

Object Definition(free text)

Business Processes

Application Modules

Example Information Object

InfrastructureComponents

Always show UML facets in same order Current View then Business (BV), Information (IV), Appliacation (AV), Infrastructure (NV)

Cur

rent

Vie

w

STRICTLY PRELIMINARY DRAFT 6/1/2004

SampleEnterpriseInformationArchitectureModel

13

Enterprise Architecture Posters

• Summary Business Enterprise Architecture– Business Processes and Relationships

• Summary Information Enterprise Architecture– Information Categories and Relationships

• Summary Application Enterprise Architecture– Application components/modules and relationships

• Summary Infrastructure Enterprise Architecture– Server and network components

– Installed software packages

Focus is on SMPs and components they depend upon

14

Architecture Trace-ability to Business Goals

Process Flows

Business Architecture

As-Is

To-Be

Mayors Citywide Strategic GoalsGoal Goal Goal Goal Goal Goal Goal Goal

MPDC Scorecard GoalsGoal Goal Goal Goal Goal Goal

OCTO Scorecard GoalsGoal Goal Goal Goal Goal Goal

CFSA Scorecard GoalsGoal Goal Goal Goal Goal Goal

Process Flows

Business Architecture

As-Is

To-Be

Process Flows

Business Architecture

As-Is

To-Be

15

Sample Infrastructure Architecture View

MODEL ELEMENTS• Server Systems• LAN/WAN Network Components• Storage Servers• Network Connections

LEVEL OF DETAIL (for Citywide EA)• All Production SMP-related Server Boxes• All Production SMP-related Network Boxes• Major Production LAN/WAN components used

by (or interfaced to) SMP’s• Installed Software Packages and Versions

SA

MP

LE M

OD

EL

SA

MP

LE M

OD

EL

The actual EA models are PROTECTED CRITICAL INFRASTRUCTURE INFORMATION (PCII)

16

Architecture Review Board ProcessAssuring IT Quality Through Milestone Peer Reviews

CONOPSStudy

Go / No-Go

Selection Phase

Development Phase

Deploy

Operations Phase

Important Architecture Decisions

RFP

RFP

RFP

RFP

RFP

DesignReviews

Tactical Arch.Changes

Tactical Arch.Changes

Tactical Arch.Changes

Milestone 1SystemConcept

Readiness

Milestone 3OperationalReadiness

Milestone 2Construction

Readiness

Verify Designwith Architecture

Verify Implementationwith Architecture

ValidateArchitecture

IT Systems Planning and Development Phase Advisory Services

Critical Architecture Decisions

17

Conclusions: Lessons Learned• Key purpose of EA: Launch Migration to SOA Common Services

– Successful in Documenting and Prioritizing the Services through the EA– Sparked Creation of New IT Business Unit for Common Services & Oversight

• Information Transparency Breeds Corrective Behavior– Architecture requirements are becoming self-reinforcing through EA experience –

Infrastructure Resilience, Use of Common Services Licenses,…• Governance is Communications

– ARB Reviews Promote Many to Many Communications/Sharing of Expertise– Discover new enterprise licenses / common service opportunities most every time

ARB meets• Plan for the consequences of architecture success

– New investment for platforms, operations, training, support for new enterprise license “Common Service” technologies

– Excellent development and operations phase management is required to realize architecture plans

– There are 25 concurrent EA-related initiatives in progress