Unification & Simplification Through: C ooperation I nnovation O pportunity

1. Unification & Simplification Through: • Cooperation • Innovation • Opportunity Interior Data Reference Model Overview September 30, 2004 Presented by: Suzanne Acar, OCIO

2. INTRODUCTION • Getting Organized • Data Architecture Framework & Approach • Relationship to the FEA DRM • Data Standardization Concepts & Approach • Implementing the IDRM • Benefits • Communication, Data Governance, & EA • Summary 1

3. Data Architecture Components • Guidance Documents • Data Resource Management • & Standardization Program • Enterprise Data Model • Formal Stewards Body • A Data Registry ENTERPRISE DATA MODEL GUIDANCE DATA REGISTRY STEWARDS 2

4. The Major Mandates • Clinger Cohen Act • OMB Circular A-130 • FEA PMO Guidance Documents • (Emerging guidance for Data and Information • DOI declared as proof-of concept) 3

5. 7 Initial Business Lines Start points for building the Interior Data Architecture: • Recreation • Wild Land Fire Management • Law Enforcement • Indian Trust Data • Finance • Geospatial • Facilities Management Limited EA funding drove the decision to pick priority business lines. The data architecture work on these business lines is accomplished in phases as funding permits. Those in Red are DOI EA priorities. 4

6. Same Data Requirement Different Functional/Business Needs and Different Data Descriptions Recreation The DOI Data Complexity Challenge Finance Fire Management Law Enforcement Records Management Facility Management Geospatial Land Management Indian Trust 5

7. THE VISION: Enabling Business Lines with Shareable Data Recreation Finance Fire Management Shared & Distributed Data (thru data standardization including reuse of external standards) Law Enforcement Records Management Facility Management Land Management Indian Trust Geospatial Requires culture change, planning, and implementation know how to be effective 6

8. Executive Sponsor DOI Data Architect DRMSG DOI Principal Data Stewards Bureau Data Architect Business Data Steward Subject Matter Expert Database Administrator IDRM Roles and Relationships IAWG or ? Appoints Principals & ensures adequate funding Maintains & publishes the IDRM in coordination with Principal Data Stewards and Bureau Data Architects. Promotes the Data Program. DOI Data Architecture Guidance Body Coordinates the creation or review of proposed data standards with all business data stewards & Bureau Data Architects for a business line. Maintains current DOI data Standards for their respective business line. Submits proposed data Standards to DOI Data Architect for formal review process. Assists the DOI Data Architect in the implementation of the Data Program among Bureaus in coordination with Principal Data Stewards and Business Data Stewards. Maintains Bureau unique data standards in coordination with business data Stewards. Coordinates implementation of new Data standards with SME and DBA in systems supporting a business line. Ensures data security & data quality requirements for each data Standard. 7

9. Development of Formal Lead Data Stewards(Current Status) Recreation Finance Law Enforcement Indian Trust Fire Management NPS Deputy CIO Trust Architect Recreation Program Mgr ??? ??? Principal Data Steward for Each Business Line Acting Dept Mgr Interior RM Mgr E-GIM Team ??? Facility Management Geospatial Records Management 8

10. Interior Data Resource Management Goals • Reduce the life cycle cost of data through integration, • data standards, and the use of authoritative reference • data sources. • Provide a data reference model which addresses both • Information requirements and data capabilities. • Provide a data resource management infrastructure to • ensure information integrity, quality, and security. • Provide a metadata registry to support data standardization • and re-use. 9

11. DOI Data Architecture Framework Data Resource Management Portals External Interfaces E-Gov Applications Legacy Migration Policy Data Resource Management Policy XML Policy Other Gov’t Agencies Info Exchange/ Info SharingRequirements Delivery Mechanism (e.g. XML) Synchronization & Implementation Support Data Standardization DOI Partners DOI Lines of Business 10

