LIST OF FIGURES.doc

682 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
682
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

LIST OF FIGURES.doc

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. • 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

×