Department of Interior Enterprise
       Architecture (IEA)




Modernization Blueprint Methodology
    and As-Is Architec...
June 8, 2010Table of Contents
1. Executive Summary...........................................................................
6.1 Introduction.............................................................................................................
7.4.2 System to C&A Status.........................................................................................41
    ...
1.    Executive Summary
The following document describes the DOI Modernization Blueprint Methodology and provides As-Is DO...
retired, consolidated, and re-engineered; and identify the investment proposals / projects to enable the
realization of th...
2. Introduction
Enterprise Architecture3 (EA) is defined as a strategic information asset base, which defines the business...
3. References
Through a collaborative Interior-wide process, the IEA Common Requirements Vision (CRV) was developed
and pu...
4. Modernization Blueprint Methodology
The Interior’s Modernization Blueprint Methodology encompasses all steps from the a...
User-Defined Diagrams                        Custom Framework




                                                        ...
Strategies &    PRM
                               Measures
                                                              ...
TRM – Technical Reference Model Domain. The TRM contains the Interior’s technology standards
arranged in the context of th...
consolidated view of bureau enterprise systems tracked at the department level. DEAR is implemented using
a standard base ...
Figure 5 shows the iterative nature of the Interior’s modernization blueprint process and the relationships
among the acti...
Define Modernization Purpose
                   Analyze “As Is”
                                                          ...
Table 1: Analyze As-Is Business Operations Subtasks
Task:           Collect Current Issues
Definition:     Document any kn...
•    (P2) Extent of stakeholder’s feedback for accomplishing performance measures associated with
         strategic goals...
•    Target systems are those systems (or system components) with relatively high business and
         technology fit.


...
that support those roles for each LOB. The tasks involved with developing the To-Be architecture are
iterative in nature--...
gather their input. Stakeholders assist in the production of the architecture during development. Completed
areas of the a...
The Capability Maturity Profile is organized to support the business focus of DOI within the IEA
modernization effort. It ...
Segment Analysis is divided into two forms of transformation. Process Transformation provides an approach
for the DOI to m...
Evaluate Alignment




                                                                                                   ...
Review Change Proposals




                                                                                              ...
5. Appendix A - LOB As-Is Architecture for Law Enforcement
5.1      Introduction

The following takes the Law Enforcement ...
use directly, or have the costs associated with bureau/ departmental office work activities captured under
them. For the D...
5.2.6    Line of Business to SRM
The SRM provides a common technology neutral framework and vocabulary to characterize the...
Outcome it supports, the BRM function/activities it supports, the SRM service components its related to, and
its associate...
Table 5-13 Law Enforcement LOB Investment to Associated BRM Function Activities

      5.3.6     Investment to SRM
OMB gui...
5.4.3   System to Privacy
The DOI tracks systems based on whether or not they contain privacy-related information. The fol...
6. Appendix B - LOB As-Is Architecture for Fire Management
6.1      Introduction

The following takes the Fire Management ...
use directly, or have the costs associated with bureau/ departmental office work activities captured under
them. For the D...
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Template for Modernization Blueprints
Upcoming SlideShare
Loading in …5
×

Template for Modernization Blueprints

