• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
LIST OF FIGURES.doc
 

LIST OF FIGURES.doc

on

  • 747 views

 

Statistics

Views

Total Views
747
Views on SlideShare
747
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LIST OF FIGURES.doc LIST OF FIGURES.doc Document Transcript

    • DOD ENTERPRISE INFORMATION INTEROPERABILITY ASSESSMENT (LIVING DOCUMENT, VERSION 0.2) FOR THE DOD LOGISTICS ARCHITECTURE MODELING PROGRAM August 2002 Submitted by ManTech Advanced Systems International, Inc. Enterprise Integration Center (e-IC) 1000 Technology Drive, Suite 3310 Fairmont, West Virginia 26554 Telephone: (304) 367-1699 In support of Contract GS-35F-4660G Order Number K1101BJ3322 Enterprise Integration Center (e-IC) Robert S. Kidwell Michael D. Evanoff Vice President/Senior Technical Director Technical Director DoD Logistics Architecture Modeling Program DoD Logistics Architecture Modeling Program
    • TABLE OF CONTENTS LIST OF FIGURES........................................................................................................................iii EXECUTIVE SUMMARY.............................................................................................................1 1.0 INTRODUCTION....................................................................................................................4 2.0 OVERVIEW OF THE ENTERPRISE DATA ENVIRONMENT CONCEPT........................6 2.1 Evolution of the Enterprise Data Environment Concept..............................................6 2.1.1 The Need for Interoperability........................................................................7 2.1.2 Product Data Markup Language..................................................................10 2.1.3 The Enterprise Data Environment...............................................................12 2.2 Enterprise Information Interoperability Discipline.....................................................14 2.2.1 Enterprise Information Interoperability Discipline vs. Enterprise Application Integration Discipline...............................................................................................................15 2.2.2 Enterprise Information Interoperability Discipline, Objectives, and Design Goals 17 2.2.3 Enterprise Information Interoperability (EII) Functional Overview...........20 3.0 EII DOD APPLICABILITY ASSESSMENT........................................................................23 3.1 DoD Information Technology Environment...............................................................23 3.2 Applicability to DoD Enterprise Architecture Environment......................................26 3.2.1 DoD Baseline Architecture (As-Is)..............................................................27 3.2.2 DoD Target Architecture (To-Be)...............................................................32 3.3 DoD Cultural Environment.........................................................................................34 4.0 CONCLUSIONS AND RECOMMENDATIONS.................................................................35 REFERENCES..............................................................................................................................37 GLOSSARY..................................................................................................................................38 APPENDIX A: RELATED COTS TOOL VENDOR – MODULANT SOLUTIONS..................1 APPENDIX B: RELATED DOD POLICIES, STANDARDS, AND DIRECTIVES...................1 ii
    • LIST OF FIGURES Figure 2.1-1 Traditional EAI is Point to Point Hard-coded Mapping............................................6 Figure 2.1.1-1 Next Generation EAI (Modulant) vs. EAI (Mercator) Comparison.......................8 Figure 2.1.1-2 What Constitutes Intelligible Information..............................................................8 Figure 2.1.1-3 UDEF Objects and Properties.................................................................................9 Figure 2.1.1-4 Conveyor Application Screenshot.........................................................................10 Figure 2.1.2-1 PDML Conceptual Architecture...........................................................................11 Figure 2.1.3-1 EDE Conceptual Architecture...............................................................................12 Figure 2.1.3-2 DoD Enterprise Information Architecture............................................................13 Figure 2.2-1 Interoperability: “Observations from the ground up”.............................................14 Figure 2.2.1-1 Traditional EAI Complexities with Direct Mapping............................................15 Figure 2.2.1-2 EII Techniques Utilize an Abstract Semantic Layer.............................................16 Figure 2.2.1-3 EII Mapping versus EAI Mapping........................................................................17 Figure 2.2.2-1 Discovery of Application Context........................................................................19 Figure 2.2.3-1 EII Functional Overview – Part One.....................................................................21 Figure 2.2.3-2 EII Functional Overview – Part Two....................................................................21 Figure 3.1-1 Minimal Intrusion to Legacy System Environment.................................................24 Figure 3.2-1 DoD C4ISR Framework - One Architecture, Three Views.....................................27 Figure 3.2.1-1 EII and Operational View 2..................................................................................30 Figure A-1 Contextia Screenshots..................................................................................................2 iii
    • EXECUTIVE SUMMARY Note that this report is a “living document” and will be revised periodically on an “as needed” basis. This report introduces the concept of a Department of Defense (DoD) Enterprise Data Environment (EDE), and its relationship to semantics-based Enterprise Information Interoperability (EII). EII represents a breakthrough approach to enabling interoperability within and across enterprises. EII represents both a discipline (known as the Context-based Information Interoperability Methodology or CIIM) and a Commercial Off-The-Shelf (COTS) toolset (known as Contextia). The EII discipline and CIIM methodology focus on both the semantics of data and context for the data in reference to a neutral semantic ontology referred to as the Integration Schema. The CIIM represents the first comprehensive attempt (discipline, methodology, toolset) at providing a standards-based, industry best practice/methodology for achieving interoperability of enterprise information systems. The goal of the CIIM is to preserve the meaning of data and the pertinent contextual information in a rigorous, formalized, repeatable, and computable manner. The following two recent articles on this topic demonstrate the emerging fervor for this technology within the IT industry: 1. The Web Services Scandal, By Jeffrey Pollock, eAI Journal Cover Story, August, 2002 2. Doing It with Meaning, By John Edwards, CIO Magazine, August 15, 2002 The main objective of the report is to assess the strengths and weaknesses of the EII concept as it applies to DoD. The report provides some background information on the EDE concept by tracing EDE from its origin in the Continuous Acquisition and Life-cycle Support (CALS)/Contractor Integrated Technical Information Service (CITIS) initiatives and then to the Product Data Markup Language (PDML) initiative, and finally into the commercial/industry marketplace with the development of emerging COTS tools and methodologies for achieving interoperability. The vast and complex nature of DoD’s enterprise information environment (and its associated data) necessitates the practice of a careful and well thought out data strategy consistently over time to coordinate disparate efforts; to develop and to administer the DoD’s enterprise information systems. Currently, however, within DoD there are no formal techniques, structured methodologies, or corresponding toolsets in place for accomplishing the goal of enterprise interoperability in a repeatable and unambiguous manner. Without such a discipline for the consistent practice of interoperability, DoD’s attempts at integrating its enterprise will be fragmented and suboptimum. • Traditional Enterprise Application Integration (EAI) efforts throughout the DoD have been relatively successful within specific Communities Of Interest (COI) due to their limited scope and also because the context encountered and methodologies used to achieve integration are generally homogeneous. EAI has not been successful at the enterprise level, however, because the context and methodologies encountered when attempting to achieve integration across multiple COIs are heterogeneous. 1
    • EII represents a breakthrough approach that supplants traditional EAI. EII addresses both the logical and physical aspects of information. Note that the term physical refers to only the physical levels of information exchange that include areas such as data access, data transport, database bridges, data extraction, application connectivity, and legacy gateways. These solutions have not delivered effective results for enterprise-wide interoperability. EII works at the most important level of information, the logical level, which focuses on the semantics or meaning of data and the context in which the data is used. This EII assessment considers the following three criteria: the DoD’s information technology environment, Enterprise Architecture (EA) environment, and cultural environment. In performing this assessment, we feel that the EII discipline, Modulant CIIM methodology, and associated Contextia toolset, in concept, can significantly reduce the Total Cost of Operation (TCO) for a given family of systems as the size and complexity increases. The key areas for which we feel DoD could benefit by using this technology include the following: the DoD information technology environment, developing and maintaining DoD enterprise architectures, and the DoD cultural environment. There is, however, an initial upfront investment required before the downstream reduction in the TCO can be realized. We further feel that additional work is required to translate this conceptual belief into demonstrated reality along with accompanying metrics of ROI. Two such projects are in process as a follow-on to this initial assessment. This assessment also sheds light on how EII and the Modulant toolset offer the following key capabilities important to achieving DoD information interoperability: • Minimal intrusion into existing legacy systems, • Semantic preservation, • Portability, and • Scalability. In addition, we are of the opinion that, in applying the methodology, there may remain some potential for ambiguity of interpretation of contexts mapped through the Integration Schema. We feel that this issue can be addressed by establishing an interoperability maturity framework, based on the CIIM methodology. This mechanism would provide assurance that consistent and repeatable semantic mapping interpretations could be achieved across and among channel partners and interoperability architects. Some of the benefits of establishing an interoperability maturity framework include the following: • Practices can be repeated, • Best practices can be rapidly transferred across groups, • Variations in performing best practices are reduced, and • Practices are continuously improved to enhance capability (optimizing). It is essential that DoD embrace formalized techniques, tools, and methodologies like EII in order to better manage their IT assets and enable long term information interoperability. Interoperability by its very nature implies openness. We feel that in order for the EII concept to 2
    • reach its full potential the CIIM should be placed in the public domain via an accredited standards body. Lastly, two DoD implementations of this technology are planned as next steps resulting from this research, which include interoperability engineering projects for the Navy SH-60 Seahawk helicopter program and for Shipboard Integration of Logistics Systems (SILS) integration. 3
    • 1.0 INTRODUCTION The U.S. DoD owns and administers the largest and most complex Information Technology (IT) enterprise in the world. The DoD IT enterprise is comprised of a diverse array of systems and processes for a wide range of functional areas such as acquisition logistics, logistics support, enterprise resource planning, command and control, business intelligence, contractor/Government relationship management, etc. In addition, two salient characteristics distinguish the DoD Enterprise environment from other large scale, complex information environments: 1. The dynamic nature of the DoD Enterprise. The DoD Enterprise is in a constant state of flux as new systems incrementally replace the legacy. The immense size of the DoD Enterprise renders any attempt at a system-wide overhaul of obsolete equipment and applications futile; 2. The fragmented nature of ownership over the pieces that make up the whole of the DoD Enterprise. Due to the autonomous operation of various program managers and information system developers and their multiple chains of command, here is no single configuration manager over the entire enterprise. The system pieces contribute to the whole through a voluntary vice forced interoperability. These factors necessitate a careful and well thought out data strategy to achieve a coordinated effort in administering the DoD’s enterprise information systems. The DoD, through various reform initiatives, is continuously faced with the planning, development, deployment and integration of system modernization projects that adopt industry best practices into a vast legacy environment. Previous generation modernization efforts become the next generation’s legacy. It is important to emphasize system integration as a major factor contributing to the lifecycle costs associated with such undertakings - for example consider the following statistics: • 85% of system interfaces are hard coded [Gartner], • 85% of all IT project effort is in understanding database schema design and business rules [Forrester Research], • It has been estimated that 35% of the cost to implement ERP is in the Enterprise Application Integration (EAI) into existing and other applications. [Technology Forecast Report], • 30% of total IT budget is spent on building, maintaining, and supporting application integration [NeoCore Research], and • 80% of system integration projects fail due to interoperability concerns [Gartner]. This report introduces the concept of the DoD Enterprise Data Environment (EDE), which represents a conceptual framework that will potentially solve some of DoD’s key modernization and enterprise information system administration needs, especially in the areas of next generation application integration and ultimately Enterprise Information Interoperability (EII). The main objective of this report is to assess the strengths and weaknesses of the EII concept as it applies to DoD. This report provides some background information for the EDE concept by tracing the EDE concept from its origin in the CALS/CITIS initiatives and then to the Product Data Markup Language (PDML) initiative, and finally into the commercial/industry marketplace 4
    • with the development of emerging COTS tools and methodologies for achieving interoperability. This report is considered a “living document” and is the first of three contract deliverables that will be provided under the DoD/Logistics Architecture Modeling Program for DoD. The two deliverables to follow this report, will provide an assessment of key COTS solutions in the areas of product design, technology, architecture, functionality, usability, and training. 5
    • 2.0 OVERVIEW OF THE ENTERPRISE DATA ENVIRONMENT CONCEPT The EDE conceptual framework represents a novel approach to achieving enterprise integration that is based on preserving and/or capturing the semantics (or meaning) of data. Key points addressed in Section 2 include the following: • Historical overview of events leading up to the development of EDE, • Overview of the objectives and design goals of EDE, • Introduction to Enterprise Information Interoperability (EII), and • Overview of EII system architecture and technology. 2.1 Evolution of the Enterprise Data Environment Concept This section provides an overview of the term interoperability and describes why it is important for disparate systems to have the ability to interoperate. It also provides an overview of the events leading up to the development of the EDE concept, including, a historical overview for some of the key initiatives that have (or are attempting to) solved the problem of interoperability, which includes PDML, the CALS/CITIS, and then finally the EDE concept. The first generation attempt at solving the problem of interoperability has been Enterprise Application Integration (EAI). EAI is a business computing term for the plans, methods, and tools aimed at modernizing, consolidating, coordinating, and integrating the business system applications in, and across, the enterprise(s). The IT industry has traditionally approached system integration using point to point techniques for which the semantics of data exchanges were hardcoded into the software underlying each particular system integration function. This type of integration is typically referred to as EAI and is illustrated in Figure 2.1-1. Figure 2.1-1 Traditional EAI is Point to Point Hard-coded Mapping 6
    • EAI is oftentimes referred to as brittle and rigid because of the complexity and cost required in managing hard-coded interfaces. Traditional EAI may also be thought of, physically, as hub-and-spoke architecture, but logically it is still point-to-point. The physical aspects of EAI involve developing maps that address the syntax, structure, and transport of the data from the source to the target. EAI has been important because it has enabled enterprises that are migrating or augmenting a particular component of their enterprise, with a way to maintain linkages to the legacy applications and databases. However, in spite of the benefits of EAI, it is brittle and it becomes excessively costly as the size and complexity of a given family of systems to be integrated increases (as you will see in later sections of this report). The IT industry recently, however, has begun to place more of an emphasis on the actual meaning of the data (also know as semantics). Efforts like the World Wide Web Consortium’s (W3C) semantic Web concept, Resource Description Framework (RDF) specification, Adobe’s eXtensible Metadata Platform (XMP), and emerging specifications like ebXML’S Core Components, and the Organization for the Advancement of Structured Information Systems (OASIS) Universal Business Language (UBL) placed extensive emphasis on semantics. The semantic evolution will eventually provide the ability for computer systems to recognize automatically and unambiguously the meaning of data within particular contexts, which will enable an enterprise environment that is loosely-coupled, flexible, and interoperable. The term c-Commerce (as identified by Gartner, et. al.), which stands for collaborative commerce, is often times synonymous with this environment. The next section of this report describes information interoperability in detail. 2.1.1 The Need for Interoperability “…today’s enterprises cannot readily exchange the necessary data on a consistent, reliable, normal course of business basis.” [Automotive Industry Action Group] The need for interoperability arose when the early mainframe computer systems first needed to work together and exchange data. Traditionally, EAI attempts to resolve application system integration conflicts. System integration conflicts may be categorized as follows: • Syntactic - the rules, grammar, or order of elements in data, • Structural - the manner in which elements of data are organized or interrelated, and • Semantics - the meaning of data within a given context. It has been a common practice for data to be tightly bound to the applications for which it is being processed and/or from which it is being generated. Early attempts at application integration have successfully allowed disparate systems to “talk” to each other by typically focusing on resolving the syntactic and structural areas of conflict. However, these approaches have often times failed in allowing for systems to understand the business context and intent of the information exchanged in a scalable way. While traditional EAI applications like Mercator, et al, have been successful at resolving conflicts with respect to syntax and structure, it is the semantics area that represents the most challenging and important barrier in achieving enterprise interoperability (see comparison in the Figure 2.1.1-1). 7
    • Figure 2.1.1-1 Next Generation EAI (Modulant) vs. EAI (Mercator) Comparison Semantic information enables the data to be interpreted as intelligible information and may be summarized as shown in the following figure. Intelligible = Formatted Data + Semantics Information Syntax Structure Content Context Intent Figure 2.1.1-2 What Constitutes Intelligible Information Consider the following example: Employee _ service _ time =< Smith, Joe,4,16,2000 > + < Employee _ Name, Date _ of _ Employment > If the semantic information were removed from the above example, it would be difficult to determine what the date 4/16/2000 represented. Is it a birthday, a meeting date, etc.? The concept of achieving an integrated enterprise through the capture of data, semantics, and information sharing, contributed to the start of the Continuous Acquisition and Lifecycle Support (CALS) initiative. This initiative originated within the U.S. DoD in the late 1980s and early 1990s led to some of the first real attempts at developing a concept for achieving an Integrated Data Environment (IDE). CALS approaches included applying the commercial best practices and technologies, processes and standards for the development, management, exchange and use of business and technical information among Government and industrial enterprises. These were used to improve the flow of high-quality information within the DoD and between the DoD and its business partners, while reducing information management overhead costs. The CALS initiative embraced the ANSI X12 EDI standard as the solution to information exchange. The Contractor Integrated Technical Information Service (CITIS) also grew out of the CALS initiative. CITIS represented a robust arrangement between Government and contractors to allow Government to take advantage of the virtual nature of information: unlike physical objects, information can be accessed and used just as effectively whether it is on site or around the world, provided that security, integrity and delays in access and retrieval are acceptable. 8
    • Both the CALS initiative and the CITIS concept helped pave the way for well thought out approaches to solve the interoperability problem. In the mid 1990s, the CALS Industry Steering Group created the Universal Data Element Framework (UDEF) methodology in response to the need to solve the problem of interoperability. The UDEF methodology provides a semantics-based approach to integrate data from disparate data sources. This methodology was based on a very simple and extensible ontology, which was comprised of a set of primary objects and properties, and rules that may be used to generate unique codes and encapsulate the semantic information pertaining to data element(s) as shown in Figure 2.1.1-3. Uses ISO 11179 Naming Convention Object List Dataa Element Dat Element Property List Document Name Name Amount Angle Enterprise Area Place Code Object Term Object Term Program Property Term Coordinat e Product Process 0...n qualifiers ++ 0 ...n qualifiers 11or more reqd + 0..n qualifiers + Dat e Dimension or more reqd 1 reqd Property Ident ifier Human Object Class Object Class Mass Asset Name Law/Rule Quant it y Example Data Element Names Rat e Environment Temperat ure Document Abstract Text Text Enterprise Name Time Product Price Amount Volume Weight Product Scheduled Delivery Date Engineering Design Process Cost Amount Figure 2.1.1-3 UDEF Objects and Properties The UDEF provides a simple, standardized, consistent, compact, and object-oriented framework within which semantic units of information could be identified. An automated tool called “Conveyor” was developed by ManTech e-IC in 1997, which served as a prototype for the UDEF concept (see Figure 2.1.1-4). 9
    • Figure 2.1.1-4 Conveyor Application Screenshot Note however that the UDEF has not achieved great success in the commercial, federal, or DoD marketplace, in part, due to its simplicity and propensity for ambiguity. The next section describes an initiative that utilized the eXtensible Markup Language (XML) to achieve interoperability for product data. This initiative, which has achieved greater success, was known as the Product Data Markup Language (PDML). 2.1.2 Product Data Markup Language Product Data Markup Language (PDML) resulted from the need within DoD to share information among various disparate Computer-Aided Design (CAD) and PDM systems and DoD information repositories such as the Joint Engineering Drawing Management Information and Control System (JEDMICS). The vision for PDML was “to enable any authorized user to access product data for any item from any site without manual intervention or coordination by other personnel.” The PDML concept grew out of lessons learned from key product data standards efforts such as ISO 10303, the Standard for the Exchange of Product model data (STEP) and Military Standard (MIL-STD)-2549 (see glossary). PDML leveraged the work done in STEP, PDM Enablers, and MIL-STD-2549. The PDML concept, not unlike UDEF, utilized a neutral ontology as an intermediate step in the integration process. This neutral ontology, for PDML, is referred to as the Integration Schema – see Figure 2.1.2-1. 10
    • MIL STD 2549 DIP Transaction Sets <!-- =========================================== --> <!ELEMENT identifier(#PCDATA)> <!ATTLIST identifier datatype CDATA #FIXED "STRING"> <!-- =========================================== --> <!-- =========================================== --> <!ELEMENT identifier(#PCDATA)> <!ATTLIST <!ELEMENT part_relationship identifier datatype(part_relationship.other_relating_product_identifier, CDATA #FIXED "STRING"> Tech Order -4 <!-- =========================================== --> part_relationship.other_relating_.other_product_relationship <!-- =========================================== --> JEDMICS _name, <!ELEMENT identifier(#PCDATA)> identifier part_relationship.other_product_relationship_description, <!ATTLIST <!ELEMENT part_relationship part_relationship.related_product)> (part_relationship.other_relating_product_identifier, datatype CDATA #FIXED "STRING"> <!ATTLIST part_relationship id ID #IMPLIED> part_relationship.other_relating_.other_product_relationship Application <!-- =========================================== --> _name, Application <!ELEMENT part_relationship.other_product_relationship_description, <!ELEMENT part_relationship part_relationship.other_relating_product_identifier part_relationship.related_product)> (part_relationship.other_relating_product_identifier, <!ATTLIST (#PCDATA)> part_relationship <!ATTLIST id ID #IMPLIED> part_relationship.other_relating_.other_product_relationship _name, part_relationship.other_relating_product_identifier Transaction Set <!ELEMENT datatype CDATA #FIXED "STRING"> part_relationship.other_product_relationship_description, Transaction Set <!ELEMENT part_relationship.other_relating_product_identifier part_relationship.related_product)> <!ATTLIST (#PCDATA)>part_relationship.other_relating_product_design_version part_relationship id ID #IMPLIED> (#PCDATA)> <!ATTLIST <!ATTLIST part_relationship.other_relating_product_identifier <!ELEMENT part_relationship.other_relating_product_design_version datatype CDATA #FIXED "STRING"> <!ELEMENT datatype CDATA #FIXED "STRING"> part_relationship.other_relating_product_identifier <!-- =========================================== --> (#PCDATA)>part_relationship.other_relating_product_design_version (#PCDATA)><!ELEMENT part_relationship_ref EMPTY> <!ATTLIST <!-- =========================================== --> <!ELEMENT identifier(#PCDATA)> <!ATTLIST part_relationship_ref <!ATTLIST part_relationship.other_relating_product_identifier <!ATTLIST identifier refid IDREF #REQUIRED> part_relationship.other_relating_product_design_version datatype CDATA #FIXED "STRING"> <!ELEMENT identifier(#PCDATA)> datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> <!ATTLIST identifier <!ELEMENT datatype CDATA #FIXED "STRING"> part_relationship.other_relating_product_design_version <!-- =========================================== --> (#PCDATA)><!ELEMENT part_relationship_ref EMPTY> <!ATTLIST part_relationship_ref <!ATTLIST <!-- =========================================== --> <!ELEMENT part_relationship refid IDREF #REQUIRED> part_relationship.other_relating_product_design_version (part_relationship.other_relating_product_identifier, datatype CDATA #FIXED "STRING"> <!ELEMENT part_relationship (part_relationship.other_relating_product_identifier, part_relationship.other_relating_.other_product_relationship <!ELEMENT part_relationship_ref EMPTY> _name, part_relationship.other_relating_.other_product_relationship <!ATTLIST part_relationship_ref part_relationship.other_product_relationship_description, _name, refid IDREF #REQUIRED> part_relationship.related_product)> part_relationship.other_product_relationship_description, <!ATTLIST part_relationship part_relationship.related_product)> id ID #IMPLIED> <!ATTLIST part_relationship id ID #IMPLIED> <!ELEMENT part_relationship.other_relating_product_identifier <!ELEMENT (#PCDATA)> part_relationship.other_relating_product_identifier <!ATTLIST (#PCDATA)> part_relationship.other_relating_product_identifier <!ATTLIST datatype CDATA #FIXED "STRING"> part_relationship.other_relating_product_identifier <!ELEMENT datatype CDATA #FIXED "STRING"> part_relationship.other_relating_product_design_version <!ELEMENT (#PCDATA)> part_relationship.other_relating_product_design_version <!ATTLIST (#PCDATA)> part_relationship.other_relating_product_design_version <!ATTLIST datatype CDATA #FIXED "STRING"> part_relationship.other_relating_product_design_version datatype CDATA #FIXED "STRING"> <!ELEMENT part_relationship_ref EMPTY> <!ATTLIST part_relationship_ref <!ELEMENT part_relationship_ref EMPTY> refid IDREF #REQUIRED> <!ATTLIST part_relationship_ref refid IDREF #REQUIRED> Product Structure Integration Product Description Application Schema Document Application Transaction Set <!-- =========================================== --> Transaction Set <!ELEMENT direction (direction.direction_ratios)> <!ATTLIST direction <!-- =========================================== --> <!-- =========================================== --> id ID #IMPLIED> <!ELEMENT identifier(#PCDATA)> <!ELEMENT identifier(#PCDATA)> <!ELEMENT direction.direction_ratios (direction.direction_ratios.item+)> <!ATTLIST identifier <!ATTLIST identifier <!ATTLIST direction.direction_ratios datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> aggregatetype CDATA #FIXED "LIST"> <!ELEMENT direction.direction_ratios.item (#PCDATA)> <!-- =========================================== --> <!-- =========================================== --> <!ATTLIST direction.direction_ratios.item datatype CDATA #FIXED "REAL"> <!ELEMENT part_relationship <!ELEMENT part_relationship (part_relationship.other_relating_product_identifier, (part_relationship.other_relating_product_identifier, <!ELEMENT direction_ref EMPTY> <!ATTLIST direction_ref part_relationship.other_relating_.other_product_relationship part_relationship.other_relating_.other_product_relationship refid IDREF #REQUIRED> _name, _name, part_relationship.other_product_relationship_description, part_relationship.other_product_relationship_description, <!-- =========================================== --> part_relationship.related_product)> part_relationship.related_product)> <!ATTLIST part_relationship <!ATTLIST part_relationship <!ELEMENT document (document.id, document.name, document.description, id ID #IMPLIED> id ID #IMPLIED> document.kind, (document_with_class?, file?)?)> <!ATTLIST document <!ELEMENT <!ELEMENT id ID #IMPLIED> part_relationship.other_relating_product_identifier part_relationship.other_relating_product_identifier (#PCDATA)> (#PCDATA)> <!ELEMENT document.id (#PCDATA)> <!ATTLIST <!ATTLIST <!ATTLIST document.id part_relationship.other_relating_product_identifier part_relationship.other_relating_product_identifier datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> <!ELEMENT document.name (#PCDATA)> <!ELEMENT <!ELEMENT Mapping Mapping <!ATTLIST document.name part_relationship.other_relating_product_design_version part_relationship.other_relating_product_design_version datatype CDATA #FIXED "STRING"> (#PCDATA)> (#PCDATA)> <!ELEMENT document.description (#PCDATA)> <!ATTLIST <!ATTLIST <!ATTLIST document.description part_relationship.other_relating_product_design_version part_relationship.other_relating_product_design_version datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> datatype CDATA #FIXED "STRING"> Specifications Specifications <!ELEMENT document.kind (document_type_ref)> <!ELEMENT part_relationship_ref EMPTY> <!ELEMENT part_relationship_ref EMPTY> <!ELEMENT document_ref EMPTY> <!ATTLIST part_relationship_ref <!ATTLIST part_relationship_ref <!ATTLIST document_ref refid IDREF #REQUIRED> refid IDREF #REQUIRED> refid IDREF #REQUIRED> Figure 2.1.2-1 PDML Conceptual Architecture The Integration Schema is a neutral data model that serves as a semantic mediator between/among the Transaction Set vocabularies, which are expressed using XML Document Type Declarations (DTD) and XML document instances. The relationship between the Transaction Set and the Integration Schema is defined by a Mapping Specification. In order to leverage the XML syntax for the exchange of data, a conversion algorithm was defined for translation/conversion of an EXPRESS schema (ISO 10303 – Part 28) into an XML DTD. The specification of the content of a Transaction Set via an EXPRESS schema is therefore directly tied to the structure of the DTD used to exchange the data. This approach represents the first attempt at focusing on the meaning and context of data and the applications that process/generate the data. PDML, unlike many other XML DTD development efforts, was not developed in haste to meet a few short-term and brittle needs. Instead, PDML offered a flexible, stable, and reusable long-term solution in the form of an Integration Schema that could be applied to any number of user communities. PDML was sponsored by the Joint Electronic Commerce Program Office (JECPO) now the Defense Electronic Business Program Office (DEBPO). PDML was developed as part of the Product Data Interoperability (PDI) project; it was also supported by several federal Government agencies and commercial entities. Several pilot projects for the PDML were successfully completed and included Government systems such as JEDMICS and 11
    • Joint Continuous Acquisition and Life-cycle Support (JCALS), automation of various Department of Defense (DD), Defense Logistics Agency (DLA), and other forms, and the installation of an archive and Web site for the Defense Supply Centers (DSC). However, to make most aspects of the DoD interoperable in an efficient and expedient manner, a much broader solution is needed. This is where the EDE concept or Enterprise Data Environment becomes a viable solution. 2.1.3 The Enterprise Data Environment The Enterprise Data Environment (EDE) is a conceptual framework that is built on the lessons learned from the PDML initiative. EDE is an emerging concept that originated under the auspices of the Business Integration Team within the DoD Electronic Business Program Office. EDE combats the problem of interoperability by taking the semantics of data to an abstract level and then performing the transfer of data from the source to the target. EDE is the culmination of a data management discipline based on the capture, transformation, and reuse of legacy semantic information. The concept of a semantic hub is the central idea of the EDE - see Figure 2.1.3-1. Figure 2.1.3-1 EDE Conceptual Architecture 12
    • This hub is the “go-between” for the data source and data destination. The hub provides translation and transformation of data between otherwise non-interoperable systems as well as supporting the accompanying semantic data. It is important to recognize the complex nature of DoD’s diverse array of legacy (and planned) systems. The EDE concept is designed to accommodate DoD’s enterprise information system complexities (see Figure 2.1.3-2), like the interdependencies across business applications, etc. Figure 2.1.3-2 DoD Enterprise Information Architecture As you can see from Figure 2.1.3-2, an enterprise information architecture is composed of various individuals, systems, and applications that require careful interaction in order for the enterprise information system as a whole to function. In order to provide uninterrupted access to the information contained in these systems, it is important that the DoD system migration/modernization process be gradual and incremental. 13
    • The strategy for achieving interoperability throughout DoD’s Enterprise Architecture (EA) must include next generation EAI tools and techniques that are non-intrusive to DoD’s legacy environment. EDE has four main advantages over previous interoperability attempts: • Technological compatibility - With XML as its base, it will be fully compatible as technology grows and changes, • Incremental implementation - Each Government agency and/or its contractors can plug into the EDE system on their own schedule. There is no need for all interested parties to become interoperable at once, • Totality - EDE can address all elements to make an enterprise network functional, and • Supervision - The hub can maintain network order in a simple, yet loosely coupled manner. The first known company that has realized the potential value of implementing the EDE concept is Modulant Solutions (www.modulant.com). This company is developing next generation EAI products that focus on semantics and context for the exchange of information between disparate and heterogeneous applications. Note that Appendix A provides a more detailed description of Modulant Solutions and their related products. These next generation EAI developments are giving rise to a new discipline (and software toolset) within the IT industry that is termed Enterprise Information Interoperability (EII). EII is the phrase coined by Modulant Solutions to describe their concept of taking data to an intermediate abstract level and then performing the semantic mediation of data. Note that EII is a discipline (and supporting toolset) that supplants traditional EAI, whereas EDE is a conceptual framework for which EII is the underlying foundation. The next section of this report provides both a conceptual and functional explanation of the EII discipline. Furthermore, the next section explains why, as enterprise information environments grow bigger and more complex, there is a need for a more comprehensive approach (one that addresses semantics and context) for application integration - one which will ultimately address information interoperability. 2.2 Enterprise Information Interoperability Discipline Enterprise Information Interoperability (EII) is an emerging IT discipline and supporting toolset that has resulted from the concepts like PDML and EDE, as touched upon in the previous section. The purpose of this section is to provide a more in depth overview of EII by describing its design goals, comparing it to traditional EAI, and by providing a functional overview of EII. EII is necessitated by the lack of consistency among the tools, techniques, and methodologies across the broad scope of application systems from large enterprises all the way down to communities of interest as illustrated in the figure below. Figure 2.2-1 Interoperability: “Observations from the ground up” The objective of EII is true information exchange between disparate and heterogeneous applications based on semantics and context in a loosely-coupled, non-invasive manner. EII achieves interoperability by operating at the logical level of information exchange, which 14
    • represents the most important challenge to achieving interoperability. EII focuses on the meaning and context of data, and identifies and resolves conflicts that might affect communication between people, organizations, and applications that generate or process the information. EII makes information between user communities understandable in a meaningful, precise way, and recognizes and accommodates different contexts or ontologies. While PDML was designed to facilitate interoperability for data relating to specific products, the scope of EII extends beyond a single product and across enterprise boundaries. EII is has the potential of helping organizations better leverage their existing IT investments, dramatically reducing the time and cost to collaborate and exchange information, and significantly reducing the risk of implementation failure. In the next section, we compare and contrast EII with traditional EAI. 2.2.1 Enterprise Information Interoperability Discipline vs. Enterprise Application Integration Discipline Traditional EAI typically focuses on integrating a business process for a given community of interest (and not the enterprise in a broad sense of the word). This involves physically mapping data (by hand), through an oftentimes long and tedious process, by identifying a particular source data element and matching it (either directly or through complex business rules) with a corresponding target data element (or if a corresponding target element does not exist, then deriving it based on some embedded rules). The physical aspects of EAI mapping address the syntax, structure, and transport of the data from the source to the target. Physical EAI for a given family of systems typically occurs in a hub-and-spoke architecture. The problem with the traditional approach is that it assumes that all users will be using the same standards (syntax and semantics) for their data. Looking at the integration problem from a logical viewpoint rather than a physical viewpoint, a problem arises when a trading partner needs to communicate with multiple trading partners (or application systems) that each use disparate systems as shown in the Figure 2.2.1-1. Figure 2.2.1-1 Traditional EAI Complexities with Direct Mapping In the above scenario, for the sake of simplicity, the assumption is made that every system needs to communicate with every other system where there are n systems total. A system that needs to interoperate with every other system in a given community of interest must create (n-1) bi-directional mappings. This repeats for every partner/system creating n(n-1) total maps if information exchange is considered to be going both ways. For unidirectional information exchange, the number of maps is divided in half n(n- 1)/2 (this is illustrated in Figure 2.2.1-3 shown on the next page). For example, for 15 systems, the number of maps needed would be 15 x (15-1) / 2 = 15 x 14 / 2 = 15 x 7 = 105. This would be similar to a situation where one person is a supplier that receives purchase orders from many different companies. They all have their own preferred method for e-Commerce, but they all map to a model provided by the supplier. If any of those companies wishes to trade with others in this exchange, they must also create a map between their method of trade and the target company’s method. An additional 15
    • problem arises with traditional EAI approaches when disparate EAI tools, that do not interoperate, are employed. The EII approach, in contrast to the traditional EAI approach, is unique because it enriches the data through a value-added step in the mapping / integration process, similar to the approach used with PDML. This value-added step is where the semantics and context of the data being processed is formally captured. Figure 2.2.1-2, illustrates what a typical EII integration scenario might look like for a given community of interest. Figure 2.2.1-2 EII Techniques Utilize an Abstract Semantic Layer In this scenario, the abstract semantic layer provides the ontology that functions as the neutral pivot point between all disparate systems that need to interoperate. In comparing traditional EAI to next generation EAI (i.e., EII), Figure 2.2.1-3 illustrates that as the number of disparate systems needing to interoperate increases, the number of maps or integrations that are required increases geometrically when using traditional EAI techniques. 16
    • Required Number of Integrations per Application System: EII vs. EAI 1400 1200 Modulant Mappings Traditional Mappings Required Number of Integrations 1000 800 600 400 200 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 Number of Systems / Applications Figure 2.2.1-3 EII Mapping versus EAI Mapping Notice that when using EII techniques like that espoused by Modulant Solutions, the increase in required integrations is only a linear factor. Consider that, for example, 105 point to point maps are required to integrate just 15 disparate application systems. It should be obvious that after the number of disparate systems reaches a certain critical mass, there will be a significant return on investment by embracing an EII, rather than an EAI, approach. In summary, EAI is a term used in the IT industry that represents a large market rich with commercial tools but lacking in discipline and methodology. In contrast, EII is a discipline first and secondly it is a supporting toolset that is based on rigorous methodology. Properly utilizing EII should result in a compelling reduction in the Total Cost of Operations (TCO) to achieve and maintain interoperability within a given community of interest. 2.2.2 Enterprise Information Interoperability Discipline, Objectives, and Design Goals The main purpose of EII is to achieve information interoperability across the enterprise, while preserving legacy knowledge. The term “enterprise” with respect to EII, refers to the entire enterprise, which is different from the meaning of “enterprise” with respect to EAI. The meaning of “Enterprise” in reference to EAI typically refers to a community of interest, which is only a subset of the enterprise, which leads to the potential problem of having to integrate disparate EAI solutions within the enterprise as a whole. This logical enterprise integration problem just mentioned is complicated by the incompatibility of EAI platforms, one to another. In other words, federation of multiple EAIs into an enterprise wide integration solution remains an unanswered challenge. 17
    • Four challenges in advancing EAI from the community (system) to the enterprise level through federation of EAI platforms include: 1. Increased number of integrations required at the enterprise level, 2. Incompatible contexts at the enterprise level escalate complexity in the mapping process, 3. Incompatibility of EAI platforms, and 4. Tendency for an enterprise to be in a constant state of change vice brittleness of the mapping methodology. An essential prerequisite that needs to be established before undertaking an interoperability effort is to ensure that all stakeholders involved realize that interoperability is a challenge and that it should not be viewed as being trivial. EII addresses both the logical and physical aspects of information. Note that the term physical refers to only the physical levels of information exchange that include areas such as data access, data transport, database bridges, data extraction, application connectivity, and legacy gateways. These solutions have not delivered effective results for interoperability. EII works at the most important level of information, the logical level, which focuses on the semantics or meaning of data and the context in which the data is used. The six characteristics of EII, as set forth by Modulant Solutions EII training course, are as follows: 1. Independent of specific physical solutions, 2. Focuses on integrity of information exchange, 3. Accommodates different perspectives on data, 4. Performs semantic mediation using abstract models, 5. Maps application information to abstract models, and 6. Based on a robust theory of digital information. Modulant Solutions has developed a methodology known as CIIM or Context-based Information Interoperability Methodology to implement the EII concept. The CIIM represents the first known attempt at providing a standards-based, industry best practice/methodology for achieving interoperability of enterprise information systems. The goal of the CIIM is to preserve the meaning of data and the pertinent contextual information in a rigorous, formalized, repeatable, and computable manner. Context is the knowledge about the information that gives meaning to data and how that data is created and used. The CIIM is comprised of four major methods (provided in the order in which they must be performed), each of which address semantics and context, and these methods are as follows: • Context Discovery, • Context Formalization, • Context Accommodation, and • Information Interoperability Specification. The first of the four major CIIM methods, Context Discovery, deals primarily with gathering, understanding, and analyzing the semantics and context of application data. This analysis includes the extent of the data to be communicated, the identification of application context elements, and the description of the structure of the data to be communicated. This process 18
    • necessitates the use of Subject Matter Experts (SME) having extensive knowledge of both the context of the data and the applications that generate and/or process the data. The following example of the Context Discovery process shows how various aspects of context contribute to the meaning of data. Figure 2.2.2-1 Discovery of Application Context In the Figure 2.2.2-1 note that some potential sources of conflict are present that require further investigation of the intended meaning of the data. For example, in the ID field, the usage intent of the data is unknown. Similarly, the data in the DOB (Date of Birth) field, the format of the data is unknown. The CIIM decomposes context in the following manner: • Data definition: A statement of the meaning of a data element, • Data aggregation: A statement about a collection of data elements for particular subject of interest, and data relationships, • Data usage: A statement of the purpose the data elements serve, o Human activity, o Business process, o Computer application, and • Data constraint: A statement of knowledge regarding valid data element values. Without knowledge of the context in which data is created and the context in which data is intended to be used, the meaning of data is incomplete, vague, or unknown. In order to communicate in a manner that is concise and unambiguous, the sharing of data must be supported by an infrastructure that recognizes the contexts in which data is created and used, makes knowledge about these contexts explicit, and uses this knowledge to mediate 19
    • interoperability. Solutions that support communication of meaningful, contextually precise information are referred to as enablers of logical communication among people and organizations; these complement the physical communication of bits, bytes, messages, and files among computer systems and applications. Notwithstanding the Context Discovery method, the other three CIIM methods are embodied within the Modulant toolset. These methods are discussed in more detail in the next section. A brief definition of the remaining CIIM methods is presented below: • Context Formalization - The representation of application information as an Application Transaction Set (ATS) definition; ATS data elements, information units, and data element groups, • Context Accommodation - The process of mapping to an Integration schema (ACM – also known as a neutral Integration Schema, or simply as the Integration Schema) in a common form that preserves the semantics of the data and allows differing perspectives on information to exist and be accommodated, and • Information Interoperability Specifications - The transformations applied to application data values, Integration Schema data population/extraction rules, data conversion, and default values. In summary, the guiding principles of the CIIM include: • Effective information interoperability depends on knowledge of the context, • Context can be described by characterizing data definition, data aggregation, data usage, and data constraints, • Context can be discovered from data values, data patterns, data descriptions, activities that create or use data, and functions that process or present data, • Context can be represented in a computable form, • Application information, including context, can be represented using an Integration Schema (ACM), • Interrelated application contexts can be accommodated using common abstractions, and • Declarative representation of instructions for information- preserving transformations between application data and an Integration Schema enable Integration Schema- mediated interoperability among applications. The EII discipline being assessed in this report leverages the CIIM methodology, which provides a rigorous and robust (formalized and computable) approach to engineering interoperability within enterprise information system environments. The next section provides an overview of the system architecture and technology for the only known COTS toolset available for implementing and administering EII. 2.2.3 Enterprise Information Interoperability (EII) Functional Overview In Section 2 thus far, we have traced some of the key evolutionary steps leading up to the emergence of a COTS toolset and recommended IT best practice and methodology for achieving interoperability. We have also in this section, provided an accurate account of why interoperability is important especially for complex sets of interrelated but disparate systems. In 20
    • the previous subsection, we provided an example of how to perform context discovery through the analysis of the semantics and context of application data. The objective of this section is to provide a more in depth look into the EII discipline from both a system architecture and technology perspective, for the Modulant Solutions (www.modulant.com) software toolset. The Modulant Solutions toolset performs the Context Formalization, Context Accommodation, and finally Information Interoperability functions as referenced within the CIIM. Recall that the CIIM provides a unique and robust (formalized and computable) approach to capturing context and semantics of applications and data that is generated or processed by applications. The Modulant Solutions toolset allows system integrators to incorporate the CIIM in the form of “formalized context maps.” These maps capture the data semantics and context of both the data and the applications that generate and/or process the data. Figures 2.2.3-1 and -2 show a functional overview of the EII scenario workflow that follows the CIIM process, as implemented by the Modulant Solutions toolset. Figure 2.2.3-1 EII Functional Overview – Part One Figure 2.2.3-2 EII Functional Overview – Part Two This illustration shows a generic semantic-based interoperability scenario between a source system and a target system. Assuming that the Context Discovery method of the CIIM has already taken place manually by a Subject Matter Expert (SME), the next logical step in this process is to perform the Context Formalization and Context Accommodation phases of the CIIM. This involves describing both source and target data in terms of an Application Transaction Set (ATS), which includes the ATS definition, ATS data elements, information units, and data element groups. The ATS consists of the original source or target data, metadata or schema describing the structure and relationships among the data, and contextual descriptions providing a frame of reference for the data. Note that an example of an ATS is provided in the glossary - see entry for ATS. In general, the schema describes the source and target data from their system perspectives, while the context describes the source and target data from the corresponding business domain perspectives. Once the source and target data have been described, it can then be assigned some meaning and context. The next step in this process is the Context Accommodation phase. The Context Accommodation comprises Mapping (ACM) the ATS’s to an Integration schema in a common form that preserves the semantics of the data and allows differing perspectives on information to exist and to be accommodated. Recall that the ACM is a neutral Integration Schema that Modulant developed as an ontology. This provides the mechanism to formally capture and relate the semantics and context of source and target data in a coherent, reliable, and repeatable manner. Note that the Integration Schema is a key component of the Interoperability Server. The result of mapping an ATS schema to the Integration Schema is called a mapping specification. 21
    • The fourth method of the CIIM, which is known as Information Interoperability Specifications, is the process of executing the transformation of data from the source system, enriching the data through relating the source data to the Integration Schema ontology (and applying any rules in the process), and then finally relating this information to the target system in the appropriate form so that it is processible by the target system. Having provided a detailed overview of the EDE concept, EII, the Modulant toolset and their relationship, Section 3 of this report provides an assessment of the EII discipline as it applies to the DoD’s enterprise information system environment. 22
    • 3.0 EII DOD APPLICABILITY ASSESSMENT This section provides an assessment of the applicability of the EII concept to the U.S. DoD. Three major aspects of the DoD are considered for the purposes of this assessment, which include EII’s applicability to the following areas: • Information Technology environment, • Enterprise Architecture (EA) environment, and • Cultural environment. 3.1 DoD Information Technology Environment The current DoD IT environment can best be characterized as having a vast and complex array of heterogeneous legacy information systems, many of which are vertically stovepiped systems. Working with obsolete legacy systems in the current DoD is common. Vast amounts of vital data are often times locked into legacy application systems running on midrange/mainframe legacy systems. Much of the current application integration has been done through hard coding or using traditional EAI tools such as Mercator, or APIs, etc. Given the existing environment, it is important that a standardized approach for achieving information interoperability among legacy systems as well as new systems be embraced across DoD. Currently, however, within DoD there are no formal techniques, tools, or methodologies in place for accomplishing the goal of interoperability in a repeatable and unambiguous manner. The purpose of this section is to provide an assessment of the potential applicability of the EII concept to the current and planned DoD IT environment. As we have seen in the previous section, the goal for the planned DoD IT environment is to strive for increased interoperability and connectivity across existing and emerging information systems. In this section, we assess the degree to which the EII and Modulant toolset will potentially support the interoperability goals for DoD’s IT environment. In order to achieve these interoperability goals for DoD, we feel the following characteristics are a necessity in engineering such an effort: • Minimal intrusion into existing legacy systems, • Semantic preservation, • Portability, • Scalability, and • Reduced Total Cost of Operations (TCO). Minimal intrusion: Because legacy systems are prevalent within DoD, and furthermore because important data is often locked into these legacy applications systems, it is important to have a non-intrusive way to access this data. In accessing the legacy application data it is important to have an efficient way to “externalize” the data in the legacy systems such that the data is intelligible to a diverse set of processing applications and/or human users. One of the principles of the EII and Modulant toolset is to be non-invasive, i.e., have minimal intrusion into existing legacy systems as illustrated in Figure 3.1-1, which represents the left half of the functional diagram shown in Figure 2.2.3-1. 23
    • Figure 3.1-1 Minimal Intrusion to Legacy System Environment In accordance with the EII and CIIM, and by using the Modulant toolset, there is minimal to no intrusion to the legacy application system. Referring to the above figure, physical transformation involves transporting the data either natively or through a connector application into the Modulant toolset. Accessing the data in the legacy application occurs either via native tool support or indirectly thru an application connector, or through custom coded solutions. The core of engineering interoperability is the logical transformation, which involves following the CIIM procedures as discussed in Section 2.2.3. As shown in the above diagram, an Application Transaction Set (ATS) or sets are created to represent the native form of the data, which prevents having to interfere with the legacy application system. Recall the discussion in Section 2.2.3 regarding the functional overview of the end-to-end semantic mapping and transformation process. The data then must be either directly or indirectly made available (externalized) for the semantic transformation process. Upon completing the logical and physical transformations, a unified interpretation of the data is achieved through the relationship to the neutral Integration Schema, which enables enterprise applications to work together in an interoperable fashion. Semantic preservation: Another important consideration for DoD is the semantic preservation of legacy data. Semantic preservation is important because of the long lifecycles of many legacy systems. It is important to point out that although standards, technologies, and applications change over time, it is important to ensure that the information required supporting DoD business processes could carry on and/or adapt through the lifecycle. We feel that the EII discipline and the Modulant toolset provide an innovative way (by transforming externalized 24
    • legacy data into the expressive conceptual model) to “future proof” the information and data required for DoD throughout the lifecycle of the system or business process. Portability: DoD’s current IT environment has a wide array of applications running on a variety of hardware platforms. In using tools to engineer the interoperability in this environment, it is therefore important to have a requisite degree of portability offered by the tools. The Modulant toolkit is based upon the Java platform, therefore it can be deployed into legacy systems environments with great portability and minimal overhead. Java code is designed to be compiled once, and then be deployed on any number of platforms without the need to edit source code. This allows a compiled Java program (also called Java bytecode) to be executed on this machine without recoding or recompilation. A Java Virtual Machine (JVM) is all that is required to execute this byte code; this is the concept behind portability and Sun Microsystem’s motto: “Write once, run anywhere.” The nature of applications written in the Java programming language is that any program can be executed on any operating system on any hardware platform that has a JVM available to execute the code. Therefore, a Java application will require only that a JVM be available on the platform. Mainframe operating systems, such as IBM’s OS/390 support JVMs. This provides maximum portability while providing minimal intrusion into the existing system. Scalability: Scalability is an important consideration because as the size and complexity of the interoperability environment increase, they must remain manageable. The EII/Modulant approach is scalable, especially in comparison to traditional EAI approaches, because (see Section 2.2.1) it manages complexity through abstraction (see Figure 2.2.1-2). In comparison to traditional approaches, the EII/Modulant approach results in more efficient management of interfaces and lower development and maintenance costs as the interoperability scenarios become larger and more complex (see Figure 2.2.1-3). Reduced Total Cost Operations (TCO): Implementing EII requires an initial upfront investment that does not yield an immediate Return On Investment (ROI) until the family of systems for an interoperability environment reaches a certain size and complexity (see Figure 2.2.1-3). The EII approach reduces TCO as follows: • Simplifies the process of developing and maintaining interfaces - simplifies the management of interface complexities through abstraction. o Provides unambiguous and repeatable processes, which results in semantically precise information (less room for error). o Minimizes the need for extra “Add-ons” that must be purchased and implemented to satisfy interoperability requirements for areas such as ERP (OAG, IDOC, BAPI, etc.), etc. • Reduction in cycle times to acquire and process data, • Preserves the meaning of legacy data, and • Reduces redundant data through reuse. In summary, by embracing the Modulant EII discipline to facilitate interoperability within DoD’s current IT environment, we feel the following potential benefits may be realized: 25
    • • Improved integration of legacy, migration, and new systems by having formal techniques to represent the precise semantics and context of “data” that can be deployed in an incremental and modular fashion, • Improved management in the development and maintenance of system interfaces and reduces duplicative data, and improved information sharing and interoperability, • “Future proof” the information and data required for DoD business processes throughout system lifecycles, and • Reduced TCO for developing, deploying, and managing interoperability. Because the DoD is in the process of modernizing and augmenting their existing IT environment, there is an opportunity to infuse these efforts with the EII. Although there is a learning curve and an initial investment in resources, the EII should enable stakeholders to better manage their IT capital investments throughout their lifecycle. The EII approach should offset these initial costs by providing a lower TCO not only for certain communities of interest, but also for larger cross sections of the DoD enterprise. 3.2 Applicability to DoD Enterprise Architecture Environment The purpose of this section is to assess the potential applicability of the EII to the emerging area of DoD enterprise architectures. It is worth mentioning that because of the Clinger-Cohen Act (the combination of both the Information Technology Management Reform Act and the Federal Acquisition Reform Act enacted by Congress and the President in 1996), DoD leadership is required to establish processes to select, manage, and control their IT investments in a more effective manner. The passage of this act has resulted, in part, in mandating the use of Enterprise Architectures (EA) for systems development, modernization, and acquisition efforts within DoD as well as across the federal Government. An EA establishes an agency-wide roadmap to achieve an agency’s mission through optimal performance of its core business processes within an efficient IT environment. Typically, agency Chief Information Officers (CIO) promote the development of EAs. EAs typically address the following items: • Business Processes, • Information Flows and Relationships, • Applications, • Data Descriptions, and • Technology Infrastructure. 26
    • The Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework is the authoritative reference for developing and presenting DoD EAs for both baseline architectures (describes the As-Is environment) as well as target architectures (describes the To-Be environment). C4ISR provides the rules, guidance, and product descriptions that are necessary to ensure a common denominator for understanding, comparing, and integrating DoD EAs. The goal of the C4ISR is to provide a guideline for developing EAs that will effectively contribute to building interoperable and cost-effective DoD systems. Note that the C4ISR divides the EA into three views: operational, systems, and technical (see Figure 3.2-1). Operational View Identifies Warfighter Relationships and Information Needs Pr form irem l da In equ oc a e ir e ion no R es qu at er si n ts Re orm Int ng Ex en tio nt m ge nf nd an ch Ba upp bil an f I g a d an S apa , si ort itie es Le ge s C c ch ls o in ts ee to in ve Te abi s Ex ve ess dl en N s ls m es, ion ch lity Le roc of no a ire iti iat P lo nd oc gy N Re Ac ss qu tiv s, A an ode ms ew N ste Sy d Specific Capabilities Identified Systems to Satisfy Information- Technical Exchange Levels and Other View Operational Requirements View Relates Capabilities and Prescribes Standards Characteristics to Operational Requirements Technical Criteria Governing and Conventions Interoperable Implementation/ Procurement of the Selected System Capabilities Figure 3.2-1 DoD C4ISR Framework - One Architecture, Three Views In Sections 3.2.1 and 3.2.2, we will point out how and where we feel that EII, through its capacity to capture context and semantics of enterprise architecture data, is applicable to enabling certain goals within both the baseline and target architectures for the DoD. 3.2.1 DoD Baseline Architecture (As-Is) As the DoD implements and matures along the guidelines of the Enterprise Architecture (EA) and C4ISR pathway, it must have “the capability to collect, process, and disseminate an uninterrupted flow of information while exploiting or denying an adversary’s ability to do the same.” The EII concept should be an excellent discipline to help the DoD along its journey from the “As-Is” state to the desired “To-Be” state. 27
    • The purpose of this section is to provide an assessment of the potential applicability of the EII concept to DoD “As-Is” enterprise architectures. This assessment focuses on the parts of the C4ISR where we feel the EII concept has the potential to satisfy interoperability requirements. Current Status: Within the DoD, IT modernization efforts are underway, but the current “As-Is” state of the DoD Infrastructure is fragmented and duplicative. Functional organizations and services deliver solutions through “vertical stovepipes” in the following enterprise communities: • C3I - Command, Control, Communications, Intelligence, • Acquisition and Logistics, and • Other communities of interest. According to a recent survey conducted by the Government Accounting Office (GAO) (see report GAO-02-6) based on a maturity framework for Enterprise Architecture (EA) management, only five agencies out of 116 agencies surveyed reported satisfactory practices that the GAO believe are needed to effectively manage EA activities or sufficiently mature enough to support IT investment decision making. In fact, not all departments/agencies have developed an Enterprise Architecture. Additionally there is no DoD-wide accepted approach for achieving information interoperability, which is sorely needed in meeting the challenges of the 21st century and to successfully manage our national defense. This leaves a lot of room for growth, which means there is still opportunity for developing more robust practices concerning information characterization. EII and the Role of C4ISR: C4ISR lays the foundation for developing architectures that can be used to help structure an organizations’ “As-Is” information technology processes. The development of an “As-Is” architecture enables stakeholders to better manage their IT capital investments throughout their lifecycle. It is very important that the DoD quantify its current or As-Is Architecture so that it can have a springboard for reaching their desired or “To-Be” state. A fully developed “As-Is” architecture provides many benefits to the organization such as: • Concise picture of an organizations current information flow • A first step to developing a “To-Be” State • Brings to light the number of systems, connections, and nodes used by an organization • Shows all regulations, standards, etc… that govern the activities of the organization • Highlights areas where information authority or security may need to be improved • Provides common guidance to ensure that multiple DoD architectures developed by organizations around the world can readily be compared, analyzed, and integrated • Furnishes DoD with the basis for satisfying new legislative requirements regarding the management of information technology by providing the means or “audit trail” for relating measures of system and technology performance to mission and functional effectiveness 28
    • As the DoD develops and implements the operational architectures of C4ISR, one of the issues they must deal with is how to consistently and unambiguously denote the context and semantics of various enterprise data. Of the products delineated by the Operational View (OV) of C4ISR there are three essential products. They are: • High-Level Operational Concept Graphic (OV-1), • Operational Node Connectivity Description (OV-2), and • Operational Information Exchange Matrix (OV-3). The High-Level Operational Concept Graphic (OV-1) is the most general and flexible of the architecture products. It is simply a graphic depiction of human communication and is intended for high-level decision makers. The Operational Information Exchange Matrix (OV-3) focuses on the specific aspects of the information flow. Who exchanges what information with whom, why the information is necessary, and in what manner. However, the brunt of EII’s applicability falls into OV-2. EII and Operational View 2: Figure 3.2.1-1 for the Operational Node Connectivity Description (OV-2), depicts operational nodes and elements, the needlines between them, and the characteristics of the information exchanged. An arrow represents each information exchange and is annotated to describe the following: • Information characteristics, • Volume requirements, • Security or Classification Level, • Timeliness, and • Requirements for information system interoperability. 29
    • Figure 3.2.1-1 EII and Operational View 2 EII - C4ISR Interoperability Level 4: This last requirement of OV-2, information system interoperability, is where the EII toolset has great potential to play an important role. When an organization sets out to determine the requirements it has for information system interoperability, it will have to determine the Levels of Information Systems Interoperability (LISI) needed. Section 4.3.3 of the C4ISR gives the guidelines for determining the level of interoperability for a given information system. Level 4 or the Enterprise level is the highest level of this guideline. Level 4 systems are defined as “capable of operating using a distributed global information space across multiple domains. Multiple users can access and interact with complex data simultaneously. Data and applications are fully independent and can be distributed throughout this space to support information fusion. Advanced forms of collaboration (the virtual office concept) are possible. Data has common interpretation regardless of form, and applies across the entire enterprise. The need for redundant, functionally equivalent applications is diminished since applications can be shared as data at this level. Decision-making takes place in the context of, and is facilitated by, enterprise-wide information found in the global information space.” The EII Concept will allow an organization to share information across disparate and heterogeneous information sources. Using the Integration Schema as the focal point, information can remain stored in various locations, databases, etc… without having the need for a central repository. Users will be able to access data from multiple locations using disparate systems. Legacy information will remain intact in its current state and will be accessible to any authorized user from any system. The EII concept has the potential to provide information interoperability that is independent of implementations issues such as technology, business processes, etc. 30
    • EII enables interoperability among source and target information stores regardless of the nature of the information store, i.e., legacy, proprietary, etc. When an organization is tasked with an objective that requires information from non-interoperable sources, EII provides information to the organization through one access portal, the Integration Schema. Rather than having to use different systems, databases, or data tables, the Neutral Integration Schema will allow access to all these information sources without the hassle of trying to access many information sources through many different methods. Incremental Implementation: The EII concept, as it relates to “As-Is” and transitional architectures, can be incremented on a timetable that is fitting to the needs of a given community of interest or organization. Organizations will not have to go through a “Big Bang” to incorporate EII. The EII concept can be implemented for one information process and/or one application system at a time. It does not interfere with any other information exchange process currently in place. This is true even if the process is part of a larger process. EII can provide interoperability first on a small scale and then grow as the experience and comfort level of the organization grows. Summary: We feel that the Modulant’s EII concept can be applied in an effective manner to augment and complement the “As-Is” enterprise architecture development, and maintenance, for the DoD. The EII concept can provide the following benefits to help address the information interoperability needs of the DoD. • Modulant EII can improve an organizations information sharing and interoperability by providing a rigorous and robust (formalized and computable) approach to engineering interoperability. • Improve the management of developing and maintaining system interfaces, and reduce duplicative data. • The amount of interoperability is up to the individual Department/Agency based proportionally on the scale of EII implementation. o The Clinger-Cohen act served as a driver, the C4ISR provides the foundation, the EII provides the discipline and supporting toolset, and the CIIM provides the robust methodology. • The EII approach should enable stakeholders to better manage their IT capital investments throughout their lifecycle. Because the As-Is EA’s have room for maturing, there is an opportunity to infuse these efforts with the EII concept. 31
    • 3.2.2 DoD Target Architecture (To-Be) IT modernization efforts are underway within the DoD, however the efforts to develop enterprise target architectures remain fragmented and in some cases undeveloped. Recall the GAO report GAO-02-6 mentioned in the previous section that was critical of DoD’s lack of enterprise architecture development and management. The purpose of this section is to provide an assessment of the potential applicability of the EII concept to DoD Target or To-Be EAs. This assessment focuses on the relevant parts of the DoD To-Be architecture from the perspectives of the C4ISR and the Global Information Grid (GIG) where information interoperability and information sharing are important goals. We will show where we feel the EII concept has the potential to satisfy interoperability requirements, information sharing, and the reduction in redundant data. The To-Be architecture describes the desired capability and structure of the enterprise business processes, information needs, and infrastructure for the enterprise three to five years (2005 - 2007) in the future. DoD decision makers use the combination of the baseline (As-Is) and target (To-Be) architectures as a foundation to plan their incremental migration. Migration systems include systems, databases, applications, or other components that may be introduced and used temporarily to sustain operations between the current systems and the establishment of target architecture components. In 1995, the Deputy Secretary of Defense directed that a DoD-wide effort be undertaken to develop a basis from which the community could work collectively to evolve and mature architecture development concepts as direction from DoD with appropriate policy directives and guidance instructions. The C4ISR Architecture Framework was the result of this effort and serves as a blueprint for enterprise architectural guidance. As previously mentioned, the C4ISR is comprised of three major views (system, technical, and operational) that logically combine to describe the overall architecture views. The operational architecture description provides detail regarding the information-exchange, interoperability, and performance parameters required to support a particular mission and task. Within this operational view lie potential problems and issues that continually confront cross-organizational architecture analyses. With the growing emphasis on Joint operations and interoperability of C4ISR systems, a common, DoD-wide approach is needed for organizing and portraying the structure of architecture information. The GIG Architecture, developed in accordance with the standards defined in the C4ISR is the globally interconnected, end-to-end set of information capabilities, associated processes, and personnel for collecting, processing, storing, disseminating and managing information on demand to war-fighters, policy makers, and support personnel. The GIG computing and communications architecture will be the foundation for enterprise computing. The implementation of the GIG is an effort to integrate the DoD’s Information Management program requirements with the Joint Staff’s evolving Joint Venture 2010/2020 Information Superiority concepts and serves as a strategic plan and roadmap in realizing more efficient and effective mission support. The GIG supports all DoD, National Security, and related Intelligence Community missions and functions - strategic, operational, tactical, and business in war and in peace. It provides capabilities from all operating locations (bases, posts, camps, stations, facilities, mobile platforms, and deployed sites) and in addition, the GIG interfaces to coalition, allied, and non-DoD users and systems. The GIG will provide a seamless integrated capability 32
    • to support all functional missions and reach from the home base to the front line. The DoD Guidance Policy for the GIG states: “GIG systems shall be interoperable to the extent necessary to the support of operational information exchange requirements.” In an effort to satisfy this policy, the GIG is to be used to achieve cross-functional integration and to implement a shared data environment to ensure semantic interoperability. With the various approaches available to bridge the interoperability gap such as the adoption of common systems or standards, harmonization of business processes, and single data sources such as ERP systems and data warehouses, these solutions prove to be brittle and tightly coupled thus inhibiting enterprise agility. Additionally, information semantics are typically only addressed with customized code, context is usually assumed within a development approach, and ongoing maintenance is very costly. Both the C4ISR and GIG architectures have identified the need for interoperability across the enterprise but To-Be EAs of the future must break out of the stovepipe environment in being narrowly focused and non-interoperable. EII provides for improved integration of legacy, migration, and new systems by having formal techniques in place to represent the precise semantics and context of data that can be deployed in an incremental and modular fashion. Improved information sharing and interoperability can add value to the management of developing and maintaining system interfaces and processes, reduce duplicative data, and cut costs. Because the To-Be EAs have room for maturing, there is an opportunity to infuse these emerging efforts with the precepts of EII. Embracing EII in To-Be EAs should enable stakeholders to better manage their IT capital investments throughout their lifecycle. EII should enable autonomous systems to exchange semantically-rich information, perform semantic mediation using abstract domain models (ontologies), and provide a non-invasive, loosely-coupled solution that remains separate from applications and data sources. Although standards, technologies, and applications change over time, it is important to ensure that the information required in support of DoD business processes can carry on and adapt through these changes. In short, EII complements existing enterprise systems and initiatives and enables them to work together and provides a way to “future proof” the information and data required for DoD. 33
    • 3.3 DoD Cultural Environment Interoperability is a problem in the current DoD environment; however, it is a problem that, for various reasons, has gone unrecognized. The current DoD community is divided among those who understand the importance of interoperability and those who continue to focus on data standardization. Three primary factors contributing to this atmosphere include the following: 1. Multiple uncoordinated standardization efforts, 2. Lack of “buy in” for coordinated metadata support, and 3. Brittle and unresponsive change mechanisms. Such syndromes as "not invented here," "it's just too hard," and "what's in it for me?" have hindered DoD interoperability strategies. Although the DoD is in the process of establishing COI’s for various families of systems and community managers, the current culture still includes those who do not embrace the principle that interoperability must occur at the information level rather than the data level (this is a throw back to the days of Defense Data Dictionary System (DDDS), etc.). Because the EII and CIIM provide a discipline and methodology, we feel that they could serve as a catalyst to help DoD leaders overcome the barriers of organizational culture and differing priorities. In order for EII and CIIM to be instituted within DoD, some core competency in this area must be developed. This will require training and education, experience and practice, cooperative planning and development, and development of skilled EII liaisons at all levels in DoD IT planning and management. As the demand for EII grows, perhaps a CIIM certification program could be put into place. This program could serve to improve the maturity of the interoperability processes in terms of an evolutionary path from ad hoc, chaotic processes to mature and disciplined interoperability processes, in a similar fashion to how the Capability Maturity Model (CMM) improved software. CIIM certification should focus on identifying key process areas and the exemplary practices comprising a disciplined interoperability process. Some of the benefits of establishing an interoperability maturity framework include the following: • Practices can be repeated, • Best practices can be rapidly transferred across groups, • Variations in performing best practices are reduced, and • Practices are continuously improved to enhance capability (optimizing). 34
    • 4.0 CONCLUSIONS AND RECOMMENDATIONS In summary, the DoD has an interoperability problem or some might refer to it as a dilemma. Many legacy systems are poorly integrated and in many cases the underlying application integration logic is obscure. In many cases, systems are integrated using traditional EAI tools and techniques. In other cases, systems that should interoperate do not because of the cost and complexity involved. The current environment has no formal methodology for approaching the interoperability problem. There is a lack of focus on the semantics and context of data sources/targets, and interfaces are created by hard-coding the business logic. Because the semantics and context of the data are forever lost in the hard-coded interfaces, existing integrations are brittle and unscalable. The EII discipline and CIIM methodology focus on both the semantics of data and context for the data. Recall that “context” is the knowledge about the information that gives meaning to data and how that data is created and used. The CIIM represents the first known attempt at providing a standards-based, industry best practice/methodology for achieving interoperability of enterprise information systems. The goal of the CIIM is to preserve the meaning of data and the pertinent contextual information in a rigorous, formalized, and computable manner. It should be noted, however, that finding real Subject Matter Experts (SME) having extensive knowledge of both the context of the data and the applications that generate and/or process the data, is oftentimes difficult because of their importance to the organization or because they no longer are available. Utilizing the SMEs is a critical success factor in engineering interoperability, which should not be taken lightly. It is also important to note that, with this technology, an initial investment is required as well as a certain level of “buy in” from the various stakeholders involved in the interoperability effort, before a significant downstream ROI can be realized. In performing this assessment, we feel that the Modulant EII discipline, CIIM methodology, and associated Contextia toolset, in concept, can significantly reduce the TCO for a given family of systems as the size and complexity increases. The key areas for which we feel DoD could benefit by using this technology include the following: • DoD information technology environment, • Developing and maintaining DoD enterprise architectures, and • DoD cultural environment. In looking at the DoD information technology environment, this assessment sheds light on how the EII and Modulant toolset offers the following key capabilities important to achieving DoD information interoperability: • Minimal intrusion into existing legacy systems, • Semantic preservation, • Portability, and • Scalability. 35
    • In looking at the DoD enterprise architecture area, this assessment shows how the EII and Modulant toolset could, in accordance with the C4ISR and GIG, improve the quality of enterprise architecture information products. Lastly, this assessment sheds light on the need for standardized tools, techniques, and methodologies for enabling interoperability within the DoD. Although this assessment focuses on the conceptual aspects of the EII and Modulant toolset, the training, product design, and usability aspects will be assessed in the subsequent deliverables following this report. In closing, we have provided some recommendations resulting from this assessment. Interoperability by its very nature implies openness. We feel that in order for the EII concept to reach its full potential the CIIM should be placed in the public domain via an accredited standards body. In concept, there is some potential for ambiguity of interpretations of the Integration Schema mappings. We therefore feel that by establishing an interoperability maturity framework, there would be more assurance that consistent and repeatable semantic mapping interpretations could be achieved across and among channel partners and interoperability architects. Furthermore, the two deliverables to follow this report, will provide an assessment of key COTS interoperability tools in the areas of product design, technology, architecture, functionality, usability, and training. Lastly, two DoD implementations of this technology are planned as next steps resulting from this research, which include interoperability engineering projects for the Navy SH-60 Seahawk helicopter program and for Shipboard Integration of Logistics Systems (SILS) integration. 36
    • REFERENCES 1. GAO Report 02-327, ELECTRONIC GOVERNMENT Challenges to Effective Adoption of the Extensible Markup Language, April 2002 2. William C. Burkett - Product Data Integration Technologies (PDIT) 3. Concept of Operations – Enterprise Data Environment 4. EII Concepts – Modulant Solutions, Inc. 5. CIIM Training Course - Modulant Solutions, Inc. 6. Preliminary EDI (X12 to United Nations (UN)/Electronic Data Interchange For Administration Commerce and Transport [EDIFACT]) Mapping Concept Paper for the DoD CALS IDE Project, June 16, 1997 7. e-Business 2.0, Ravi Kalakota Book, Figure 13-6 8. Preliminary DoD Data Strategy Concept of Operations March 2001, Submitted by ManTech Advanced Systems International, Inc. Enterprise Integration Center (e-IC) 9. DoD Directorate for Interoperability Website: http://www.itsi.disa.mil/groups.html 10. DoD GIG Website: http://www.dla.mil/j-6/gnie/ 11. DoD CIO Website: http://www.c3i.osd.mil/org/cio/#dod 12. C4ISR Architecture Framework Document 13. The Global Information Grid (GIG) 14. The Web Services Scandal, By Jeffrey Pollock, eAI Journal Cover Story, August 2002 15. Doing It with Meaning, By John Edwards, CIO Magazine, August 15, 2002 37
    • GLOSSARY ACM - Integration schema - A data model that uses the EXPRESS language to capture and relate data semantics and context, created or used by many different applications. This type of model is used by Modulant to achieve EII. ADMSP - Army Data Management and Standards Program AFMC - Air Force Materiel Command ATS - Application Transaction Sets - A set of data related to things, events, processes, relationships, or collections that are the subject of a modeling effort. This set includes the structure and instances of the data. An example for the JEDMICS database would be: <!ELEMENT jedmics (drawing_number, cage_code, sheet, frame, revision, high_dwg, drawing_size, contl_code, revision_date, number_frames, file_type, file_size, security, rights, foreign, nuclear, safety, dist, physical_location, ODMS_date, in_date, last_access_date, last_change_date, last_change_user_id, file_type_source_flavor, file_type_dest_flavor, file_type_format, extension, num_acc_docs)> As-Is (Architecture) - The current enterprise architecture of an agency or department as mentioned in C4ISR. BAPI - Business Application Programming Interfaces - Used to access the SAP databases from within SAP or from an external development platform that supports the Remote Function Call protocol. CAD - Computer-Aided Design CALS - Continuous Acquisition and Life-cycle Support C3I - Command, Control, Communications, Intelligence C4I - Command, Control, Communications, Computers, and Intelligence C4ISP - Command, Control, Communications, Computers, and Intelligence Support Plan C4ISR - Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance CCITT - Consultative Committee for International Telephone and Telegraph 38
    • c-Commerce - Collaborative Commerce has given rise to eBusiness collaboration and Knowledge Sharing (ecKnowledge), a solution that can push/pull data in/out of a wide range of application interfaces. CIIM - Context-based Information Interoperability Methodology CITIS - Contractor Integrated Technical Information Service CMM - Capability Maturity Model COI - Community Of Interest - A group of individuals with a common interest, such as finance, purchasing, etc. Context Map - Specifies how an application’s information, including the context, is represented. COTS - Commercial Off-The-Shelf CRD - Capstone Requirements Document DD - Department of Defense form DDDS - Defense Data Dictionary System DEBPO - Defense Electronic Business Program Office DII - Defense Information Infrastructure DISA - Defense Information Systems Agency DLA - Defense Logistics Agency DMI - Data Management and Interoperability DoD - Department of Defense DTD - Document Type Definition - A type of XML file that provides the rules used to describe the structure or syntax of an XML document. Data Element - A basic unit of data having a meaning and distinct units and values. (Derived from 8320.1). A uniquely named and defined component of a data definition; a data “cell” into which data items (actual values) can be placed; the lowest level of physical representation of data. (Derived from IEEE 610.5) 39
    • EA - Enterprise Architecture EAI - Enterprise Application Integration - The unrestricted sharing of data and business processes throughout the networked applications or data sources in an organization. This allows enterprises to streamline business processes and to be interconnected. ecKnowledge - eBusiness collaboration and Knowledge sharing EDE - An XML-based data management discipline, information framework, supporting toolset and common set of services (semantic hub) that enables integration of the acquisition and logistics enterprise with minimal intrusion into the legacy systems. EDIFACT - Electronic Data Interchange For Administration Commerce and Transport. EDR - Environmental Data Registry EII - Enterprise Information Interoperability - The ability for enterprises to exchange information between disparate and heterogeneous applications based on semantics and context in a loosely-coupled, non-invasive manner. ERP - Enterprise Resource Planning-A business integration management system that uses multi-function application software packages designed to serve and support multiple business functions such as planning, manufacturing, sales, marketing, accounts receivable/payable, ledgers, warehousing, transportation, and human resources. ERP II - The ERP foundation extended to an open-architecture, vertical-specific functionality to position the enterprise in the supply and value chain. EXPRESS - A modeling language used to describe constraints and data structure, defined in ISO specification 10303. GCCS - Global Command and Control System GCSS - Global Combat Support System IDE - Integrated Data Environment IDOC - An interface that consists of the definition and processing logic within a data structure. It is used to exchange business data between two different systems. This interface is modeled after EDI transaction sets and provides the basis for EDI interfaces to R/3. IEC - International Electrotechnical Commission IRDS - Information Resource Dictionary System IRM - Information Resource Management 40
    • ITA - Information Technology Architecture JCALS - Joint Continuous Acquisition and Life-cycle Support JECPO - Joint Electronic Commerce Program Office JEDMICS - Joint Engineering Data Management Information and Control System is the DoD’s standard repository system for storing and retrieving engineering drawings used by the United States Armed Services maintenance depots and DLA sites. This is a Commercial Off-The-Shelf (COTS) intensive system that can operate in a Windows, UNIX, or DOS environment. Data integrity, indexing, remote output, input, storage, and output are the functions that make up the JEDMICS architecture. LANs, WANs, and a Central Processor tie these functions together. Drawings are input and output from the system in C4 format (a tiled, Consultative Committee for International Telephone and Telegraph (CCITT) Group IV bitmap encoding format service). JEDMICS recognizes input data from hard copy scanning, 1840A/B tapes, optical platters, Compact Disks (CD), and 8mm magnetic tape and can store and manage more than 570 file types including 2D/3D vector drawings. Output data is produced on microfilm aperture cards, paper reproductions, CDs, and 8mm tapes. The JEDMICS C4 format is a CALS Raster format identified in the Military Performance standard (MIL-PRF)-28002 as CALS Raster Type 4. These repositories can store 190 million engineering drawings and 500,000 technical publications. JTA-A - Joint Technical Architecture - Army JVM - Java Virtual Machine KPP - Key Performance Parameter Legacy System - A system that has been in existence for some time. This term often refers to mainframe or ERP applications. LISI - Levels of Information Systems Interoperability Logical Mapping - Focuses on the semantics or meaning of data and the context in which the data is used. Mapping Specification - The result of mapping fields, relationships, and structures in an ATS schema to the corresponding fields, relationships, and structures in an ACM. MIL-PRF – Military Performance standard MIL-STD-2549 - Department of Defense Interface Standard - Establishes a standard interface for the delivery of, or access to, electronic configuration management data. 41
    • MNS - Mission Need Statement Neutral Integration Schema - Allows an organization to access different systems, databases, or data tables through one access portal using EII. OAG - The Open Applications Group is a non-profit consortium focusing on best practices and process based XML content for eBusiness and Application Integration. It is the largest publisher of XML based content for business software interoperability in the world. Open Applications Group, Inc. members have over six years of extensive experience in building this industry consensus based framework for business software application interoperability and have developed a repeatable process for quickly developing high quality business content and XML representations of that content. OASIS - Organization for the Advancement of Structured Information Systems Ontology - The structure of a system or system model. ORD - Operational Requirements Document OV - Operational View PDIT - Product Data Integration Technologies PDM - Product Data Management - An information system used to manage product development from beginning to end. This includes all necessary data such as plans, geometric models, CAD drawings, images, NC programs as well as all related project data, notes, and documents needed for inception to manufacturing to maintenance. PDM Enabler - A specification comprised of twelve Interface Definition Language modules, developed by the Object Management Group, designed to support interoperability between two PDM systems or a PDM system and a client system. PDML - Product Data Markup Language Physical Mapping - Focuses on syntax, structure, and transport of the data. RDF - Resource Description Framework ROI - Return On Investment Schema - An abstract representation of the structure of a set of data and their relationships. Semantics - The term used to differentiate the meaning of a command from its format. 42
    • Semantic Hub - The focal point for the translation/transformation of diverse data from a source system to destination system. In addition, the site for the posting of and access to the semantic information that underlies enterprise data. Semantic Mediation - A discipline for information interoperability that addresses the integration of similar but not identical data elements. SHADE - SHAred Data Environment SILS - Shipboard Integration of Logistics Systems SME – Subject Matter Expert STEP - (STandard for the Exchange of Products Model Data), is an ISO standard (10303) for product modeling. It is designed to provide a vendor-neutral and computer readable definition of a product throughout its lifecycle. Structure Mapping - The connections between the target element and the mapping target of the root element. Syntax - The rules governing which statements and combinations of statements in a programming language will be acceptable to a compiler for that language. TCO - Total Cost of Operation TDQM - Total Data Quality Management To-Be (Architecture) - The desired capability and structure of the Department of Defense business processes, information needs, and infrastructure three to five years in the future. UBL - Universal Business Language UN - United Nations UDEF - Universal Data Element Framework W3C - World Wide Web Consortium XML - EXtensible Markup Language - A specification developed by the World Wide Web Consortium (W3C), used for defining data elements on a Web page and business-to-business documents. XML uses HTML (Hyper Text Markup Language) tag structures. HTML only defines how the elements are displayed; XML defines what the elements contain. This allows the designer to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. With XML being able to provide a universal method for identifying data and supporting 43
    • business-to-business transactions, it is expected to become the dominant format for Internet and Web-based Electronic Data Interchange (EDI). XMI - XML Metadata Interchange XMP - eXtensible Metadata Platform 44
    • APPENDIX A: RELATED COTS TOOL VENDOR – MODULANT SOLUTIONS
    • Modulant (www.modulant.com) was founded in 2000 and merged with PDIT. Modulant operates PDIT as a wholly owned professional services subsidiary. Together, they have approximately 140 employees and are headquarted in San Francisco, California. Modulant’s underlying philosophy, which sets them apart from other A2A efforts, is that they focus upon the data and not the hardware or the application. By preserving the semantics of the data as it transfers among the various systems, the Contextia platform enables organizations to develop an EDE, thus, preserving legacy data files and their associated worth. This allows companies and/or the Government to interoperate in an efficient manner. This platform also allows for incremental implementation, which helps organizations evoke this EDE at their own pace. Modulant™ Contextia™ Interoperability Server The Modulant Contextia Interoperability Server performs run-time data transformations between source and target applications. The transformation engine uses predefined mapping specifications to populate source data sets into the Integration schema (ACM), and subsequently extract the data into the native form of the target system. It goes beyond the simple transformation of data at the syntactic or format level, achieving interoperability among systems by transforming information at the contextual/semantic level. The Modulant Contextia Interoperability Server also includes the Analyst Tool, which is a GUI tool that serves as the “central control” to the Interoperability Server and other Modulant tools. It enables a user to launch transformation runs, validate the consistency of the mapping specifications and their dependencies on the ACM, import/export XML documents, and configure databases for an integration run, among other capabilities. The Interoperability Server can also be invoked programmatically by other applications via the Modulant Lifecycle Manager API. Modulant™ Contextia™ Mapping Tool The Modulant Contextia Mapping Tool enables a user to map and model the meaning, relationships, context, and structures of data elements in source and target applications to the Integration schema (ACM). The Modulant Contextia Interoperability Server then uses the mapping specifications and the ACM to transform data from source to target at run-time, while preserving the semantics of the data. The Mapping Tool accepts a variety of input formats for mapping and modeling, including XML schemas, native schemas, database tables, and delimited files, etc. Unlike other approaches that create brittle couplings between each application or data source, the Modulant Contextia Mapping Tool maps information from applications or data sources to the ACM. The neutral characteristics of the ACM allow applications to evolve independently without affecting their ability to interoperate with one another. Thus, current implementation projects complement past integration efforts and do not limit future integration plans. A sample screenshot of the tool is provided in Figure A-1. A-1
    • Figure A-1 Contextia Screenshots For more information on Modulant products, visit www.modulant.com/products. A-2
    • APPENDIX B: RELATED DOD POLICIES, STANDARDS, AND DIRECTIVES
    • DoD “As-Is” Structure: Terms, Policies, Standards, and Directives AFI 33-110 “Air Force Policy Establishes roles and responsibilities throughout the Air on Data Element Force to facilitate development and implementation of the Standardization” DoD standardized data elements. Air Force Materiel Command Supports the DoD Air Force programs as defined in the DoD Data Administration Policy Directive 8320.1, Air Force Instruction 33-110, and related (AFMC DA), March 27, 1997 guidance. AR25-1, Section 4.6, “The Establishes information about the set of data standards, Army Data Management and business rules, and data models required to govern the Standards Program (ADMSP) definition, production, storage, ownership, and replication of data used in the Army. This implements DoD Directive 8320.1 and the information standards portion of the Joint Technical Architecture - Army (JTA-A). Chairman of the Joint Chiefs of An instruction that establishes policies and procedures for the Staff Instruction 6212.01B, J-6 interoperability requirements certification of Mission “Interoperability and Need Statements (MNS), Capstone Requirements Documents Supportability of National (CRD), and Operational Requirements Documents (ORD), Security Systems, and details a methodology to develop Interoperability Key Information Technology Performance Parameters (KPP), establishes policies and Systems,” May 8, 2000 procedures for the J-6 supportability certification of Command, Control, Communications, Computers, and Intelligence (C4I) Support Plans (C4ISP), establishes policies and procedures for the J-6 interoperability system validation. DA PAM 25, Chapter 3 Provides guidance and procedures to support information interoperability initiatives based on Enterprise Architectures and supports development of an integrated data management environment for information interoperability initiatives. Data Element Standardization Describes how to implement standard data elements for DoD Primer software and computer systems. This primer details the processes and procedures associated with implementing, reusing, and gaining approval for DoD Standard Data Elements. DoD has approved 11,070 data standards; the primer contains information to provide you access to this tremendous resource. Defense Data Dictionary The repository used to support the DoD Data Administration System (DDDS), Release 4.0 in developing and managing standard data per Directive 8320.1. This system provides a mechanism for defining metadata, cross-referencing and consistency checking, and supports the standardization of data element names, definitions, and relationships. Defense Information Systems Agency responsible for executing the policy and procedures Agency (DISA) and making available DoD Data Standards to the community. Administers procedures and techniques in planning, data engineering, and data quality, review, approval, and maintenance of data standards for the DoD. B-1
    • Defense Information Systems A component of the Joint Information Engineering Agency (DISA) Center for Organization that provides the necessary policy and Standards procedures, guidance and tools to assist in the development, implementation, and enforcement of standardized data. Department of the Navy (DON) A plan that addresses data management and interoperability Data Management and as it applies to databases and data exchange within and across Interoperability (DMI) Strategic the warfighting and business systems. Plan, U.S. Navy (November 2000) DoD Directive 4630.8 Implements the policy in DoD Directive 4630.5, “Procedures for Compatibility, "Compatibility, Interoperability, and Integration of Interoperability, and Integration Command, Control, Communications, and Intelligence (C3I) of Command, Control, Systems," November 12, 1992, and assigns responsibilities, Communications, and and prescribes procedures to achieve compatibility and Intelligence (C3I) Systems,” interoperability of a consolidated, DoD-wide, global C3I November 18, 1992 infrastructure. DoD Directive 8000.1, Defense Establishes policy and assigns responsibilities under Information Management (IM), Directive 5137.1 for implementation, execution, and October 27, 1992 oversight for the Defense IM Program. DoD Directive 8320.1 Establishes policies for DoD data administration. Authorizes the establishment of and assigns responsibilities for DoD data administration to plan, manage, and regulate data within the DoD. Authorizes the publication of DoD 8320.1-M, "DoD Data Administration Procedures." Authorizes the establishment of a DoD Information Resource Dictionary System (IRDS). Reissues DoD Directive 5000.11, "Data Elements and Data Codes Standardization Program." DoD 8320.1-M, March 1994 A manual issued under the authority of DoD Directive 8320.1 that provides “Data Administration Procedures.” DoD 8320.1-M-1, April 2, 1998 A manual issued under the authority of DoD Directive 8320.1 that describes “DoD Data Element Standardization Procedures.” DoD Guidelines on Data Describes the Total Data Quality Management Program, Quality Management defines a core set of data quality requirements, and sample metrics to measure conformance to those requirements, and provides guidance for the establishment and implementation of a data quality project. The document describes the four major Total Data Quality Management Activities: Define, Measure, Analyze, and Improve. The guidelines document also presents a data quality improvement case study. DoD Standard Data Elements A clear and concise data element standardization that describes and exchanges information, improves communications, and eliminates redundant data across the battlefield and functional areas. B-2
    • DoD Total Data Quality A process to support database migration, promote the use of Management (TDQM) data standards, and improvement of databases in conformance to business rules. DoD Web Site Administration Delineates the policy and assigns responsibility related to and Policies, establishing, operating, and maintaining unclassified Web November 25, 1998 sites and other related services. It supersedes the “Guidelines for Establishing and Maintaining a Publicly Accessible Department of Defense Web Information Service.” DoD XML Registry Constitutes guidance in the generation and use of XML among the COE (Common Operating Environment) of the (DII) and is the authoritative source for registered XML data and metadata components. Environmental Data Registry A comprehensive, authoritative reference for information (EDR) about the definition, source, and users of environmental data. This registry catalogs EPA’s data collections and helps locate environmental information of interest. Global Command and Control One system of the GIG Architecture. It is the nation’s System (GCCS) premier system that incorporates the force planning and readiness assessment applications required by battlefield commanders to effectively plan and execute military operations. Global Combat Support System One of four operational concepts developed in response to (GCSS) Joint Vision 2010 as part of the GIG Architecture. This concept provides the joint warfighter with a single, end-to-end capability to manage and monitor units, personnel, and equipment from mobilization through deployment, employment, sustainment, redeployment, and demobilization. Global Information Grid (GIG) A globally interconnected, interoperable, and secure system of systems for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. The GIG includes all owned and leased communications and computing systems and services, software (including applications), data, security services and other associated services needed to achieve Information Superiority. ISO/International Information technology - Specification and standardization of Electrotechnical Commission data elements - Part 1: Framework for the specification and (IEC) 11179-1:1999 standardization of data elements. ISO/IEC 11179-2:2000 Information technology - Specification and standardization of data elements - Part 2: Classification for data elements. ISO/IEC 11179-3:1994 Information technology - Specification and standardization of data elements - Part 3: Classification for data elements. ISO/IEC 11179-4:1995 Information technology - Specification and standardization of data elements - Part 4: Rules and guidelines for the formulation of data definitions. B-3
    • ISO/IEC 11179-5:1995 Information technology - Specification and standardization of data elements - Part 5: Naming and identification principles for data elements. ISO/IEC 11179-6:1997 Information technology - Specification and standardization of data elements - Part 6: Registration of data elements. OMB Circular A-130, Establishes Information Resource Management (IRM) “Management of Federal Policies for IRM Planning and Management of Information Information Resources” Systems and Technology, assigns IRM responsibilities, and provides for oversight/monitoring of IRM implementation and practices. OMB Memorandum M97-16, Transmits guidance to federal agencies on the development Information Technology and implementation of Information Technology Architectures, June 18, 1997 Architectures (ITA). Shared Data Environment Provides an overview of the concepts, requirements, (SHADE) CAPSTONE implementation policy, architectural components, and data Document Version 1.0, sharing approaches, processes and procedures embodied in July 11, 1996 the Defense Information Infrastructure (DII) Shared Data Environment (SHADE). B-4
    • DoD “To-Be” Structure: Derived Requirements for DoD Data Strategy Service Requirement Design or Implementation Strategy Improve Metadata Standardization and • Education/Training - promotion of Metadata Quality Registry sites and data exchange • Define quality metrics Adhere to ISO/IEC 11179 and W3 metadata Resource Description Framework (RDF) for standards expressing machine readable metadata about resources. Provide a link between system design and • Reverse Engineering Product to Derive Data system “as-built” architectures and data Models from an “As-Built” Implementation (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) • Compare “As-Designed” Model to “As-Built” Model • Add policy memorandum requiring delivery of “as-built” data models to designated, authorized repository. • Define an accountability method. Identify Data Management Change Develop DoD Enterprise Modeling for Support Requirements to support the achievement of of Joint Vision 2020 using COTS products Joint Vision 2010 or 2020 (Gensym’s G2/Rethink and e-Score) Identify strategic approach and Develop End-to-End Models of the Global interoperability requirements for Global Information Grid and its major components Information Grid, C4ISR, logistics support using COTS products (Gensym’s G2/Rethink and other functional domains, not just C2 and e-Score) systems The question is, how to “Interface” to share • Develop End-to-End Models of the Global data among systems. Focus should be on Information Grid and its major components Interface requirements. using COTS products (Gensym’s Provide a mapping between data and system G2/Rethink and e-Score) to identify required interfaces for both “as-designed and interfaces “as-built.” • Reverse Engineering Product to Derive Data Models from an “As-Built” Implementation (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) • Compare “As-Designed” Model to “As-Built” Model Add authoritative source for data and meta Modify Metadata Registry Database Design to data of the Metadata Registries that includes provide authoritative source attributes the DDDS Establish or revise DoD policy that • Develop/revise existing DoD policy to link recognizes data management/administration data administration and data management as as a required prerequisite for information part of information superiority strategy. superiority B-5
    • Service Requirement Design or Implementation Strategy There is a need to determine interoperability Develop End-to-End Models of the Global basis before systems are built, not after Information Grid and its major components using COTS products (Gensym’s G2/Rethink and e-Score) to identify required interfaces Adhere to emerging industry metadata • XML Schema standards • XML Metadata Interchange (XMI) One stop shopping to shareable, reusable Design/develop a database to hold metadata metadata entities. Write (maintain) once, Read (share) many Identify who will be authorized to post approved metadata – DoD Functional Data Administrators or authorized representatives? Begin to develop metadata conventions to Span DoD XML Namespaces optimize reuse Design and implement a synchronized Design and implement Oracle PL/SQL Triggers process to manage reference tables based on business rules. Identify a data management/administration • Reverse Engineering Product to Derive Data process to keep up with “as-built” and Models from an “As-Built” Implementation “as-maintained” IT systems (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) • Compare “As-Designed” Model to “As-Built” Model There is still a tremendous interest in legacy • DoD Enterprise Modeling using COTS systems and how to work the interoperability products (Gensym’s G2/Rethink and issue top down and bottom up e-Score) simultaneously • Reverse Engineering Product to Derive Data Models from an Implementation (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) Legacy warfighter and business systems were DoD Enterprise Modeling using COTS products designed separately yet they need to be (Gensym’s G2/Rethink and e-Score) interoperable. Review interoperability requirements and system interfaces for these legacy systems and identify data entities that need to be standardized for reuse in new or enhanced IT systems. Revise current data administration policies to Create Policy and Guidance Memorandum provide a process for technology refreshment requiring technology refreshment using a including XML and other technologies Business Case Model B-6
    • Service Requirement Design or Implementation Strategy What can XML do for the user and how does • Develop a white paper for the COE it fit into the COE? community - but also should address how it might support the Global Information Grid • Develop an XML policy document and guidelines document for the generation of XML artifacts (e.g., DTDs or schemas) that link these artifacts with metadata requirements of a specific domain or interoperability requirements Develop a data model for the GCCS in the Reverse Engineering Product to Derive Data Global Information Grid Context Models from an Implementation (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) Bring data into substance (implementation) Reverse Engineering Product to Derive Data Models from an Implementation (e.g., Computer Associates Erwin, or Sybase’s PowerDesigner) Update DDDS naming conventions Establish Naming Conventions and define a process for update Separate environments: Private Intranet for Separate servers for private/public access Working entities and “Public” Internet for Data Sharing with authorized users Help move (or replicate) metadata between • XMI - based metadata interchange Systems (e.g., metadata repositories and/or • Application Programming Interface (API) XML repositories) Produce metadata in different, required Browser Accessible (as much as possible) for output formats interactive access XML Schema for bulk transfers? Add appropriate security to metadata objects • Digital signatures for approved objects • User Identification and Password • Smart Card Support? • Anti-virus Capability for Server(s) Archival of DoD metadata assets Backup to CD, tape, or disk media Load/unload metadata and XML data into XML Interchange Technologies: different DISA, military service, DLA and • SOAP Weapon System Program systems • XML Schema • XML Metadata Interchange (XMI) for of UML models and MOF meta models Maintain rich metadata content for Program Browse and Search Capability of metadata and Corporation Information Management entities by organization, domain, or functional demands area B-7