12. Framework Pillars Amplified (Sample products and services) Info Exchange/ Info SharingRequirements Synchronization & Implementation Support Transport Mechanism (e.g. XML) Data Standardization • Interior Data • Reference Model • (IDRM) • Common Data • Standardization • Procedures • Data Registry • Data Stewards Roster • Interface Requirements • Information Exchange • Data Models • Data Transformation • Models • Re-usable Reference • Data Sets • Re-usable XML • Tags & Schemas • Replication Support • Transformation These activities are imperative to achieve and maintain traceability of the data from the business need to data in the systems including XML. 11

13. The Data & Information Sharing Approach • Identify data and information most important to share • Standardize the data in collaboration forums following • Department procedures • Publish and promote use of the official standard data 12

14. Agencies that need to solve a • common problem • - Agencies that need to share data - Agencies that perform similar processes Topic of interest Community of Practice *SUBJECTAREA: Public Health *SUPER-TYPES: Categories of data used to perform business operations and shared by business functions Business Sub-Functions: Public Health Monitoring Disease Facility Person Location External Request Business Process Agencies define their information and processing needs. This can be applied to the most granular level of information passed. *INFORMATION EXCHANGE:Packages of meaningful data used as an input to decisions or generated as an output during process execution Information Exchange Information Exchange *DATA ELEMENT DESCRIPTION Relational Table XML Schema Object Description FEA DRM CONCEPT 13

15. CREATE TABLE RECAREA (RECAREA_ID CHAR(12) NOT NULL, RECAREA_NM VARCHAR(50) NOT NULL PRIMARY KEY (RECAREA_ID)); CREATE UNIQUE INDEX XPKRECAREA ON RECAREA ( RECAREA_ID ASC); CREATE TABLE RECAREA_ACT (RECAREA_ID CHAR(12) NOT NULL, RECAREA_ACT_CD CHAR(2) NOT NULL, RECAREA_ACT_DESC VARCHAR(240) NULL, RECAREA_ACT_FEE VARCHAR(240) NULL); CREATE UNIQUE INDEX XPKRECAREA_ACT ON RECAREA_ACT ( RECAREA_ID ASC, RECAREA_ACT_CD ASC); Physical Model Schema (SQL) RECREATION-AREA DENTIFIER RECREATION-AREA NAME RECREATION-AREA MAP URL TEXT RECREATION-AREA IDENTIFIER (FK) RECREATION-ACTIVITY TYPE CODE RECREATION-AREA-ACTIVITY DESCRIPTION TEXT RECREATION-AREA-ACTIVITY FEE DESCRIPTION TEXT XML Schema METADATA REGISTRY/REPOSITORY Glossary of Metadata DOMAIN: RECREATION-ACTIVITY TYPE CODE <?xml version="1.0" ?> <xsd:Schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xs:element name="RecAreaActivity"> <xs:annotation> <xs:documentation>A recreational activity available at a Recreation Area. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="RecAreaActivityType" type="xs:string"> <xs:annotation> <xs:documentation>The code that denotes a specific kind of Recreational Activity.</xs:documentation> </xs:annotation> </xs:element> REGISTRY ENTRY: RECREATION-ACTIVITY TYPE CODE DATA TYPE: CHARACTER LENGTH: 2 DEFINITION: The code that denotes a specific kind of Recreational Activity CLASS WORD: CODE A1|AIR-HANG GLIDING B1|BOATING-SAILING B2|BOATING-CANOEING B3|BOATING-KAYAKING C1|CAMPING-CAMP SITES C2|CAMPING-FREE SPACE H1|HIKING-TRAILS H2|HIKING-FREE RANGE S1|SWIMMING-LAKE, POND S2|SWIMMING-POOL IDRM Implementation of FEA DRM(Illustration Example: RECREATION) *Subject Area: RECREATION *Super Type: RECREATION AREA *Information Exchange Package: PUBLIC RECREATION AMENITY REQUEST Data Object: DOI Conceptual Data Entities (Standardized) RECREATION-AREA *Data Element Description Data Property: DOI Conceptual Data Elements (Standardized) RECREATION-AREA-ACTIVITY Data Representation: 14

