Pick up an Information Technology (IT) strategic plan from virtually any organization today and you will read statements like "our goal is to migrate from the current multitude of separated systems toward a single, integrated, system capable of ... we will provide users with a secure network environment allowing them to access shared data and applications, regardless of location ...the right information anytime, any place!" Interoperability and information assurance are major objectives of IT, and it is enterprise architecture that will provide the analytical methodology that will let us 1) explicitly visualize the obstacles along our path, and 2) make the right decisions to effectively attain our mission capability objectives.
Consider This Situation
In reference to the development of a Command, Control, Communications, Computer and Intelligence Support Plan (C4ISP), required for the acquisition milestone decisions of a major new weapon system, a Program Manager (PM) asked, "How can I develop the Information Exchange Requirements (IER) for my system (as specified for the C4ISP), if I don't know who I will be exchanging information with?" This doesn't seem possible. A multi-billion dollar defense program, and we don't know who's talking with whom? After subsequent discussion though, what the PM was validating was really the "case" for enterprise architecture.
With enough resources and fortitude anyone can roll up their sleeves and get on with the business of collecting the data that comprises IERs for systems existing today. It's pretty much an exercise in due diligence as described in the Department of Defense (DoD) Architecture Framework. You're a program manager and you know how your particular system exchanges information within the context of the System-of-Systems (SoS) or Family-of-Systems (FoS) in which you currently operate. Documenting these IERs in C4ISP format may be a bit time consuming, but you can collaborate with other affected PMs and gather the information with whatever tool you're comfortable with and be done with it. What you have then is a static snapshot of your system's IERs (and hopefully, what is needed to satisfy interoperability and information assurance requirements).
Interfaces Under Development
But now let's think about a major DoD weapon system that won't be delivered for seven years or more. Consider directing this PM with the challenge: "Document all of your IERs." OK — they know how their system is going to work seven years from now because the program is "spec'ed-out", and it's under configuration management. Cost, schedule, performance changes as the program moves through the Programming, Planning, and Budgeting System (PPBS)? No problem. The PM is right on top of it. But what about the other programs that are similarly evolving over time and with which this system plans to exchange information? Our PM has no control over these, yet they too are subject to the perturbations of the PPBS. How will programmatic changes within these future SoS/FoS be collectively assessed for their unforeseen impact on IERs and the resultant mission capability that these major acquisition are expected to provide?
Clearly, we have a case for enterprise architecture and specifically, robust tools to support its development and analysis. From the example presented here, we have a requirement to document existing and evolving systems in a centralized repository that authorized managers can use to ensure that the interoperability and information assurance thresholds established early on in the development of warfighting capability are, at a minimum, maintained when the systems comprising that capability go into operation years later.
The DoD Architecture Framework
The DoD Architecture Framework provides a construct for fully documenting the details of an IT system, as well as its inter-relationship to a SoS and FoS. The framework is broken down into three main views: operational view, systems view and the technical view.
- Describes tasks and activities and the information exchanges required.
- Independent of technology.
- Describes systems and the connections and communications among them.
- Existing or planned technologies.
- Defines a minimal set of standards and rules governing the implementation, arrangement, interaction, and interdependence of system elements.
Each of the three views is further broken down into 26 distinct products.
The DON CIO has been sponsoring the development of the following three architecture tools to support systems developers and managers in documenting and managing IT systems:
- The Architecture Development Process Model (ADPM).
- The Department of the Navy Integrated Architecture Database (DIAD).
- The Data Management and Interoperability Repository (DMIR).
The Architecture and Development Process Model
The ADPM is a government off-the-shelf (GOTS) product that provides a roadmap for the development of enterprise architecture descriptions as documented in the DoD Architecture Framework Version 2.0. ADPM provides a step-by-step approach to developing framework architecture descriptions.
Using a set of hyperlinked documents or as a downloadable Microsoft Project process template, the ADPM provides a product-driven work breakdown structure (WBS) for architecture description development, supplemented by:
- Task descriptions and dependencies.
- Best practices and lessons learned.
- Product examples from various DoD functional areas.
- Technical references to the Core Architecture Data Model (CADM) for each product.
To accommodate the unique aspects of each architecture initiative (e.g., differences in scope, objectives and functional application), the ADPM is intentionally generic and functionally independent. Modifications to the template to accommodate specific project needs can easily be made in the Microsoft Project process template.
The ADPM is organized hierarchically. High level tasks are outlined in the table of contents, and users may drill down to lower level tasks from this page. On all lower level pages, there is a “Return to Table of Contents” link to enable users to easily return to the higher-level task listing. It is recommended that users either review the table of contents or download and review (at a high level) the tasks in the Microsoft Project file to familiarize themselves with the task hierarchy.
Intended Audience and Usage
The intended audience and usage of the ADPM is twofold. First, it is intended to support architecture program and project managers from any DoD functional area (personnel, logistics, C4ISR, etc.) who are responsible for overseeing the development of architectures. The objective is to enable effective oversight and coordination of architectural description development efforts.
Second, the ADPM serves as a role in enterprise architecture education. The model picks up where the Architecture Framework leaves off. The framework’s six-step high-level process tells the reader to pick the products and build them; it does not provide any guidance on how to do it. The ADPM fills the gap by providing the detailed, yet generic process for the oversight of the actual building of the architecture products. The ADPM does not take the place of the framework; it serves as a companion, providing the process component for enterprise architecture development.
ADPM Content and Reference Documents
The project management template included in the ADPM is a Microsoft Project file used to manage the development of architectures. It contains a mirror image of the task hierarchy and descriptions provided in the HTML document, as well as task dependencies and the ability (via Microsoft Project) to view the tasks and their associated timelines in Gantt chart form.
The file provides a skeletal management approach which is intended to be modified to meet specific project needs. Once downloaded, users should determine and enter task duration estimates, resources, and other relevant information to reflect project specific variables, such as scope, complexity, available resources, and the like.
Reference documents included in the ADPM are the C4ISR Architecture Framework Version 2.0 in MS Word and the Core Architecture Data Model in compressed file format containing the CADM logical data model.
The CADM is primarily a technical document. Its primary value is that it provides a common and consistent framework for capturing, storing and manipulating architectural data. Each project has a “view” of the CADM and data model objects (e.g., entity types) that are shared by multiple products that are inherently consistent. In turn, this ensures consistency of analytical results across the entire scope of the architecture.
ADPM Next Version
The DON CIO is planning to enhance the ADPM in concert with future iterations of the Architecture Framework and the development of DON architecture policy and guidance. Go to the DON CIO website for the latest enterprise architecture information: http://www.doncio.navy.mil/.
The DON Integrated Architecture Database
The DON Integrated Architecture Database is another GOTS product that provides a repository for data collected in support of operational and systems views as outlined in the DoD Framework. The DIAD will be used by the DON to create an information technology architecture (ITA) as prescribed by the Clinger-Cohen Act and further defined in OMB Circular A-130.
The DIAD has the following attributes:
- A data model developed to be fully compliant with the CADM that supports the DoD C4ISR Architecture Framework V 2.0.
- Standalone MS Access for installation at local sites to develop and capture architecture artifacts.
- Inclusion, reference, and traceability of requirements to the sources of the requirements, as well as the systems created to support the requirements.
- Edit, entry, and analysis tools to ensure data integrity and to support the framework methodology for creating architecture products.
- The ability to store and integrate the data underlying the operational and systems view products of the framework for analysis and decision support to resource and acquisition decision-makers.
The DIAD employs a series of “picklists” that contain standard terms of reference used by a community of functional area (e.g., personnel or command and control) to define its organizations, facilities, platforms, activities, and the information exchanged. This semantic reconciliation of terms is intended to be used within the community, as well as by other communities, to articulate the information exchanges between them in a standard fashion.
As architectures are developed, a configuration management process will control and update the contents of the picklists to ensure that common terms of reference are used within the community of interest or functional area. They will also be available to other functional areas. Reconciling and maintaining the contents of the picklists brings another level of integration to architecture developed across the enterprise, and it is the key to using the architectures as an enterprise level decision support system.
CADM compliance in the DIAD data model will allow the exchange of architecture information among DoD Services and agencies. The CADM and DIAD provide the level of interoperability necessary to allow cross-functional analysis and capability management to support Program Operational Memoranda (POM) and PPBS decision-makers.
The DIAD is intended to support any architecture development effort at any level or degree of integration. Since it instantiates the CADM, there is automatic integration between architectures that use it to capture their products. The graphical user interface (GUI) allows operational personnel, as well as architects, to use an iterative process in developing their architecture products and provides the appropriate output of the products (reports, graphics and matrices) to provide meaningful information to decision makers.
The Data Management and Interoperability Repository
The Data Management and Interoperability Repository (DMIR) is an integrated suite of commercial off-the-shelf (COTS) and GOTS tools. The DMIR is a web-enabled registry of DON systems and their associated data structures and data exchange formats. It supports both management and engineering activities for development, operation, and maintenance of IT systems. It is part of the DON Data Management and Interoperability (DMI) infrastructure which supports development of a common data architecture to enable systems interoperability, knowledge management and information assurance.
The purpose of the DON DMIR is to support accomplishment of the DON DMI Strategic Goals and Objectives. Data management is the essential foundation for information and knowledge management. Effective decision support depends on the integrity and reliability of the information and knowledge base. Attaining these characteristics requires sound data, reinforced by standards, to satisfy operational and technical requirements. DMI is integral to achieving systems interoperability and supporting information assurance.
The DMIR is a key component of the DON approach for responding to the requirements of the Clinger-Cohen Act. It is more than a data dictionary system. It documents data used by systems and applications in context. The information in the repository is available to system developers to reduce development costs for new systems and to enable better understanding of other systems for interoperability.
Capturing the structures of data and the entities and attributes (metadata) as implemented in operational systems provides a baseline to:
- Determine data inconsistencies.
- Assess data redundancies.
- Improve interoperability.
- Ensure data requirements are included in systems being developed to replace a legacy system.
- Support collaborative data standards development.
The DON CIO is the sponsor of the DMI and DMIR effort. The DON CIO was joined by more than 30 Navy and Marine Corps organizations in the development of a DMI Implementation and Planning Guide (IPG), which specifically for development and implementation of a DMI repository; the DON CIO board of representatives approved the IPG report in November 2000.
The DMIR is intended to support a wide range of users, from managers to developers, to data consumers. The DMI infrastructure brings together diverse capabilities and focuses them with defined data management and engineering processes. These processes include the planning and implementation necessary to leverage loosely coordinated efforts into a unified program that provides much more value than independent projects can accomplish.
The DMIR supports the development and implementation of a key element of the DON ITA. The DON Data Architecture is a framework for organizing and managing the interrelationships of data. The DMIR is an enabler of data interoperability between various efforts.
DMIR supports the DMI management and engineering process to enable evolution to a shared data environment, achieved at Levels of Information System Interoperability (LISI) 3 and 4. The DMIR must be able to evolve to support the DON DMI vision that calls for global, affordable and timely access to shared, reliable and secure data that enables maritime information superiority by 2005. It must support the DMI plan of action and milestones (POA&M) from Section 3 of the DON DMI IPG.
The POA&M is broken into four phases:
• Phase 0 – DMI requirements and concept definition (Nov 00-Jan 01)
• Phase I – Implementation planning and portfolio development (Jan 01-Sep 01)
• Phase II – DON functional data architecture (established by each FDM) (Oct 01- Dec 02)
• Phase III – DON Enterprise Data Architecture (Jun 03-Jul 03)
DMIR products and services and based on the DMI functional requirements and allocated into the following modules.
• DMIR management Modules
- User access
- Document control
• Systems DMI Registration Module
- IT systems registration
- Information asset registration
- Applications registration
• Information Requirements Analysis Support Module
- IT requirements documents
- Authoritative Data Sources
- Reference database production information
- Data access and retrieval profiles
• Architecture and Standards Module
- Conceptual data models
- Logical data models
- Data standards development and maintenance
• Assessment Support Module
- IT assessment support
- Systems interoperability assessment support
- Organization/platform interoperability assessment support
- Organization/platform information assurance assessment
• DMI Management Module
- Plans and policy
The DMIR administration module serves as the control center for the repository and controls user access.
The systems registration module includes the establishment and maintenance of a system’s data requirements baseline, i.e., legacy and new systems, applications, database structures and data dictionaries. It also includes systems transfer format implementation documented in a consistent format to provide management visibility.
The data baseline supports aggregation of metadata for systems and groups of systems to produce the as is data architecture. This foundation supports realignment and continued evolution of system data to support future operations. Functionally oriented data managers work with system developers to register their systems and associated metadata to develop data architectures and standards.
The information requirements analysis module helps link requirements to authoritative data sources (ADS) maintained by organizations collecting and producing data. The data architecture standards module includes construction and maintenance for DON data models and the DoD data element and transfer format standards to support system development and interoperability.
The information technology, interoperability and information assurance assessment support module supports analysis of the systems metadata that is maintained in the DMIR database. This module supports multiple data and metadata assessments.
Assessment support involves analysis of system metadata maintained in the repository and in support of other DMI and IT assessment efforts. Specific capabilities include assessments of: (1) IT; (2) systems database interoperability; and (3) information assurance (data integrity). Emphasis is on an outcome of reliable data that is interoperable across systems and architectures.
The DMI management module involves monitoring systems registration, addressing cross-functional interoperability issues, and coordination of efforts to ensure maritime information superiority.
DMIR requirements and procedures will be refined during testing beginning in July 2001. The principal participants are MARCORSYSCOM, CINCPACFLT and FIWC (Fleet Information Warfare Center). DMIR is planned for full production release in October 2001.
In conclusion, DMIR supports a complete data lifecycle process from operational requirements through meeting day-to-day data needs, including a configuration management methodology that is responsive to data producers and users.
The concept of network-centric warfare (NCW) presupposes a Global Information Grid (GIG) that possesses an awareness and “intelligence” of anything that it touches. Designing and managing this GIG and its clients will require systems engineering and configuration management on an enterprise scale. To date, we perform these functions at a programmatic level.
As was revealed at the beginning of this article, a PM’s knowledge of his or her own systems is not enough to ensure interoperability with the evolving systems that other PMs will be plugging into the GIG. That kind of capability, which is necessary if net-centric warfare is to be realized, must be designed in the DON.
The tools presented here represent the analytical underpinnings of knowledge management. If we are serious about sharing information and harnessing the power of IT to enhance communication within and among communities of interest, to revolutionize command and control, then we must understand the important role of enterprise architecture as a strategy to attaining net-centric warfare.
Navy and Marine Corps activities are piloting the use of IT architectures to support the DoD’s key decision support systems. Likewise, the Office of the Assistant Secretary of Defense for C3I intends to utilize the GIG architecture to support planning for interoperable, secure joint systems and capabilities.
The potential value of architecture information is tremendous—visionary thinkers are currently devising new and innovative ways to use this information. Without these visionaries, the tools are just mere database applications; used properly, they will lead to achievement of the DoD’s and DON’s information and knowledge superiority goals.
Steve Carey is the project manager for the DON Architecture Development Process Model and DON Integrated Architecture Database.
Michael Jacobs is the project manager for the DON Data Management and Interoperability Repository.