# Presentation: 066689

## Department of the Interior, Enterprise Architecture Program

- DEAR Overview and
- Refresher Training

## Agenda

- Introduction - Enterprise Information in Action [60 minutes]
- Example: Where does EA Information fit into overall Enterprise Information
- MBT
- Governance
- DEAR
- Enterprise Planning Information
- Getting Started and Gaining Access – [60 minutes]
**BREAK at own time**
- Common Inventory  [30 minutes]
- Data Collection Phase Scope/History
- Integrating Views [30 minutes]
- CIO Integration - C&A, CPIC, EA Inventories
- Common Language [30 minutes]
- Reference Model Review

## After this training, our expectation is, for you to:

- ...have a view of where _**EA Information fits in enterprise view **_of all enterprise information
- ...have _**familiarity with the language **_used to describe enterprise architecture
- ...be able to _**communicate the history **_of information collection and maintenance of EA information
- ...have a clear _**understanding of what information is available **_in DEAR
- ...be _**aware of future state of EA Information **_Use and Availability
- ...know _**how and what to access for your EA information**_
- ...be able to firmly _**support the principle of maintaining **_accurate EA Information

## Additional DEAR Classes

- Report User
- Navigation, Information Available, Capabilities, Lab
- Architect/Regular User Specific Training
- System Wizard, Reports, Modeling Import Intro, and Collection Templates
- Security/Privacy Specific Training
- C&A Wizard, Reports, and Collection Templates
- Future: Modeling User
- Business, Data, Managing Project Modeling, Bridge/Import

## Introduction

## Quick – To follow along the training presentations

