U.S. Department of the Interior

Interior Enterprise Architecture

Technical Reference Model

Version 2.0

![](media/image1.jpeg){width="2.6034722222222224in"
height="2.6034722222222224in"}

####### **October 15, 2003**

## Table of Contents {#table-of-contents .TOC-1}

## [Executive Summary](#executive-summary) I-3 {#executive-summary-i-3 .TOC-1}

## [Introduction and Background](#Intro_and_Background) I-5 {#introduction-and-background-i-5 .TOC-1}

## [Using the Interior Enterprise Architecture Technical Reference Model](#using-the-interior-enterprise-architecture-technical-reference-model) I-10 {#using-the-interior-enterprise-architecture-technical-reference-model-i-10 .TOC-1}

## [Maintaining the Interior Enterprise Architecture](#maintaining-the-iea) I-12 {#maintaining-the-interior-enterprise-architecture-i-12 .TOC-1}

## [The Interior Enterprise Architecture Exception Process](#the-iea-exception-process) I-15 {#the-interior-enterprise-architecture-exception-process-i-15 .TOC-1}

## [Chapter 1, Information Security](../TRM%20Chapters%20and%20Appendices/Chapter%201%20-%20TRM_Security%20v2.0.doc) 1-1 {#chapter-1-information-security-1-1 .TOC-1}

## [Chapter 2, Infrastructure](../TRM%20Chapters%20and%20Appendices/Chapter%202%20-%20TRM_Infrastructure%20v2.0.doc) 2-1 {#chapter-2-infrastructure-2-1 .TOC-1}

## [Chapter 3, Data Management](../TRM%20Chapters%20and%20Appendices/Chapter%203%20-%20TRM_Data_Mgmt%20v2.0.doc) 3-1 {#chapter-3-data-management-3-1 .TOC-1}

## [Chapter 4, Geospatial Technologies](../TRM%20Chapters%20and%20Appendices/Chapter%204%20-%20TRM_Geospatial%20v2.0.doc) 4-1 {#chapter-4-geospatial-technologies-4-1 .TOC-1}

## [Chapter 5, Application Development and Acquisition](../TRM%20Chapters%20and%20Appendices/Chapter%205%20-%20TRM_App_Dev%20v2.0.doc) 5-1 {#chapter-5-application-development-and-acquisition-5-1 .TOC-1}

## [Chapter 6, Platform](../TRM%20Chapters%20and%20Appendices/Chapter%206%20-%20TRM_Platform%20v2.0.doc) 6-1 {#chapter-6-platform-6-1 .TOC-1}

## [Chapter 7, Distributed Systems Management](../TRM%20Chapters%20and%20Appendices/Chapter%207%20-%20TRM_DSM%20v2.0.doc) 7-1 {#chapter-7-distributed-systems-management-7-1 .TOC-1}

## [Chapter 8, Records Management](../TRM%20Chapters%20and%20Appendices/Chapter%208%20-%20TRM_Records%20v2.0.doc) 8-1 {#chapter-8-records-management-8-1 .TOC-1}

## [Appendix A, Glossary](../TRM%20Chapters%20and%20Appendices/Appendix%20A%20-%20DOI_IEA_Glossaryv2.0.doc) A-1 {#appendix-a-glossary-a-1 .TOC-1}

## [Appendix B, List of Acronyms](../TRM%20Chapters%20and%20Appendices/Appendix%20B%20-%20DOI_IEA_Acronyms%20v2.0.doc) B-1 {#appendix-b-list-of-acronyms-b-1 .TOC-1}

## [Appendix C, Overview of Populated Components by SRM Service Area](../TRM%20Chapters%20and%20Appendices/Appendix%20C%20-%20Populated%20Components%20of%20SRM%20%20v2.0.doc) C-1  {#appendix-c-overview-of-populated-components-by-srm-service-area-c-1 .TOC-1}

## Executive Summary {#executive-summary .TOC-1}

The Department of the Interior (Interior) is a decentralized,
bureau-centric organization consisting of eight bureaus, a national
business center, and several individual offices. Interior maintains a
full-time staff of about 70,000 located at over 2,000 sites across the
United States and its territories. A large number of sites are located
in remote areas. As a result, information technology (IT) solutions have
traditionally evolved in a separate and contained manner.

