**Department of Interior Enterprise Architecture (IEA)**

![](media/image1.png){width="2.910416666666667in"
height="2.7354166666666666in"}

**Modernization Blueprint Methodology and Activities**

## 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 1:

-   **Analyze As-Is Environment** -- Provides an understanding of
    current issues and capabilities of Interior business operations and
    systems.

```{=html}
<!-- -->
```
-   **Develop To-Be Enterprise Architecture** -- Defines the future
    business operating environment and the supporting system and
    technological capabilities.

```{=html}
<!-- -->
```
-   **Develop Transition Plan** -- Provides a roadmap to transition from
    the As-Is state to the To-Be state.

```{=html}
<!-- -->
```
-   **Drive Transformation** -- Analyzes selected segments of the
    architecture and corresponding alternative solutions, and initiates
    or redirects programs to implement solutions that realize strategic
    objectives.

```{=html}
<!-- -->
```
-   **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.

```{=html}
<!-- -->
```
-   **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.

![](media/image2.png){width="2.7625in" height="2.7625in"}

**Figure 1: The Interior's Modernization Blueprint Process**

Figure 2 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.

![](media/image3.wmf){width="5.95625in" height="3.283333333333333in"}

**Figure 2: 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 {#analyze-as-is-environment .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 3 provides the process flow
for analysis of the As-Is environment.

![](media/image4.wmf){width="5.9847222222222225in"
height="3.4055555555555554in"}

**Figure 3: Analyze As-Is Environment**

### 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.

## Modernization Blueprint Assessment Criteria

In partnership with Interior's business and IT community (i.e., Line of
Business (LOB) managers, Interior Business Architecture Team IBAT,
Interior Architecture Working Group IAWG, Architecture Review Board ARB,
etc.), the IEA will analyze major applications in the respective
business portfolio based on pre-established measurement criteria. This
criteria is based upon the IEA Conceptual Architecture Prinicples (CAP),
January 2002 document. The criteria are predominately associated with
the OMB Federal Enterprise Architecture (FEA) layers as defined below.

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.

### Business Architecture (Performance Reference Model and Business Reference Model)

-   (P1) System's capability for supporting associated Strategic goals
    and objectives as defined in DOI Strategic Plan.

-   (P2) Extent of stakeholder's feedback for accomplishing performance
    measures associated with strategic goals, objectives and performance
    measures.

