DTIC ADA487932: Interoperability in DOD Acquisition Programs Through Enterprise 'Architecting'

23 Pages·2.2 MB·English

by  Defense Technical Information Center

Acquisition Review Quarterly — Summer 2002
Courtesy of the United States Army
Courtesy of European Aeronautic Defense & Space Company
Courtesy of the United States Navy, photo taken by
1st Mate Toss Cichonowicz
Courtesy of European Aeronautic Defense & Space Company
190
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
2002 2. REPORT TYPE 00-00-2002 to 00-00-2002
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Interoperability in DOD Acquisition Programs Through Enterprise
5b. GRANT NUMBER
’Architecting’
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
National Defense University,Information Resources Management REPORT NUMBER
College,300 5th Avenue,Washington,DC,20319
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
Acquisition Review Quarterly, Summer 2002
14. ABSTRACT

15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE Same as 22
unclassified unclassified unclassified Report (SAR)
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
Interoperability in DoD AcquisitionT UPrToOgrRaImAsL through Enterprise “Architecting”
INTEROPERABILITY IN
DOD ACQUISITION PROGRAMS
THROUGH
ENTERPRISE “ARCHITECTING”
Mary Linda Polydys
Joint Vision (JV) 2020 guides the continuing transformation of America’s Armed
Forces toward information superiority in the ongoing “information revolution.”
JV 2020 states that information superiority “is a key enabler to this trans-
formation,” and that interoperability facilitates information superiority. This article
discusses the role of enterprise architecture in the acquisition of interoperable
systems in the Department of Defense.
J
oint Vision (JV) 2020 guides the con- every military operation, JV 2020 ac-
tinuing transformation of America’s knowledges the major role of informa-
armed forces toward a goal of in- tion and information technology in
formation superiority.1 JV 2020 states that achieving information superiority.
“the ongoing ‘information revolution’ is The JV 2020 discussion on informa-
creating not only a quantitative, but quali- tion superiority is followed by a discus-
tative change in the information environ- sion on interoperability2 and its role in
ment that by 2020 will result in profound achieving information superiority. JV
changes in the conduct of military opera- 2020 states that “Interoperability is a
tions” (Chairman Joint Chiefs of Staff mandate for the joint force of 2020 —
[CJCS], 2000, June, p. 8). Because infor- especially in terms of communications,
mation, information processing, and com- common logistics, and information
munications networks are at the core of sharing” (CJCS, 2000, p. 15). With re-
DISCLAIMER
Any opinions expressed in this article are those of the author and do not reflect the official
policy or position of the National Defense University, Defense Acquisition University, the
Department of Defense, or the United States Government.
191
Acquisition Review Quarterly — Summer 2002
spect to interoperability, JV 2020 states these subjects are covered, it is useful
that “Information systems and equip- to briefly review the concepts of en-
ment that enable a common relevant terprise architecture as mandated in law
operational picture must work from and regulation.
shared networks that can be accessed
by any appropriately cleared partici-
pant” (CJCS, 2000, p. 15). JV 2020 fur- “ARCHITECTING” AS A MANDATE
ther acknowledges that interoperability
goes beyond technical interoperability The requirement for enterprise ar-
and includes a chitecture is mandated in the Clinger-
focus on pro- Cohen Act of 1996. This act requires
“JV 2020 further cedures or or- that all Federal Government chief in-
acknowledges that ganization. formation officers “develop maintain,
interoperability “Although and facilitate the implementation of a
goes beyond techni-
t e c h n i c a l sound and integrated information tech-
cal interoperability
interoper- nology architecture” [40 U.S.C. §1425
and includes a focus
ability is es- ¶(b) (2)]. The act further defines infor-
on procedures or
sential, it is not mation technology architecture (often
organization.”
sufficient to called enterprise architecture) as “an
ensure effec- integrated framework for evolving or
tive operations. There must be a suit- maintaining existing information tech-
able focus on procedural and organiza- nology and acquiring [emphasis
tional elements, and all decision-mak- added] new information technology to
ers at all levels must understand each achieve the agency’s strategic goals
other’s capabilities and constraints” and information resources manage-
(CJCS, 2000, p.15). ment goals” [40 U.S.C. §1425 ¶(d)].
This article addresses the role of en- The Clinger Cohen Act architecture
terprise architecture in documenting mandates are implemented in Office
interoperability requirements and to of Management and Budget (OMB)
some extent, procedural and organiza- Circular A-130 (2000). OMB Circular
tional interoperability requirements in the A-130 (2000) states that an enterprise
Department of Defense (DoD) system architecture must include a description
acquisition. More specifically, this article of the business or operational pro-
addresses the use of enterprise cesses, information flows and relation-
architecture products3 in creating ships, data descriptions and relation-
interoperability key performance param- ships, applications, and technology in-
eters4 (KPPs) for Capstone and Opera- frastructure. The enterprise architecture
tional Requirements Documents (CRDs must also include a technical reference
and ORDs) and documenting interoper- model and standards profile (includ-
ability and supportability requirements ing a security standards profile). This
for the Command, Control, Communi- circular requires that federal agencies
cation, Computers, and Intelligence establish an architecture framework
(C4I) Support Plan. However, before that would provide specific agency
192
Interoperability in DoD Acquisition Programs through Enterprise “Architecting”
direction on developing enterprise ar- sources to the operational view. This
chitectures. view illustrates multiple systems infor-
The DoD developed their architec- mation exchanges via communication
ture framework in 1997, titled Com- links and may describe the internal con-
mand, Control, Communication, Intel- struction and operations of particular
ligence, Surveillance, and Reconnais- systems. More specifically, this view
sance (C4ISR) Architecture Framework includes the
(future editions to be renamed DoD physical con-
“In addition to the
Architecture Framework; see DoD, nections, loca-
three architecture
2001b, ¶C6.3.2). This framework or- tions, and iden-
views, the DoD
ganizes DoD’s enterprise architecture tification of key
architecture
into three views (e.g., operational ar- hardware and
framework also
chitecture view, systems architecture software; may identifies architec-
view, and technical architecture view) include data ture products that
and provides a set of rules for DoD or- stores, circuits, are used
ganizations to follow in creating their and networks; to describe each
architecture descriptions. and may specify view.”
The purpose of the operational archi- system and
tecture view is to provide a clear opera- component per-
tional picture for decision-making. At formance parameters.
the heart of this view are the operational The purpose of the technical archi-
concept, operational processes, and tecture view is to provide the minimal
information exchanges. This view con- set of rules governing the arrangement,
tains graphical and textual descriptions interaction, and interdependence of sys-
(architecture products) defining the tem parts or elements. This view con-
tasks/activities/processes, operational sists of technical standards, conventions,
nodes5 or elements, and information rules, and criteria organized into
exchange requirements (IERs)6 between profile(s) that govern system services,
nodes. The process and IERs descrip- interfaces, and relationships for particu-
tions may be supplemented by business lar systems views.
rules, data descriptions, and sequenc- Figure 1 provides a cross-walk be-
ing and timing descriptions. tween the architecture components de-
The purpose of the system architec- scribed in OMB Circular A-130 and the
ture view is to provide a clear picture DoD architecture framework. In com-
of the systems and communications that paring OMB Circular A-130 with de-
support the operational concept. At the scriptions of each of the views, it is evi-
heart of this view are the descriptions dent that DoD is consistent with the ar-
of system interfaces and communica- chitecture policy mandates of the Fed-
tions needs and capabilities. This view eral Government.
contains graphical and textual descrip- In addition to the three architecture
tions of the applications and technol- views, the DoD architecture framework
ogy infrastructure to satisfy operational also identifies architecture products that
needs and associates the physical re- are used to describe each view. The
193
Acquisition Review Quarterly — Summer 2002
OMB DoD (C4ISR)
Circular A-130 Framework
Business
Operational
Processes
Architecture
View
Information Flow
and Relationships
Systems
Data Descriptions Architecture
View
Applications
Technical
Architecture
Technology
View
Infrastructure
Technical JTA
Reference Model
DoD Technical
and Standards
Reference Model
Figure 1. A Comparison of Architecture Components
products that are used in DoD system ac- (cid:127) SV-6, Systems Information Ex-
quisitions to document interoperability re- change Matrix.
quirements and derive interoperability
(cid:127) TV 9-1, Technical Architecture Pro-
KPPs are defined and illustrated in this
file.
article. They include the following:
USING ARCHITECTURE PRODUCTS
(cid:127) OV 7-1, High-Level Operational Con-
IN DOD SYSTEM ACQUISITIONS
cept Graphic.
(cid:127) OV-2, Operational Node Connectivity
There are two primary uses of archi-
Description.
tecture products in DoD system acqui-
(cid:127) OV-3. Operational Information sitions. The first use is in the develop-
Exchange Matrix. ment of interoperability KPPs that must
be included in CRDs and ORDs. CJCS
(cid:127) OV-6c, Operational Event Trace
Instruction 3170.01B (2001) and CJCS
Description.
Instruction 6212.01B (2000) provide
(cid:127) SV 8-1, System Interface Description. direction in deriving interoperability
KPPs from IERs. Additionally, CJCS In-
194
Interoperability in DoD Acquisition Programs through Enterprise “Architecting”
struction 6212.01B (2000) provides a ments for the CRD using enterprise ar-
list of DoD enterprise architecture prod- chitecture products specified in the DoD
ucts that must be included as part of the architecture framework (DoD, 1997;
CRD (CJCS, 2000, pp. C-A-4 through also see CJCS, 2000, pp. B-1 through
C-A-6) and ORD (CJCS, 2000, pp. C- B-3).
A-7 through C-A-10). The architecture
products that are included with the CRD CRD STEP ONE
and ORD provide supporting documen- Create OV-1, High-Level Operational
tation for the interoperability KPP and Concept Graphic. The OV-1 is a graphi-
document high-level interoperability cal and text description of the opera-
requirements. tional concept. The graphic includes
A second use is in the evolution of high-level organizations, missions, geo-
detailed interoperability requirements as graphic configuration, and connectiv-
an acquisition proceeds through its life ity. It is also the most general and flex-
cycle. These detailed interoperability re- ible in format. Therefore, the graphical
quirements are documented in the C4I appearance depends on the scope and
Support Plan. CJCS Instruction intent of the architecture product. The
6212.01B (2000) provides a list of DoD value of OV-1 may be characterized as
enterprise architecture products that follows:
must be included in C4I Support Plan
(CJCS, 2000, pp. C-B-3 through C-B- (cid:127) Provides context or scope for a
9), and Appendix 5 of DoD 5000.2-R family-of-systems or system-of-sys-
(DoD, 2001b) further explains the use tems.
of architecture products in the C4I Sup-
port Plan. This plan “identifies C4ISR (cid:127) Facilitates human communications
needs, dependencies, and interfaces for during the acquisition process by
programs in all acquisition categories, orienting and focusing detailed dis-
focusing attention on interoperability, cussions.
supportability, and sufficiency con-
cerns” (DoD, 2001b, ¶AP5.1.1). The (cid:127) Facilitates the understanding of com-
regulation further states that the “level plexity.
of detail in a C4I Support Plan will in-
crease as an acquisition program pro- Figures 2 and 3 are Joint Meteoro-
ceeds from program initiation to Mile- logical and Oceanographic (METOC)
stone C, and to follow-on blocks of an Architecture examples10 of an OV-1
evolutionary acquisition” (DoD, 2001b, graphic and its text description for the
¶AP5.5.2). CRD.
“ARCHITECTING” INTEROPERABILITY
CRD STEP TWO
KPPS AND REQUIREMENTS FOR THE CRD
From the OV-1, identify top-level
IERs. The following is a partial list of
The following is a process for identi- top-level information exchanges for the
fying interoperability KPPs and require- example:
195
Acquisition Review Quarterly — Summer 2002
Joint
METOC
Database
Figure 2. CRD – High-Level Operational Graphic (OV-1) for METOC
(cid:127) METOC Forecast Centers receive JTF area of operation receive weather
information from weather satellites. information from the local weather
observation facilities.
(cid:127) METOC Forecast Centers receive in-
formation from local weather obser- CRD STEP THREE
vation facilities at the Joint Task Document top-level IERs depicted in
Force (JTF) Commander’s location. OV-1 in an Operational Information
(cid:127) Naval and air forces operating in the Exchange Matrix (OV-3) format. The
196
Interoperability in DoD Acquisition Programs through Enterprise “Architecting”
OV-1: Operational Concept for Meteorological and
Oceanographic Support to the Joint Task Force
This acquisition falls within the context of the METOC operational concept. This graphic
represents the high-level operational concept diagram for Joint METOC. This graphic
conveys two major ideas.
First, within the Area of Operations (AO), forces require access to the observations and
forecasts of all other forces operating in the AO. In some cases the exchange of METOC
information also includes results of tactical decision aids (TDAs) or other detailed
METOC information that drives the TDAs hosted on the computers of the other Ser-
vices. Local observations from the AO also need to be communicated to the METOC
Forecast Centers (MFCs) for future analysis.
The second major idea that the graphic is designed to depict is the concept that forces
in the AO require access to the theater-scale and space environment products created
at two types of MFCs:
(cid:127) Air Force and Navy worldwide production and climatology facilities.
(cid:127) Air Force and Navy theater component/regional METOC production facilities
that are responsible for a specific geographic area.
Additionally, the graphic depicts METOC satellites transmitting imagery data and at-
mospheric profiles to all of the conceptual nodes. This shows that all of the operational
[business] nodes require METOC satellite information. Determining which nodes re-
ceive direct access to METOC satellite data and which ones receive stored data or
products derived from stored data, is a design decision based on CINC requirements,
Service-provided capabilities (including METOC forecast center capabilities) and
weather agency advice on the integration of space-based data with other sources of
METOC data. The resulting structure is included in the system architecture.
For the purpose of this architecture, it is not important to understand exactly how an
MFC supports each of its customers. However, an understanding of how the MFCs
support a Joint Task Force is important. This level of detail is provided in the information
exchange requirements (IERs).
Figure 3. CRD – OV-1 Text Description for METOC
contents of this matrix are the high-level 5 are mandatory and 6 through 8 are
interoperability requirements for the optional. Optional columns are sug-
CRD. Table 1 is a METOC example of gested in the DoD architecture frame-
OV-3. For the sake of brevity, not all work (1997, pp. 4-19 through 4-22).
information exchanges are included in Column 1 contains the tasks listed in
the example. the Universal Joint Task List (UJTL).
Several points are important in un- Column 2 identifies the event. These
derstanding OV-3. Columns 1 through events should be systemically designed
197
Acquisition Review Quarterly — Summer 2002
Table 1. CRD – Information Exchange Matrix (OV-3) for METOC
1 2 3 4 5 6 7 8 9
Info UJTL EVENT INFORMATION SEND REC MEDIA QUALITY QTY CRITICAL
Exch NODE NODE
Op2.2 Collect Atmospheric CJTF Regional Text, Updates 200- YES
Collect METOC Information: Air, (JMO/ METOC Data Every 300MB
1 Ops Information Cloud, Visibility, JMFU) Forecast 20 “raw”
Info Precipitation, Center Minutes data
Lightning, Local (MFC)
Unusual Weather Weather
OP2.2 Collect Oceanographic Satellite Regional Text, Updates 200- NO
Collect METOC Information: Ice, Sensor Data Every 300MB
Ops Information Ice Berg, Wave, 20 “raw”
2 Beach Minutes data
Bathymetry,
Water Column
using some form of process modeling in the METOC example. The first in-
technique. One such technique is called formation exchange in OV-3 must be
IDEF0, Functional Modeling Language. satisfactorily accomplished for the
(Discussion of process modeling tech- threshold objective value of 100 per-
niques is out of the scope of this article.) cent, and all information exchanges
Column 3 lists the information that is must be satisfactorily accomplished for
exchanged, column 4 identifies the the objective value of 100 percent.
sending node, and column 5 identifies
the receiving node. “ARCHITECTING” INTEROPERABILITY KPPS
AND REQUIREMENTS FOR THE ORD
CRD STEP FOUR
Identify and label critical top-level
Although the interoperability require-
IERs.11 In addition, IERs that must flow
ments in the CRD are specified for an
down to specific ORDs must be clearly
FoS or SoS, the interoperability require-
identified. IERs that are critical will be
ments for an ORD are specified for the
required at threshold. Notice that in col-
proposed system that is being acquired.
umn 9 of Table 1 METOC, the first IER
The following is a process for identify-
is identified as critical and the second
ing ORD interoperability requirements
is not.12
using architecture products specified in
the DoD architecture framework (DoD,
CRD STEP FIVE 1997; also see CJCS, 2000, pp B-3
Derive an interoperability KPP from through B-5).
the IERs documented in the OV-3 ma-
trix. Table 2 includes a very simple
interoperability KPP for the critical IER
198