Interior
Technical Reference Model
Version 2.0
Executive Summary..................................................................................................................... I-3
Introduction and Background...................................................................................................... I-5
Using the Interior Enterprise Architecture Technical Reference Model.............................. I-10
Maintaining the Interior Enterprise Architecture.................................................................... I-12
The Interior Enterprise Architecture Exception Process........................................................ I-15
Chapter 1, Information Security ................................................................................................ 1-1
Chapter 2, Infrastructure............................................................................................................ 2-1
Chapter 3, Data Management.................................................................................................... 3-1
Chapter 4, Geospatial Technologies.......................................................................................... 4-1
Chapter 5, Application Development and Acquisition............................................................... 5-1
Chapter 6, Platform..................................................................................................................... 6-1
Chapter 7, Distributed Systems Management.......................................................................... 7-1
Chapter 8, Records Management.............................................................................................. 8-1
Appendix A, Glossary................................................................................................................. A-1
Appendix B, List of Acronyms................................................................................................... B-1
Appendix C, Overview of Populated Components by SRM Service Area.............................. C-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
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.
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.
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.
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.
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.
The graphic below provides a visual overview of
Interior’s TRM.
Using the Interior
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 Meaning
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.
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.
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;