DOI Enterprise Architecture

1
DOI Enterprise Architecture

• Using Enterprise Architecture to create
  Modernization Blueprints at the
• Department of the Interior

2
U.S. Department of the Interior

• The Department manages more than 440 million
  areas of federal lands, including some 360
  national parks. This includes fostering the
  wisest use of our land and water resources,
  protecting our fish and wildlife, providing
  recreation, and preserving the environmental and
  cultural values of our national parts and
  historic places.
• The Interior Department also assesses mineral
  resources and works to assure that their
  development is in the best interest of all the
  people.
• Additionally, the Department has a major
  responsibility for American Indian reservation
  communities and for people who live in the Island
  Territories under United States administration.
• The Interior Department manages an annual I/T
  budget of approximately 1B USD with over 900
  major I/T systems across 8 Bureaus and multiple
  Offices

3
Modernization Blueprint Approach
4
Goals of DOI Modernization Blueprint Approach

• Develop a sequencing plan that describes a
  value-based incremental strategy for
  transitioning the baseline to the target
  architecture
• Ensure alignment between application systems and
  customer mission and goals.
• Reduce or eliminate functional redundancies
  across systems.
• Foster the Write-Once Use-Many principle of
  data management through integrated data stores.
• Obtain/retain adequate funding for customers
  application systems.
• Reduce OM costs associated with existing and
  planned systems.
• Leverage, where possible, existing and planned
  infrastructure components.
• Re-use, where possible, existing and planned
  technology components.

5
The DOI enterprise architecture engagement has
technology, process, application and data
modernization goals. Initially cost savings are
realized from technology and software
transformation savings
6
DOI developed a tailored enterprise architecture
modeling tool. (Screenshot)
DOI Enterprise Architecture Repository
7
Within the DOI each domain (security, IT
investments, IT portfolios, data, software
development, configuration management) had
multiple, isolated repositories
8
DOI integrated these isolated repositories into a
single integrated repository - D.E.A.R.
9
Today, D.E.A.R. is the source of record for
architecture artifacts across the DOI and its
Bureaus. This provides the CIO with a single
view of the enterprise.
10
A Four Step Take Action Approach was developed to
set the vision, develop an inventory, analyze,
and take-action via a modernization blueprint of
the Target Application Architecture (TAA)
TAA Step 1
Step 4
Step 2
Step 3
11
Step 1 The capturing of DOI Business Strategy
involved modeling the DOI Strategic Plan and
interviews with DOI business and technology
leaders
12
The DOI Strategic Plans logical structure lent
itself to being modeling within the DEAR modeling
tool
US law mandates that US departments have
performance metrics. Each department (ministry)
is measured in their ability to achieve these
metrics each year and this is reported to the US
congress.
13
Within DEAR, Strategic Plan elements have been
mapped to ABC Work Activities and have been
classified within the context of OMB PRM
Measurement Categories
Strategic Plan Mapped to End Outcomes
Strategic Plan Mapped to ABC Elements
Within the modeling tool, we can see what IT
investments support a given end outcome goal. We
can see how much the DOI spends to achieve and
end outcome goal.
14
Modeling the Strategic Plan in DEAR allows DOI to
perform queries such as what I/T investment
support a given End Outcome Goal?
We can perform queries against the repository and
view the results as formatted HTML This report
shows multiple IT investments supporting various
DOI strategic goals.
15
Step 2 Capturing the DOI Baseline Architecture
involved data collection templates and validation
workshops for each line of business
16
Examination of the As Is (Current) Environment

• Each system developed to support a single line of
  business
• Systems created to support historical goals /
  process not necessarily valid today
• Systems have stove-piped infrastructures with no
  component sharing
• Technology often outdated with escalating
  operations and maintenance costs
• Systems developed using proprietary or local
  standards low reusability
• Information exchange among systems is ad hoc or
  manual

17
The Business Reference Model as implemented by
the DOI extended the FEA BRM down to the level of
function / activities and process steps

• Original FEA BRM was extended two additional
  levels
• DOI systems were mapped at lower levels of the
  DOI BRM to perform more detailed Analysis.
• Lower-level function / activities were decomposed
  further into IDEF0 and IDEF3 process models
• Process models were used to examine existing work
  processes and then used optimize work flow for to
  be (target) systems

