Enterprise Architecture Tools for
Delivering Combat and Business Capabilities

By  Steve Carey and  Michael Jacobs

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", the Operational View, the Systems View, and the Technical View.

Operational View
Describes tasks and activities and the information exchanges required
Independent of technology

Systems View
Describes systems and the connections and communications among them
Existing or planned technologies

Technical View
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 twenty-six 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 their IT systems:

The Architecture Development Process Model (ADPM)

What is the ADPM? 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.  Accessible through any standard Internet browser at http://www.don-imit.navy.mil/ (or on CD-ROM upon request), the 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:

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 high-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 tool's objective is to enable effective oversight and coordination of architectural description development efforts. Second, the ADPM serves 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 document; 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 ios a Microsoft Project file used to mange the development of architectures.  It contains a mirror image of he 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 or taken from the CD-ROM, users should determine and enter task duration estimates, resources, and other relevant information to reflect project specific variables (e.g., scope, complexity, available resources, etc.).

Reference Documents included in the  ADPM are the C4ISR Architecture Framework, Version 2.0 in MS Word document format; and the Core Architecture Data Model (CADM) in compressed file format (.Zip), containing the CADM logical data model, in ERWin format (Erwin data modeling software V2.5 or higher is required). 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 product has a "view" of the CADM, and data model objects (e.g., entity types) that are shared by multiple products are inherently consistent. In turn, this ensures consistency of analytical results across the entire scope of the architecture. This document is intended for technical reference by the project  technical staff. A Portable Document Format (.PDF) view for each architecture product is also included in the model for quick reference.

ADPM Next Version
DON CIO is planning to enhance the ADPM in concert with future iterations of the Architecture Framework document and the development of DON architecture policy and guidance.  Users are encouraged to provide specific and constructive suggestions to mailto:ADPM@hq.navy.mil

The Department of the Navy Integrated Architecture Database (DIAD)

The Department of Navy Integrated Architecture Database is another GOTS product that provides a repository for data collected in support of Operational and Systems Views of Architecture as outlined by 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:

Key Concepts
The DIAD employs a series of "picklists" that contain standard terms of reference used by a community or 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 these picklists to insure that common terms of reference are used within the community of interest or functional area, as well as make them available globally 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. 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.

Intended Audience
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 "outputs" of the products (reports, graphics, and matrices) to provide meaningful information to decision makers.

The Data Management and Interoperability Repository (DMIR)

TheData 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 Operability (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 of new systems and to enable better understanding of other systems with which they are required to interoperate.

Capturing the structures of data and the entities and attributes (metadata) as implemented in operational systems provides a baseline to:

The DON CIO is the sponsor for the DMI effort and the DMIR. The CIO was joined by over 30 Navy and Marine Corps organizations in the development of a DMI Implementation Planning Guide (IPG), which specifically called 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 planning and implementation necessary to leverage loosely coordinated efforts into a unified program that provides value far in excess of what 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 inter-relationships 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 3 and 4 in the Levels of Information Systems Interoperability (LISI). 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:

DMIR Products and Services are based upon the DMI functional requirements and allocated into the following DMIR modules:

DMIR Management Module
-User Access
-Document Control
Systems DMI Registration Module
-IT Systems Registration
-Information Asset Registration
-Application 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 Support
DMI Management Module
-Plans and Policy
-Training
-Outreach
-Evaluation

The DMIR Administration Module serves as the control center for the repository and controls user access.

The Systems Registration Module includes establishment and maintenance of a system's data requirements baseline, i.e., legacy and new systems/applications database structures and data dictionaries, and systems transfer format implementations documented in a standard or 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 the Authoritative Data Sources (ADS) maintained by organizations collecting and producing data. The Data Architecture and Standards Module includes construction and maintenance of 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 support of other DMI and IT assessment efforts. Specific capabilities include assessments of (1) Information Technology, (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 commencing July 2001. The principal participants are MARCORSYSCOM, FIWC (Fleet Information Warfare Center), and CINCPACFLT. DMIR is planned for full production release in October 2001.

In conclusion, DMIR supports a complete data life-cycle process from operational requirement through meeting day-to-day data needs, including a configuration management methodology that is responsive to data producers and users.

Conclusion

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 one day be "plugging into" the GIG. That kind of capability, that which is necessary if NCW is to be realized, must be architected into 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 NCW.

What lies ahead for IT architecture? Navy and Marine Corps organizations are piloting the use of IT architectures to support the key decision support systems of the DoD: PPBS, requirements, acquisition. 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 the information. Without these visionaries, the tools are just mere database applications; used properly, they will lead to achievement of the information and knowledge superiority goals of the DON and the DoD.

Steve Carey is the Project Manager for the DON Architecture Development Process Model (ADPM) and the DON Integrated Architecture Database (DIAD); Michael Jacobs is the Project Manager for the DON Data Management and Interoperability Repository (DMIR).