16. Basic Standardization Framework People Consumer Engineer SME Architect Steward(s) DOI Data Architect Stages Harvest Or Design Analyze & Refine Integrate & Refine Formal Review Update Publish & View Use in Integrated Systems 15

17. Standardization Framework Applied(Illustration Example: Recreation) People Consumer Engineer SME Architect Steward(s) DOI Data Architect Stages Harvest Or Design Access Repository Artifacts Previous RecML Harvest Metadata Analyze & Refine Access Repository Artifacts Iterative Facilitated Modeling Sessions (Multi-Department and Agency) Integrate & Refine Draft New RecML Introduce Cross-Departmental Data Standards Store Repository Artifacts Develop Transformation Model Formal Review) Model Review Package Repository Standardization Management Facility RecML Review Package Update Working RecML Working Recreation Model Update Repository Artifacts Working Transformation Model Publish& View V1.0 RecML Schema Recreation Conceptual Model V1.0 Use in Integrated Systems Pointers to accessible, integrated e-Gov Data Artifact Reuse and Integration Use RecML Schema Use Information Knowledge and Requirements Implement Physical Standards DRM Program Performance Measurements 16

18. Interior Data Reference Model (IDRM) Views All View Common View Lines of Business View 17

19. Proposed Key attribute Key attribute Standard element Proposed element Proposed element Standard element Proposed element Proposed element Data Standardization Process Submission Package DOI DRM Integrated Business Line Views Extraction Review period with Business Data Stewards facilitated by the Interior Data Architect Integrate DRM Upon review completion of a submission Package for a business line, proposed data become official DOI standards and published in various highly accessible sources. 18

20. NAMING STRUCTURE (Maps to ISO 11179 Guidance) Prime Word (subject/entity) Modifier Class Word + + Amount Rate Angle Temperature Area Text Code Time Coordinate Volume Date Weight Dimension Identifier Mass Name Number Quantity EXAMPLES: - DOCUMENT APPROVED DATE - CONTRACT PAYMENT RATE - PERSON NAME 19

21. NAMING RULES RULES FOR DEFINITIONS • Don’t repeat the name in the definition • Describe the “what”, not the “how”, • “when”, “where”, or “who” • Data elements must have only one • meaning. Avoid multiple meanings and • concepts • Have only one interpretation • Avoid ambiguity • Describe purpose & usefulness without • using physical qualities • Name is always unique • Be clear, accurate, and self explanatory • Name is always singular • Always end with a class word • Include only alphabetic characters, • and spaces • Unless commonly used, spell out all • acronyms Some Rules to Follow (Consistent with ISO 11179 guidance) 20