18
BRM Reports Generated from DEAR
19
SRM Complete OMB FEA SRM Modeled in DEAR
20
DRM as implemented in DEAR
Data Subject Areas for Law Enforcement LoB in DEAR
Conceptual Data Model for Law Enforcement LoB in
DEAR
21
DOI System to System Interfaces Modeled in
DEAR (CBS System Shown)
22
HTML Report of Systems and their relationship to
all FEA Reference Model domains
23
Ad Hoc Matrix Report showing Systems related by
Data Subject Areas (DRM)
24
OMB TRM Framework Modeled in DEAR
25
OMB TRM Framework Modeled in DEAR (details on a
single TRM Standard shown)
26
TRM Reports Generated from DEAR
27
Step 3 DOI Gap Analysis resulted in the
classification of existing systems and the
identification of horizontal services
28
DOI Gap Analysis assessed alignment of baseline
architecture with FEA and DOI architecture
standards
System Assessment
Application Architecture
Technology
Process
Data

• Business processes supported by the system
• System support of DOI and BLM strategies, goals,
  and objectives
• Stakeholders feedback on performance
• Functional overlap with other systems
• System training and support opportunities
  addressed.

• Existence and documentation of data standards and
  protocols
• Data storage / access method maturity
• Data entity access / modification overlap with
  other systems.

• Target Application Architecture compliance
• Extent system design requirements are defined and
  documented.
• Extent systems interfaces are defined and
  documented.
• Extent to which high-level design or operational
  concepts are defined.

• Compliance with TRM technology architecture
  components
• Extent of use of shared, existing infrastructure
  components and services
• Extent of compliance with TRM standards,
  protocols and best practices.

Classification

• Legacy
• Data Migration (re-engineer)
• Consolidate (re-engineer)
• Target

DRM
SRM / CBA
PRM / BRM
TRM
29
DOI Gap Analysis explored and defined tactical
(short term) Improvements for existing systems

• Conduct baseline Analysis
• Set improvement targets
• Identify, select, and propose improvements
• Maximize investment across entire portfolio

30
DOI Gap Analysis classified existing systems
based on weighted results of Analysis
31
Step 4 The results of the gap Analysis, industry
best practices, and DOI patterns and reference
architecture artifacts drove the creation of the
DOI conceptual target architecture
32
Definition of the Conceptual To Be (Target)
Environment

• Systems are a collection of service components
  supporting multiple business lines
• Systems support current mission / goals and can
  adapt rapidly to change
• Technology based on service orientated
  architecture (SOA)
• Reusable components are deployed in a scaleable
  distributed infrastructure
• Systems developed using open enterprise standards
• Data standards and standard information exchange
  mechanisms support information sharing among
  systems

33
The DOI conceptual target application
architecture is a service oriented architecture
designed to meet future business requirements
34
The DOI conceptual target application
architecture is aligned with the FEA E-Government
Interoperability Model

• End-user access (across the top section A).
• Applications (in the center section B).
• Application Integration and Common Services (the
  vertical bar on the right section C).
• External Applications and Portals (the boxes on
  the right section D).
• Cross-cutting Architectural Requirements (the
  layers upon which the application are built
  section E).

35
Migration planning resulted in both a tactical
and strategic implementation plan
36
Tactical recommendations included short-term
improvements in alignment with strategic
architecture goals within constraints of existing
OM budgets.
37
Tactical recommendations were prioritized to
yield maximum benefits across the portfolio
within budget constraints
38
The strategic implementation plan provided a
conceptual roadmap to the target architecture

• Enables progress towards target application
  architecture
• Provides conceptual roadmap to target
  architecture
• Identifies systems to be retired, consolidated,
  and re-engineered
• Informs project, program, and portfolio
  management
• Identifies investment proposals to be worked now
  to enable the future state

39
DOI Schedule Where are we today?
Department-wide Interpretable Information
Associated and Normalized Artifacts
Actionable Recommendations and Plans
Agency Raw Data
Apply Standards and Conventions
5 LOB Functions
Repository
DEAR Reporting
IT Assets
Common Collection Technique
DOI Level Portfolio
Modernization Blueprints
I n g e s t
A c c e s s
TAA
DEAR
System Inventories and lists
TRM/SRM PRM BRM System Inventory
OMB Reference Models
Security CA technical info and status
DOI TRM DRM ITIPS Strategic Plan ABCs
April, 2004
40
Some lessons learned

• Importance of collaboration / concurrence more
  difficult than technical issues organizational /
  process / culture / view of change
• Common vision, FEA reference models, documented
  processes, documented work products provide a
  common language among diverse team members
• Importance of program management skills for
  engagement lead Enterprise Architect must be
  diplomatic yet lead
• Short term successes and deliverables are
  important to provide feedback and direction to
  the team
• Well-documented deliverable descriptions,
  well-documented schedule important to manage
  customer expectations
• Each EA engagement must be tailored to
  customer-specific requirements
• Common modeling tool / repository assisted with
  enforcing common modeling methods and ensuring
  compatibility of model artifacts across different
  teams.

41
Document Abstract
Revision History