Interior
Chapter 3
Data Management Architecture
Version 2.0

CHAPTER 3. DATA MANAGEMENT ARCHITECTURE
3.1 Introduction and Background
Principle 2: Data Collection and Reuse
Principle 4: Data Contingency Planning
Principle 8: Mainstream Technologies
3.3.9 Data Format / Classification
3.3.10 Data Types /
Validation
Data is the representation of facts, concepts or instructions in a formalized manner suitable for communication, interpretation or processing. When data is combined appropriately, information is derived. Much like the natural resources it manages, Interior’s data and information are valuable assets that must managed. The full value of data and information resources is realized when Interior is able to appropriately share that data and information internally, as well as with external partners.
The focus of the Interior Enterprise Architecture is on providing guidance for information technology (IT) issues and initiatives that are Interior-wide or multi-bureau in scope. The Data Management architecture defines the mechanisms and standards for collecting, documenting, accessing, managing, maintaining the integrity of and securing Interior’s electronic data assets.
If used correctly, the Interior Enterprise Architecture 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 the non-IT organization in discussions around tradeoffs and priorities within the proper governance structure (e.g., Management Initiatives Team (MIT), Information Technology Management Council (ITMC)). The Interior Enterprise Architecture is not intended to be the “last word” (e.g., some automated checklist for product selection). It is intended to be one of the “first words” to assure that Interior’s mission priorities and its IT priorities remain closely aligned.
There are many instances within Interior of data sharing and reuse. Conversely, there are also many examples of where data is not reused and shared enterprise-wide but collected and duplicated in innumerable databases throughout Interior or even within a single Bureau (e.g., names, addresses, and social security numbers may be stored and maintained in every application system that needs that particular data). It is difficult to determine which database stores the most current or correct information. Storing and maintaining multiple copies of the same data throughout the enterprise is time consuming and expensive.
Because Interior is incorporating the OMB’s Federal Enterprise Architecture (FEA) models, the technical guidance provided by the subject area experts within a domain spans both the Service Component Reference Model (SRM) as well as the Technical Reference Model (TRM). For the Data Management domain, the SRM elements are as follows:
Service Domain(s): The Back Office Services Domain defines the set of capabilities that support the management of enterprise planning and transactional-based functions.
Service Type(s): Data Management - defines the set of capabilities that support the usage, processing and general administration of unstructured information.
Development and Integration - defines the set of capabilities that support the communication between hardware/software applications and the activities associated with deployment of software applications.
Component(s): Data Classification – defines the set of capabilities that allow the classification of data.
Data Cleansing – defines the set of capabilities that support the removal of incorrect or unnecessary characters and data from a data source.
Data Exchange – defines the set of capabilities that support the interchange of information between multiple systems or applications.
Data Recovery – defines the set of capabilities that support the restoration and stabilization of data sets to a consistent, desired state.
Extraction and Transformation – defines the set of capabilities that support the manipulation and change of data.
Loading and Archiving – defines the set of capabilities that support the population of a data source with external data.
Data Mart – defines the set of capabilities that support a subset of a data warehouse for a single department or function within an organization.
Data Warehouse – defines the set of capabilities that support the archiving and storage of large volumes of data.
Data Integration - defines the set of capabilities that support the organization of data from separate data sources into a single source using middleware or application integration as well as the modification of system data models to capture new information within a single system.

These SRM service elements are likewise supported by Interior’s
IT (technical) infrastructure (e.g., servers, networks). Within this
infrastructure are individual TRM components for which this domain team is
providing guidance. The graphic below outlines those TRM elements for this
domain that support the service needs of the SRM.
Additionally, it’s doubtful that a single domain chapter from the TRM can be used to address a substantive issue. More realistically, a few 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 Web application that could be used both by the general public and Interior personnel, then the TRM chapters like Data Management Technologies, Information Security, Distributed Systems Management and Application Development might all need to be reviewed.
The
principles listed below provide guidance for the design and selection of
technology components that will support the data management needs of Interior-wide
IT initiatives.
Principle 1: Data
Sharing
|
|
|
|
Data and information must be managed to facilitate data sharing across Interior, with our partners and the public. Rationale:
Implications:
12. Need to balance the
desire to share data with sensitivity, privacy and confidentiality
restrictions. 13. Need to take
electronic records management requirements into consideration. |
|
|
|
Principle 2: Data Collection and Reuse |
|
|
|
In considering data requirements, we should look to reuse existing data before we buy. If no data exists within Interior, consider acquisition of data from external sources before collecting/creating new data. Rationale:
Implications:
|
|
|
|
Principle 3: Data
Security
|
|
|
|
Data needs to be secured according to its sensitivity. Rationale:
Implications:
|
|
|
|
Principle 4: Data Contingency Planning |
|
|
|
Contingency planning processes need to be in place to ensure data availability. Rationale:
· Allows Interior to continue its mission and meet legal requirements. Implications:
|
|
|
|
Principle 5: Data Lifecycle |
|
|
|
Information is valued as an Interior asset; therefore, Interior data needs to be managed throughout its lifecycle. Rationale:
Implications:
|
|
|
|
Principle 6: Data Stewardship |
|
|
|
Data and information must be managed and maintained as a stewardship responsibility to support the mission of the department. Rationale:
· Data stewardship promotes the establishment of authoritative sources. · Complies with requirements of Section 515 of the Treasury and Consolidated Agency Appropriation Act. Implications:
|