22. Data Architecture Communication(http://www.doi.gov/ocio/architecture/index.html) IDRM Artifacts posted on Interior’s EA web page. High level Data Architecture (i.e. data subject areas) and data models are in the Department’s EA Repository (DEAR). 21

23. Interim DOI Data Repository(MS Access Database) Easier to track data life cycle, search, sort, parse, and/or map data elements for analysis work with MS Access DB 22

24. Data Architecture Role in Modernization Blueprint Analysis Identify Common Data Data Subject Area A B Super Type A Super Type B Super Type C BRM Business Need Financial System A Recreation System B Data Sharing Opportunities Fire Management System C Discovery of data sharing opportunities and redundancies begins by mapping systems to Data Subject Areas and Super Types. 23

25. DOI Data Subject Areas and Super Types Report September 13, 2004 This document contains the high level classification of data subject areas and super types approved by the Data Resource Management Steering Group. The purpose of this document is to facilitate the discovery of data sharing opportunities and redundant data across the DOI enterprise. It also supports various data analysis activities. DOI Data Subject Areas (Sample) 24

26. Existing Bureau and External Data Subject Areas • DEAR System Info. • Database Schemas (Rec.) • Artifacts • Data Subject Area Definitions Identify and Define Data Subject Areas and Super Types Acquire System Artifacts and SME Knowledge Develop maps between Systems and Subject Areas 1 2 3 DOI Data Architecture Contractor and DRMSG DOI Data Architecture Contractor and DRMSG DRMSG Data Subject Area Mapping Process 25

27. Outcomes $ $ $ $ IDRM Implementation - Recreation Requirements & Challenges IDRM Role Outcomes Needed a basis for data sharing amongst multiple Federal, State, Local & Commercial parties Provided a basis for requirements gathering and data analysis – Rapid Standardization All parties agree to data sharing requirements – greatly increased collaboration Provided a mechanism for discussion and validation amongst data sharing partners Integrated data requirements and data sharing across business lines Share data from multiple business lines Must be easily extensible to accommodate new requirements Extensibility proven through inclusion of Trails data standard Identification of data sharing opportunities Translation of conceptual analysis into database and XML Schema Translate data sharing to a database and XML Implemented database and XML Schema 26

28. Outcomes $ $ $ IDRM Implementation – Law Enforcement Requirements & Challenges IDRM Role Outcomes Needed to develop comprehensive set of data requirements for new LE Systems Procurement Provided a basis for requirements gathering and data analysis Provided a clear set of data requirements to be included in procurement documents Must integrate with Department of Justice XML Schema Justice XML data standards have been included. Provides ability for data exchange using emerging standard Model provided platform for integration of Justice standards and DOI requirements Provide an extensible standard for the concept of an Incident, whether it is LE, Emergency Management, Search & Rescue, etc. Model currently being extended to include Emergency Management, Security and Organizations Inclusion of an extensible concept for an “incident.” 27

29. $ $ $ IDRM Implementation – Records Mgmt Requirements & Challenges IDRM Role Outcomes Outcomes Provided a basis for requirements gathering and data analysis With one analysis session, provided an extension to the IDRM that clearly captures the core data requirements for Records Management. Needed to identify the core data requirements necessary to conduct the Records Management business process IDRM Methods and Techniques provide a flexible mechanism for data sharing analysis Model to be used as a basis for analysis of data sharing and redundancies Provide for future analysis of data sharing opportunities and reduction of redundancies IDRM Methods and Techniques are based on ISO 11179 and other standards, ensuring a basis for Federal-wide analysis Model has been circulated among several Federal Agencies Provide for possible data reference model across the Federal Government 28

30. IDRM Benefits • Reduces Costs • Control redundancy thru data standardization & integration • Re-use opportunities improved • Interface development/maintenance costs reduced • Traces data and information in systems to the business need • Takes advantage of existing information planning efforts • Common language, common definitions • Meets OMB/Federal Enterprise Architecture (FEA) and DOI Architecture mandates 29

31. Interior EA Components & Governance Teams Interior Architecture Work Group Interior Architecture Review Board PRM BRM SRM Data Marts Data Warehouses Information Systems Knowledge Management Records Management • LINES OF BUSINESS • Subfunctions • Recreation • Finance • Law Enforcement Interior Business Architecture Team (IBAT) Domain Arch. Teams (DAT’s) DRM Data Resource Mgmt Steering Group (DRMSG) Recreation-Amenity TRM Recreation-Amen Name Subject Area RECREATION Recreation-Amen Description Text Facility Agency Code Product Name Vendor Visio Microsoft Erwin CA Int’l Oracle Oracle XML Altova Facility Facility Identifier Facility Name Facility Type Code Provides 30

32. Summary • DOI Data Architecture work is evolutionary and maps to the • concepts in FEA DRM and ISO 11179 • IDRM development tied to DOI EA priority business lines • IDRM serves as the basis for database design, data integration, • and XML artifacts (RECREATION proof-of-concept) • Effective Data Stewardship is critical to success “I am careful not to confuse excellence with perfection. Excellence I can reach for, perfection is God’s business.” ---- Michael J. Fox 31

33. QUESTIONS Suzanne Acar Enterprise Data Architect Department of the Interior Office of the Chief Information Officer Phone: 202-208-3216 E-mail: suzanne_acar@ios.doi.gov 32