-   (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.

### Data Architecture (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 Architecture (Service Reference Model and Interior's Conceptual Target Applications Architecture (TAA))

-   (A1) Degree of architectural compliance with the conceptual Target
    Applications Architecture (TAA)\*.

-   (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 Architecture (Technical Reference Model)

-   (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

> \* 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.).

## Business Domain Evaluation Criteria

Using the information gathered on the system during the interview
process, the system will be scored within the business domain based on
the following three criteria:

  ------------------------------------------------------------------------------------------------
  **Criteria**   **Description**             **Low (1)**     **Medium (3)**     **High (5)**
  -------------- --------------------------- --------------- ------------------ ------------------
  P1             ***System's capability for  No linkages     Some linkages      There is a direct
                 supporting associated       between system  between system     link between
                 Strategic goals and         functionality   functionality and  linkage system
                 objectives as defined in    and DOI         DOI strategies and functionality and
                 DOI Strategic Plan***       strategies and  goals objectives   DOI strategies and
                                             goals                              goals objectives
                                             objectives                         

  P2             ***Extent of***             No stakeholder  Some stakeholder   Extensive
                 ***stakeholders feedback    feedback for    feedback for       stakeholder
                 for accomplishing           accomplishing   accomplishing      feedback for
                 performance measures        performance     performance        accomplishing
                 associated with strategic   measures        measures           performance
                 goals, objectives and       associated with associated with    measures
                 performance measures***     strategies      strategies goals   associated with
                                             goals           objectives and     strategies goals
                                             objectives and  performance        objectives and
                                             performance     measures           performance
                                             measures                           measures

  B1             ***Lack of functional       Significant     Some overlap       The functionality
                 overlap with other systems  overlap between between system     provided by the
                 as defined by DOI BRM***    system          functionality and  system does not
                                             functionality   COTS, GOTS         significantly
                                             and available   products, and      overlap with other
                                             COTS, GOTS      other systems      systems
                                             products, and                      
                                             other systems.                     

  B2             ***System incorporates      Business        Business processes Business processes
                 re-engineered/streamlined   processes       automated are      automated and
                 business processes          automated are   partial documented stakeholders
                 (workflow) in an automated  not defined                        supported are
                 fashion that supporting DOI                                    clearly defined
                 Strategic goals and                                            and documented
                 objectives.***                                                 
  ------------------------------------------------------------------------------------------------

## Data Domain Evaluation Criteria

Using the information gathered on the system during the interview
process, the system will be scored within the data domain based on the
following three criteria:

  --------------------------------------------------------------------------------------
  **Criteria**   **Description**   **Low (1)**     **Medium (3)**     **High (5)**
  -------------- ----------------- --------------- ------------------ ------------------
  D1             ***Existence and  Data standards  Data standards are Standardized data
                 documentation of  are not         defined, but       collection
                 data standards    defined, or are redundancies exist protocols and data
                 and protocols     in a constant   within a given     standards are
                 compliant with    state of flux.  scale. Informal    fully documented
                 DOI and Federal   No              and ad hoc QA/QC   and easily
                 data standards    documentation   systems. Some      accessible and
                 (as               exists outside  documentation      utilized in all
                 applicable)***    of personal     exists, but it is  data collection
                                   files and notes not complete nor   procedures at
                                   of the system   easily accessible. suitable scales.
                                   developers to                      QA/QC systems are
                                   implement QA/QC                    fully operational.
                                   systems.                           

  D2             ***Relative       Data stored and Information        Information
                 maturity and      maintained in   systems and data   systems and data
                 accessibility of  proprietary     structures allow   structures provide
                 system\'s data    databases       data entry and     employees and the
                 storage and       and/or unique   exit, but it is    public ready
                 access            formats, which  cumbersome for     access to current
                 methods.***       preclude access users to gain      economic, social,
                                   or use by       access and to      and ecological
                                   customers.      extract            data and
                                                   information in a   information using
                                                   usable format.     current
                                                                      technology.

  D3             ***Relative       Significant     Some overlap with  Minimal overlap
                 overlap with data overlap with    other DOI systems  with other DOI
                 stored in other   other DOI       in terms of data   systems in terms
                 Interior          systems in      subject areas      of data subject
                 systems.***       terms of data   accessed. Few      areas accessed.
                                   subject areas   system data        System data
                                   accessed. Many  elements           elements
                                   system data     maintained are     maintained are
                                   elements        redundant with     unique with
                                   maintained are  respect to other   respect to other
                                   redundant with  DOI systems.       DOI systems.
                                   respect to                         
                                   other DOI                          
                                   systems.                           
  --------------------------------------------------------------------------------------

## Application Domain Evaluation Criteria

Using the information gathered on the system during the interview
process, the system will be scored within the application domain based
on the following three criteria:

  ----------------------------------------------------------------------------------------
  **Criteria**   **Description**    **Low (1)**      **Medium (3)**     **High (5)**
  -------------- ------------------ ---------------- ------------------ ------------------
  A1             ***Degree of       The system is    The system and its The system and its
                 architectural      not in alignment development plan   development plan
                 compliance with    with the         are partially      are aligned with
                 the conceptual     conceptual TAA.  aligned with the   the Target system
                 Target Application No plans have    TAA. Plans have    Architecture.
                 Architecture.***   been established been established   
                                    to bring the     to bring the       
                                    system into      system back into   
                                    closer alignment alignment.         
                                    with the TAA.                       

  A2             ***Extent to which System           System             System
                 system design      availability,    availability       availability,
                 requirements are   bandwidth,       bandwidth,         bandwidth,
                 defined and        performance, and performance, and   performance, and
                 documented.***     functional       functional         functional
                                    requirements are requirements are   requirements have
                                    undefined and    partially defined  been fully defined
                                    documented.      and documented.    and documented and
                                    System           System             aligned with
                                    requirements not requirements       business
                                    aligned with     partially aligned  processes.
                                    business         with business      
                                    processes.       processes.         

  A3             ***Extent to which System           System interfaces, System interfaces,
                 systems interfaces interfaces,      APIs, and          APIs, and
                 are defined and    APIs, and        dependencies are   dependencies are
                 documented.***     dependencies are partially defined. fully defined.
                                    not defined. Not                    
                                    aligned with                        
                                    TAA.                                

  A4             ***Extent to which No high-level    Some documentation High-level design
                 high-level design  design diagram   exists, but it is  and operational
                 or operational     or description.  not complete nor   concept exists and
                 concepts are       No operational   easily accessible. is fully
                 defined.***        concept                             documented and
                                    documentation.                      accessible.
  ----------------------------------------------------------------------------------------

## Technology Domain Evaluation Criteria

Using the information gathered on the system during the interview
process, the system will be scored within the technology domain based on
the following three criteria:

  ---------------------------------------------------------------------------------------
  **Criteria**   **Description**   **Low (1)**      **Medium (3)**     **High (5)**
  -------------- ----------------- ---------------- ------------------ ------------------
  T1             ***Extent of      System uses      System uses some   System uses some
                 compliance with   components that  recommended TRM    recommended TRM
                 Technology        have are in      components.        components.
                 Reference Model   direct                              
                 technology        opposition to                       
                 architecture      the TRM.                            
                 components.***                                        

  T2             ***Extent of      The system       The system makes   The system makes
                 maximum use of    essentially      some use of        maximum use of
                 shared, existing  creates its own  existing and       existing and
                 infrastructure    infrastructure   sanctioned         sanctioned
                 components and    of independently infrastructure     infrastructure
                 services.***      procured and     components,        components,
                                   managed          services, and      services, and
                                   components,      technology         technology.
                                   services and                        
                                   technology                          
  ---------------------------------------------------------------------------------------

##  {#section .unnumbered}

## Security Domain Evaluation Criteria

Using the information gathered on the system during the interview
process, the system will be scored within the security domain based on
the following criteria:

  --------------------------------------------------------------------------------------
  **Criteria**   **Description**   **Low (1)**     **Medium (3)**     **High (5)**
  -------------- ----------------- --------------- ------------------ ------------------
  S1             ***Extent to      System does not System partially   System fully
                 which the system  comply with     complies with      complies with
                 complies with     current         current security   current security
                 current security  security        requirements of    requirements of
                 requirements and  requirements of has begun the C&A  has completed the
                 extent of         has not begun   process.           C&A process.
                 progress through  the C&A                            
                 the C&A           process.                           
                 process.***                                          

  --------------------------------------------------------------------------------------

# Summary Dashboard Report

Application systems are represented by an evaluation matrix that
summarizes at a glance the system's score in relationship to other
portfolio systems for that business function. The summation of the
preceding criteria will be weighted and then summed as part of a linear
equation to produce a single score. Additional criteria such as O&M
costs per user cost may be show in addition to the weighted score. The
following "dash board" report would be provided to the appropriate
governing body to aid in the approval/disapproval of the modernization
blueprint recommendations. Initially, weighting will be equal in all
domains but may be modified according to decisions made by the
governance structure (i.e., ITMC, MIT, MED). The weighted score will
range from 4 to 20.

Weighted Score = (P1+P2+P3+P4+P5)/5 + (D1+D2+D3)/3 + (A1+A2+A3)/3 +
(T1+T2) + (S1)/3

<table>
<colgroup>
<col style="width: 11%" />
<col style="width: 7%" />
<col style="width: 5%" />
<col style="width: 7%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
</colgroup>
<tbody>
<tr class="odd">
<td>Subsystem or Module</td>
<td><p>Sponsor/</p>
<p>Partner</p></td>
<td>O&amp;M Costs per User</td>
<td>Weighted Score</td>
<td><strong>P1</strong></td>
<td><strong>P2</strong></td>
<td><strong>P3</strong></td>
<td><strong>P4</strong></td>
<td><strong>P5</strong></td>
<td><strong>D1</strong></td>
<td><strong>D2</strong></td>
<td><strong>D3</strong></td>
<td><strong>A1</strong></td>
<td><strong>A2</strong></td>
<td><strong>A3</strong></td>
<td><strong>T1</strong></td>
<td><strong>T2</strong></td>
<td><strong>S1</strong></td>
</tr>
<tr class="even">
<td>App Name</td>
<td>300</td>
<td>$</td>
<td>4</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>App Name</td>
<td>300</td>
<td>$</td>
<td>5</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>App Name</td>
<td>700</td>
<td>$</td>
<td>6</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>App Name</td>
<td>300</td>
<td>$</td>
<td>8</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>App Name</td>
<td>300</td>
<td>$</td>
<td>10</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>App Name</td>
<td>800</td>
<td>$</td>
<td>11</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>App Name</td>
<td>300</td>
<td>$</td>
<td>13</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>App Name</td>
<td>200</td>
<td>$</td>
<td>14</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>App Name</td>
<td>500</td>
<td>$</td>
<td>19</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

### 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 4.

![](media/image5.wmf){width="5.655555555555556in"
height="1.1972222222222222in"}

**Figure 4: Analyze As-Is Business Operations**

The table below reflects the definitions, inputs, and outputs associated
with the Analyze As-Is Business Operations subtasks.

+----------+-----------------------------------------------------------+
| **Table  |                                                           |
| 1:       |                                                           |
| Analyze  |                                                           |
| As-Is    |                                                           |
| Business |                                                           |
| Op       |                                                           |
| erations |                                                           |
| Su       |                                                           |
| btasks** |                                                           |
+----------+-----------------------------------------------------------+
| *        | **Collect Current Issues**                                |
| *Task:** |                                                           |
+----------+-----------------------------------------------------------+
| Def      | Document any known issues that must be addressed by the   |
| inition: | To-Be architecture.                                       |
+----------+-----------------------------------------------------------+
| Input:   | Existing business and technical documentation             |
+----------+-----------------------------------------------------------+
| Output:  | Current issues                                            |
+----------+-----------------------------------------------------------+
| *        | **Inventory Existing Critical Processes**                 |
| *Task:** |                                                           |
+----------+-----------------------------------------------------------+
| Def      | Understand and capture an inventory of processes to the   |
| inition: | 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                                               |
+----------+-----------------------------------------------------------+
| *        | **Document Process Weaknesses / Gaps**                    |
| *Task:** |                                                           |
+----------+-----------------------------------------------------------+
| Def      | For each functional area, catalog the weaknesses          |
| inition: | associated with current business operations.              |
+----------+-----------------------------------------------------------+
| Input:   | Existing business and technical documentation             |
|          |                                                           |
|          | Known weaknesses/gaps                                     |
+----------+-----------------------------------------------------------+
| Output:  | Catalog of weakness/gaps                                  |
+----------+-----------------------------------------------------------+

### 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 5.

![](media/image6.wmf){width="5.814583333333333in"
height="1.1097222222222223in"}

**Figure 5 Analyze As-Is System Portfolio**

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.

-   Target systems are those systems (or system components) with
    relatively high business and technology fit.

![](media/image7.jpeg){width="4.779861111111111in"
height="3.329861111111111in"}

**Figure 6 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  {#develop-to-be-enterprise-architecture .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 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 7 below provides the overall process flow for this major
activity.

![](media/image8.wmf){width="5.9847222222222225in"
height="3.4055555555555554in"}

**Figure 7: 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
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 {#develop-the-transition-plan .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 8 below provides an overview of this activity.

![](media/image9.wmf){width="5.99375in" height="3.5729166666666665in"}

**Figure 8: 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.

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 {#drive-transformation .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 9.

![](media/image10.wmf){width="5.990972222222222in"
height="4.216666666666667in"}

**Figure 9: Drive Transformation**

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 .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 10.

![](media/image11.wmf){width="5.990972222222222in"
height="3.3430555555555554in"}

**Figure 10: 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 {#maintain-the-enterprise-architecture .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

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 11 below provides an overview of this major activity.

![](media/image12.wmf){width="5.990972222222222in"
height="3.6458333333333335in"}

**Figure 11: Maintain Enterprise Architecture**

## Schedule of Activities {#schedule-of-activities .Style-Heading-2Heading-2-Char2ndOrd-(A.)-CharAppendix-Title-Char...}

Shown below is a generic schedule of activities based on the work
currently being done on the focus LOBs for this year. The schedule
depicts only those activities involved in the creation and delivery of
the final modernization blueprint. The generic schedule assumes a
moderately complex Line of Business with approximately 30 applications.

![](media/image13.png){width="7.10625in" height="4.970833333333333in"}