Many programs have requirements to share information with partners
outside Interior, and have sometimes adopted partners\' technological
requirements. While a number of cross-bureau/partner and Interior-wide
initiatives have taken place in recent years, the bulk of the current IT
environment remains heterogeneous and fragmented. It consists chiefly of
self-contained systems designed to meet the specific needs of individual
bureaus operating independent, self-sufficient programs. The
infrastructure reflects this diversity.

There is a growing demand for Interior to conduct its business
differently. This new business model includes a need for: (1)
coordinated service delivery across bureaus, (2) citizen-centric one
stop shopping, (3) more planned and coordinated partnerships with
external organizations, and (4) streamlined administrative business
processes. Interior has a significant challenge to redesign its business
approaches and processes. Moreover, its greatest challenge in the IT
world is to implement an IT environment that supports this new business
model by building the IT infrastructure needed to connect bureaus to
each other and their customers, and to provide appropriate access to
information from any place, at any time.

Interior is not alone in seeking to change the way it uses technology.
Most agencies within the Federal government are trying to adapt to a
changing environment while delivering on their mission. The Interior
Enterprise Architecture (IEA) is a process that can be used to
facilitate these necessary changes within the Department.

While there are a number of major pieces to the IEA (e.g., Business
Reference Model, Data Reference Model), this document outlines the
Technology Reference Model (TRM) that reflects the technical
architecture.

To ensure success, Interior\'s technical architecture needs to:

-   Be based on the strategic business direction of Interior as an
    enterprise;

-   Be based on a planning process that supports strategic business
    planning as well as ongoing tactical decisions made when
    implementing systems;

-   Involve bureau business managers as well as IT staff throughout the
    process;

-   Provide strategic direction for making technology decisions without
    requiring wholesale and major changes to the current IT environment;

-   Allow bureaus to share many IT infrastructure components without
    sacrificing responsiveness to the changing business needs of
    individual bureaus;

-   Make the IT environment adaptable to quickly adjust to changes in
    the business environment;

-   Have a governance process that supports the ongoing evolution of the
    architecture as well as its enforcement;

-   Evolve in synch with changing business strategies; and

-   Be implemented in a short amount of time to avoid analysis
    paralysis.

Questions regarding the Interior Enterprise Architecture should be
directed to the Interior Chief Architect.

## Introduction and Background  {#introduction-and-background .TOC-1}

