District of Columbia
Citywide Enterprise Architecture
Tom Mowbray, Keane Federal Systems
DC OCTO Enterprise Architect
April 13, 2005
Tom.Mowbray@DC.Gov
Mowbray@Keane.com
(202)727-9580
Outline
1.
2.
3.
4.
5.
6.
7.
8.
9.
The EA Challenge
Key EA Principles
EA Framework
To-Be EA Process
As-Is EA Process
EA Notation
EA Views
EA Governance
Lessons Learned
ACRONYMS
ARB ::= Architecture Review Board
BPR ::= Business Process Engineering
CONOPS ::= Concept of Operations
EA ::= Enterprise Architecture
OCTO ::= Office of the CTO
SMP ::= Services Modernization Program
SERVICES MODERNIZATION PROGRAMS
• Administrative (ASMP)
• Customer (CSMP)
• Education (EdSMP)
• Enforcement (ESMP)
• Financial (FSMP)
• Human (HSMP)
• Motorist (MSMP)
• Property (PSMP)
• Transportation (TSMP)
2
68 Agencies, Need Transparency
9 Multi-Agency Services Modernization Programs (SMP)
ASMP
CSMP
ESMP EdSMP
FSMP
HSMP
MSMP
PSMP
TSMP
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
Undocumented, Isolated Proejects
The District’s EA Challenge
380+ Legacy Systems
Strong Disincentives to Share, Need for Data Integrity
3
Key EA Principles
OCTO’s Architecture Philosophy is Focused on Results
1.
RESULTS DRIVEN – Tactically Implementation Oriented
–
Architecture results should be simple, practical, feasible, and useful
2. VISUAL
–
3.
SELF-CONTAINED
–
4.
Use best practices of BPR and EA
FACT-BASED and ACTIONABLE
–
6.
Docs must be self-explanatory and standalone
BEST PRACTICES
–
5.
Priority for visual architecture models
Generate rigorously engineered information that is actionable
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
4
DC Enterprise Architecture Framework (DC-EAF)
SMP Concepts of Operations
To-Be
District of Columbia - Enterprise Architecture Framework
Business Architecture
Information Architecture
Processes
X
Entities
Process Flows
Entities
As-Is
As-Is
Entities
X
Modules
Processes
X
Modules
Servers
X
Modules
Entities
X
Interfaces
Server Systems
Application Modules
Interface Adapters
Infrastructure Software
Network Components
EAI
As-Is
io
at
el ips
R sh
n
Application Architecture
As-Is
Infrastructure Architecture
5
To-Be EA Process
Understand the Problem,
Define Business Solution
Devise Target Architectures,
Craft Transformation Plans,
Initiate Cost-Benefits Realization
Process for “To Be” Concept of Operations
Process Improvement Planning
Project:
Root Causes
& Best Practices
(i.e. Business Conops)
Approx 2 MBA X 4-6 weeks
Natural Role for BPR Group
Strategic Implementation Planning
Natural Role for Team of MBA/Business Analysts
Identifies
Scope of
Project: Business Operating Model
(i.e. Program Planning)
Approx 2 MBA/Agency X 12-14 Weeks
Business
Solution
Drives
Business
Priorities
Determine
Solution
Direction
Technical
Solution
Enables
SubProject: IT Architecture Envisioning
Approx 1 Arch X 8-12 Weeks
Natural Role for Enterprise Architecture Team
• 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
Best Practices Combination of BPR and EA
7
“To Be” CONOPS 3X5 Matrix
Concept of
Operations
Business
Operations Model
Enterprise
Architecure Plans
Mission
Best
Practices
Analysis
Concept of
Operations
Stakeholders
Business
Process
Analysis
Business
Enterprise
Architecture
Benign
Service
Delivery
Mechanism
Implementation Plans
Information
Enterprise
Architecture
Cost
Benefits
Anaysis
Application
Enterprise
Architecture
Enterprise
Architecture
Plans
Technology
Enterprise
Architecture
Single Point
of Entry
Guaranteed
Closure
EXECUTIVE PERSPECTIVE
BUSINESS/PROGRAM PERSPECTIVE
GENERAL PERSPECTIVE
8
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
9
“As Is” Enterprise Architecture Process
6/4/04
EA FY05
Kickoff
Meeting
One-on-One
Information
Modeling
Sessions
Information
Architecture
Day
•X-Brief
•X-Linkage
6/18/04
One-on-One
Business Arch
Modeling
Sessions
7/2/04
One-on-One
Application Arch
Modeling
Sessions
8/6/04
Review, Publicize, Finalize
Application
Architecture
Day
•X-Brief
•X-Linkage
Business
Architecture
Day
•X-Brief
•X-Linkage
7/16/04
One-on-One
Infrastructure
Modeling
Sessions
Infrastructure
Architecture
Day
•X-Brief
•X-Linkage
Next Year…
EA FY06 Kickoff (October 2005)
- X-Brief FY05 “As Built” Models
- FY05 Lessons Learned
10
EA Notation Conventions
Example Information Object
General Incident
Information
General incident information is
common header data on many
MPDC forms, including: system
generated case numbers, party
identification, and incident
locations.
Bold Object Name
(Abbreviation)
Object Definition
(free text)
Current View
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
BV-ESMP MPDC Event
Business Processes
AV-ESMP Records Management
System
Application Modules
NV-ESMP RMS Production DB Server
NV-ESMP RMS Backup DB Server
Infrastructure
Components
Always show UML facets in same order Current View then Business (BV), Information (IV), Appliacation (AV), Infrastructure (NV)
11
1
Sample
Enterprise
Information
Architecture
Model
Arrest Information
District Attorney Report
Fingerprint/Photograph
Arrest information is collected at
the time of arrest from suspects,
and their property, witnesses, and
physical evidence detailed in a
case narrative.
The District Attorney Report
contains all of the incident reports,
investigations, evidence
information, histories, other
information assembled to support a
court case.
Traditional biometric information is
accompanied with standard FBI
Red Card identity fields on paper
and digitized formats.
0..*
0..1
-includes
AV ESMP Records Management
System (RMS)
BV ESMP Conduct Papering
Process
AV ESMP Records Management
System (RMS)
AV ESMP Records Management
System (RMS)
NV ESMP RMS Production Cluster
NV ESMP RMS Backup Cluster
NV ESMP RMS Production Cluster
NV ESMP RMS Backup Cluster
NV ESMP RMS Production Cluster
NV ESMP RMS Backup Cluster
BV ESMP Arrest Suspect
1
-has
0..1
0..*
-includes
1
BV ESMP Book Suspect
-includes
0..1
-has
-has
0..1
1
1..*
Property and Evidence
Information
Specific Incident Information
Use of Force Information
Describes property items that are
inventoried in the MPDC property
management process, including
warehoused property, and property
in the custody of police officers and
the judicial officials.
Details of the incident such as the
crime classification, witness
identification, known suspects and
other case-related information.
Describes use of force incidents
involving sworn officers (e.g.
service weapon, K-9, baton, etc.)
which are idenfitied, tracked, and
reported through the Use of Force
Information.
BV ESMP Collect Property and
Evidence
0..*
1
1
-has
BV ESMP Investigate Event
AV ESMP Property and Evidence
Module
AV ESMP Records Management
System (RMS)
NV ESMP Property and Evidence
Systemr
NV ESMP RMS Production Cluster
NV ESMP RMS Backup Cluster
0..1
BV ESMP Investigate Event
AV ESMP Personnel Performance
Management System (PPMS)
NV ESMP PPMS Production
Server
1..*
0..*
-identifies
1
1..*
LEGEND
-describes
1
General Incident Information
General incident information is
common to many MPDC forms,
such as: system generated case
numbers, party identification, and
incident locations.
BV ESMP MPD Event
AV ESMP Records Management
System (RMS)
STRICTLY PRELIMINARY DRAFT 6/1/2004
-involves
NV ESMP RMS Production Cluster
NV ESMP RMS Backup Cluster
Framework: DC Enterprise Architecture Framework
(District of Columbia Profile of FEAF Level III)
Viewpoint: Information Architecture View; Portrays
Enteprise Information Objects from viewpoint of
Citywide Executive Decision-Makers
Timeframe: Future Year Target Architecture; To-Be
FY05 Year End; Best Case Development Projection
Notation: Unified Modeling Language (TM) Logical
View; Tailored 5 Facet Information Objects, as follows:
ObjectNameHere
NarrativeDescriptionHere
BV ?SMP BusinessProcessHere
AV ?SMP ApplicationModuleHere
NV ?SMP ServerNameHere
-VerbHere
1
1..*
multiplicity
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
13
Architecture Trace-ability to Business Goals
Mayors Citywide Strategic Goals
Goal Goal Goal Goal Goal Goal Goal Goal
MPDC Scorecard Goals
OCTO Scorecard Goals
CFSA Scorecard Goals
Goal Goal Goal Goal Goal Goal
Goal Goal Goal Goal Goal Goal
Goal Goal Goal Goal Goal Goal
Business Architecture
Business Architecture
Process Flows
Process Flows
To-Be
To-Be
As-Is
As-Is
Business Architecture
Process Flows
To-Be
As-Is
14
Sample Infrastructure Architecture View
SAN
Integration
Server
LAN
LAN
IBM 2109 Fibre
Switches
Dual
Fabric
All 2GB Fibre
Attachment
3583 LTO
Tape Library
p650 Database
Server and
Development LPAR
MODEL ELEMENTS
• Server Systems
• LAN/WAN Network Components
• Storage Servers
• Network Connections
SAMPLE MODEL
SAMPLE MODEL
IBM FAStT 600
SAN
IBM x345 Web
Servers
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
The actual EA models are PROTECTED CRITICAL INFRASTRUCTURE INFORMATION (PCII)
15
Architecture Review Board Process
Assuring IT Quality Through Milestone Peer Reviews
CONOPS
RFP Study
Milestone 1
System
Concept
Readiness
Validate
Architecture
Go / No-Go
RFP
Selection Phase
Milestone 2
Construction
Readiness
RFP
RFP Development Phase
Verify Design
with Architecture
Verify Implementation
with Architecture
Critical Architecture Decisions
Important Architecture Decisions
Design
Reviews
Milestone 3
Operational
Readiness
Deploy
Tactical Arch.
Changes
RFP
Operations Phase
Tactical Arch.
Changes
Tactical Arch.
Changes
IT Systems Planning and Development Phase Advisory Services
16
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
17