- Go to DEAR Home page
- _[http://www.doi.gov/ocio/architecture/dear](http://www.doi.gov/ocio/architecture/dear)_
- Scroll down and click on “DEAR Training”
- Training is provided in a lab on the DOI Network
- Download/Save/Open the appropriate Training Presentation

## DOI EA History

- How did DOI EA Program transform to where it is today?
- What tasks comprise the EA Program?
- How does the EA Program fit into other DOI Enterprise Planning functions?
- Where is the EA Program going next?
- Along all this, how has the EA Information been managed and used?

## FROM WHENCE WE CAME:

- 	***OMB Levied a $66 Million Cut in DOI’s 2004 IT Budget***
- _Extracts from OMB Budget Passback Language:_
- “*Interior appears to have many ****separate and uncoordinated EA efforts**** underway. The Department is directed to *
***- create an integrated and  comprehensive departmental process for           EA****; *
*- to identify and reduce redundancies in these separate approaches; *
*- work with OMB to develop a department-wide EA process; *
*- and continue its efforts to ****map the departmental EA to the Federal Enterprise Architecture efforts of OMB****. *
*This architecture should be fully developed to a ****detail level that ensures the efficient management of Department IT resources****, not merely a high-level overview.”** *

***This drove the transformation of the DOI EA Program***

**Notes:**
Before discussing what they want from us.  Let’s examine how they’ve shown us their displeasure in our performance.  Albeit most of this is targetted at the Departmental level, we’re suffering in the balance.

They’ve levied a substantial cut in IT.  They’ve stated in meetings that the Department doesn’t do an adequate job of screening Major IT investments for duplication, mission essential, architecture alignment, etc.

They’ve scored many of the Bureau’s 300Bs Low.

They don’t see an overarching connected game plan.

Let’s review the OMB Budget Pass Back Language

## To be a “Design” Planning function for a very complex organization... we looked at, what is needed?

- Blueprints

- Line of Sight

- Digestible

- Multiple Stakeholders

- Standard Approach

- Standard Analytics

- Complex
- Organization

## DOI EA has established three major components that drive EA success: “The Triumvirate”

**DOI EA has established three major components that drive EA success: “The Triumvirate”**

**Methodology for Business Transformation**

**DOI Governance Structure**

**DEAR**

- _D_OI _E_nterprise _A_rchitecture _R_epository

## Governance

## We can summarize the DOI IT Governance objectives into four focus areas:

**We can summarize the DOI IT Governance objectives into four focus areas:**

_***Strategic Alignment***_:  focus on aligning with the business and collaborative solutions.
_***Value Delivery***_:  focus on optimizing expenses and proving the value of IT.
_***Risk Management***_:  focus on safeguarding IT assets, disaster recovery, and continuity of operations.
_***Performance Measurement***_:  focus on tracking project delivery and monitoring IT services.

***IT Governance Institute, ***_***Board Briefing on IT Governance***_***, ***
***Second Edition, 2003***

## The supporting governance structure is one of DOI IEA’s cornerstones for success

- An Integrated Governance Structure that Supports EA Recommendations
- All Teams Provide Inputs into Modernization Blueprints
- IEA Governance Structure Linked to E-Gov and CPIC Programs

## Strategic Business Alignment

**The DOI IT governance structure supports all four target focus areas. **

**Strategic Business Alignment**

**Value Delivery**

**Risk Management**

**Performance Measurement**

## The DOI approach is to incrementally plan each DOI and Bureau business areas

## IEA is supporting the eGov Team by having analyzed the DOI business areas and recommending future Blueprints.

| Fiscal Year | Blueprints Completed in Year |
| --- | --- |
| FY 2004 | 4 |
| FY 2006 | 1 |
| FY 2007 | 4+ |
| FY 2008 | ? |
| ... | ? |

**Progress of Architecture Planning (based on major investments)**

**Which Blueprints should be done next?**

## Methodology for Business Transformation

## Quick – Getting Started

- Go to MBT Home page
- http://www.doi.gov/ocio/architecture/mbt

## It is important for an organization to understand the process by which business drivers turn into operational reality.

**Are Used To**

**It is important for an organization to understand the process by which business drivers turn into operational reality.**

**Business Drivers**

**Prioritize Business Areas**

## Developed at the DOI, the Methodology for Business Transformation (MBT) enables all of the major planning functions to analyze business and service areas based on the priorities established by the governance teams.

**Are Analyzed By**

**Are Used To**

**Business Drivers**

**Prioritize Business Areas**

**Enterprise Transition Plan**

## MBT guides integrated change across multiple enterprise planning roles

**MBT guides integrated change across multiple enterprise planning roles**

## The Methodology for Business Transformation (MBT) is designed to answer some of today’s more challenging business questions.

- Mission Performance
- What are the business changes I really need to have?
- Where can we achieve dramatic improvements in performance and how do I know I’ve achieved them?
- Where are the opportunities for and risks for program collaboration, data sharing, and shared business processes?
- Investment Performance
- Where do we spend program funds?
- Do our investments support the business needs?
- HR Performance
- What is the target level of resources I need to have in place, and where?
- How can I move back office resources into mission functions?
- IT Performance
- Where do I have redundant buying?
- Where am I over/under invested? How do I know?
- What metrics do I need?

## The MBT itself is a collection of 14 integrated steps, each with sub-tasks, deliverables, and decision points. 

***Change******(1-5 years)***

***Maintain  Architecture***

***Create the Blueprint***
***(6-12 months)***

**The MBT itself is a collection of 14 integrated steps, each with sub-tasks, deliverables, and decision points. **

***Set Core Team***
***(3-6 months)***

***Scope***
***(Annually)***

## How did we get here?

**How did we get here?**

**MBT v1.5 Released 12/31/2006 – Developed from feedback since 2004 and includes over 200 enhancements focusing ****- ****improved executive/core team alignment and improved blueprint usability and quality**

## Each step within the MBT is further broken into tasks that are described in guidance documents and the MBT project plan.

**Each step within the MBT is further broken into tasks that are described in guidance documents and the MBT project plan.**

## The MBT provides an analysis toolkit of techniques helping information capture and standardizing presentation methods for decision makers.

## DEAR Fully supports all 100+ deliverables within MBT

- All models and metadata required for MBT analysis has been defined within DEAR
- MBT data is loaded within DEAR currently by coordination with DEAR Administrators.
- MBT Team data updates affecting organization portfolio data must be updated by IAWG
- MBT Modeling classes will be implemented in 2007 including managing modeling work in progress databases.

## DOI Enterprise Architecture Repository (DEAR)

## DEAR is one of several information sources used in analysis support of MBT effortsAn effort is underway to integrate this enterprise planning information 

## What Is DEAR?

- IEA developed a system to hold the _D_OI’s _**E**_nterprise _**A**_rchitecture Information in a _**R**_epository – DEAR
- DEAR is a repository of integrated enterprise architecture data.
- DEAR is an enterprise modeling tool that emphasizes data integration and reuse of enterprise objects.
- DEAR is A reporting site that greatly expands access to integrated enterprise architecture data.

## The DOI EA Repository was launched in January 2004 in  support of four major areas:
Maintaining the System Inventory
Integrating the Inventory across several OCIO views
Maintaining and Describing the Inventory in a common language
Maintaining Models used for business transformation efforts 

- Maintaining the System Inventory
- Integrating the Inventory across several OCIO views
- Maintaining and Describing the Inventory in a common language
- Maintaining Models used for business transformation efforts

## DEAR Information is reviewed and accessible over the DOI Network via a protected web-site

## Guidance for Managing EA Information is providing on the DEAR web page http://www.doi.gov/ocio/architecture/dear

- Sources of Guidance
- Population and Maintenance Policy
- Phase Guidance
- FAQs
- DEAR Data Entry Tutorial
- Periodic Training Session Materials
- Regular Interior Architecture Working Group (IAWG) Meetings
- Concept of Operations Document (not posted on Web/DOI Network)

## DEAR Statistics : Usage

- Was Developed in 2003 then launched in 2004
- Over 250 Registered Users from all DOI Bureaus, offices, and contractor support
- Via over 50 Information Sharing sessions with other federal organizations, DEAR has been evaluated for use, used components of, or are using DEAR as their solution.
- DEAR was first EA Information solution to be OMB FEA compliant
- DEAR has over 35000 relationships
- DEAR currently has minor releases every 3 months and major releases every 6 months

## DEAR Statistics : Tech

- DEAR has been/is certified via the DOI C&A process
- DEAR is hosted at NBC and a Service Level Agreement is regularly reviewed and maintained with NBC
- DEAR is based on:
- SQL Server 2005
- Windows
- Generated Web Paged
- Telelogic COTS Package
- Processes for Maintaining and Operating DEAR are maintained by a full-time administration Staff

## DOI Transformation Assets:Current Projects

## Current Major Enhancements in the works

**Current Major Enhancements in the works**

- MBT 1.5 including:
- TCO/ROI
- Security
- Solutions Architecture
- Governance
- Linkage to ETP and FTF
- (Launched December 2006)

**OCIO Modernization Study Findings**

## Enterprise Planning Business Intelligence Integration

## EPBI will give a single view from multiple angles across multiple data sources/services

## Enterprise Architecture

**Enterprise Architecture**

**Solution Architecture**

**Enterprise Service Organization**

**Performance**

**Similar**
**Overlay**
**Could be**
**Demonstrated**
**Using**
**Other**
**Vendor**
**Suites**

**Architecture PMO**

**Viewing architecture ownership**

**Notes:**
Not intended to suggest use of Telelogic, yet to show hypothetical view using Telelogic products in MBT as discussed
At length in conference

Bubbles off the Technology references represent the service standards required if were technology agnostic.

A suite of integrated tools ultimately would be the best result if could be delivered.

Graphic Demonstrates 3 things:
- Further understanding of how Telelogic Products could be implemented in a department using MBT
Understanding of what standard services are needed to implement end to end CIO lifecycle
Understanding of how services are used across MBT

Further Overlays that could be done:
Interfaces
Info Value
MBT Steps
Other Processes – CPIC, C&A, OMB/GAO Assessments
Architecture in action scenarios

## Getting Started

- Getting Access

## Quick – Getting Started

- Go to DEAR Home page
- _[http://www.doi.gov/ocio/architecture/dear](http://www.doi.gov/ocio/architecture/dear)_
- Navigate to the “Get DEAR Access” page

## DEAR Home page has five sections based on where you are as a user

- Getting Access
- Links to login forms, instructions, first-time password, and browser plug-ins
- DEAR Guidance
- 100 page mini-site on Managing EA Information in DEAR
- Using DEAR
- Login buttons to DEAR Reporting Web site or DEAR for editing
- Learning about DEAR
- High Level introduction to DEAR
- More Information About DEAR
- Links to Training, Tutorials, FAQs, Reference Models, and Metamodel

## Who has not obtained a DEAR Login?

- We’re going to review the 4 steps:
- Apply for login and access
- Get/Set Password
- Setup Plug-ins
- Take DEAR Training
- NOTE:
- These training courses use Training accounts and the Lab Computers have Plug-ins setup

## Getting Access to DEAR is processed by NBC and is paper based – here are a few highlights from this page

- Instructions are provided on this page
- Fill out the NBC form online – PDF online fillable form
- Print, sign
- DEAR Requires approving signature by a Security Point of Contact
- Once signed, fax to NBC
- NBC will provide user name and password
- Change password on web page
- Install plug-ins if:
- Adobe SVG - You will be viewing charts/diagrams on web site (All)
- Citrix  - You will be editing information in DEAR

## OK - Let’s practice accessing DEAR

- Three Labs
- Review Gain Access Procedures
- Go to DEAR Page
- Go to “New User”
- Review all 4 steps
- Logging into the DEAR Reporting Site
- Go to DEAR Page
- Click on a Reporting Section
- Your Organization or Blueprint
- Choose a report
- Logging into DEAR (if you will be an Edit/Security User)
- Go to DEAR Page
- Review DEAR Login Page for status
- DEAR Regular or Security User Training will complete this lab with full login
_*Break At your own pace – This lab should take 20-30 minutes*_

## DEAR Policy and Guidance

## Quick – Getting Started

- Go to DEAR Home page
- _[http://www.doi.gov/ocio/architecture/dear](http://www.doi.gov/ocio/architecture/dear)_
- Navigate to the “DEAR Policy” page
- We will navigate
- the DEAR policy
- the Task Guidance
- Detailed Task instructions

## DEAR and its guidance was established by following Policy

- Policy was created in 2004 and revised in 2006
- DEAR has been updated with each policy revision
- DEAR Guidance gets updated including
- Step Guidance
- For Each step, the following is provided online
- Collection Templates
- Wizard Tutorials
- Quality Assurance Reports
- As well as,
- FAQs, Step Summary, relationship to MBT, and Training Links
- This follows the Collect, Load, and QA process for each Step/Task

## DEAR Step-by-step guidance follows the policy requirements to allow for complete and accurate collection, loading and QA

- Like the agenda of this training, the updated Guidance flows as follows:
- Step A: Create/Maintain Inventory
- Chief Architects/IAWG Rep. Responsible
- Step B: Integrate with OCIO
- C&A – ITST Rep. Responsible
- CPIC – OCIO responsible
- Privacy – Future area
- Step C: Describe with Reference Models
- Chief Architects/IAWG Rep. Responsible
- Step D: Capture/Maintain EA Models
- Blueprint teams responsible as part of MBT
- 2004 guidance separately highlighted all areas emphasizing
- Step A as Phase 1 (parts of Step B)
- Step C as Phase 2, 3, and 4
- Step D was covered in MBT separately

## Basic DEAR CONOPS* Requirements

- Selected systems must be tracked at the Departmental level.
- Inventory Policy
- A core set of data is applicable to all systems for consistency in tracking & decision making.
- Reference Models
- Bureaus are the primary owners and managers of data on their systems.
- Policy and Guidance
- Governance & synchronization of bureau & departmental data (content & metadata) is conducted in order to achieve a unified Interior Enterprise Architecture (IEA).
- Integrated OCIO and Bureau Governance
- Information Changes in DEAR are available to Report Users Nightly and all Edit/Security Users can see all changes real-time

- *  Concept of Operations (CONOPS)

## Data Collection Policy and Guidance were created to assist in establishing uniformity and reusability

- Sources of Guidance
- Population and Maintenance Policy - _[http://](http://www.doi.gov/ocio/architecture/DEARPolicy.htm)__[www.doi.gov/ocio/architecture/DEARPolicy.htm](http://www.doi.gov/ocio/architecture/DEARPolicy.htm)_
- Phase Guidance - _[http://www.doi.gov/ocio/architecture/step2.htm](http://www.doi.gov/ocio/architecture/step2.htm)_
- FAQs - _[http://www.doi.gov/ocio/architecture/dearfaq.htm](http://www.doi.gov/ocio/architecture/dearfaq.htm)_
- DEAR Data Entry Tutorial - _[http://www.doi.gov/ocio/architecture/tutorial/index.htm](http://www.doi.gov/ocio/architecture/tutorial/index.htm)_
- Periodic Training Session Materials - _[http://dear.nbc.gov/reports/documents/deartraining.htm#reportuser](http://dear.nbc.gov/reports/documents/deartraining.htm#reportuser)_
- Regular Interior Architecture Working Group (IAWG) Meetings - _[http://www.doi.gov/ocio/architecture/iawg.htm](http://www.doi.gov/ocio/architecture/iawg.htm)_
- Concept of Operations Document (not posted on Web/DOI Network)
- Inventory Change Management Processes are maturing from manual
-  requests to integrated workflow processes over 2006

## Reviewing the Four Parts of DEAR

- _Inventory Management_
- Integrated Inventory
- Describing with Reference Models
- MBT Modeling

## History of Building the Inventory – 	Overall Data Collection Time Frame Summary

|  | 8/1/
2003 | 11/1/
2003 | 2/1/
2004 | 5/1/
2004 | 8/1/
2004 | 11/1/
2004 | 2/1/
2005 | 5/1/
2005 | 8/1/
2005 | 11/1/
2005 | 2/1/
2006 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Phase 0 – Collecting Initial Inventory  |   |   |  |  |  |  |  |  |  |  |  |
| Phase 1 – Bureaus Validating Inventories  |  |  |   |  |  |  |  |  |  |  |  |
| Phase 2 – Mapping inventories to DOI TRM and FEA SRM  |  |  |  |   |  |  |  |  |  |  |  |
| Initial 4 DOI Blueprints |  |  |  |   |   |   |  |  |  |  |  |
| Phase 3a – ... DOI PRM  |  |  |  |  |   |  |  |  |  |  |  |
| Phase 3b – ... DOI BRM  |  |  |  |  |  |   |  |  |  |  |  |
| Phase 4a – ... DOI DRM Information Classes  |  |  |  |  |  |  |  |   |  |  |  |
| Phase 4b Pilot – DOI DRM Entities for Law Enforcement and Recreation  |  |  |  |  |  |  |  |  |   |  |  |
| Bureau Blueprints |  |  |  |  |  |  |  |  |  |   |   |

**Notes:**
Inventory discovering is on-going ; especially as we progress in each blueprint area.

## Architect’s manage the System Inventory for your Bureau; the Bureau CIO is responsible for the Inventory

- Architects manage the DOI System Inventory
- Attributes, detail the System Architecture
- Architects quarterly have a data quality report they review and receive to measure the system inventory accuracy
- Policy dictates that Bureau CIOs must maintain accurate and complete inventories
- If you have a System Inventory Change, please coordinate with your Bureau Chief Architect to facilitate the change

## Inventory Management Controls

- Policy dictates that Bureau CIOs must maintain accurate and complete inventories
- Inventory additions can be made via DEAR System Wizard tool guiding Mandatory Fields and assuring business rules are met
- Inventory removals are currently a manual request process approved by CIOs
- This is to assure that records of inventory removals are kept for each inventory record within DEAR
- Sample Remove Request Reasons Captured:
- System has been retired and is no longer funded
- System was mis-entered, and should be a sub-system of System ID X
- System was mis-entered, and is a duplicate of System ID X
- Project was cancelled, and System never/no longer funded
- Boundary removals must be approved by OCIO Cyber-security Division in order to assure correct C&A reporting and status.

## System Wizard Overview

**System Wizard Overview**
**(Covered in Regular User Training)**

**User context defines which systems you can see and/or edit**

**BFA is used directly on a System**

**Constrained to your Active Group**

## Reviewing the Four Parts of DEAR

- Inventory Management
- _Integrated Inventory_
- Describing with Reference Models
- MBT Modeling

## Integrating all Inventories – example: C&A Boundary and System Inventory

- C&A and EA have partnered to manage the Accreditation Boundary Inventory, Attributes and mapping to DOI System Inventory in DEAR
- This includes:
- C&A Boundary Status
- C&A Boundary Dates
- Contacts
- C&A Boundary Privacy Attributes
- This information is reported quarterly to FISMA

## Integrating all Inventories – example: Ex. 300s and System Inventory

- The Current Investments – Ex. 300 and Ex. 300-1 and its status/description attributes are loaded into DEAR annually
- By relating the Investments to the System Inventory, information related to Systems can be re-used for Ex. 300s – specifically Reference Model information
- eCPIC data is only loaded after the final OMB submission is approved. Meaning for months out of year, DEAR and eCPIC are out of synch.

## Architect or C&A Scenarios for editing in DEAR are performed using “Wizards”

- Architects use the System Wizard to support
- Managing the DOI System Inventory
- Attributes, detail the System Architecture
- Mapping Investments, Systems and detail to all DOI Reference Models
- Using Checkboxes and dropdowns
- Security Users will use the C&A System Wizard to support
- Managing the Accreditation Boundary Inventory
- Adding, editing Attributes (as mentioned)
- Mapping to DOI System Inventory
- Load Privacy Attributes provided by Privacy Officers
- Using Checkboxes and dropdowns

## Inventory Reporting has many stakeholders of varying interests

**Inventory Reporting has many stakeholders of varying interests**

- Different Objectives, Process, Mandates, and reporting needs requires different views of the Inventory
- Thus, Different audiences need to see inventory at different levels

- C&A Boundary

- Ex. 300/300-1

- System A-130

- Sub-System

- Components

- Component Instances

- Sub-System

- Component Instances

- Components

- System A-130

- Capital Planners need to create an Exhibit 300/300-1 inclusive of all systems that are part of the business case

- IT Security Managers are recommended to Certify and Accredit systems within a defined boundary and create a C&A package based on that group

- Enterprise Architects need to be able to construct a blueprint with a sequencing plan and set of steps for each specific system within a certain business focus area

- Business users of the system are typically interested in understanding the functions and information that they use as part of the system – i.e. reporting, transactions, applications

- Solution Architects and Engineers are interested in understanding how the different components they use or build will be deployed in the overall system

- Architects looking for more information on reusable assets – services provided, technology base, scope implemented...
**Used In conjunction with a Component Registry – core.gov**

**CPIC**

**C&A**

**EA**

**BIZ**

**Eng.**

**Arch**

- Audiences

## Let’s take an example – FBMS – (Major App.)

**Let’s take an example – FBMS – (Major App.)**

- Inventory Management requires understanding the audiences needs to view the same inventory at different levels

- C&A Boundary

- Ex. 300/300-1

- System A-130

- Sub-System

- Components

- Component Instances

- Sub-System

- Component Instances

- Components

- There is 1 Ex. 300 for FBMS

- There is 1 C&A Boundary yielding 1 package of documents for FBMS

- FBMS in itself by A-130 is defined as 1 system

- When discussing FBMS to its stakeholders, it is discussed as 7 or so groups of functional and service value that it will provide

- To provide this functionality, over 60 components will be deployed

- FBMS is using Commercial Off the Shelf software to provide much of its services i.e. SAP, Compusearch, etc., but not all software modules/components are being instantiated or have been purchased

**1**

**1**

**1**

**7+**

**60**

**>60**

- Audiences

## Let’s take an example – Enterprise Web  (USGS)

**Let’s take an example – Enterprise Web  (USGS)**

- What happens in the case where a boundary has minor applications as systems within the Boundary?
- Minor System off the WAN ?

- C&A Boundary

- Ex. 300/300-1

- System A-130

- Sub-System

- Components

- Component Instances

- Sub-System

- Component Instances

- Components

- There is 1 C&A Boundary yielding 1 package of documents

- 3 – Web, Public Web, Bureau Web

- 2 - Web is part of Public WEB and the others are part of EWEB

- Looking at Web specifically it has 16 subsystems

- Currently, each sub-system is 1 major component, but more likely due to not being detailed out yet or legacy sub-systems

**2**

**1**

**3**

**16**

**16**

**16**

- Audiences

## Reviewing the Four Parts of DEAR

- Inventory Management
- Integrated Inventory
- _Describing with Reference Models_
- MBT Modeling

## The goals of the Federal Enterprise Architecture are to – 

Enable the Federal Government to identify opportunities to leverage technology and alleviate redundancy, or to highlight where agency overlap limits the value of information technology (IT) investments

Facilitate horizontal (cross-Federal) and vertical (Federal, State and Local) integration of IT resources

Establish the “line of sight” contribution of IT to mission and program performance

Support a more citizen-centered, customer-focused government that maximizes IT investments to better achieve mission outcomes 

**The goals of the Federal Enterprise Architecture are to – **
- Enable the Federal Government to identify opportunities to leverage technology and alleviate redundancy, or to highlight where agency overlap limits the value of information technology (IT) investments
- Facilitate horizontal (cross-Federal) and vertical (Federal, State and Local) integration of IT resources
- Establish the “line of sight” contribution of IT to mission and program performance
- Support a more citizen-centered, customer-focused government that maximizes IT investments to better achieve mission outcomes

- Page

**The need for a Federal Enterprise Architecture (FEA) was a significant finding from the President’s E-Government strategy efforts...**

## Federal Enterprise Architecture (FEA)

_**Business Reference Model (BRM)**_

-  Lines of Business
-  Agencies, Customers, Partners

_**Service Component Reference Model (SRM)**_

-  Capabilities and Functionality
-  Services and Access Channels

_**Technical Reference Model (TRM)**_

-  IT Services
-  Standards

_**Data Reference Model (DRM)**_

-  Business-focused data standardization
-  Cross-Agency Information exchanges

_**Performance Reference Model (PRM)**_

-  Government-wide Performance Measures & Outcomes
-  Line of Business-Specific Performance Measures & Outcomes

**Federal Enterprise Architecture (FEA)**

- Page

**Using the FEA Reference Models, Agencies can now, for the first time, look across the Federal Government and identify opportunities to collaborate, consolidate, and leverage IT investments...**

## Reference models are a taxonomy – much like an index categorization – used to achieve a common language

- Categorize ...
- organization measures by consistent performance categories (i.e. balanced scorecard)
- process architecture models by business function categories
- Organization IT capabilities or products by federal service categories
- Logical entities by subject areas for use across many organizations
- Technology products and categorizations by domains, categories and and standard areas
- Example:
- How many different soft drinks can you come up with?
- How do you categorize those?

## Summary: Moving beyond the OMB – DOI’s DEAR

- The DOI Architecture effort through DEAR can provide the following:
- More detailed business functions for richer description and more powerful means to manage and review business cases
- The relationships of the PRM to investments, business activities and  systems etc.
- It can be a starting point for the development of the investment proposals or the business case.
- A detailed description of technology and services in the context of DOI standards. It can facilitate a means to generate better cost estimates, guide procurements etc..

## Quick – Getting Started

- Go to DEAR Home page
- _[http://www.doi.gov/ocio/architecture/](http://www.doi.gov/ocio/architecture/)_
- From the Home Page, on the bottom, navigate to “Reference Models”
- As we review each reference model, navigate to the enterprise Reference model
- i.e. First will be DOI Performance Reference Model
- Review any of the reports as we review how they are structured – find the example mentioned for each

## The PRM will help agencies identify the performance improvement opportunities that will drive Government transformation

**Notes:**
 A standardized performance measurement framework designed to:
  Enhance available performance information,
  Better align inputs with outcomes, and 
  Identify improvement opportunities across organizational boundaries.
  Agencies can use the PRM to select standard performance indicators—which may be new or coincide with those already in use—which can be tailored or “operationalized” to the specific environment.
  The PRM can be integrated into the existing federal budget process.
  The PRM can mutually reinforce and work together with GPRA and current PMA Budget and Performance Integration initiatives such as the PART, and Common Measures.

## Using the OMB PRM, we can take our strategic plan and report in a balanced scorecard manner

- DOI Performance Reference Model – PRM
- Built from the DOI Strategic Plan
- Linked to all the ABC activity codes
- Contains the following information:
- Mission areas
- End outcomes and measures
- Intermediate outcomes and measures
- Now put in context of Investments, Business functions, Systems etc...
- Information available through Reports

## DOI PRM Example

- Recreation Example:
- DOI Strategic Plan to End Outcome Measures
- Summary:
- Performance Reference Model (PRM) captures the DOI Bureau or Program Strategic Plan and can link to understand which functions or investments are supporting those goals.

## Business Reference Model, Version 2.0

**Business**** Reference Model, Version 2.0**

- Page

## There are two ways to view – Federal and Enterprise

- Sub-Function

- Business Area

**Lines of Business**

**Internal DOI Functions**

**Business Focus Areas**

- Process

- DOI Functions

- DOI Functions

- Process

- Process

- Process

**Start**

**Processes**

**Activities**

**Tasks**

**Service**

**FEA BRM Hierarchy**

- Department of the Interior

## Terminology

**Functions**

**Processes**

**Activities**

**Tasks**

- Related business activities performed to produce an end product or provide a service.
- Have a specific beginning and an end point marked by the delivery of a product or output.

- A group of business tasks usually executed in a sequential fashion to achieve intermediate results.

- The smallest unit of work performed by an organization.
- Limited in duration and scope.

- A logical set of business processes performed on a continual basis.
- Have no specific beginning or end point.

## The initial Department Business Reference Model (BRM) extensions were extended using...?

**The initial Department Business Reference Model (BRM) extensions were extended using...?**

**OMB Business Areas**

**OMB Lines of Business (LOBs)**

**OMB Sub functions *******

**DOI Function/Activities**
- Recursive
- Decomposes to whatever level makes sense

**OMB BRM**

**ABC Work Activities**
- Maps to whatever level makes sense
- Initially, mapped at the terminal nodes of the DOI Function/Activity node tree

*** Acts as the top level of the DOI Decomposition**

- Something you charge to every day
- Those tasks are mapped to work elements
- Those work elements are grouped into enterprise work activities
- All of these have labor costs, roles, time captured, organizations, projects, etc. attributed in payroll and Activity Based Costing Management Systems
- By extending the BRM with this information, we have a headstart as to describing what processes we automate

## Services for Citizens

**Services for Citizens**

**General Science & Innovation**

**Natural Resources**

**Health**

**Litigation and Judicial Services**

**Income Security**

**Disaster Management**

**Environmental Management**

**Community & Social Services**

**Education**

**Law Enforcement**

- Disaster Monitoring and Prediction
- Disaster Preparedness and Planning
- Disaster Repair and Restore
- Emergency Response

- Scientific & Technological Research and Innovation

- Water Resource Management
- Conservation, Marine and Land Management
- Recreational Resource Management and Tourism

- Illness Prevention
- Public Health Monitoring
- Consumer Health and Safety

- Community and Regional Development
- Social Services

- Legal Defense
- Legal Investigation
- Resolution Facilitation

- Criminal Apprehension
- Citizen Protection
- Property Protection
- Crime Prevention

- Housing Assistance
- Food and Nutrition Assistance
- Survivor Compensation

- Environmental Monitoring and Forecasting
- Environmental Remediation
- Pollution Prevention and Control

- Elementary, Secondary, and Vocational Education
- Cultural and Historic Preservation
- Cultural and Historic Exhibition

**Department of the Interior delivers more BRM Services to Citizens Sub Functions than any other Federal Agency.**

**Economic Development**

- Business/Industry Development
- Financial Sector Oversight
- Intellectual Property Protection
- Industry Sector Income Stabilization

**Energy**

- Energy Resource Mgmt.
- Energy Supply
- Energy Conservation/Preparedness
- Energy Production

## Chart of all Federal Agencies and their total BRM Services to Citizens Sub Functions being performed.

_***SOURCE***_:	OMB Report on Information Technology (IT) Spending for the Federal Government For Fiscal Years 2005, 2006, and 2007
- 	http://www.whitehouse.gov/omb/budget/fy2007/sheets/itspending_new.xls

## DOI BRM Example

- Recreation Example:
- Recreation Functions linked through Activities to IDEF0 Models
- Summary:
- Business Reference Model (BRM) at the DOI has been extended by over 300 functions representative of the functions and processes and lower-level activities being performed at the DOI. Overlap and Gap Analysis of this area is very powerful.

## Draft Data Reference Model (DRM)

***Standardization of data for cross-agency data exchange***

## Data Reference Model (DRM)

- Key Concepts:
- Defines data standards & models used by the DOI business functions & systems
- Includes:
- Logical data models
- Conceptual data models
- Data categories (groups of data entities, also known as data subject areas)
- Note:
- FEA DRM is not formally released
- Interior’s DRM is built on the best FEA DRM information available
- Key Domain Links:
- Links to BRM to show data entities supporting DOI Function/Activities
- Links to System Architecture to show data entities used by system components

## Service Component Reference Model (SRM)

- Page

**Service Component Reference Model (SRM)**

***A business-driven, functional framework that classifies capabilities (or service components) according to how they support business and performance objectives***

## Technical Reference Model (TRM)

- Page

***Provides the means by which service components can be leveraged, built, and deployed across the Federal Government***

## The TRM provides guidance and recommendations that support the development and implementation of service components that embrace a Component-Based Architecture

**The TRM provides guidance and recommendations that support the development and implementation of service components that embrace a Component-Based Architecture**

**Security**

**Presentation / Interface**

**Business Logic**

**Data Interchange**

**Data Management**

- Security

- Presentation / Interface

- Business Logic

- Data  Management

- Data Interchange

- Component Architecture

** ****X.509**
** ****NIST / FIPS 186**
** ****Secure Socket Layers (SSL)**

** ****HTML**
** ****JSP, ASP, ASP.Net**
** ****DTHML, CSS, XHTMLMP**

** ****Java/J2EE (EJB)**
** ****C, C++, JavaScript**
** ****COM/COM+, C#**
** ****Visual Basic**

** ****XML**
** ****ebXML**
** ****RDF, WSUI**
** ****XSLT**

** ****XBRL, JOLAP, OLAP**
** ****JDBC, ODBC**
** ****ADO, ADO.Net**

*Partial List*

- Page

## Collectively, the FEA Reference Models provide the framework for linking IT to business and performance objectives...

- Regulatory Management

- Support Delivery
- of Services

- Policy and Guidance Devel.
- Public Comment Tracking
- Regulatory Development
- Rule Publication

- Knowledge Mgmt
- CRM
- Content Mgmt
- Collaboration
- Search
- Portal
- Personalization

_**Business**_
_**Reference Model**_
**( BRM )**

- Rule Publication

_**Service Component**_
_**Reference Model**_
**( SRM )**

- Technologies

- Platforms
-    J2EE
-    .NET
-    Windows NT

- Data Mgmt
-    ODBC
-    JDBC
- Business Logic

_**Technical**_
_**Reference Model**_
**( TRM )**

_**Performance Reference Model (PRM)**_
*Outcomes, Measurements, Metrics*

*Business lines and functions*

*Supporting technology*
*and standards*

*Enabling capabilities, components, and services*

**Component-Based / Service-Oriented Architecture**

**Service Layers**

**Service Types**

**Service Components**

_**Data and Information Reference Model (DRM)**_
*Classification, Categorization, XML, Sharing*

- Page

**Collectively, the FEA Reference Models provide the framework for linking IT to business and performance objectives...**

## By describing the inventory with reference cross-analysis can be performed, EA can help answer more than 50% of MB questions (other % are cost related)

**DEAR Sample Touch Points**

- Mission Performance
- What are the business changes I really need to have?
- Where can we achieve dramatic improvements in performance and how do I know I’ve achieved them?
- Where are the opportunities for and risks for program collaboration, data sharing, and shared business processes?
- Investment Performance
- Where do we spend program funds?
- Do our investments support the business needs?
- HR Performance
- What is the target level of resources I need to have in place, and where?
- How can I move back office resources into mission functions?
- IT Performance
- Where do I have redundant buying?
- Where am I over/under invested? How do I know?
- What metrics do I need?

## The Methodology for Business Transformation (MBT) is designed to answer some of today’s more challenging business questions.

- Mission Performance
- What are the business changes I really need to have?
- Where can we achieve dramatic improvements in performance and how do I know I’ve achieved them?
- Where are the opportunities for and risks for program collaboration, data sharing, and shared business processes?
- Investment Performance
- Where do we spend program funds?
- Do our investments support the business needs?
- HR Performance
- What is the target level of resources I need to have in place, and where?
- How can I move back office resources into mission functions?
- IT Performance
- Where do I have redundant buying?
- Where am I over/under invested? How do I know?
- What metrics do I need?

## The Complex Logical Data Model and Glossary will be reviewed in the Edit User Class to understand how to discover the touch points

**The Complex Logical Data Model and Glossary will be reviewed in the Edit User Class to understand how to discover the touch points**

- Deployment Arch

- CPIC Touchpoints

- TRM

- System Architecture

- ABC Matrix

- SRM

- BRM

- Business Area

- PRM

- DRM

- Data Category
- Subject Area, Info Class, Entity

- Conceptual Data Models

- Logical Data Models

- Physical Data Models

- Line of Business

- Service Standard

- Subsystem*

- Service Area

- Service Category

- ABC Work Activities

- Mission

- Measures *

- Sub Function
- /Activity *

- Service Layer

- Service Type

- Service Component

- System Comp *

- Service Specification*

- System*

- Intermediate Outcome

- End Outcome

- Location*

- Processing Node*

- System Comp Instance

- C&A System *

- CPIC Status

- Org and People

- Person

- Organization*

- Investment *

## Reviewing the Four Parts of DEAR

- Inventory Management
- Integrated Inventory
- Describing with Reference Models
- _MBT Modeling_

## 1. Who do we serve?

**1.**** Who do we serve?**

**2.**** What do they say about our business products and services?**

**3.**** Why do we exist?**

**4.**** What business products or services do we deliver to meet our stakeholders’ needs?**

**5.**** How do we deliver the business products and services?**

**6.**** What do we need to deliver the business products and services?**

**7.**** How much does it cost to deliver the business products and services?**

## The MBT itself is a collection of 14 integrated steps, each with sub-tasks, deliverables, and decision points. 

***Change******(1-5 years)***

***Maintain  Architecture***

***Create the Blueprint***
***(6-12 months)***

**The MBT itself is a collection of 14 integrated steps, each with sub-tasks, deliverables, and decision points. **

***Set Core Team***
***(3-6 months)***

***Scope***
***(Annually)***

## The MBT is designed to align with the Federal Enterprise Architecture reference models in order to facilitate inter-Agency communications.

***Change******(1-5 years)***

***Maintain  Architecture***

***Create the Blueprint***
***(6-12 months)***

**The MBT is designed to align with the Federal Enterprise Architecture reference models in order to facilitate inter-Agency communications.**

***Set Core Team***
***(3-6 months)***

***Scope***
***(Annually)***

- PRM

- BRM

- SRM/TRM

- BRM

- DRM

- SRM/
- TRM/
- DRM

- DRM

## The MBT is designed to leverage and build out your segment architecture views and build on your portfolios

***Change******(1-5 years)***

***Maintain  Architecture***

***Create the Blueprint***
***(6-12 months)***

**The MBT is designed to leverage and build out your segment architecture views and build on your portfolios**

***Set Core Team***
***(3-6 months)***

***Scope***
***(Annually)***

- BFA

- System

- Deploy/
- Security

## Conclusion

## Concluding Observations

- DEAR manages a single _**integrated**_ _**inventory**_ across the department
- Using _**Reference models**_ support improved communication in one common language resulting in better analysis
- DEAR is one of several current data sources required for _**Methodology for Business Transformation (MBT)**_
- DEAR is no substitute for the judgment of an experienced manager:
- Managers evaluate recommendations, make decisions, & set policies based on Interior’s mission, business, and resources.

## Conclusion, it is the EA Programs hope that you

- ...have a view of where _**EA Information fits in enterprise view **_of all enterprise information
- ...have _**familiarity with the language **_used to describe enterprise architecture
- ...be able to _**communicate the history **_of information collection and maintenance of EA information
- ...have a clear _**understanding of what information is available **_in DEAR
- ...be _**aware of future state of EA Information **_Use and Availability
- ...know _**how and what to access for your EA information**_
- ...be able to firmly _**support the principle of maintaining **_accurate EA Information