[]{#Intro_and_Background .anchor}

A primary focus of Enterprise Architecture (EA) is enabling an
organization's regular re-alignment of the business strategies and the
IT resources employed to support these strategies. Among the tools used
by EA are architecture models. The Department of the Interior is
incorporating the models provided by the Office of Management and Budget
(OMB) within its Interior Enterprise Architecture (IEA.)

The OMB Federal Enterprise Architecture (FEA) was created to facilitate
efforts to transform the Federal Government into one that is
citizen-centered, results oriented, and market-based. It is a
business-based framework for Government-wide improvement. As illustrated
below, the OMB FEA was constructed through five interrelated "reference
models" designed to facilitate cross-agency analysis and the
identification of duplicative investments, gaps, and opportunities for
collaboration within and across Federal Agencies.

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

The five reference models in the OMB FEA include:

-   The Business Reference Model (BRM) that describes the business
    lines, functions and sub-functions of the Federal Government
    independent of the agencies which perform them;

-   The Performance Reference Model (PRM) that identifies the common set
    of general performance outcomes, metrics and indicators that
    Agencies will use to define, measure, and achieve program goals and
    objectives;

-   The Data and Information Reference Model (DRM) that describes the
    data and information that support program and business line
    operations (The model will aid in describing the types of
    interactions and information exchanges that occur between the
    Federal Government and its customers, constituencies, and business
    partners.);

-   The Service Component Reference Model (SRM) that is a
    business-driven, functional framework that classifies service
    components with respect to how they support business and/or
    performance objectives; and

-   The Technical Reference Model (TRM) that provides a foundation to
    describe the standards, specifications, and technologies to support
    the delivery, exchange, and construction of business or service
    components and e-Gov solutions.

A more complete description of the OMB models can be found at the
following address: (<http://www.feapmo.gov/fea.asp>).

While this document mostly covers the Interior TRM, the extensive
integration between the SRM and the TRM requires a brief overview of the
SRM. The SRM serves to identify and classify horizontal and vertical
service components that support an agency and its IT investments and
assets.

Specifically, the SRM was created to:

-   Provide a framework that identifies service components and their
    relationships to the technology architecture of agencies across the
    Federal Government;

-   Classify, categorize and recommend components for the reuse of
    business services and capabilities across the Federal Government;

-   Define existing service components that may be leveraged outside
    agency boundaries;

-   Align and leverage existing federal guidance and
    application/architecture recommendations;

-   Support the 24 Presidential Priority E-Gov initiatives; and

-   Evolve based on new services and components as they are discovered
    across industry and federal markets.

The Federal Enterprise Architecture Service Component Reference Model
Version 1.0 is organized as a functional hierarchy, with *Service
Domains* at the highest level followed by *Service Types* and
*Components*.

![](media/image3.png){width="1.75in" height="1.3055555555555556in"}

There are 7 Service Domains that provide a top-level categorization of
the service capabilities and categories from a business perspective.
These seven Service Domains are comprised of 28 Service Types that
further categorize and define the capabilities of a Service Domain. The
Service Types define the second level of detail that describe a
business-oriented service. The next, and final, layer of the SRM is the
Component level. These 164 Components represent the lower-level, logical
"building blocks" of a business or application service component. The
graphic below depicts the depth and breath of the FEA SRM.

During this initial implementation of the FEA models, 77 of the 164 SRM
components were populated with technical guidance and information
captured from appropriate technical experts (e.g., SRM component =
Network Management.) (An overview of all the populated components by SRM
service area can be found in Appendix C.) Many of the remaining SRM
components (e.g., Recruiting, benefits management, etc.) are better
populated with guidance from business personnel and will be "fleshed
out" during future updates to the architecture. The current populated
SRM service components are supported by elements of the technical
infrastructure reflected within the Technology Reference Model.

The TRM serves to outline the technology elements that collectively
support the adoption and implementation of component-based
architectures. The model provides the foundation to advance the re-use
of technology and component services across the Federal Government
through standardization. Aligning agency capital investments to the TRM
leverages a common, standardized vocabulary, allowing inter-Agency and
intra-Agency discovery, collaboration, and interoperability. Agencies,
and the Federal Government, will benefit from economies of scale by
identifying and re-using the best solutions and technologies to support
their business functions, mission, and target architecture.

Specifically, the FEA TRM was created to:

-   Create a government-wide reference model that unifies agency TRMs
    and existing e-Gov guidance;

-   Focus technology standards, specifications, and recommendations on
    those that embrace the Internet and related approaches;

-   Create a foundation that focuses heavily on the delivery and
    construction of service components and their interfaces; and

-   Identify the layers of a Component-Based Architecture, the
    supporting technologies, and recommendations for each.

##  

There are four (4) Service Areas within the TRM. They are:

-   Service Access and Delivery - refers to the collection standard and
    specifications to support external access, exchange, and delivery of
    Service Components or capabilities. This area also includes the
    Legislative and Regulator requirements governing the access and
    usage of the specific Service Component;

-   Service Platform & Infrastructure - refers to the collection of
    delivery and support platforms, infrastructure capabilities and
    hardware requirements to support the construction, maintenance, and
    availability of a Service Component or capabilities;

-   Component Framework - refers to the underlying foundation,
    technologies, standards, and specifications by which Service
    Components are built, exchanged, and deployed across
    Component-Based, Distributed, or Service-Orientated Architectures;
    and

-   Service Interface and Integration - refers to the collection of
    technologies, methodologies, standards, and specifications that
    govern how agencies will interface (both internally and externally)
    with a Service Component, as well as defines the methods by which
    components will interface and integrate with back office / legacy
    assets.

![](media/image6.wmf)The graphic below provides a visual overview of
Interior's TRM.

## 

## 

##  

## Using the Interior Enterprise Architecture Technical Reference Model {#using-the-interior-enterprise-architecture-technical-reference-model .TOC-1}

The eight technical architecture domains are:

1.  Information Security

2.  Infrastructure

3.  Data Management

4.  Geospatial Technologies

5.  Application Development and Acquisition

6.  Platform

7.  Distributed Systems Management

8.  Records Management

The focus of the Interior Enterprise Architecture is on providing
guidance for IT issues and initiatives that are Interior-wide or
multi-bureau in scope. Each of the eight domain teams of technical
experts from Interior was instrumental in creating their chapter of the
TRM.

If used correctly, the TRM will act as a catalyst for those looking to
capitalize on its contents and better understand the full meaning of its
guidance. This understanding will permit IT personnel to better engage
non-IT organizations in discussions around tradeoffs and priorities
within the proper governance structure (e.g., Management Initiatives
Team (MIT), Information Technology Management Council)). The TRM (like
the architecture itself) is not intended to be the "last word" (e.g.,
some automated checklist for product selection) but it is intended to be
one of the "first words" to assure that Interior's mission priorities
and its IT priorities remain closely aligned.

Additionally, it is doubtful that a single TRM domain chapter can be
used to address a substantive issue. More realistically, several
architecture domains may need to be reviewed when addressing an
important IT decision. For example, if Interior was considering the
creation of a new Interior-wide reporting system that could be used by
the general public, then the TRM chapters like Information Security,
Application Development and Records Management might all need to be
reviewed.

The IEA Exception Process for seeking exceptions to these requirements
is outlined in the Maintaining the IEA section of this Introduction.

######## Domain Document (TRM) Contents

> **Introduction and background** -- Briefly describes the Domain and
> its areas of influence.
>
> **Architecture Principles** -- Based on the IEA Conceptual
> Architecture Principles, these domain principles define the rules for
> guiding IT decisions in this domain. For most domains, these are the
> design guidelines for implementing systems using these technology
> components. The domain principles also include justifications, or
> rationales for the principle, as well as the implications of that
> principle. These principles are key to making decisions about
> technology and product standards.
>
> **Technology Components**-- Each component of the domain is described.
> These descriptions will help readers begin to understand the
> technology areas.
>
> **Standards, Protocols, and Products**-- Each domain team, where
> appropriate, evaluated current technical standards, protocols, and
> products based upon their ability to meet the domain principles. This
> evaluation resulted in classifying the life cycle stage for these
> standards, protocols and products.

The classifications used were:

Life Cycle Definition/

[Classifications]{.underline} [Meaning]{.underline}

Preferred Product/standard of choice; support available; recommended.

Contained Develop solutions using these standards or products only if
there are no suitable alternatives categorized as preferred; if a
preferred product is available that will meet the requirements, plans
should be developed to move from contained to preferred as soon as
practical.

Obsolete Being phased out; (e.g., vendor support ending); plans should
be developed to rapidly phase out and replace (often to avoid
substantial risks).

Research Product/standard to be used in conjunction with technology
research efforts only (e.g., testing, pilots).

Rejected Product/standard has been evaluated and found not to meet
technical architecture needs.

> **Select Best Practices** -- Some domain teams provided additional
> guidance with select best practices. These recommendations are
> practical advice based upon either their own experiences or research
> from other public sector architecture efforts.

## Maintaining the IEA {#maintaining-the-iea .TOC-1}

The Interior Enterprise Architecture is never completed. It is an
ongoing process. During the development of the IEA, the participants
recognized that there are gaps in the current technical environment that
need to be filled to meet the strategic needs of Interior. For the IEA
to be a meaningful tool for decision-making, the domain teams will need
to continue to address these gaps.

Another component of maintaining the IEA is the enforcement of the
architecture standards. The OCIO reviews compliance to the IEA via its
responsibility for IT planning and IT procurement oversight. The key to
administering this compliance role is good communications and planning.
At times, there will be a need for exceptions to the architecture. The
process for requesting an exception to the IEA principles and standards
is outlined in the IEA Exception Process section at the end of this
introduction.

To meet this need for maintaining the IEA, four groups are involved. The
following is a description of the different groups and their roles.

######## Management Initiatives Team 

The Management Initiatives Team (MIT) exists to ensure the alignment of
IT with the business requirements of Interior and its bureaus.
Additional responsibilities of the group include:

-   Responsibility for prioritizing Interior-wide IT efforts in relation
    to business requirements;

-   Responsibility for maintaining alignment between IT and business;

-   Establishment of supporting policies to the CIO for Interior-wide
    infrastructure services to support the architecture;

-   Functioning as final appeals authority for architecture exceptions;
    and

-   Responsibility for maintaining appropriate linkages to corresponding
    processes (e.g., strategic planning, capital planning).

######## Information Technology Management Council 

The Information Technology Management Council (ITMC) is responsible for
the promotion, approval and enforcement of the technical standards. The
Information Technology Management Council (ITMC) is made up of bureau
senior IT management and is co-chaired by the Department's Chief
Information Officer (CIO) and a bureau CIO, on a rotating basis. Its
membership is made up of senior bureau IT personnel. The ITMC approves
domain team deliverables (e.g., design principles, product standards,
best practices). Responsibilities also include:

-   Functioning as technical liaisons for the Management Initiatives
    Team;

-   Responsibility for assuring Interior-wide IT initiatives comply with
    technical architecture;

-   Reviewing and approving technical products and standards aligned
    with the architecture;

-   Responsibility for initial technical reviews of Interior-wide IT
    initiatives; and

-   Responsibility for appropriate approval/ denial of exceptions to the
    architecture.

######## Architecture Review Board 

######## 

######## The Architecture Review Board (ARB) is a standing board that serves the Interior Chief Information Officer (CIO) and Information Technology Management Council (ITMC) on issues related to technical compliance with the IEA. The ARB identifies and/or facilitates components for update to the IEA through liaison with standing Domain Architecture Teams (DATs). Responsibilities and activities include:

######## 

-   Enhance and evolve the IEA

-   Recommend establishment and disbandment of Domain Architecture Teams

-   Review and recommend approval of technical products and standards
    proposed by the DATs for inclusion in the IEA

-   Recommend resolutions to architecture and technological issues

-   Develop and recommend priorities for approved IT initiatives

-   Review requests for and recommend IEA and Technical Reference Model
    (TRM) waivers

-   Technical liaison between the ITMC, the Interior Chief Architect,
    and the DATs

-   Provide recommendations and reports to the ITMC

########  

######## Interior Architecture Working Group

The Interior Architecture Working Group (IAWG) is chaired by the
Interior Chief Architect and is comprised of bureau/office chief
architects or other designees. The IAWG is:

-   Bureau/office liaison between the Domain Architecture Teams (DATs),
    Interior Chief Architect, and the ITMC;

-   Resource for supporting and communicating architecture benefits and
    requirements, and promoting alignment of Interior-level and
    bureau/office-level architectures;

-   Responsible for coordinating within the bureau/office, along with
    the bureau/office CIO, on architecture issues;

-   Responsible for coordinating DAT activities within the
    bureau/office, and ensuring DAT representatives present a unified
    bureau/office position on technical architecture issues; and

The above described architecture governance is a natural outgrowth of
the architecture process and will continue to be fine-tuned as the IEA
matures.

######## Domain Architecture Teams

The technical domain teams provide the knowledge and expertise required
to develop the technical architectures and standards for the enterprise
architecture process. Each team is composed of technical experts from
throughout Interior. These teams are responsible for the development and
maintenance of a Domain Architecture chapter of the TRM, including the
domain specific deliverables (e.g., design principles, technical
standards, products). The teams are expected to keep abreast of new
technology and make recommendations on solutions to close gaps in the
current environment. Additional responsibilities include:

-   Responsibility for assuring domain architecture aligns with
    Interior-wide Conceptual Architecture;

-   Function as a resource for ITMC for technical analysis during
    Interior-wide initiative reviews (e.g., ITMC "arms & legs"); and

-   Function as a resource for the ITMC on significant updates/ changes
    occurring within the Domain.

## The IEA Exception Process {#the-iea-exception-process .TOC-1}

An exception to the standards and guidance defined in the Interior
Enterprise Architecture can be requested for several reasons.

1.  An initial architecture review is performed and non-compliance to
    the IEA is identified. The IT project lead can file a request for an
    exception to the architecture for the project. The exceptions will
    be addressed at regularly scheduled ITMC meetings.

2.  Once a project has been approved and the project is in an
    implementation phase, a bureau may find a need to deviate from the
    standards in the IEA for business reasons. This type of exception
    request would also cover procurement situations where a bureau is in
    the process of evaluating proposals to a request for proposal (RFP),
    statement of work (SOW), etc. A bureau can also request an expedited
    review if the situation warrants it and the ITMC will convene a
    meeting to review the request. Otherwise review will be scheduled
    for the next ITMC meeting.

A written request to the ITMC should document the justifications for the
exceptions and the impact of granting versus not granting this request.

If an exception is not granted for the IT project, an appeal can be
filed to the MIT. This appeal should be in writing and should state
clearly the business reasons for granting the exception.

Questions regarding the Interior Enterprise Architecture should be
directed to the Interior Chief Architect.