991 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
991
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
65
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Template for Modernization Blueprints

  1. 1. Department of Interior Enterprise Architecture (IEA) Modernization Blueprint Methodology and As-Is Architectures for Lines of Business (LOBs): Fire Management Law Enforcement Financial Management Recreation Draft – Version 1.0
  2. 2. June 8, 2010Table of Contents 1. Executive Summary..........................................................................................................5 2. Introduction .......................................................................................................................7 3. References..........................................................................................................................8 4. Modernization Blueprint Methodology..............................................................................9 4.1 DOI Enterprise Architecture Repository (DEAR).......................................................9 4.1.1 DEAR Metamodel...............................................................................................10 4.1.2 DEAR Implementation / Concept of Operations................................................12 4.2 Interior’s Modernization Blueprint Methodology Activities.....................................13 Analyze As-Is Environment............................................................................................14 4.2.1 Define Modernization Blueprint Purpose and Scope..........................................15 4.2.2 Analyze As-Is Business Operations ...................................................................15 4.2.3 Analyze As-Is System Portfolio..........................................................................16 Develop To-Be Enterprise Architecture .........................................................................18 Develop the Transition Plan............................................................................................20 Drive Transformation......................................................................................................21 Drive Compliance...........................................................................................................22 Maintain the Enterprise Architecture..............................................................................23 5. Appendix A - LOB As-Is Architecture for Law Enforcement.........................................25 5.1 Introduction................................................................................................................25 5.2 Line of Business (LOB) Associations........................................................................25 5.2.1 Line of Business to PRM....................................................................................25 5.2.2 Line of Business to Outcomes.............................................................................25 5.2.3 Line of Business to ABC Work Activities..........................................................25 5.2.4 Line of Business to BRM....................................................................................26 5.2.5 Line of Business to Process Models....................................................................26 5.2.6 Line of Business to SRM....................................................................................27 5.2.7 Line of Business to TRM....................................................................................27 5.2.8 Line of Business to DRM....................................................................................27 5.3 Investment Associations.............................................................................................27 5.3.1 Investment List showing CPIC Status and Investment Attributes......................28 5.3.2 Investment to System..........................................................................................28 5.3.3 Investment to PRM..............................................................................................28 5.3.4 Investment to Primary BRM...............................................................................28 5.3.5 Investment to Associated BRM...........................................................................28 5.3.6 Investment to SRM..............................................................................................29 5.3.7 Investment to TRM (Standard)...........................................................................29 5.4 System Portfolio Associations...................................................................................29 5.4.1 System Diagram..................................................................................................29 5.4.2 System to C&A Status.........................................................................................29 5.4.3 System to Privacy................................................................................................30 5.4.4 System to FEA Models (BRM, SRM, TRM)......................................................30 5.4.5 System to TRM Technical Specifications...........................................................30 5.5 Conclusion / Recommendations.................................................................................30 6. Appendix B - LOB As-Is Architecture for Fire Management.........................................31 2
  3. 3. 6.1 Introduction................................................................................................................31 6.2 Line of Business (LOB) Associations........................................................................31 6.2.1 Line of Business to PRM....................................................................................31 6.2.2 Line of Business to Outcomes.............................................................................31 6.2.3 Line of Business to ABC Work Activities..........................................................31 6.2.4 Line of Business to BRM....................................................................................32 6.2.5 Line of Business to Process Models....................................................................32 6.2.6 Line of Business to SRM....................................................................................33 6.2.7 Line of Business to TRM....................................................................................33 6.2.8 Line of Business to DRM....................................................................................33 6.3 Investment Associations.............................................................................................33 6.3.1 Investment List showing CPIC Status and Investment Attributes......................34 6.3.2 Investment to System..........................................................................................34 6.3.3 Investment to PRM..............................................................................................34 6.3.4 Investment to Primary BRM...............................................................................34 6.3.5 Investment to Associated BRM...........................................................................34 6.3.6 Investment to SRM..............................................................................................35 6.3.7 Investment to TRM (Standard)...........................................................................35 6.4 System Portfolio Associations...................................................................................35 6.4.1 System Diagram..................................................................................................35 6.4.2 System to C&A Status.........................................................................................35 6.4.3 System to Privacy................................................................................................36 6.4.4 System to FEA Models (BRM, SRM, TRM)......................................................36 6.4.5 System to TRM Technical Specifications...........................................................36 6.5 Conclusion / Recommendations.................................................................................36 7. Appendix C - LOB As-Is Architecture for Financial Management.................................37 7.1 Introduction................................................................................................................37 7.2 Line of Business (LOB) Associations........................................................................37 7.2.1 Line of Business to PRM....................................................................................37 7.2.2 Line of Business to Outcomes.............................................................................37 7.2.3 Line of Business to ABC Work Activities..........................................................37 7.2.4 Line of Business to BRM....................................................................................38 7.2.5 Line of Business to Process Models....................................................................38 7.2.6 Line of Business to SRM....................................................................................39 7.2.7 Line of Business to TRM....................................................................................39 7.2.8 Line of Business to DRM....................................................................................39 7.3 Investment Associations.............................................................................................39 7.3.1 Investment List showing CPIC Status and Investment Attributes......................40 7.3.2 Investment to System..........................................................................................40 7.3.3 Investment to PRM..............................................................................................40 7.3.4 Investment to Primary BRM...............................................................................40 7.3.5 Investment to Associated BRM...........................................................................40 7.3.6 Investment to SRM..............................................................................................41 7.3.7 Investment to TRM (Standard)...........................................................................41 7.4 System Portfolio Associations...................................................................................41 7.4.1 System Diagram..................................................................................................41 3
  4. 4. 7.4.2 System to C&A Status.........................................................................................41 7.4.3 System to Privacy................................................................................................42 7.4.4 System to FEA Models (BRM, SRM, TRM)......................................................42 7.4.5 System to TRM Technical Specifications...........................................................42 7.5 Conclusion / Recommendations.................................................................................42 8. Appendix D - LOB As-Is Architecture for Recreation....................................................43 8.1 Introduction................................................................................................................43 8.2 Line of Business (LOB) Associations........................................................................43 8.2.1 Line of Business to PRM....................................................................................43 8.2.2 Line of Business to Outcomes.............................................................................43 8.2.3 Line of Business to ABC Work Activities..........................................................43 8.2.4 Line of Business to BRM....................................................................................44 8.2.5 Line of Business to Process Models....................................................................44 8.2.6 Line of Business to SRM....................................................................................45 8.2.7 Line of Business to TRM....................................................................................45 8.2.8 Line of Business to DRM....................................................................................45 8.3 Investment Associations.............................................................................................45 8.3.1 Investment List showing CPIC Status and Investment Attributes......................46 8.3.2 Investment to System..........................................................................................46 8.3.3 Investment to PRM..............................................................................................46 8.3.4 Investment to Primary BRM...............................................................................46 8.3.5 Investment to Associated BRM...........................................................................46 8.3.6 Investment to SRM..............................................................................................47 8.3.7 Investment to TRM (Standard)...........................................................................47 8.4 System Portfolio Associations...................................................................................47 8.4.1 System Diagram..................................................................................................47 8.4.2 System to C&A Status.........................................................................................47 8.4.3 System to Privacy................................................................................................47 8.4.4 System to FEA Models (BRM, SRM, TRM)......................................................48 8.4.5 System to TRM Technical Specifications...........................................................48 8.5 Conclusion / Recommendations.................................................................................48 9. Glossary of Terms ...........................................................................................................49 4
  5. 5. 1. Executive Summary The following document describes the DOI Modernization Blueprint Methodology and provides As-Is DOI Architectures for the following business areas1, or lines of business (LOBs): Fire Management, Law Enforcement, Financial Management, and Recreation. The As-Is DOI architectures provides a baseline as the precursor to developing the To-Be, or target, architectures. The Interior’s Modernization Blueprint will define a roadmap between Interior’s existing and target applications architecture with associated transition plans for migrating between the two. The supporting analyses of the blueprint will aim to improve alignment of Interior’s proposed information technology (IT) investments with the DOI strategic plan, minimize functional and data redundancies, and leverage proven state-of-the-art technologies consistent with the DOI technical reference model (TRM). To define the As-Is DOI Business Architectures, data was gathered across organizational boundaries. Existing architecture artifacts were reviewed, placed into the context of the OMB Federal Enterprise Architecture (FEA) Reference Models, and imported into the DOI Enterprise Architecture Repository (DEAR) modeling tool. DEAR is a repository of integrated enterprise architecture data. It is the authoritative source of Interior’s application systems and architecture artifacts. The DEAR modeling tool emphasizes data integration and re-use of enterprise objects. It also features reporting capabilities that greatly expands access to integrated enterprise architecture data. One key aspect of DEAR is its ability to standardize the data collected about systems and ensure uniform modeling of the systems across system groupings. Various DEAR ad hoc reports were created in support of the development of the As-Is DOI Business Architecture reports. DEAR has been tailored to fully support the Interior’s Modernization Blueprint Methodology and OMB FEA reference models. The FEA Reference Models are designed to facilitate cross-agency analysis and improvement. They consist of five interrelated models2: 1. The Performance Reference Model (PRM) - The PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. 2. Business Reference Model (BRM) – The BRM is a function-driven framework to describe the LOBs and sub-functions performed by the federal government independent of the agencies that perform them. 3. Service Component Reference Model (SRM) – The SRM provides a common framework and vocabulary to characterize the IT and business components that collectively comprise an IT investment. The SRM will help agencies rapidly assemble IT solutions through the sharing and re- use of business and IT components. 4. Technical Reference Model (TRM) – The TRM provides a foundation to describe the standards, specifications, and technologies supporting the delivery, exchange, and construction of business or service components and e-government solutions. 5. The Data and Information Reference Model (DRM) – The DRM will describe, at an aggregate level, the data and information that support program and business line operations. The model will aid in describing the types of interaction and exchanges that occur between the federal government and its various customers, constituencies, and business partners. Upon concurrence of the As-Is architecture baseline, the Interior Enterprise Architecture (IEA) team will execute a detailed analytical process to develop modernization blueprints for Interior business functions in partnership with Interior’s business and IT communities. The scope of this analysis will include existing and planned Interior major application systems. These blueprints will classify Interior application systems based upon agreed upon criteria. Tactical and strategic transition plans will be developed based on the system classification to migrate towards Interior’s Target Applications Architecture (TAA). The tactical transition plan will include short-term improvements in alignment with strategic architecture goals. Improvements will be prioritized to yield maximum benefits across a LOB or system grouping within budget constraints. The strategic transition plan will provide a conceptual roadmap to target architecture; identify systems to be 1 Note: the Indian Trust Line of Business referenced in the original Statement of Work (SOW) was subsequently removed from the Northrop Grumman scope of work. 2 http://www.feapmo.gov/fea.asp 5
  6. 6. retired, consolidated, and re-engineered; and identify the investment proposals / projects to enable the realization of the future state. 6
  7. 7. 2. Introduction Enterprise Architecture3 (EA) is defined as a strategic information asset base, which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. An enterprise architecture includes a baseline architecture (As-Is architecture), target architecture (To-Be architecture), and a sequencing plan (transition plan). These EA work products in totality are often referred to as a Modernization Blueprint. The OMB defines these Modernization Blueprints as a component-based enterprise architecture that addresses business lines, data, information, and technology necessary to meet missions, within and across departments. The DOI has a requirement to create an integrated and comprehensive Interior-wide enterprise architecture (IEA) and associated management processes (such as governance, CPIC integration, communications, etc.). The Interior’s Modernization Blueprint is the collective effort to achieve the IEA requirement. The IEA will integrate the business and technology architectures. The IEA will be used to ensure effective and efficient alignment of DOI’s IT resources (such as its automated systems and computing and networking environment) with its strategic business objectives. The IEA will also be used to identify and reduce functional, process, data and technology redundancies that prove inefficient and/or ineffective in DOI’s application system portfolio and computing/networking environment. The development of in-depth As-Is DOI Business Architectures is the first step in the creation of an integrated enterprise architecture and begins the process of business and technology architecture integration and alignment of IT resources to strategic business objectives. The goals of the Interior’s Modernization Blueprint effort are: 1. Ensure alignment between application systems and DOI mission and goals. 2. Reduce or eliminate functional redundancies across systems. 3. Foster the “Write-Once Use-Many” principle of data management through integrated data stores. 4. Obtain/retain adequate OMB funding for Interior’s application systems. 5. Reduce O&M costs associated with existing and planned systems. 6. Leverage, where possible, existing and planned infrastructure components. 7. Re-use, where possible, existing and planned technology components. 3 “A Practical Guide to Federal Enterprise Architecture”, Federal CIO Council 7
  8. 8. 3. References Through a collaborative Interior-wide process, the IEA Common Requirements Vision (CRV) was developed and published on October 15, 2001. This vision document is intended to ensure that Interior's IT products and services are aligned with the business community’s strategic direction. Subsequently, the IEA Conceptual Architecture Principles (CAP) was published in January 2002. The CAP identifies a logically consistent set of principles derived from the business requirements in the CRV. These principles guide the engineering of the organization’s information systems and technology infrastructure. The approach, methodology and supporting criteria for developing Interior’s modernization blueprint is based on the above documents, which may be reviewed at: http://www.doi.gov/ocio/architecture/. • Business Reference Model (BRM) Version 2.0 Release Document - This document outlines the definition of the Business Reference Model Version 2.0. It includes the BRM creation and validation processes, as well as detailed descriptions of the Federal Business Areas, Lines of Business, Sub-Functions and Modes of Delivery. • Performance Reference Model (PRM) Version 1.0 Release Document Volume I - This document describes the PRM and provides information about why a PRM is needed, who can benefit from using it, and how the PRM was developed. • Performance Reference Model (PRM) Version 1.0 Release Document Volume II - This document discusses how the PRM can be used through the IT life cycle and identifies integration points with other key management processes, including agency IT CPIC, EA, GPRA, PART, and the budget process. • Service Component Reference Model (SRM) Version 1.0 Release Document - This document outlines the definition of the Service Component Reference Model Version 1.0. It includes the SRM creation and validation processes, as well as detailed descriptions of the Federal Service Domains, Types and Components. • Technical Reference Model (TRM) Version 1.1 Release Document - This document outlines the definition of the Technical Reference Model Version 1.1. It includes the TRM creation and validation processes, as well as detailed descriptions of the Federal Service Areas, Categories, Standards and Specifications. • FEA Federal Reference Models (BRM,SRM,TRM) Version 1.2: XML Document - This document is the part of the Federal Enterprise Architecture relating to the BRM v2.0, SRM v1.0, and theTRM v1.1. It includes the various layers of the Federal Reference Models and their detailed descriptions. • E-Gov Enterprise Architecture Guidance (Common Reference Model) - This document describes a federal e-government target conceptual architecture. The architecture is based on the business requirements derived from the initiatives as well as system engineering design best practices. It provides a workable description of the components needed by e-government initiatives and business activities to move rapidly into the web service-enabled business transaction environment. • FEA A-11 Additional Guidance Document - This document provides detailed guidance and examples to help agencies complete the FEA-related requirements, and to help them complete questions in the OMB Exhibits 53 and 300 for IT investments. This document is intended for IT project managers or senior analysts completing these exhibits for submission to OMB. 8
  9. 9. 4. Modernization Blueprint Methodology The Interior’s Modernization Blueprint Methodology encompasses all steps from the analysis of the As-Is environment, developing the To-Be architecture, and developing Transition Plan, to the actual realization of the IEA through architecture transformation, compliance, and maintenance. The Interior’s modernization blueprint will define a roadmap between Interior’s existing and target applications architecture with associated transition plans for migrating between the two. The supporting analyses of the blueprint will aim to improve alignment of Interior’s proposed IT investments with the DOI strategic plan, minimize functional and data redundancies, and use proven, state-of-the-art technologies consistent with the DOI TRM. This blueprint will have sub-documents (or sections) that address specific lines of business (e.g., recreation, law enforcement, financial management) and will be reviewed and updated periodically as business needs and priorities change. The development of Interior’s modernization blueprint is a collaborative and iterative effort that encompasses stakeholders from both business and IT communities throughout Interior. In partnership with Interior’s business and IT communities, the IEA will execute a detailed analytical process to develop modernization blueprints for Interior business functions. The scope of this analysis will include existing and planned Interior major application systems. These blueprints will classify Interior application systems based upon an agreed upon criteria. Transition plans will also be developed based on the system classification to migrate towards Interior’s Target Applications Architecture (TAA). 4.1 DOI Enterprise Architecture Repository (DEAR) The DOI selected Popkin’s System Architect as the architecture modeling tool supporting the Interior’s modernization effort. As part of the Interior’s modernization blueprint effort, architecture artifacts are being reviewed and imported into the DOI Enterprise Architecture Repository (DEAR) modeling tool4. DEAR is a repository of integrated enterprise architecture data. The DEAR modeling tool emphasizes data integration and re-use of enterprise objects. It also features reporting capabilities that greatly expands access to integrated enterprise architecture data. DEAR has been tailored to fully support the Interior’s modernization blueprint methodology and OMB FEA reference models. DEAR features a tailored user interface, DOI- defined diagrams, 100s of DOI-defined model objects, stakeholder views, and a custom DOI framework. The DEAR user interface is shown below. 4 http://www.doi.gov/ocio/architecture/dear/ 9
  10. 10. User-Defined Diagrams Custom Framework Custom Matrices Custom Tabs Stakeholder Views FEA Model Views Figure 1: DEAR Tailored User Interface DEAR is the authoritative source of Interior’s application systems and architecture reference models (PRM, BRM, SRM, DRM and TRM). The DEAR will be used as an analytical tool to develop modernization blueprints for specific lines of business functions (such as Recreation and Law Enforcement). In accordance with OMB FEA guidance and directives, the Interior’s major applications will be mapped to the FEA models (PRM, BRM, SRM and TRM) to drive the analysis discussed above. The IEA will work closely with all stakeholders and IEA sub-teams to ensure the information contained in the DEAR is accurate, current and reflects the systems’ capabilities. 4.1.1 DEAR Metamodel The DEAR metamodel is the data schema for the architecture artifacts contained and modeled within DEAR. The DEAR metamodel consists of eight interrelated domains. The five FEA reference models are modeled with DEAR. These are the PRM, BRM, SRM, TRM, and DRM. In addition, the DOI added three additional domains: Investment Architecture, System Architecture, and Deployment Architecture. Each of these domains is discussed below. A diagram of the DEAR Conceptual Metamodel is shown below. 10
  11. 11. Strategies & PRM Measures Business Description Investment Architecture BRM Reusable Data System Architecture DRM Deployment Architecture SRM Common TRM Capabilities Standard Technologies Figure 2: DEAR Conceptual Metamodel PRM – Performance Reference Model Domain. The PRM contains Interior’s strategy, goals, and objectives that drive the architecture. The PRM portion of DEAR contains elements of Interior’s Strategic Plan (goals, outcomes, outcome measures). The PRM is linked to ABC work activities by end and intermediate outcomes, thus linking work performed to strategic objectives. ABC work activities also have corresponding function activities. ABC work activities can be used to connect the BRM to the PRM. Business cases (investments) are also linked to the PRM by the strategic goals and objectives a given investment supports. BRM – Business Reference Model Domain. The BRM contains the Interior’s business function and processes. The BRM portion of DEAR contains mappings of Interior business activities to the OMB’s FEA BRM. The DOI has extended the FEA BRM by two additional levels to make it easier to map system details The BRM helps show whether systems are redundant. The BRM is linked to PRM (by ABC work activities) to show which business activities are addressing which goals. The BRM is linked to the Investment Architecture to show how investments contribute to the business. The BRM is linked to the System Architecture to show which systems support the business. The BRM is linked to the DRM to show what data supports the business and what data is re-used. Finally, the BRM is linked to the SRM to show what capabilities/services support a business function or line of business. SRM – Service Reference Model Domain. The SRM contains the Interior’s service components or capabilities. It is a technology-neutral language to describe systems and investments in terms of the services or capabilities they require or provide. The SRM portion of DEAR builds on the pattern of OMB’s FEA SRM, but the Interior SRM adds IT principles and best practices. The SRM is linked to BRM to show which BRM sub-function each SRM service supports. The SRM also has links to the TRM to show which technologies perform each service. DRM – Data Reference Model Domain. The DRM contains the Interior’s data standards and models. The DRM portion of DEAR includes logical data models, conceptual data models, and data categories (groups of data entities, also known as data subject areas). The FEA DRM is not yet formally released, so the Interior’s DRM is built on the best FEA DRM information available, combined with the best practices from the Interior and its bureaus. 11
  12. 12. TRM – Technical Reference Model Domain. The TRM contains the Interior’s technology standards arranged in the context of the FEA TRM. The TRM builds on the hierarchical pattern of OMB’s FEA TRM: Technical-Service-Area (Level 1), Technical-Service-Category (Level 2), Technical-Service-Standard (Level 3). To these levels, the Interior TRM adds Interior and bureau details below the third level, as Technical- Service-Specifications, which are actual products, specifications, standards, and technologies associated with key Interior systems. Investment Architecture Domain. The Investment Architecture contains Interior project or investment information. It contains the vast majority of information typically found in a business case (OMB Exhibit 300 or 300-1). It allows investments and systems to be compared by where are they in the investment cycle and how are they funded. DEAR is not the system of record for investment data, but it does allow the DOI to analyze the data within enterprise architecture and other architecture domains. System Architecture Domain. The System Architecture contains the Interior’s systems and their building blocks. It is closely related to the Investment Architecture and hierarchically links: systems; sub-systems and re-usable system components. It uses links to other domains to describe the following characteristics of sub-systems and system components: services they perform (how they fit the SRM), technology they use (TRM), data they use (DRM), what business they support (BRM), and where they are deployed. The domain also has certification and accreditation (C&A). Deployment Architecture Domain. The Deployment Architecture contains information on where things are. It shows a system’s physical location and where its processing happens (not necessarily the same place). It helps in making decisions on whether systems could be concentrated or moved. 4.1.2 DEAR Implementation / Concept of Operations The following diagram shows the DEAR hosting environment. DEAR is a centrally-hosted application that is accessed using a thin-client architecture. DOI Hosting Environment Bureau Hosting Environment Popkin LM Popkin SA 9.1 MS Office 2000 or XP Citrix Internet Explorer WAN Windows SQL Server 2000 Windows XP, 2000 Terminal Services Windows 2000 Windows 2000 Server LAN Server SQL Server Citrix Server Client Encyclopedias are Reports, macros, and data Bureau clients can print, stores as SQL extractions are stored on upload data, and tables the Citrix server download reports Figure 3: DEAR Hosting Environment Within DEAR, bureaus maintain integrity over their architecture artifacts/systems. Bureaus access a single encyclopedia for model artifacts and information on systems within their domain. DEAR provides a single 12
  13. 13. consolidated view of bureau enterprise systems tracked at the department level. DEAR is implemented using a standard base DOI metamodel5. Bureau model artifacts are subject to review before being included in the departmental encyclopedia for distribution and re-use. 4.2 Interior’s Modernization Blueprint Methodology Activities There are a number of major activities that must be performed during the development of Interior’s modernization blueprint. This section discusses these activities and identifies the resulting work products. While the methodology is discussed in its totality, the scope of the deliverable is limited to the output of the first activity – Analyze As-Is Environment for the aforementioned four lines of business. The major activities that comprise the Interior’s modernization blueprint and the purposes of those activities are listed below and pictured in Figure 4: • Analyze As-Is Environment – Provides an understanding of current issues and capabilities of Interior business operations and systems. • Develop To-Be Enterprise Architecture – Defines the future business operating environment and the supporting system and technological capabilities. • Develop Transition Plan – Provides a roadmap to transition from the As-Is state to the To-Be state. • Drive Transformation – Analyzes selected segments of the architecture and corresponding alternative solutions, and initiates or redirects programs to implement solutions that realize strategic objectives. • Drive Compliance – Manage the configuration of the baselined IEA while at the same time maintaining the integrity of its architectural products as the architecture adapts to the changing needs of business, technology, and technology standards. • Maintain Enterprise Architecture – Manages the evolution of the enterprise-level view in support of transformation and compliance activities, changing regulatory requirements, leading practices, and technological innovations. Figure 4: The Interior’s Modernization Blueprint Process 5 The term metamodel is more commonly known as a database schema. Bureaus may elect to extend the DEAR metamodel to support Bureau-specific modeling and reporting requirements. 13
  14. 14. Figure 5 shows the iterative nature of the Interior’s modernization blueprint process and the relationships among the activities. As shown in the diagram, the Interior’s modernization blueprint process draws from previous work such as the BLM’s TAA Methodology. Analyze “As Is” Environment – Current Issues – Material Weaknesses – Characteristics of Current Environment – Leading Practices – Changes to – Regulatory Requirements Develop “To Be” Enterprise Architecture … …Enterprise Level … …Views based on . … …Change Requests, Maintain Enterprise Architecture – Definition of “To Be” Enterprise Level Operational, ... System, and Technology State and Derived Requirements – Changing … …Regulatory … …Requirements, Develop Transition Plan … …Leading Practices – Changes to – A Roadmap for Transition from “As Is” to “To Be” …Transition Plan … – Segmented Architecture Drive Transformation – Segment Analysis Results( Process Model, Refined Data . . – System Assessment … …Models, Derived Requirements); Change Request Scope of Original – Program Architecture Reviews Target Application Architecture Drive Compliance Methodology – Change Requests based on Results of Compliance …. ….Review Figure 5: The Iterative Nature of the Interior’s Modernization Blueprint Process The following sections address the individual major activities depicted. A high-level process flow is provided for the activity with a description of the associated tasks. This document only fully addresses the analyses of the As-Is environment. Therefore, subtask details are only provided for this first step of the Interior’s modernization blueprint process. Overviews of each step help the reader understand the subtask details in the context of the entire modernization process. Analyze As-Is Environment The As-Is environment reflects current business operations within DOI. Analyzing the environment provides an understanding of the current issues and capabilities of DOI business operations. The information gathered serves as a reference point to move from, toward the To-Be environment. An understanding of the As-Is environment is essential for development of the To-Be architecture and the transition plan. In analyzing the As-Is environment, existing architecture artifacts are reviewed, placed into the context of the OMB’s FEA Reference Models, and imported into the DEAR modeling tool. Figure 6 provides the process flow for analysis of the As-Is environment. 14
  15. 15. Define Modernization Purpose Analyze “As Is” and Scope Environment Maintain Develop “To Be” Enterprise Enterprise Architecture Architecture Drive Develop the Analyze “As Is” Compliance Transition Plan Analyze “As Is” Business Operations Drive Transformation System Portfolio (BRM) Figure 6: Analyze As-Is Environment 4.2.1 Define Modernization Blueprint Purpose and Scope Architecture development begins with an understanding of the purpose and scope. The As-Is architecture and the driving needs of the organization help determine the nature of the To-Be architecture. In order to promote use of a common language, the architecture team defines terms at the beginning of To-Be architecture development and continues to define and capture terms throughout the process. This activity also involves the determination of functional and informational lines of responsibility that serve to facilitate future integration efforts. This activity begins during analysis of the As-Is environment in order to provide a scope for analysis activities. This activity is completed as part of To-Be architecture development. 4.2.2 Analyze As-Is Business Operations The focus of this activity is to understand the current issues, material weaknesses, and capabilities. The process flow for this activity is shown in Figure 7. Inventory Critical Collect Current Document Existing Issues Gaps Processes Existing model artifacts, Process Inventory, documentation, and Issues, and Gaps information Figure 7: Analyze As-Is Business Operations The table below reflects the definitions, inputs, and outputs associated with the Analyze As-Is Business Operations subtasks. 15
  16. 16. Table 1: Analyze As-Is Business Operations Subtasks Task: Collect Current Issues Definition: Document any known issues that must be addressed by the To-Be architecture. Input: Existing business and technical documentation Output: Current issues Task: Inventory Existing Critical Processes Definition: Understand and capture an inventory of processes to the appropriate level of depth where needed as input to business process transformation activities. Input: Current process descriptions (DOI ABC Work Activities, IDEF0 Function/Activity models, FEA BRM) Output: Extended (five-levels) DOI BRM and associated IDEF0 Function/Activity models for lines of business where appropriate Task: Document Process Weaknesses / Gaps Definition: For each functional area, catalog the weaknesses associated with current business operations. Input: Existing business and technical documentation Known weaknesses/gaps Output: Catalog of weakness/gaps 4.2.3 Analyze As-Is System Portfolio The focus of this activity is to understand the current system portfolio that supports business operations. This inventory should be limited to systems that are critical to the business to avoid undue expense in gathering information that will not be useful in development of the To-Be architecture and the transition plan. For the DOI, scope has been initially limited to mission-critical systems and those systems support the four cross- cutting lines of business and mission below: • Fire Management • Law Enforcement • Financial Management • Recreation. The process flow for this activity is shown in Figure 8. Inventory Map Systems to Assess Existing FEA Reference Alignment Systems Models Existing System System Inventory Information Figure 8 Analyze As-Is System Portfolio Using uniform data collection templates, existing systems will be inventoried for each LOB. Each system will be mapped to capabilities (SRM), functionality (BRM), and purpose (PRM). Systems will also be described in terms of their technical composition (TRM) and informational requirements (DRM). Systems will be scored based upon pre-established measurement criteria to generate an architecture maturity score. This criteria is based upon the IEA Conceptual Architecture Principles (CAP), January 2002 document. The criteria are associated with the OMB Federal Enterprise Architecture (FEA) layers as defined below. PRM (Performance Reference Model) • (P1) System’s capability for supporting associated Strategic goals and objectives as defined in DOI Strategic Plan. 16
  17. 17. • (P2) Extent of stakeholder’s feedback for accomplishing performance measures associated with strategic goals, objectives and performance measures. BRM (Business Reference Model) • (B1) Lack of functional overlap with other systems as defined by DOI BRM. • (B2) System incorporates re-engineered/streamlined business processes (workflow) in an automated fashion that supporting DOI Strategic goals and objectives. DRM (Data Resource Management) • (D1) Existence and documentation of data standards and protocols compliant with DOI and Federal data standards (as applicable). • (D2) Relative maturity and accessibility of system's data and access methods. • (D3) Relative overlap with data stored in other Interior systems. Application (Service Reference Model and Interior’s Conceptual Target Applications Architecture (TAA)) • (A1) Degree of architectural compliance with the conceptual Target Applications Architecture (TAA)6. • (A2) Extent to which system design requirements are defined and documented. • (A3) Extent to which system interfaces are defined and documented. • (A4) Extent to which high level design or operational concepts are documented. Technology Reference Model (TRM) • (T1) Extent of compliance with Technology Reference Model standards, protocols and best practices. • (T2) Extent of maximum use of shared, existing infrastructure components and service. Security Architecture • (S1) Extent to which the system complies with current security requirements and extent of progress through the C&A process Based on their alignment to the FEA references and architecture maturity score, systems will be classified into one of four groups: Legacy, Migration (Consolidate/Retire), Migration (Integrate), or Target. • Legacy systems are those systems still required by DOI that should be considered for integration with other systems or consolidation with target systems. The systems being consolidated will essentially be retired. These systems have relatively low business fit (alignment with DOI Strategic Plan, CRV, CAP, process and data maturity) and/or low technology fit (alignment with TRM, Conceptual TAA, etc.). • Migration (Integrate) systems are those systems with relatively high business fit and relatively low technology fit. In these systems it is cost-effective to upgrade the technology architecture/infrastructure to adhere to the TRM and conceptual TAA. • Migration (Consolidate/Retire) systems are those systems with relatively high technology fit but low business fit. These systems should be examined for possible retirement and/or consolidation of required functionality and data into target systems. 6 Note: Interior’s conceptual TAA is in progress. It will identify best practices for application development (e.g., multi-tier systems that foster ease in system integration and adherence to the products defined in the DOI TRM.). 17
  18. 18. • Target systems are those systems (or system components) with relatively high business and technology fit. Figure 9 System Grouping Analysis Template – Assessment Quadrants The table below reflects the definitions, inputs, and outputs associated with the Analyze As-Is System Portfolio analyses subtasks. Table 2: Analyze As-Is System Portfolio Subtasks Task: Inventory Existing Critical Systems Definition: Document current inventory of systems Input: System descriptions Output: Systems Inventory (DEAR Repository) Task: Map Existing Systems to FEA Reference Models Definition: Establish a mapping between the current systems and functions to FEA reference models Input: Systems inventory, FEA reference models, system owner interviews Output: System to FEA model mappings (DEAR) Task: Assess Alignment Definition: Systems are assessed against established criteria and are then classified Input: Completed system data collection templates, evaluation criteria Output: Business processes supported by the system, strategies, goals, and objectives supported by the system, functional (BRM) overlap with other systems, TRM architecture compliance, SRM service component overlap, and system classification as Legacy, Migration (Consolidate/Retire), Migration (Integrate), or Target Develop To-Be Enterprise Architecture The To-Be architecture defines and depicts the desired future business environment. The architecture development effort uses the knowledge of the As-Is environment to address compliance requirements and material weaknesses as well as identify applicable best practices. This knowledge is used to guide the definition of the future business operations, the roles that perform the operations, and the system capabilities 18
  19. 19. that support those roles for each LOB. The tasks involved with developing the To-Be architecture are iterative in nature--completing an architecture product may require adjusting the preceding products. Figure 10 below provides the overall process flow for this major activity. Define Modernization Purpose and Scope Change Management Communications Analyze “As Is” Environment Maintain Develop “To Be” Enterprise Enterprise Identify Enterprise Architecture Architecture Outline Business Outline System Services, Operations Interactions Technology Standards, Profiles Drive Develop the Compliance Transition Plan Drive Transformation Summarize and Revize Purpose and Scope Figure 10: Develop To-Be Enterprise Architecture After describing an overall view of the enterprise from the executive level, work begins on the description of the future business operations. Analyzing the compliance requirements and material weaknesses frames the development effort. The overall view of the enterprise starts with describing the concept of operations, both functional and informational (i.e. the future data environment), and continues through to the behavioral aspects of business operations in common scenarios, including the descriptions of roles performing specific tasks. Once the operational environment has been described, architecture development focuses on how to use automated systems. Operational tasks that can be partially or fully automated are identified early; in some instances a current system may provide sufficient capability after only minor modification. With a focus on the interchange of data, systems are described in terms of the future environment in which they will operate. Basic descriptions of the expected behavior of systems help to identify the general features desired, an identification that is used to develop requirements for either production or acquisition. The technological development aspects of the architecture look primarily at the services systems can provide. If a service environment already exists, the applicable services are selected. The purpose of this activity is to identify services, standards and profiles that guide and constrain the eventual design/modification, implementation, deployment, and maintenance of solutions that support operational activities in order to facilitate interoperability and standardization. The overall view (i.e., vision, objectives, scope and terms) is revisited upon completion of the description of the operational environment, the supporting systems, and the technical standards required to realize the operational environment. The full attributes of all architecture artifacts are stored in DEAR to assist in extension/implementation of the architecture. Findings and recommendations are also recorded. The communication of the future business environment is an ongoing task of the architecture development effort. It begins with engaging business process owners, called stakeholders, early in development in order to 19
  20. 20. gather their input. Stakeholders assist in the production of the architecture during development. Completed areas of the architecture include a strategy for implementing the changes needed and a process that ensures a collaborative change environment. Develop the Transition Plan The purpose of the transition plan is to provide DOI with an overview of the key elements necessary to successfully transition from the As-Is environment to the To-Be state in a cost-effective, efficient, and timely manner, while minimizing the impact of the transition on current operations, organizations and personnel. It provides the framework, structure, and initial planning needed to develop detailed transition plans for a given line of business or domain. Tactical and strategic transition plans will be developed based on the system classification to migrate towards Interior’s Target Applications Architecture (TAA). The tactical transition plan will include short-term improvements in alignment with strategic architecture goals. Improvements will be prioritized to yield maximum benefits across a LOB or system grouping within budget constraints. The strategic transition plan will provide a conceptual roadmap to target architecture; identify systems to be retired, consolidated, and re- engineered; and identify the investment proposals / projects to enable the realization of the future state. Figure 11 below provides an overview of this activity. Provide Packaged and Segmented Requirements and Analyze “As Is” Environment Capabilities Maintain Develop “To Be” Enterprise Enterprise Architecture Architecture Drive Develop the Compliance Transition Develop Plan Define Schedule Capability Develop Resource Drive and Milestone Transformation Maturity Plan Plan Profile Figure 11: Develop the Transition Plan The purpose of the Packaged and Segmented Requirements and Capabilities activity is to provide a structure for organizing the transition to the To-Be architecture into components that can be implemented. The transition plan describes how the pieces of the architecture have been categorized and how the derived requirements have been assembled into logical groupings that describe the transition packages and segments. The Schedule and Milestone Plan establishes an initial planning baseline for managing the IEA modernization transition. It provides a basis for decision-making and evaluation of alternatives, and provides the framework for the department to plan, communicate, and monitor the IEA modernization transition at the enterprise level. 20
  21. 21. The Capability Maturity Profile is organized to support the business focus of DOI within the IEA modernization effort. It describes the maturation of the Interior business processes, systems, and management support functions and provides a framework within which the DOI can set a target, measure current and proposed solutions, and align associated plans, training materials, and appraisal materials. Besides providing an initial To-Be target profile, the Capability Maturity Profile delineates characteristics of a mature, capable Interior process, function, or system, which in turn can describe and illustrate the progress of the Interior modernization effort. The purpose of the Resource Plan is to provide a framework and methodology with a supporting cost element structure and a time-phased cost estimate of the potential resource requirements associated with the implementation of the IEA modernization effort. Drive Transformation The purpose of this major activity is to analyze selected segments of the architecture and corresponding alternative solutions, and to then initiate or redirect programs to implement solutions that realize segment- specific and DOI strategic objectives. This process enables the evolution of the IEA by providing selection, approval and analysis for selected high-impact segments. Two segment-level analysis approaches are prescribed: Process Transformation (for transactional/operational systems), and Information Aggregation (for data warehouse/business intelligence applications). The focus of Process Transformation is on business process reengineering, while the focus of Information Aggregation is the ability to provide visibility of information. Both approaches drive a segment through segment-level modeling, sharing common activities for Architecture Review Board (ARB) Preparation, Analysis of Alternatives (AoA), and Business Case Identification, and conclude with the Initiation and/or Redirection of Programs as depicted in Figure 12. Select Positive Concept Select High-Impact Segments Decision Analyze “As Is” Segment Analysis Environment Maintain Develop “To Be” Information / Data Enterprise Enterprise Process Transformation / BPR Architecture Architecture Aggregation Drive Develop the Compliance Transition Plan Analysis of Alternatives Drive Transformation Business Case Initiate or Redirect Programs Figure 12: Drive Transformation 21
  22. 22. Segment Analysis is divided into two forms of transformation. Process Transformation provides an approach for the DOI to manage the progress of a segment through initiation, business process reengineering (BPR), and segment-level modeling. Initiation qualifies a segment and validates existing IEA artifacts for further analysis. BPR entails the redesign of business processes, along with the associated systems and organizational elements, to achieve a dramatic improvement in business performance. The process models, data models, system view diagrams, relevant Technology Architecture Profiles, and mapping of existing systems to reengineered processes are necessary inputs for Analysis of Alternatives. The form of transformation is related to Information and Data Aggregation. Information Aggregation can use existing legacy data assets as well as solutions that will be eventually deployed as a result of business process re-engineering. Therefore, Information Aggregation can continually deliver short- and long-term benefits by providing enterprise-level visibility to highly distributed data assets across DOI. Information Aggregation helps the government use its own data. It provides for the framework for developing and effectively supporting information applications such as Decision Support Systems (DSS), Executive Information Systems (EIS), and data mining systems to harvest and deliver business intelligence. It consists of the following components: • Acquisition of internal and external data (Information Data Stores) • Transformation and cleansing of the data (Data Quality). • Facilities to find and understand relevant information that describes the contents and characteristics of the information (Metadata) • Automation and management of data flows and processing tasks needed to maintain reliability, availability, and serviceability of data (Data Acquisition) • Distribution, staging, propagation, and packaging of data so that it can be properly stored (Data Propagation) • Facilities to access, analyze, and discover kernels of information that form business intelligence (Data Access and Security) Drive Compliance Drive Compliance facilitates and promotes the convergence of IT programs initiated by DOI and its bureaus towards IEA objectives and aligns the IEA with FEA and interdepartmental EA objectives. This is achieved through a variety of mechanisms, such as: • Promote awareness • Enforce alignment • Resolve compliance issues • Institute procedures that cause compliance-related activities to occur The high-level activities are shown in Figure 13. 22
  23. 23. Evaluate Alignment Operations and Maintenance of Drive Compliance Awareness Analyze “As Is” Compliance Process Environment Maintain Develop “To Be” Enterprise Enterprise Architecture Architecture Remediate Compliance Issues Drive Develop the Compliance Transition Plan Drive Transformation Validate Remediation Figure 13: Drive Compliance The primary purpose of the Drive Compliance Awareness activity is to promote acknowledgement of, and participation in, the IEA Compliance process across DOI. This activity also communicates the required scheduling intervals for compliance activities and communicates the results of those assessments and evaluations. The Evaluate Alignment activity provides an approach for programs initiated by DOI and its bureaus to comply with the IEA. It also enables existing systems to be assessed for their compliance with the IEA. Through this process of evaluating alignment, the DOI can determine its effectiveness in meeting its stated objectives and in supporting the strategic objectives of the department, as well as complying with the requirements of the Clinger-Cohen Act and OMB Circular A-130, Management of Federal Information Resources. Maintain the Enterprise Architecture The method developed to support the Interior’s Enterprise Architecture maintenance and evolution is designed to manage the configuration of the baselined IEA while at the same time maintaining the integrity of its architectural products as the architecture adapts to the changing needs of business, technologies, and technology standards. Where applicable, the maintenance activities will employs event-driven and process- driven activities to support the following program goals: • Communicating IEA merits • Validating IEA integrity • Enabling IEA segment (LOB) implementation • Facilitating IEA compliance certification Figure 14 below provides an overview of this major activity. 23
  24. 24. Review Change Proposals Update & Publish IEA and DEAR Analyze “As Is” Environment Maintain Develop “To Be” Enterprise Enterprise Architecture Architecture Schedule Changes for Inclusion in IEA / DEAR Drive Develop the Compliance Transition Plan Drive Transformation Update & Validate IEA / DEAR Artifacts Figure 14: Maintain Enterprise Architecture 24
  25. 25. 5. Appendix A - LOB As-Is Architecture for Law Enforcement 5.1 Introduction The following takes the Law Enforcement Line-of-Business (LOB) As-Is architecture and shows its association to DOI Investment-Projects, Systems, and the OMB FEA Reference Models (PRM, BRM, SRM, and TRM). The information, diagrams, and tables were derived from the DOI Enterprise Architecture Repository (DEAR). Concurrence on the As-Is architecture is a critical first step in developing the To-Be, or target architecture. 5.2 Line of Business (LOB) Associations LOB associations show the As-Is relationships between the Law Enforcement LOB and modeled architecture domains: DOI Investment-Projects, Systems, and the OMB FEA Reference Models (PRM, BRM, SRM, and TRM). These relationships (or mappings) allow the DOI to view the LOB within a uniform frame of reference as a precursor to future system classification and re-engineering. 5.2.1 Line of Business to PRM The Department of the Interior’s (DOI) Integrated Performance Reference Model (PRM) is an extension of the OMB’s FEAPMO PRM. The PRM is a standardized measurement framework to characterize performance in a common manner. The DOI Integrated PRM contains elements of the DOI’s Strategic Plan and DOI ABC Work Activities. The DOI Integrated PRM links DOI ABC Work Activities to the DOI Strategic Plan goals and objectives a given work activity supports. The Performance Reference Model diagram (below) graphically shows the End-Outcome and Intermediate-Outcome goals associated with the Law Enforcement LOB. The planned Law Enforcement IT investments and existing operational systems will be evaluated through an interview process and other analytical means to determine the capabilities of such systems to effectively support the End-Outcome and Intermediate-Outcome goals in the DOI PRM. The results of this evaluation will be contributing factors in the development of the modernization blueprint for the Law Enforcement LOB. Figure 5-1 Law Enforcement Line-of-Business PRM Diagram 5.2.2 Line of Business to Outcomes End Outcomes (EO) are long term performance goals which describe and support the DOI’s strategic goals. End Outcomes express a desired result and are measured by one or more performance measures / indicators. Performance measures indicate the success in achieving the long-term goal. Intermediate Outcomes describe and support major milestones of an annual End Outcome goal. There are two or more Intermediate Outcome Goals to every End Outcome Goal. The actual results, effects, or impacts of a business initiative, program, or support function. Actual outcomes typically are compared to expected outcomes. End-Outcome and Intermediate-Outcome goals associated with the Law Enforcement LOB are shaded in the tables below. Table 5-2 PRM Goals associated with the Law Enforcement LOB 5.2.3 Line of Business to ABC Work Activities Activity Based Costing (ABC)7 is a management process that examines how program activities consume resources and produce outputs. In ABC, work processes are broken down into activities so that the cost and performance effectiveness of the activities and processes can be measured. There are approximately 326 DOI (Department/bureau) crosscutting work activities that the bureaus and departmental offices will either 7 See http://www.doiu.nbc.gov/abc/ for more information on the DOI’s approach to ABC 25
  26. 26. use directly, or have the costs associated with bureau/ departmental office work activities captured under them. For the DOI, ABC cost information is directly traced from the activity to the transaction generating the cost. Within DEAR, ABC Work activities are modeled and associated to both the PRM (End Outcome) and the BRM (function/activities). Those ABC Work Activities support the Law Enforcement LOB are shown shaded in the table below. The mapping of ABC Work Activities to a LOB allows the DOI to derive cost associated with a given LOB. Modeling ABC Work Activity to PRM associations enable the DOI to estimate costs associated with the fulfillment of a given PRM goal. Table 5-3 ABC Work Activities associated with the Law Enforcement LOB 5.2.4 Line of Business to BRM The Department of the Interior’s (DOI) Integrated Business Reference Model (BRM) is an extension of the OMB’s FEAPMO Business Reference model. The BRM provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology. The DOI will use the BRM for identifying potentially redundant IT investments in its business lines, which will ultimately result in significant cost savings. These savings will be made available to move into other, citizen-centered investments to further improve DOI performance and service to citizens. The DOI has extended its BRM beyond the Business Areas, Lines of Business, and Sub Functions defined by the FEA BRM Version 2.0 to the level of DOI function / activities which extend two to three levels beneath the FEA BRM. This extension allows the DOI to map systems at a lower level of granularity providing meaningful information in the development of the Law Enforcement LOB modernization blueprint. Existing Law Enforcement systems supporting the same BRM function / activity will be examined for possible consolidation or redundancies. Systems from other LOBs mapped to the same function / activity will be examined for reusable system components which could be potentially leveraged by the Law Enforcement LOB. Table 5-4 BRM Function Activities associated with the Law Enforcement LOB 5.2.5 Line of Business to Process Models Business process modeling is used to lead process change and improvement. The results of the business process modeling are process models. The DOI is currently using IDEF0 and IDEF3 process modeling to describe, measure and optimize its lines of business to improve customer satisfaction, cut costs and streamline operations in support of its modernization efforts. Business process models define enterprise value chains as sets of activities supporting a LOB that can be analyzed and improved. The DOI will use business modeling to understand, analyze and design business process flows and to document business requirements in the development of LOB modernization blueprints. Business process modeling using the DEAR modeling tool provide business value in a number of ways: • Establishes direct linkages between DOI objectives & process improvement • Validates DOI business process change prior to expensive IT deployment • Accurately describes DOI business requirements to streamline IT implementations • Captures, evaluates and selects best practices for enterprise deployment • Ensures achievement of DOI Investment-Project objectives through cost & resource analysis At the time of this report, the information Law Enforcement Processes had not been documented and therefore could not be imported and associated within the DEAR. Figure 5-5 Law Enforcement LOB Process Models 26
  27. 27. 5.2.6 Line of Business to SRM The SRM provides a common technology neutral framework and vocabulary to characterize the IT and business components that collectively comprise an IT investment. The SRM will help the DOI with the development of modernization blueprints through the sharing and re-use of business and IT components. Investment-Projects can be directly associated with SRM Service Components, or the SRM Service Components may be derived from System associations. Currently work is progressing on the mapping of SRM Service Components to their corresponding enabling technology standards in the TRM. SRM Service Components mapped to TRM Technology Standards will provide the foundation for the “To-Be” technology architecture in support of the services required to support a given LOB. The following table collectively shows the SRM Services supporting the Law Enforcement LOB. Table 5-6 SRM Services associated with the Law Enforcement LOB 5.2.7 Line of Business to TRM The TRM contains the Interior’s technology standards arranged in the context of the FEA TRM. The TRM is a technology classification taxonomy. It contains products, specifications, standards, and technologies associated with key Interior systems and their classification. The following table uses the TRM Technology Standard to Investment-Project relationship to derive the TRM Technology Standards supporting the Law Enforcement Line-of-Business. This section provides a TRM view across all systems within the Law Enforcement LOB. The business value of this information is to provide high-level direction for the establishment of standards across a LOB. The LOB TRM view quickly shows the extent of compliance of the Law Enforcement LOB to TRM standards across all systems. For individual Law Enforcement LOB systems mapped to TRM Technology Standards, the reader is directed to the section on System Portfolio Associations. Table 5-7 TRM Standards associated with the Law Enforcement LOB 5.2.8 Line of Business to DRM The DRM to LOB mapping describes, at an aggregate level, the data and information that supports LOB. The LOB to DRM mapping will aid in describing the types of interaction and exchanges that occur between within and between LOBs. The DRM to LOB model will aid the identification of candidates for data consolidation and/or standardization. The information in this section represents the logical data entities, their meta-data and relationships for the Law Enforcement LOB. The information is currently being associated to the BRM and System objects which shall create additional analytic opportunities. For complete viewing, the model should be reviewed within the DEAR modeling tool Table 5-8 DRM entities associated with the Law Enforcement LOB 5.3 Investment Associations The investment architecture domain contains both information technology-related investment and project information. An IT Investment represents a special type of capital project (or investment). An Investment for an IT project has a corresponding Exhibit 300 and is represented by a summary line on an Exhibit 53. For FY2004, all funding requests to OMB require alignment to four OMB Reference models (PRM, BRM, SRM, and TRM)8. Within DEAR, the INVESTMENT-PROJECT model object is related to the PRM End 8 OMB Circular A-11 Part 1, June 2003 27
  28. 28. Outcome it supports, the BRM function/activities it supports, the SRM service components its related to, and its associated TRM standards. DEAR allows the DOI to perform quick checks of investment compliance to OMB mandates. Queries against the investment architecture in the DEAR modeling tool allow investments and systems to be compared as to where they are in the investment cycle and how investments are funded. Investment associations show the As-Is relationships between the Law Enforcement LOB and system, PRM, BRM, SRM, and TRM domains. Investment associations are key to developing strategic modernization blueprints by identifying investment proposals to enable the future architecture state. Given limited resources, investment association analyses will identify those Law Enforcement investments that achieve the greatest progress towards the To-Be state. 5.3.1 Investment List showing CPIC Status and Investment Attributes The following table shows a list of investments supporting the Law Enforcement LOB. Select attributes of these investments are provided including CPIC status, investment description, and other investment attributes. Table 5-9 Law Enforcement LOB Investment List 5.3.2 Investment to System Investment projects may fund systems. The following table shows the list of investments supporting the Law Enforcement LOB and the systems associated with those investments. Table 5-10 Law Enforcement LOB Investment to Systems List 5.3.3 Investment to PRM OMB guidance specifically requires investments be linked to performance metrics (End and Intermediate Outcome Goals) for development, modernization, and enhancement of IT investments. The following table shows the list of investments supporting the Law Enforcement LOB and their associated PRM measures. Table 5-11 Law Enforcement LOB Investment to PRM Measures 5.3.4 Investment to Primary BRM OMB guidance specifically requires investments be linked to a primary BRM subfunction. The primary BRM association identifies the primary alignment for major IT initiatives to be used in the development of a Unique Project ID. The following table shows a list of investments supporting the Law Enforcement LOB and their associated primary BRM subfunction. Table 5-12 Law Enforcement LOB Investment to Primary BRM 5.3.5 Investment to Associated BRM OMB guidance allows for additional BRM associations to a given investment. The DOI has elected to further extend the BRM so that investments may be mapped at a greater level of detail thus providing more meaningful information on the business functions actually supported by a given investment. The following table shows a list of investments supporting the Law Enforcement LOB and their associated BRM function activities. 28
  29. 29. Table 5-13 Law Enforcement LOB Investment to Associated BRM Function Activities 5.3.6 Investment to SRM OMB guidance requires that investments be discussed with respect to their relationship to the Service Component Reference Model (SRM). The appearance of the same SRM service component across multiple investments shows a likely candidate for a horizontal service. The following table shows a list of investments supporting the Law Enforcement LOB and their associated SRM service components. Table 5-14 Law Enforcement LOB Investment to Associated SRM Service Components 5.3.7 Investment to TRM (Standard) OMB guidance requires that investment be discussed with respect to their relationship to the Technical Reference Model. The following table shows a list of investments supporting the Law Enforcement LOB and their associated TRM standards. Table 5-15 Law Enforcement LOB Investment to Associated TRM Standards 5.4 System Portfolio Associations Within DEAR, IT systems are a combination of hardware, software and documentation that implement and describe a solution. A system is funded by a Project-Investment; it supports at least one (BRM) function/activity; and it supports the fulfillment of at least one (PRM) End-Outcome. A system is described in terms of the System, Subsystem, System Component Instance, and System Components. A great deal of detail is available within DEAR on a single system (100’s of attributes detailing system architecture, CPIC status, security, deployment, ownership, BRM function supported, SRM service components utilized, DRM data subject areas accesses, project-investment information, owning organization, etc.). The system portfolio associations provide various views of systems supporting the Law Enforcement LOB 5.4.1 System Diagram Often it is advantageous to view systems within a LOB and their relationships with other systems. For select LOBs, system to system interface diagrams were created showing data exchanges between system components. The following figure shows the systems that comprise the Law Enforcement LOB and associated data exchanges between those systems. Figure 5-16 Law Enforcement LOB System Diagram 5.4.2 System to C&A Status The Government Information Security Reform Act (GISRA) requires that the DOI track major systems by their Certification and Accreditation (C&A) status. C&A status can be used to track DOI progress to certify and accredit all existing and emerging systems within their inventory. The following table shows the systems that comprise the Law Enforcement LOB and their C&A status. Table 5-17 Law Enforcement LOB Systems and C&A Status 29
  30. 30. 5.4.3 System to Privacy The DOI tracks systems based on whether or not they contain privacy-related information. The following table shows the systems that comprise the Law Enforcement LOB and their privacy status. Table 5-18 Law Enforcement LOB Systems and Privacy Status 5.4.4 System to FEA Models (BRM, SRM, TRM) Within the DEAR modeling tool, systems are mapped to the various FEA reference models. The following table provides a list of the systems supporting the Law Enforcement LOB and their associated BRM (function activities), SRM (service components) , and TRM (standards). Table 5-19 Law Enforcement LOB Systems to BRM, SRM, and TRM 5.4.5 System to TRM Technical Specifications Within the DEAR modeling tool, there is an extensive amount of information on the technical service specifications (products) that make up a given system and that products classification. The following table lists the systems supporting the Law Enforcement LOB and their associated technical service specifications and classification. Table 5-20 Law Enforcement LOB Systems to BRM, SRM, and TRM 5.5 Conclusion / Recommendations 30
  31. 31. 6. Appendix B - LOB As-Is Architecture for Fire Management 6.1 Introduction The following takes the Fire Management Line-of-Business (LOB) As-Is architecture and shows its association to DOI Investment-Projects, Systems, and the OMB FEA Reference Models (PRM, BRM, SRM, and TRM). The information, diagrams, and tables were derived from the DOI Enterprise Architecture Repository (DEAR). Concurrence on the As-Is architecture is a critical first step in developing the To-Be, or target architecture. 6.2 Line of Business (LOB) Associations LOB associations show the As-Is relationships between the Fire Management LOB and modeled architecture domains: DOI Investment-Projects, Systems, and the OMB FEA Reference Models (PRM, BRM, SRM, and TRM). These relationships (or mappings) allow the DOI to view the LOB within a uniform frame of reference as a precursor to future system classification and re-engineering. 6.2.1 Line of Business to PRM The Department of the Interior’s (DOI) Integrated Performance Reference Model (PRM) is an extension of the OMB’s FEAPMO PRM. The PRM is a standardized measurement framework to characterize performance in a common manner. The DOI Integrated PRM contains elements of the DOI’s Strategic Plan and DOI ABC Work Activities. The DOI Integrated PRM links DOI ABC Work Activities to the DOI Strategic Plan goals and objectives a given work activity supports. The Performance Reference Model diagram (below) graphically shows the End-Outcome and Intermediate-Outcome goals associated with the Fire Management LOB. The planned Fire Management IT investments and existing operational systems will be evaluated through an interview process and other analytical means to determine the capabilities of such systems to effectively support the End-Outcome and Intermediate-Outcome goals in the DOI PRM. The results of this evaluation will be contributing factors in the development of the modernization blueprint for the Fire Management LOB. Figure 5-21 Fire Management Line-of-Business PRM Diagram 6.2.2 Line of Business to Outcomes End Outcomes (EO) are long term performance goals which describe and support the DOI’s strategic goals. End Outcomes express a desired result and are measured by one or more performance measures / indicators. Performance measures indicate the success in achieving the long-term goal. Intermediate Outcomes describe and support major milestones of an annual End Outcome goal. There are two or more Intermediate Outcome Goals to every End Outcome Goal. The actual results, effects, or impacts of a business initiative, program, or support function. Actual outcomes typically are compared to expected outcomes. End-Outcome and Intermediate-Outcome goals associated with the Fire Management LOB are shaded in the tables below. Table 5-22 PRM Goals associated with the Fire Management LOB 6.2.3 Line of Business to ABC Work Activities Activity Based Costing (ABC)9 is a management process that examines how program activities consume resources and produce outputs. In ABC, work processes are broken down into activities so that the cost and performance effectiveness of the activities and processes can be measured. There are approximately 326 DOI (Department/bureau) crosscutting work activities that the bureaus and departmental offices will either 9 See http://www.doiu.nbc.gov/abc/ for more information on the DOI’s approach to ABC 31
  32. 32. use directly, or have the costs associated with bureau/ departmental office work activities captured under them. For the DOI, ABC cost information is directly traced from the activity to the transaction generating the cost. Within DEAR, ABC Work activities are modeled and associated to both the PRM (End Outcome) and the BRM (function/activities). Those ABC Work Activities support the Fire Management LOB are shown shaded in the table below. The mapping of ABC Work Activities to a LOB allows the DOI to derive cost associated with a given LOB. Modeling ABC Work Activity to PRM associations enable the DOI to estimate costs associated with the fulfillment of a given PRM goal. Table 5-23 ABC Work Activities associated with the Fire Management LOB 6.2.4 Line of Business to BRM The Department of the Interior’s (DOI) Integrated Business Reference Model (BRM) is an extension of the OMB’s FEAPMO Business Reference model. The BRM provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology. The DOI will use the BRM for identifying potentially redundant IT investments in its business lines, which will ultimately result in significant cost savings. These savings will be made available to move into other, citizen-centered investments to further improve DOI performance and service to citizens. The DOI has extended its BRM beyond the Business Areas, Lines of Business, and Sub Functions defined by the FEA BRM Version 2.0 to the level of DOI function / activities which extend two to three levels beneath the FEA BRM. This extension allows the DOI to map systems at a lower level of granularity providing meaningful information in the development of the Fire Management LOB modernization blueprint. Existing Fire Management systems supporting the same BRM function / activity will be examined for possible consolidation or redundancies. Systems from other LOBs mapped to the same function / activity will be examined for reusable system components which could be potentially leveraged by the Fire Management LOB. Table 5-24 BRM Function Activities associated with the Fire Management LOB 6.2.5 Line of Business to Process Models Business process modeling is used to lead process change and improvement. The results of the business process modeling are process models. The DOI is currently using IDEF0 and IDEF3 process modeling to describe, measure and optimize its lines of business to improve customer satisfaction, cut costs and streamline operations in support of its modernization efforts. Business process models define enterprise value chains as sets of activities supporting a LOB that can be analyzed and improved. The DOI will use business modeling to understand, analyze and design business process flows and to document business requirements in the development of LOB modernization blueprints. Business process modeling using the DEAR modeling tool provide business value in a number of ways: • Establishes direct linkages between DOI objectives & process improvement • Validates DOI business process change prior to expensive IT deployment • Accurately describes DOI business requirements to streamline IT implementations • Captures, evaluates and selects best practices for enterprise deployment • Ensures achievement of DOI Investment-Project objectives through cost & resource analysis At the time of this report, the information Fire Management Processes had not been documented and therefore could not be imported and associated within the DEAR. Figure 5-25 Fire Management LOB Process Models 32

×