8/14/2019 Programmatic Interoperability
1/44
Programmatic Interoperability
B. Craig MeyersJames D. Smith
December 2007
TECHNICAL NOTECMU/SEI-2008-TN-012
Integration of Software-Intensive Systems InitiativeUnlimited distribution subject to the copyright.
8/14/2019 Programmatic Interoperability
2/44
This report was prepared for the
SEI Administrative Agent
ESC/XPK
5 Eglin Street
Hanscom AFB, MA 01731-2100The ideas and findings in this report should not be construed as an official DoD
position. It is published in the interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded
research and development center sponsored by the U.S. Department of Defense.
Copyright 2008 Carnegie Mellon University.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS
FURNISHED ON AN AS-IS BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF
ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED
TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS
OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY
WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR
COPYRIGHT INFRINGEMENT.
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.
Internal use. Permission to reproduce this document and to prepare derivative works from this document for internaluse is granted, provided the copyright and No Warranty statements are included with all reproductions and
derivative works.
External use. Requests for permission to reproduce this document or prepare derivative works of this document for
external and commercial use should be addressed to the SEI Licensing Agent.
This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with
Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and
development center. The Government of the United States has a royalty-free government-purpose license to use,
duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for
government purposes pursuant to the copyright license under the clause at 252.227-7013.
For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site
(http://www.sei.cmu.edu/publications/pubweb.html).
http://www.sei.cmu.edu/publications/pubweb.htmlhttp://www.sei.cmu.edu/publications/pubweb.html8/14/2019 Programmatic Interoperability
3/44
Table of Contents
SOFTWARE ENGINEERING INSTITUTE |i
Acknowledgements v
Abstract vii
1 Introduction 1
2 Setting the Context 3
2.1 Defining Network-Centric Operations and Systems of Systems 3
2.2 Defining Interoperability 4
2.3 Influence of Interoperability in Acquisition 5
2.3.1 Scope of Interaction 5
2.3.2 Nature of Agreements 6
2.3.3 Shared Information 7
2.4 Aspects of Interoperability 7
2.5 Programmatic Interoperability 10
3 The Programmatic Aspect of Interoperability 13
3.1 Concepts 13
3.1.1 Entities and Their Means of Communicating 13
3.1.2 Acquisition Management Information 14
3.1.3 Operations 15
3.1.4 Summary of Perspectives on Programmatic Interoperability 15
3.2 Programmatic Interoperability Examples 16
3.3 Programmatic Interoperability Research Issues 17
4 Enlarging the Context 21
4.1 Overview 21
4.2 Perspectives on Interoperability Influences 22
4.3 Implications 23
5 Summary 25
Appendix A Definitions of Interoperability 27
References 29
8/14/2019 Programmatic Interoperability
4/44
i i | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
5/44
List of Figures
SOFTWARE ENGINEERING INSTITUTE |i i i
Figure 1: Models of the Scope of Interaction 5
Figure 2: Mapping of Functions to Organizations 8
Figure 3: SOSI Model 8
Figure 4: Illustrating Orchestration of Interoperability Aspects in a Multisystem Context 21
8/14/2019 Programmatic Interoperability
6/44
i v | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
7/44
SOFTWARE ENGINEERING INSTITUTE |v
Acknowledgements
This work was supported in part by the Ca rnegie Mellon 1 Softwar e E ngineering
Instit ute Independent Research an d Development project called Toward Interopera-ble Acquisition: The Ca se of Risk Man agemen t . We also acknowledge discussions
with colleagues Lisa Brownsword, Suzanne Garcia, and Ed Morris.
1. Carnegie Mellon is registered in the U. S. Patent and Trademark Office by Carnegie Mellon University.
8/14/2019 Programmatic Interoperability
8/44
vi | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
9/44
SOFTWARE ENGINEERING INSTITUTE |v
Abstract
Interoperability has traditionally been considered a property of operational systems,
wher e systems a re a ble to excha nge inform at ion in some agreed-upon fash ion. How-ever, oth er a spects of int eroperability ar e often overlooked. This report int roduces one
of th ose aspectsthe concept of program ma tic inter opera bility,which is the applica-
tion of principles of int eroperability to th e acquisition ma na gement of system s. It
shows how programmatic interoperability contributes to fielding interoperable capa-
bilities and r elates th is aspect t o cur rent tr ends such as network-centr ic operat ions.
The report also discusses th e orchestr at ion of decisions a nd a ctivities t hat ar e appli-
cable to acquisition in a system -of-system s environmen t. Fin ally, the report s uggests
several research topics.
8/14/2019 Programmatic Interoperability
10/44
vi | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
11/44
SOFTWARE ENGINEERING INSTITUTE |1
1 Introduction
There is increased emphasisin commercial industry and governmenton moving
towar d a net work-centr ic perspective to provide operat iona l capa bilities t o end us ers.For acquirer s an d developers, this perspective shifts th e view from an individual sys-
tem t o a system-of-systems environmen t an d funda ment ally alters t he na tur e and
extent of the requirement s for interoperability. We use t he phr ase system-of-systems
environment, not syst ems-of-system s acquisition. The form er t erm describes the int e-
grat ion of mu ltiple separ at e acquisitions; th e latt er conn otes a single acquisit ion of
some lar ger system.
Interoperability has traditionally been considered a property of operational systems.
Efforts t o achieve interopera bility h ave u sua lly focused on defining comm un icat ion
protocols an d inter face sta nda rds a nd verifying (usu ally thr ough t estin g) conform -
an ce to th em.
Recent work at the Carn egie Mellon2 Softwar e En gineering Inst itut e (SEI) has led
to the r ecognition t ha t a chieving interoperability actually requires an underst an ding
an d orchestr at ion of activities a cross a ll aspects of th e affected system s. A useful
appr oach growing from t ha t work is to consider int eroperability in ter ms of th ese dis-
tinct aspects:
operationalinteroperability among entities engaged in the operation of systems
(As previously discussed, t his a spect is th e focus of th e tr adit iona l approach t o
achieving int eropera bility.)
constru ctiveinteroperability among entities engaged in the development and
maint enan ce of systems programmaticinteroperabil ity among ent it ies engaged in the acquisi t ion m an-
agement of systems
This report examines progra mma tic int eroperability an d discusses its relat ion t o the
other aspects of int eroperability. The discussion is focused on govern men t a cquisi-
tions, but m an y of the prin ciples are believed to apply to comm ercial acquisitions as
well. We suggest th at achieving int eroperability in fielded system s requir es consider-
ing th e activities in each of those aspectsas well as t heir int errelat ions.
This r eport is organ ized as follows:
Section 2
- sets the context through an overview of network-centric principles and sys-
tem s of system s an d a discussion of int eroperability
- broadens the scope of interoperability to include aspects beyond the t radi-
tional cont ext of operat iona l systems
2. Carnegie Mellon is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
8/14/2019 Programmatic Interoperability
12/44
2 | CMU/SEI-2008-TN-012
Section 3 examines program mat ic int eroperability in m ore deta il through discus-
sion, examples, an d r esearch questions.
Section 4 includes a discussion of th e orchest ra tion of activities an d decisions
across all asp ects of a s ystem of system s.
Section 5 provides a su mma ry of the report .
8/14/2019 Programmatic Interoperability
13/44
8/14/2019 Programmatic Interoperability
14/44
4 | CMU/SEI-2008-TN-012
em er gen t beh avior
The beha vior of th e system of system s is a char acter istic of th e inter action of th e
individual system s th at compose the syst em of system s; it is not embodied in any
part icular system a nd is a consequence of the interactions tha t t ake place among
the systems.
The combina tion of th ese cha ra cterist ics mea ns t ha t t he policies, practices, proce-
dures, and techniques used now to acquire, develop, field, use, and sustain stand-
alone systemswhile still import ant must be reinterpret ed and perh aps changed
for a system -of-system s cont ext.4 Fu rt her more, new policies, practices, procedur es,
and techniques may n eed to be formed and integrat ed th roughout th e acquisition life
cycle t o meet t he n eeds of acquisition in a system -of-system s cont ext.
2.2 DEFINING INTEROPERABILITY
We also recognize tha t t he curr ent a pproaches to inter operability may be inefficient .
Because of th eir emph asis on principles such a s collaborat ion an d cha ra cterist ics like
emer gence, net work -centr ic operat ions a nd syst ems of system s necessar ily rely oninteroperability. Like the term system of systems, interoperability has m any defini-
tions. For example, this Ins tit ut e of Electrical an d Electronics Engineers (IEE E) defi-
nition is often cited [IEE E 00]:
in t eroperab i l i t y : the abilit y of two or m ore system s or elem ents to excha nge
inform ation and to use the inform ation that has been exchan ged
The DoD uses mu ltiple definitions of int eropera bility, all of which ar e based t o some
degree on definitions developed by IE EE . For exam ple, one definition is [DoD 00]
1. Th e ability of system s, un its, or forces to provide services to and accept ser-
vices from other system s, un its, or forces and to use th e services so exchan ged
to enable th em t o operate effectiv ely togeth er.
2. Th e condit ion achieved am ong com m un ications-electronics system s or
items of com m un ications-electronics equip m ent w hen in formation or services
can be exchan ged d irectly an d satisfa ctorily between them a nd / or their users.
Th e degree of in teroperability should be defined w hen referring t o specific
cases.
Oth er definitions of int eroperability from th e IEE E, th e DoD, and other s our ces ar e in
the Appendix. An exam ination of the IE EE and DoD definitions pr esented h ere an d
th ose in t he Appendix can be sum ma rized by notin g the following point : Th e term
interoperability h as been t rad itionally u sed in th e context of an operational system .
We believe, however, tha t a br oader ap proach to inter opera bility is needed. We base
our determ ination on t he view that interoperability is independent of a domain ofapplicat ion. Int eroperability a pplies t o the acquisition ma nagement an d const ruction
of a collection of system s just as m uch a s it does to its opera tion.
4. It is important to underscore the difference between the terms network-centric operationsand system of systems.The former emphasizes concepts, while the latter emphasizes a realization of those concepts.
8/14/2019 Programmatic Interoperability
15/44
SOFTWARE ENGINEERING INSTITUTE |5
In keeping with th at view, we offer th e following definition ([Levine 03], [Morris 04]):
in t eroperab i l i t y: th e ability of a set of com m un icating entities to (i)
exchange specified inform ation an d (ii) operate on th at in form ation accordin g
to a specified, agreed-upon, operational semantics.5
We emphasize th e doma in-neut ra lity a nd pr imar y nat ure of this definition. Our defi-
nition m ay be applied to any cont ext, such a s th e acquisition m an agement, constr uc-tion, or opera tion of a system of system s. We suggest t ha t our d efinition is
funda ment al, in th at the IEEE and DoD definitions given ea rlier can be derived from
it .6
2.3 INFLUENCE OF INTEROPERABILITY IN ACQUISITION
Given tha t int eropera bility is cent ra l to achieving network-cent ric concepts in sys-
tems of systems an d can be a pplied in ma ny contexts, it is r elevan t to discuss k ey
influences tha t a ffect t he acquisition process. Alth ough ther e ma y be ma ny such fac-
tors, our focus her e is on t hose factors th at closely relate t o th e considerat ions r egard -
ing t he ba sic elemen ts of inter opera bility. Thu s, th e following discussion is couched a t
a h igher level to empha size principles.
2.3.1 Scope of Interaction
Int eropera bility in t he a cquisition pr ocess is influenced by the scope of int era ction
am ong organizat ions t hat part icipate in t he process.In su pport of th is claim , we con-sider th e basic situ at ions sh own in Figure 1.
5. Operational semantics refers, loosely, to the semantics of operations that are performed by an abstract machinecapable of executing a specification. Operations may be defined in terms of pre- and post-conditions whose ap-plication may result in a state change. The meaning of the (abstract) specification, then, is defined in terms of theoperations that may be performed.
6. Quality characteristics such as interoperability are sometimes defined in measurable terms. In this approach, ourdefinition of interoperability would begin with the phrase The degree to which. Although such an approach canbe taken and has interest in its own right, we shall not pursue that path here. The idea of measuring interoperabilitydoes, however, raise the interesting issue of determining the relevant metrics.
Figure 1: Models of the Scope of Interaction
(a) Within thesameorganization
(b) Between differentorganizations,known to each other
(c) Between differentorganizations,possibly unknown
?
Note: Different acquisition functionsare denoted by the symbols
8/14/2019 Programmatic Interoperability
16/44
6 | CMU/SEI-2008-TN-012
The different cases depicted by th e models in Figure 1 are described as follows:
Case (a) represents interoperability within a particular organization. In general,
th is is th e easiest case becau se a sin gle organ ization is likely to ha ve comm on
pra ctices, cult ur e, and decision-ma king processes.
Case (b) represents interoperability between different, but known, organiza-
tions.7 Dealing with differen t organiza tions adds considerat ion for organ izational
policies and pr actices tha t m ight be in conflict. It is as sum ed in th is model th at
the set of commu nicat ing entities is kn own a nd r elatively sta ble over time.
Case (c) is fundament ally different from (b) in that the identity of the other orga-
nizations m ay not be known. This case is a nalogous t o an organization pr esent-
ing informa tion about risk ma na gement to oth ers th at m ay need such
informationindependent of any prior agreement about which organizations
should be given th at inform ation.
The th ree cases can be seen as depicting two situat ions t hat are quite different. The
first two cases ar e t ypical of a boundedenvironmen t, in tha t th e commu nicat ing ent i-
ties and their n umber are k nown (and t ra ditionally they are r elatively stable over
tim e). The last case is cha ra cterist ic of an unboundedenvironmen t in which t he iden-
tity an d num ber of comm unicating entities ma y not be known. That situat ion, an
un boun ded environmen t, is often found in net work-centr ic operat ions a nd syst ems of
systems.8
There a re a dditional concerns th at are related t o the question of scope. For exam ple,
each of th e th ree cases presen ts different governa nce fra meworks. As organ izations
int era ct, the consequen ces of th ose differen t govern an ce fram eworks ma y lead to con-
flicts a mong the ent ities tha t a re less likely when one consider s a single organ izat ion.
The quest ion of governa nce is but one exam ple; we would su ggest an y process per-
formed, such as requirement s man agement or schedule man agement, ma y be asource of contention.
2.3.2 Nature of Agreements
Int eropera bility in t he acquisition process is also influenced by the na tu re of agr ee-
ment s am ong organizat ions t hat part icipate in th e process.Various types of agree-men ts can be consider ed as pa rt of achieving int eroperability:
public la w
con t ra ct u al r ela t ion sh ip s
memoranda of understanding (explici t , yet informal , agreements)
7. There are gradations possible for this case. For example, one could distinguish between organizations that aredifferent but somehow closely related (within the same agency) and organizations that are unrelated (such as anacquisition organization and a contractor).
8. Our intent here is not to go into the details of the unbounded case. However, consider an environment in whichinformation is available to others, although the identity of the consumers of information may not be known. Someorganization may take information from this environment and, if it chooses, enter into an agreement with the or-ganization that placed the information there. This is still an unbounded environment in that others, who may notbe known, can gain information, and then, if necessary, engage in binding agreements with providers of informa-tion. Of course, the nature of agreements need not involve only pair-wise interactions.
8/14/2019 Programmatic Interoperability
17/44
8/14/2019 Programmatic Interoperability
18/44
8 | CMU/SEI-2008-TN-012
In F igure 2, notice th at th e sam e type of fun ction can be perform ed by different t ypes
of organizat ions a nd t ha t t he sa me organiza tion can perform differen t t ypes of func-
tions.
As noted earlier, interoperability has traditionally been considered a property of the
system opera tion domain only. The SEI ha s developed a m odel showing how inter op-
era bility am ong those aspects work s (see Figure 3). The syst em-of-system s int eroper-
ability (SOSI) model arose from a n earlier SE I Independent Research an d
Development effort whose deta ils are described in two previous r eports ([Levine 03],
[Morris 04]).
Figure 3 simply shows two acquisitions, denoted Pr ogra m-1 and P rogram -2. The fun c-
tions performed within each pr ogram are identified as well as th e various types of
interoperability relations between them. While showing only pair-wise interactions,
Figure 2: Mapping of Functions to Organizations
Figure 3: SOSI Model
Functions Organizations
Program-1Management
System-1Construction
System-1
Operation
Program-2Management
System-2Construction
System-2
Operation
Operational Interoperability
Constructive Interoperability
Programmatic Interoperability
Program-1 Program-2
8/14/2019 Programmatic Interoperability
19/44
SOFTWARE ENGINEERING INSTITUTE |9
Figure 3 intr oduces concepts t hat are easily extensible to a lar ger nu mber of organi-
zations. Thus, it includes the ter ms
p rogr a m ma t ic in t er op er a bilit y
This concept refers to interopera bility in th e context of acquisition man agemen t;
it is our focus an d will be discussed furt her .
con st r u ct ive in t er op er a bilit y
This concept r efers to inter operability in th e cont ext of th e const ru ction of sys-
tems.
op er a t ion a l in t er op er a bilit y
This concept refers to inter opera bility in th e opera tional cont ext. The tra ditional
view is that interoperability is viewed as operational interoperability.
Ther e ar e two dimen sions of int era ction sh own in Figure 3. Along t he vert ical dim en-
sion t her e is, as one would expect, int eroperability am ong constit uen ts in t he cont ext
of a particularacquisition pr ogram. In general, this is t he ea sier case, since
The in teract ion between th e funct ions of acquis it ion ma nagement and systemconst ru ction is governed by a cont ra ct, which is a formal a greemen t h aving a
strong intent. The interaction may also include subcontractual relations (e.g., a
prime t o a subcont ractor). It m ay also include other contr actua l agreement s, such
as with an organization th at performs independent verificat ion of a system.
Thus, in genera l, the governance of the r elations am ong th e constitu ents is more
forma l and str onger in intent.
The const i tuents engaged in the acquis it ion of a system have a vested in terest in
th e acquisition process and ma y part icipat e to a significant degr ee. For example,
it is often th e case t hat a u ser (representing the operational commu nity) is
involved in a cquisition m an agemen t decisions. Organ izations t ypically commu ni-cate more with ea ch oth er, th rough, for exam ple, the use of int egrat ed product
teams.
The vert ical, or program -cent ric, perspective shown in Figure 3 has strengths and
weaknesses. Its str engths rest with its focus on a part icular system. Its weaknesses
stem from a failure t o consider a lar ger acquisition perspective tha t limits effective-
ness beyond th e program -cent ric perspective and leads t o the well-known stovepipe
beha vior. The second dim ension of int eroperability sh own in Figure 3 ta kes place
along the h orizont al pers pective. This view focuses on int eropera bility a mong th e
functions perform ed by constit uent s t hat are engaged in differentacquisitions.
This second dimen sion r epresen ts t he m ore difficult case, as t he governa nce processof each organizat ion is more t ena ble; for example, th e relat ion bet ween different
acquisition m an agement organizations m ay be manifest by verbal agreement s ra ther
th an a m ore form al t ype of agreement . There is also little or no explicit r elat ion
between organ izat ions enga ged in the const ru ction of differen t syst ems.9
9. However, there may be implicit relations among organizations producing different systems. A simple example isthat each organization may adhere to the same standard. It is through commonality of standards that one mightexpect interoperability among systems to be achieved. In this sense, a standard serves as the bridge betweensystems, even in the development context.
8/14/2019 Programmatic Interoperability
20/44
10 | CMU/SEI-2008-TN-012
Taken t ogether, th e intera ctions sh own in Figure 3 represent var ious aspects of
interoperability tha t need to be unders tood a ndto the extent practicablema naged.
These aspects lie both within an d between organizations tha t pa rt icipate in t he acqui-
sition process. Fur ther more, it is t he int eraction among th e types of interoperability
th at presen ts cha llenges to the su ccess of acquisition in th e cont ext of a syst em of sys-
tems.The diagram in Figure 3 appear s quite simple, and t here is sometimes a tenden cy to
interpret it in a n equa lly simple mann er. For exam ple, it would be quite easy to
assum e th at program ma tic inter operability represent s inter operability between only
acquisition m an agement organizations . Such an interpr etat ion is overly simplistic
and, at best, ambiguous.
2.5 PROGRAMMATIC INTEROPERABILITY
Our a pproach to developing a definition of program ma tic inter opera bility10 is to
am end t he definition of int eroperability from page 5, as follows:
progra m ma t ic interopera bi l i ty: Th e ability of a set of comm un icatingentities engaged in acqu is i t ion m a na gement activit ies to (i) exchan ge spec-
ified acquisition management information and (ii) operate on thata cq ui si-
t ion ma na gement inform ation according t o a specified, a greed-up on,
operational sem an tics.
The exchanged information has syntactic (form) and semantic (meaning) content.
Syntactic matt ers ar e easier to resolve than seman tic issues. Many concerns can ar ise
out of the inter preta tion of the sema nt ics, however. It is also necessary t o understa nd
th e relat ion bet ween th e two elemen ts. For examp le, a high risk (sema nt ic) might
be defined as h aving a value greater tha n 0.8 (syntactic).
Considerat ion of beha viors is a lso relevan t. Some of th ese beha viors r elat e to comm u-
nicat ion a spects. For example, it is r easonable to assume t hat if an entity gains somenew informa tion, th at entity n eeds to distribute t he informa tion t o oth ers. The infor-
mat ion passed on, th e other entities tha t need it, and th e requirements for its distri-
but ion would have to be worked out . This type of comm un icat ion ens ur es th at ent ities
shar e informa tion deemed relevant with other s tha t need it.
The sharing of information by some entity emphasizes the behavioral aspects of that
part icular entity. From t his, it is importa nt to consider t he collective behavior th at
multiple entit ies perform in t heir a pproach to program mat ic inter operability. For
example, sha rin g of risk in forma tion is th e first step; wha t m ust follow is the collec-
tive beha vior t o deal with tha t risk informa tion.
To engage in collective beha vior, ent ities mu st also have some kn owledge of the qua l-
ity of that information. Sharing high-quality information leads to trust among com-
mu nicat ing entit ies. However, shar ed inform at ion of low qualit y or highly var iable
quality can lessen tr ust, r esulting in behavior t hat is less likely to have positive
results.
10. In the following we refer explicitly to acquisitionmanagement, as opposed to simply management. Managementoperations are performed in all contexts, such as the construction or operation of a system. Correspondingly, aterm such as management interoperability would be ambiguous without the context in which that managementoccurs.
http://-/?-http://-/?-8/14/2019 Programmatic Interoperability
21/44
SOFTWARE ENGINEERING INSTITUTE |11
Consider an example from risk m an agement. Most discussions of risk m ana gement
include some discussion of processes rela ted t o risk iden tificat ion. Ther e ar e ma ny
met hods (an d tools) to identify risks, such as in ter views, bra inst orming, question-
na ires, and ana lysis of risks on similar projects. E ach of th ese meth ods m ight apply
different r esources and pr ovide result s of differing qua lity. Despite a ll of th at variet y,
some knowledge of the qu ality of inform at ion a bout risks is needed if the sh ar ing ofth at inform at ion is to foster collective beha vior.
But the informa tion exchan ged and t he quality of th at inform ation ar e separa te con-
siderations. The quality of inform at ion in a sta ndar d and the m eans by which t hat
informa tion is est ablished, for inst ance, are deter mined t hrough th e implementa tion
of pra ctices by an organ ization. By implicat ion, organizat iona l practices relevant to
some programmatic function can directly impact the quality of the information gath-
ered an d exchan ged.11
The preceding discussion ha s illustra ted several a spects of programm at ic inter opera-
bility, including sha rin g of inform at ion a nd en gaging in collective beha vior in light of
concerns regarding syntax, semantics, and qualities of information. The activities,an d their cha ra cterist ics, are relevan t when one seeks to face the challenges of viable
acquisition in a system -of-system s cont ext su ccessfully.
11. For processes, compliance to some model, such as the CMMIframework, alone does not always produce high-quality results in an implementation. In short, compliance is necessary, but it is not sufficient. The SEI report Pro-cess Considerations for Interoperable Acquisitionexamines the role of process in interoperable acquisition [Gar-cia 06]. (CMMI is registered in the U. S. Patent and Trademark Office by Carnegie Mellon University.)
8/14/2019 Programmatic Interoperability
22/44
12 | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
23/44
SOFTWARE ENGINEERING INSTITUTE |13
3 The Programmatic Aspect of Interoperability
In t his section, we explore t he ma in concepts of program ma tic inter operability, pro-
vide some examples of problems an d successes in program ma tic interopera bility, an draise some questions for research. P rogram ma tic interoperability perm its acquisition
entities to make bett er decisions with r egard to the acquisition m ana gement a spects
of a syst em-of-system s environmen t. To meet t he need s of a s ystem of system s, it is
importa nt to str ess th e perspective of a collection of ent ities in th e processes th at
influence the pr oduct(s) delivered t o th e end us er.
3.1 CONCEPTS
A view of program ma tic inter operability tha t bu ilds from our gener al definition of
program mat ic interoperability on page 10 an d emph as izes acquisition is a s follows:
progra m ma t ic interopera bi l i ty: Th e ability of a set of com m un icating
entities to achieve a shared u nd erstan din g with respect to acquisition m an-
agem ent fu nction s to allow th em to engage in effective collective behav ior.
This definition naturally leads to several questions, namely:
What are the communicat ing ent it ies that par t icipate in acquis it ion manage-
ment activities?
What acquis it ion mana gement information needs to be shared to achieve pro-
gramm at ic inter operability?
How is the qual ity of the relevant information determined?
What beha viors a llow effective collective behavior? How is effectiveness of behav-
ior determ ined?
In t he following sections, we briefly comm ent on th ese quest ions th rough viewing
three concepts of programmatic interoperability: communicating entities, sharing of
acquisition m ana gement informa tion, an d operat ions on t he sh ared informa tion.
3.1.1 Entities and Their Means of Communicating
From a DoD acquisition perspective, we can a ssume t ha t t he entities most relevant to
program mat ic inter ests a re t he a cquisition m ana gement office (typically a PMO) and
program execut ive office (PEO). Oth er r elevant ent ities ma y be a milest one decision
agen t (MDA) or a r esource allocat ion repr esent at ive such as t he well-known Pr ogra m,
Plann ing, Budgeting, and Execut ion System (PPBE S).12 Overall, th e ra nge of com-
municating entities could include
PMOs, PEOs, MDAs, and serv ice acquis it ion author it ies
Federal agencies , such as the Depar tment of Homeland Secur i ty (DHS)
Congress iona l over sigh t commit tees
st a t e a n d loca l gover nm en t s
in ter na tiona l pa rt ner s
12. Some background on the PPBES system can be found at on the organizations Web site [PPBES 03].
8/14/2019 Programmatic Interoperability
24/44
14 | CMU/SEI-2008-TN-012
In a ddition to governm ent organizations, other types of entities m ay pa rt icipate in
the acquisition m an agement process, such a s
contractors of the systems that are in tended to in teroperate
r ep re sen t a t ive s fr om th e u se r com m u nity
managers of suppliers of commercial products that are used in the systems13
Two other factors ar e as import an t a s th e identificat ion of ent ities: (1) th e mean s by
which ent ities comm unicat e a nd (2) the protocol employed (where a protocol defines
th e synta x and sem an tics of a comm un icat ion pr ocess). When consider ing a pr otocol,
entities a lso must address concerns about when and how commu nicat ion t akes place.
3.1.2 Acquisition Management Information
By looking at th e acquisition ma na gement inform at ion, we ar e moving from a focus
on who communicates and how they communicate to whatis comm unicated. We ar e
interested h ere in t he informa tion tha t needs to be visible in order to achieve inter op-
erability in the programmatic context. Certainly, information associated with sched-
ule (especially schedu le varian ce) falls int o this category. Inform at ion r elat ed to
products (both fun ction a nd qua lity) is a pr ime candida te, too, as is inform at ion
related t o risk man agement. Oth er t ypes of inform at ion m ay be necessary as well,
notably drivers from the operational community.
Those element s ma y be obvious t ypes, but oth er form s of inform at ion a re less well
recognized. Consider cost, for in sta nce: Wha t in form at ion r egard ing cost n eeds t o be
shar ed, and wh y does it n eed to be shar ed? Questions surr ounding t he sha ring of cost
inform at ion illustr at e a typical difficulty in achieving int eroperability in an a cquisi-
tion man agement context. P rogram s a re n at ura lly protective of cost informa tion.
However, th e ability to repr ogram funding am ong program s ma y just ify shar ing cost
information.14 Similar ly, one m ight expect to gain insight into risks a ffecting sched-
ule. However, which risk, wha t level of deta il about th e risk, an d how the qua lity of
inform at ion a bout th e risk is t o be assessed n eed to be ident ified. Indeed, for a ll types
of inform at ion, ent ities need to specify what deta ils (an d at wha t level of specifica-
tion) are relevant to share and be a ble to assess the qua lity of informa tion sh ared.
13. The list of other entities can be extended to include various types of organizations involved in short-term, limitedinteractionsa view that brings one close to virtual organizations and their collaboration, a tenet ofnetwork-centric operations.
14. Reprogramming thresholds for costs among programs are specified in statute. Overall, we might ask: Do statutesand DoD policies impose a barrier on achieving programmatic interoperability? If they do, what needs to bechanged? The implications of statute (in particular, Title 10) for acquisition in a system-of-systems context is underexamination by the authors of this technical note and will appear in a forthcoming report.
8/14/2019 Programmatic Interoperability
25/44
SOFTWARE ENGINEERING INSTITUTE |15
3.1.3 Operations
An entit y perform s behaviors, and a beha vior m ay be viewed as a n operat ion. Of rele-
vance to the program ma tic aspect is t ha t t hese operat ions a re performed on acquisi-
tion ma nagement inform at ion.15 We consider a pr ocess t o be an encapsu lat ion of
operat ions. Many types of processes ar e relevant to acquisition ma nagement , such a s
those dealing with a cquisition st ra tegy mana gement, cost m ana gement, contr actman agement, schedule ma nagement, or r isk ma nagement.16 Details of specific pr o-
cesses are n ot r elevant to this report.
There a re pr oblemat ic issues with informa tion about process, part icularly with
respect to interopera bility among processes. Some a rgue t hat the outputfrom a pro-
cess is relevant a nd th at how th e out put is produced is not importa nt. A count er to
this argum ent is tha t shar ing details of how a process is performed can be useful, if
only as a learning opportu nity. Fur ther , those details could be used to judge the qua l-
ity of work per formed. Whether th ey deem t he output or t he deta il importan t, ent ities
need t o establish a fram e of reference to effectively sha re a ny pr ocess-derived infor-
mation.
3.1.4 Summary of Perspectives on Programmatic Interoperability
Pr ogram ma tic inter opera bility, as weve seen, can be considered from t he per spec-
tives of commu nicat ing entities, the inform at ion t hey shar e, and t he operations tha t
are perform ed on t hat inform at ion. In essence, these th ree perspectives represent ele-
ments in an acquisition in a system-of-systems cont ext, a situa tion t hat we fram e as
interoperable acquisition. The SEI ha s reported on research int o some key ar eas for
int eropera ble acquisition: cha llenges facing th e ent ities involved [Smith 06], risk
management [Meyers 06b], and schedule [Meyers 06c].
15. The operations (behaviors) of each entity are important; even more significant is collectivebehavior.
16. The SEI work in the area of processes for acquisition includes the CMMI framework for process and product im-provement [Chrissis 03] and its extension for acquisition organizations [Dodson 06]. It is also expected that theSEI will release the CMMI for acquisition (denoted CMMI-ACQ) in the near future.
8/14/2019 Programmatic Interoperability
26/44
16 | CMU/SEI-2008-TN-012
3.2 PROGRAMMATIC INTEROPERABILITY EXAMPLES
These examples ar e based on our intera ctions with cust omers a nd include both prob-
lems and successes.
Table 1: Examples of Programmatic Interoperability
Context Problem Resolution or Outcome
Reuse in an
integration context
Development of a large system emphasized
the reuse of products created by other acqui-
sition efforts. However, the integration agent
did not specify any entrance criteria for can-
didate reusable products. The products were
selected without regard to maturity or quality.
Numerous problems plagued the integration
effort. One unresolved issue was the ques-
tion of who should pay to make changes to
the reused products.
Synchronization
through a contract
specifying the use of
standards
In an acquisition effort where multiple sys-
tems were expected to interoperate, some
synchronization among the programmatic
entities was needed. One implicit approach
to achieving the desired synchronization was
through the contract that mandated compli-
ance with various standards.
Unfortunately, different implementations of
the same standard caused problems during
integration. Contracts are typically structured
from the perspective of a particular system,
rather than the collection of systems.
Integration ofrequirements
In an acquisition effort where multiple sys-tems were expected to interoperate, require-
ments were placed against the individual
systems and their integration. But little atten-
tion was paid to conflicts among require-
ments. Furthermore, there was a conflict
between the top-down approach specified in
DoD policies and the actual, bottom-up pro-
cess employed to achieve interoperability
between operational systems.
The lack of any acquisition managementprocess that addressed the full scope of
requirements management (i.e., require-
ments at the system-of-systems level) was
an ongoing source of difficulty. (Require-
ments management conflicts in a system of
systems are discussed in a previous report
[Meyers 06a].)
Schedule problems
in integration
In a simulation for a large collection of sys-
tems, insufficient attention was paid to the
coordination and acquisition management of
the overall schedule. Thus, it was not sur-
prising when the simulation was not deliv-
ered on time.
There was a delay in meeting schedule.
Also, the rush to produce one system less-
ened its quality and caused problems in inte-
gration. It was not simply the lack of an agent
responsible for coordination of schedules; of
greater importance was the lack of sharing ofinformation.
Joint award fee
boarda
a. Joint award fee boards have many interesting aspects, including the business strategies of the organizations in-volved in constructing a system. For example, a contractor may choose to sacrifice part of an incentive fee awardto satisfy longer term business goals. Or, intellectual property concerns about sharing information among devel-opment organizations may warrant taking such a position. (One counter to this action is the use of past perfor-mance evaluations by government, but its use may be diff icult.) The preceding examples underscore thatacquisition in a system-of-systems context and its inherent interoperability considerations can be significantly dif-ferent from the acquisition of a particular system.
Two PMOs used the same prime contractor
for their respective systems. The systems
being produced had a number of important
interoperability requirements. The PMOs
decided to conduct a joint award fee board.
Rather than satisfying an individual PMO,
the award fee board changed its focus to
stress interoperability between systems. The
contractor preferred this approach; a
decrease in interoperability problems
resulted.
System engineering
resourcing oversight
A number of large systems were being
acquired separately. However, it did not take
long to realize that there had been no alloca-
tion of resources (funding and staff) in order
to address issues related to system engi-
neering of the collection of systems.
The individual programs could not work out
the resourcing oversight, because they
focused on their own systems. Failure to rec-
ognize programmatic concerns related to
system engineering caused difficulties
throughout the integration.
8/14/2019 Programmatic Interoperability
27/44
SOFTWARE ENGINEERING INSTITUTE |17
In ea ch case det ailed in Table 1, ther e are im plications for h ow th e ma nagement of an
acquisition involving a collection of system s can be appr oached. In th e reu se scenar io,
for inst an ce, th e absence of crit eria for selectin g products proved detrimen ta l; in th e
examp le of a cont ra ct used t o synchronize integra tion activities, the rep eat ed use of
th e sam e sta ndar d caused problems due to differing implementa tions; failure t o rec-
oncile requirem ent conflicts, coordinat e schedules, or pr ovide adequ at e resour ces forsystem -of-system s engineer ing nega tively affected other effort s. One a pproach did
ha ve positive resu lts: th e use of a joint a war d fee boar d provided incent ives to focus
on t he int eroperability between systems.
Pr oblems r esult ed in five of th e six examples described in Table 1. One inference from
th e out comes is th at a t ra ditional appr oach to acquisition is not sufficient for a sys-
tem -of-system s environmen t. Ea ch out come, th e problems a s well as t he success, sup-
ports our cont ent ion t ha t operat iona l inter opera bility is more likely to be achieved if
consider at ion of program ma tic (an d const ru ctive) int eropera bility is addr essed
throughout the acquisition process.
3.3 PROGRAMMATIC INTEROPERABILITY RESEARCH ISSUES
Many issues su rround program ma tic interoperability, including
How does one identify the communicating entities that participate in programmatic
interoperability and their degree of boundedness?
Clearly, it is necessary to ident ify the en tities th at need to comm unicate in order t o
achieve programmatic interoperability. An interesting aspect of this question is the
bounded or unbounded nature of the interactions. We see two relevant perspectives,
illustr at ed in Figur e 1 on pa ge 5 where:
1. the entities and their number are known and relatively stable over time (the
boun ded case)
2 . the ent it ies and their number are not known (the unbounded case)
These perspectives represent limits in th e temporal intera ctions am ong the int er-
ested ent ities. It is one thing to shar e informa tion with a r elatively small num ber of
entities, but it is quite something else to ma ke informa tion a vailable to an yone.
Notice t hat th e un bounded case has a close par allel to discussions a bout network-cen-
tric operations.
What information must be shared to achieve programmatic interoperability?
Describing the comm unicating ent ities, acquisition man agement informa tion, a nd
operat ions on th at inform at ion is importan t, as we m entioned in Section 3.1. Of evengreat er significance is to ident ify the specific entities, acquisition ma nagement infor-
mation, and operations. Consider the case of sharing information about schedule in
th e context of risk ma nagement . Should an organization expose th e inability to meet
a scheduled m ilestone? We say yes. But should th e organ ization also expose the risks
associated with failing to meet th at milestone? This question is problemat ic. An orga-
nizat ion m ight st at e a risk in t his way: The int egrat ion facility is not on schedule due
to a delay in implemen tin g air condit ioning in t he facility; th ere is a risk t o th e sched-
http://-/?-http://-/?-http://-/?-http://-/?-8/14/2019 Programmatic Interoperability
28/44
18 | CMU/SEI-2008-TN-012
ule for t he rea diness of th e facility. Is it r eally necessary t o expose th at th ere is a r isk
to th e complet ion of th e facility due t o an a ir condit ioning pr oblem? Many organiza-
tions would argue t hat th e importa nt point is tha t the facility is not on schedule.17
How does one assess the quality of information shared?
Ent ities need to know the qua lity of shared informa tion t o make decisions t ha t will
affect t heir collective beha vior. Typically, pieces of inform at ion ar e of var ying qua lity.
The r an ge of inform at ion qu ality could be reflected in decisions r eached on t ha t infor-
ma tion. How can an organizat ion kn ow whet her th e inform at ion pr ovided is of suffi-
cient qua lity th at th e collective decisions rea ched an d collective beha vior per form ed
are appropriate?
What are the implications of programmatic interoperability for process?
The r ole of process in acquisition is well known; it ha s been incorpora ted, for exa mple,
int o the CMMI fram ework for a cquisition [Dodson 06]. When we add a considera tion
of inter opera bility t o acquisition, t wo issues em erge:
1. How should existing processes be modified to account for int eroperability whenthe scope of an a cquisition is lar ger th an an individual program?
2. What additional processes are necessary to address interoperability among
acquisition m ana gement organizations?
Notice th at each of th e examples given in Section 3.2 ha s implications for a cquisition
processes. We expect that questions related to process are important, because a pro-
cess perspective is expected to be an importa nt componen t of program ma tic int eroper-
ability.18
What collaborative behaviors support successful programmatic interoperability?
A key to achieving program ma tic inter operability is th at the relevant entities engagein collective beha vior beyond sha ring informa tion. In pa rt icula r, for a function su ch
as r isk ma nagement , it is necessar y to identify behaviors for ea ch entity a s well as
collaborat ive behaviors for all relevant ent ities. A star t t o ident ify collabora tive
behaviors h as been discussed for schedule ma na gement in Schedule Considerations
for In teroperable Man agement[Meyers 06c].
How much automated support can be provided to programmatic interoperability?
We envision a cquisition being condu cted with great er supp ort from a ut oma ted sys-
tems. We believe more aut oma tion is necessary to meet th e increased deman d for
acquisition ma nagement informa tion shar ing. If one a ccepts t his prem ise, where can
such support be brought t o bear? For example, if there is a cha nge to some a tt ributeof a schedule for s ome system (e.g., a modificat ion t o a m ilestone or t he knowledge of
its schedule var iance), how can th at inform at ion be efficiently distr ibuted? How can
such informa tion be fur ther processed by receiving entities with aut oma ted su pport ?
17. An example like this one suggests that how much risk information an organization is willing to share in generaland what the term interoperable risk managementwould entail are also interesting areas for investigation. Thissubject is pursued further in Risk Management Considerations for Interoperable Acquisition[Meyers 06b].
18. For more information, see Process Considerations for Interoperable Acquisition[Garcia 06].
8/14/2019 Programmatic Interoperability
29/44
SOFTWARE ENGINEERING INSTITUTE |19
In t he lan guage of th e CMMI fra mework, we seek more aut oma ted pr ocess cont rol
wher e cont rol can be exercised even by au tonomous agent s.19 Notice th at th e goal
her e is similar t o th at for network-cent ric operat ions: the benefit gained from th e use
of automated support in order to obtain grea ter shar ing of informa tion t hat permits
collaborat ive beh avior.
What are the metrics to assess programmatic interoperability?
In d iscussin g our definition of int eroperability (see page 5), we ment ioned tha t pr e-
ceding it with t he ph ra se th e degree to which recast s th e definition in term s of met -
rics. But wha t are t he useful metrics, and more importan tly, how would th ey be used?
Some examples of possible met rics have been discussed ea rlier in r egard t o schedule
information [Meyers 06c].
What are the impediments to achieving programmatic interoperability due to the legal
and regulatory framework?
The en vironm ent in which a cquisition occurs is influenced by man y thin gsfrom
sta tu tes an d regu lat ions (e.g., Feder al Acquisition Regulat ions) to DoD policy, direc-tives, an d business pra ctices. Although one m ay often hear th at th e legal environ-
ment causes problems for achieving interoperability, is this assumption borne out by
th e text of the st at utes a nd regulat ions t hemselves? And if it is, what chan ges to the
sta tues a nd regulations need to be made?
What approaches lead to successful programmatic interoperability?
All of the pr eceding issues apply t o the goal of having an appr oach to achieve pro-
gramm at ic inter operability. In order for th at approach to be developed, fur ther iden-
tificat ion a nd exam ina tion of all issues, as well as th eir int egrat ion, is necessary. We
an ticipate tha t an y approach must address th e three funda ment al char acteristics of
programmatic interoperability: communicating entities, information shared, and col-lective beha viors. On e init ial a pproach, whose concepts a re continu ing to evolve, has
been described in System-of-Systems Navigator: An Approach to Managing System-of-
Systems Interoperability[Brownsword 06].
How does interoperable acquisition affect programmatic interoperability?
The phr ase int eroperable acquisition is a shortha nd for int eroperability in t he a cqui-
sition process. An interoperable acquisition approach would address programmatic,
operat ional, a nd const ructive interoperability aspects tha t ar e necessary to produce
systems r equired to interoperate, a s well as integrat ion of these aspects of interopera-
bility. Some work in int eroperable acquisition by the SE I ha s been done, ra nging from
ontologies t o models (includin g forma l models) ([Meyers 05], [Meyers 06b], [Meyers
06c], [Smit h 06]).
How extensible are research questions regarding programmatic interoperability to
19. There is a close connection here with process, particularly in the modeling of a process to achieve some purposesuch as interoperability and in the realization of that model.
8/14/2019 Programmatic Interoperability
30/44
20 | CMU/SEI-2008-TN-012
other aspects of interoperability?
Issues relat ed to interoperability m ay be described in term s of a p rogram mat ic, a sys-
tem const ru ction, or a n opera tional persp ective. However, man y issues a pply equa lly
to these differen t domain s. For exam ple, th e issue of wha t inform at ion is necessary to
be shar ed applies to each domain. To the extent th at research findings regarding pro-
gram ma tic int eropera bility can be applied to other a spects of int eroperability, ther e isth e opportu nit y to develop more genera l appr oaches for t he r esolut ion of issues.
8/14/2019 Programmatic Interoperability
31/44
SOFTWARE ENGINEERING INSTITUTE |21
4 Enlarging the Context
The pr eceding discussion focused on progra mm at ic int eropera bility, which is but one
asp ect of int eropera bility. As weve shown, t he SOSI m odel (see Figur e 3 on pa ge 8)also includes const ru ctive an d opera tional int eroperability aspects. To achieve
interoperability, it is n ecessary to underst and not only each a spect but also the inter-
actions between th em.
4.1 OVERVIEW
We can illustr at e th e orchest ra tion of aspects of int eroperability in a system -of-sys-
tems context by extending Figure 2 (from page 8) to consider mu ltiple organizat ions
th at ar e producing systems expected to interoperate in a system-of-systems context.
Figure 4 shows th e functions perform ed an d t he organ izat ions involved for two differ-
ent systems that are expected to interoperate in a system-of-systems context. As in
Figure 2 on page 8, the same organization can perform multiple functions, and t he
sam e fun ction can be perform ed by more th an one organizat ion.
In t his figur e, however, we show interopera bility relat ions bet ween functions with in
each system t hr ough conn ecting lines; fur th er, oth er conn ectin g lines between organ i-
zations in a system imply int eroperable relations t hat result from t he related func-
tions. Also, heavy, arr owed lines bet ween functions performed by organizat ions in
different systems connote t hat it is necessary to orchestra te t he a ctivities relevan t to
each system in a way tha t some larger goal is achieved, such a s an acquisition m an-
Figure 4: Illustrating Orchestration of Interoperability Aspects in a Multisystem Context
FunctionsOrganizations
denote different types of functions (e.g., programmatic, constructive and operational) per-formed by the indicated corresponding type of organization shown as squares
Functions Organizations
System A System B
8/14/2019 Programmatic Interoperability
32/44
22 | CMU/SEI-2008-TN-012
agement organization perform ing a risk m ana gement activity an d needing to provide
its resu lts to mu ltiple organizations.
For an example of this orchestr ation, consider a situat ion in which m ultiple systems
are being developed and must synchronize their schedules. This synchronization
might r equire dealing with cost factors related to schedule in one system and technol-
ogy factors rela ted t o schedule in an other syst em. The orchestr at ion of th ese factors isa su bject t ha t m ust be considered to achieve th e broader goal of int eropera bility.
4.2 PERSPECTIVES ON INTEROPERABILITY INFLUENCES
J ust as ea ch aspect of inter operability is influenced by scope, nat ur e of agr eement s,
and sha red informa tion (as detailed in Section 2.3), so, too, is t he orchest ra tion of
those aspects:
scope of in t er a ct ion
An increase to th e scope of int eraction m eans t hat man y more organizations pa r-
ticipate in t he pr ocess. The nu mber a nd t ype of functions per form ed by th ese
organizat ions a re rela tively const an t. All systems, for inst an ce, requ ire cost est i-mat ion, risk man agement, ar chitectur e, and t esting. However, the implementa -
tion of th ose functions can differ a s t he n um ber a nd t ype (e.g., governm ent or
indus tr y) of organizat ion in crease. In a ddition, we would expect cha nges to exist-
ing processes, and per ha ps even new pr ocesses, ar e necessar y to achieve pro-
gramm at ic inter operability.
n at ur e of a gr eem en ts
The inclusion of more organizations means greater a variety of agreements
among them . For example, there m ay be a n eed to develop an agreement am ong
organizat ions for t he dist ribut ion of inform at ion.
sh ar ed in for ma tion
The am ount of inform ation tha t m ust be sha red will depend on t he functions tha t
are perform ed. For example, some informa tion regarding cost ma nagement ,
schedule man agement, an d risk man agement is a likely candidate. With agree-
ment s in place regarding h ow th e informa tion m ay be distr ibuted, one would
expect th e synta x and seman tics of such informa tion t o be sha red. One might
expect th at such informa tion would be specified in a st anda rd t hat can be used by
all part icipants; in t ha t case, th e functions sh own in Figure 4 would collaps e t o a
single set. This scenar io ass um es th at th e specification of functions per form ed is
sufficient t o addr ess int eroperability considerat ions a mong those fun ctions,
which need not be (and in our experience is not) the case.
8/14/2019 Programmatic Interoperability
33/44
SOFTWARE ENGINEERING INSTITUTE |23
However, as we point ed out in S ection 3.1, it is not simply inform at ion relevan t
to the functions performed tha t is of int erest. The sha ring of tha t inform at ion is
necessar y but n ot sufficient to achieve collective beha vior t ha t m eets t he goals of
acquisition in a system -of-system s cont ext. Knowledge of th e qua lity of inform a-
tion sha red is also needed t o asses s its r elevance to any decisions r egardin g col-
lective behavior.
20
For each of th ose th ree factors, a fram e of reference th at promotes effective mu tu al
understanding of the information exchanged is needed. For example, consider the
case where one program develops cost estimat es using a par am etric approach.
Anoth er pr ogram develops cost estim at es usin g activity-based cost ing. In order for
th ese progra ms t o sha re cost inform at ion effectively, th ey must first sh ar e a fram e of
reference. The mut ually compat ible frame of reference permits t hem to shar e rele-
vant inform at ion an d ta ke appr opria te collective action (beha vior) on it. Thu s, to
shar e cost estima ting informa tion, the pr ograms in our example need to underst and
each other s appr oach to obta ining estima tes. Without a comm on, or at least compa ti-
ble, fra me of referen ce, effective sha ringand un derst an dingwill not be possible.
4.3 IMPLICATIONS
The orchestr at ion of activities an d decisions n eeded across all aspects of int eropera -
bility is a su bject in its own right. We ar e suggesting th at orchestra tion m akes a chiev-
ing programm at ic interoperability more complicat ed tha n one might a t first th ink.
Fu rth ermore, interoperable acquisition must account for th e int eraction of various
aspects of interoperability. Yet, as an increase in scale further breaks the bonds of
coupling, how can one un dersta nd a nd a ddress th e new environmen t?
20. If one takes a standards-based view on relevant information that could be shared (such as risk management), itis noteworthy that standards documents rarely, if ever, discuss the means by which information may be obtainedor its quality assessed.
8/14/2019 Programmatic Interoperability
34/44
24 | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
35/44
SOFTWARE ENGINEERING INSTITUTE |25
5 Summary
The t erm int eroperability ha s t raditionally been used in the cont ext ofoperational
systems. This report suggests a broader scope for t his ter m th at encompasses opera-tional, const ru ctive, an d program ma tic aspects. We specifically discuss t he a spect of
program m atic int eroperability , which we define a s
progra m ma t ic interopera bi l i ty : Th e ability of a set of com m un icating
entities engaged in acquisition m an agement activities to (i) exchan ge speci-
fied acquisition m an agement in form ation an d (ii) to operate on tha t acquisi-
tion m an agement in form ation accordin g to an a greed, operationa l sem an tics.
We propose th at program ma tic int eroperability is centr al t o acquisition in a system-
of-system s cont ext. When we orient our definit ion t owar d th e needs of th e acquisition
comm unity, we see tha t t he comm unicating entities need to achieve a sh ared u nder-
sta nding a bout acquisition ma na gement functions (th rough exchan ging informa tion
an d oth er actions) tha t a llows th em t o act collectively in th e cont ext of a t he system -
of-systems environment. The purpose, then, of programmatic interoperability is to
assu re t ha t a collection of ent ities can successfully opera te r egardin g the a cquisition
ma nagement in th e context of a system of systems.
In t his report, we examine a num ber of topics related t o programm at ic int eroperabil-
ity including concepts, exam ples, and research quest ions. Fu rth er, we argue t hat a
connection exists among all three aspectsoperational, constructive, and program-
ma tic. In order t o achieve interopera bility in t he operat iona l context (which is th e
desired st at e), it is necessar y to also consider pr ogram ma tic and const ru ctive inter op-
era bility as pects. In add ition, it is necessar y to consider th e orchest ra tion of activities
an d decisions across all aspects of int eroperability.
8/14/2019 Programmatic Interoperability
36/44
26 | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
37/44
SOFTWARE ENGINEERING INSTITUTE |27
Appendix A Definitions of Interoperability
In t his Appendix we present a num ber of approaches to the definition of the term
int eroperability. For example, IEE E h as t he following definitions [IEE E 00]:the ability of two or more system s or elements to excha nge informa tion an d to
use the informat ion that h as been excha nged
the capability for un its of equipm ent to work together to do useful fu nctions
the capability, prom oted bu t not gua rant eed by joint conform an ce wit h a
given set of stand ard s, that enables heterogeneous equipm ent, generally built
by various vendors, to work together in a n etwork environm ent
the ability of tw o or m ore system s or components t o exchange inform ation in a
heterogeneous network and use that in formation
DoD also uses mu ltiple definitions of int eropera bility, all of which ar e bas ed to some
degree on th e definitions developed by IEE E. F or examp le, one definition is [DoD 00]
1. The ability of systems, units, or forces to provide services to and accept ser-
vices from oth er systems, n its, or forces an d t o use the services so excha nged t o
enable them to operate effectively together. 2. The condition achieved am ong
com m un ications-electronics systems or items of com m un ications-electronics
equip m ent wh en informa tion or services can be exchan ged d irectly and sa tis-
factorily between them an d/ or their users. Th e degree of interoperability
should be defined when referring to specific cases.
Item 2 of th e preceding definit ion wa s lat er m odified in t he following ma nn er in con-
nection with the Joint Requirements Oversight Council [DoD 02]:
2. Th e condit ion achieved am ong com m un ications-electronics systems or
items of com m un ications-electronics equipm ent w hen inform ation or services
can be excha nged directly and satisfactorily between them a nd / or their users.
Th e degree of in teroperability should be defined w hen referring t o specific
cases. For the purposes of this instruction, the degree of interoperability will
be determin ed by the accomp lishm ent of the proposed in format ion exchange
requirem ents fields.
Fur th er, in the context of th e Joint Cap abilities Integration Development S ystem
[DoD 05], th e following appea red:
Th e ability of systems, un its or forces to provide data , informa tion, m ateriel
and services to and accept the sam e from other system s, un its or forces and to
use the d ata, in formation, m ateriel an d services so excha nged t o ena ble them
to operate effectively together. Inform ation techn ology an d N ational S ecurity
S ystems in teroperability includ es both th e technical excha nge of inform ation
and th e end -to-end operational effectiveness of th at excha nged in formation a s
required for mission accomplishment.
In t he cont ext of th e Global Inform ation Grid, th e following is found [DoD 01]:
(1) Ability of inform ation systems to comm un icate with each other an d
exchange inform ation. (2) Conditions, achieved in varyin g levels, when in for-
m ation system s an d/ or their com ponents can exchange informa tion directly
and satisfactorily am ong them . (3) The ability to operate softwa re and
8/14/2019 Programmatic Interoperability
38/44
28 | CMU/SEI-2008-TN-012
exchan ge informa tion in a heterogeneous n etwork (i.e., one large network
m ade u p of several different local area n etworks). (4) System s or program s
capable of excha ngin g in formation and operating togeth er effectively.
The U. S. Congress also has int erest in interoperability. For exam ple in th eE-Govern-
m ent A ctof 2002 [USC 02] one finds t he following:
Int eroperability m eans th e ability of d ifferent operating an d software sys-tems, applications, and services to comm un icate an d exchan ge da ta, in an
accurat e, effective, and consistent m an ner.
Of interest to the DoD are sta tement s regarding interoperability th at ar e specified in
law, in par ticular Tit le 10 is the U.S. Code [USC 04]. Although the t erm int eropera-
bility is not defined th ere, it is used in a n um ber of ways:
research and development projects (10 USC 2358)
establish ing s tandards and cooperat ive research work with NATO (10 USC
2350B an d 2457)
responsibility of the Chief Informat ion Office to ensure interoperability (10 USC
2223) acquisition auth ority for joint experimenta tion by the Unified Combatan t Com-
ma nd (10 USC 485)
assessment of capabilities, adequacy, and interoperability of coalition forces (10
USC 153)
Two point s ar e relevant about a perspective of int eroperability based on Title 10.
Fir st, one must be car eful in so strict a view, because th e word int egrat ion (or a syn -
onym) ma y be used inst ead of int eroperability. Somet imes int eroperability is
implied.21 Second, a nd p erh aps of more pr actical significan ce, one can not forget all
the regulations, policies, and pr actices th at ar e later implemented by DoD in r esponse
to the la nguage in Title 10.
We can su mm ar ize an examin at ion of th e definitions of int eroperability by noting th e
following point : Th e term interoperability ha s been tra ditiona lly used in th e context of
an operationa l system .
21. One gains an interesting perspective by examining the language in Title 10. For example, in 10 USC 124, theDoD is designated as the single lead agency for the Federal Government for detection and monitoring the transitof illegal drugs into the U.S. The word interoperability does not appear in the that text. However, in Pub. L. 106-65 1043 (October 23, 1992), the rationale for DoD assuming lead-agency responsibility is explicitly stated as(3) to promote commonality and interoperability between counter-drug detection and monitoring systems in acost-effective manner. . . . Thus, from Public Law to Title 10, consideration of interoperability went from explicitto implicit. This migration should not be viewed as diminishing its importance [USC 04].
8/14/2019 Programmatic Interoperability
39/44
SOFTWARE ENGINEERING INSTITUTE |29
References
URLs are valid as of the publication date of this document.
[Alberts 99]Albert s, David S., Gartska , J ohn J ., & Stein, Fr ederick P. Network Centric Warfare.
Comma nd a nd Control Research Pr ogram Publication Series, 1999.
h t tp :www.dodccrp.org/files/alberts_NCW.pdf
[Brownsword 06]Brownsword, Lisa, Fisher, Da vid, Morris, Ed, Sm ith, J ames, & Kirwan , Pa trick.
S ystem -of-S ystem s N avigator: An Approach to Man aging S ystem -of-S ystem s
Interoperability (CMU/SEI-2006-TN-019, ADA449276). Software Engineering
Institute, Carnegie Mellon University, 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06tn019.html
[Chrissis 03]Chrissis, Mary Beth, Konra d, Mike, & Shrum , Sandy. CMMI: Guidelines for Process
Integration and Produ ct Im provement. Addison-Wesley, 2003.
[DoD 00]Department of Defense.DoD Dictionary of Military a nd Associated T erm s (Joint
Pu blicat ion 1-02, J un e 14, 2000). http://www.dtic.mil/doctrine/jel/new_pubs/
jp1_02.pdf
[DoD 01]Department of Defense. Global Informat ion Grid (GIG) Capstone Requirem ents
Docum ent (CRD) (Flag Dra ft, Ma rch 28, 2001). http://www.dfas.mil/technology/pal/
spipgmdc/policy-regs/gigcrdflaglevelreview.pdf
[DoD 02]Depar tm ent of Defense,Joint Requirem ents Oversight Coun cil (JR OC) Program m atic
Processes for J oint Experim entation an d J oint Resource Cha nge Recomm enda tions
(Chairm an of th e J oint Chief of Sta ff Inst ru ction [CJ CSI] 3180.01, October 31, 2002).
http://www.dtic.mil/cjcs_directives/cdata/unlimit/3180_01.pdf
[DoD 05]Department of Defense,Joint Capabilities Integration and Development System
(Cha irma n of the J oint Chief of Staff Instr uction [[CJCSI] 3170.01E, May 11, 2005).
http://www.dtic.mil/cjcs_directives/cdata/unlimit/3170_01.pdf
[Dodson 06]Dobson, Kat hr yn M., Hofma nn , Huber t F ., Ram am ni, Gowri, & Yedlin, Deborah K.
Adapt ing CMM I for Acquisition Organizations: A Prelimin ary Report(CMU/SEI-
2006-SR-005, ADA453524). Softwar e E ngineerin g In stit ut e, Car negie Mellon
Un iversity, 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06sr005.html
http://www.dodccrp.org/files/alberts_NCW.pdfhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn019.htmlhttp://www.dtic.mil/doctrine/jel/new_pubs/http://www.dfas.mil/technology/pal/http://www.dtic.mil/cjcs_directives/cdata/unlimit/3180_01.pdfhttp://www.dtic.mil/cjcs_directives/cdata/unlimit/3170_01.pdfhttp://www.sei.cmu.edu/publications/documents/06.reports/06sr005.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06sr005.htmlhttp://www.dtic.mil/cjcs_directives/cdata/unlimit/3170_01.pdfhttp://www.dtic.mil/cjcs_directives/cdata/unlimit/3180_01.pdfhttp://www.dfas.mil/technology/pal/http://www.dtic.mil/doctrine/jel/new_pubs/http://www.sei.cmu.edu/publications/documents/06.reports/06tn019.htmlhttp://www.dodccrp.org/files/alberts_NCW.pdf8/14/2019 Programmatic Interoperability
40/44
30 | CMU/SEI-2008-TN-012
[Fisher 07]Fish er, David A., Meyers, B. Craig, & Pla ce, Pa t. Conditions for Achieving N etwork-
Centric Operations in S ystems of S ystems (CMU/SEI-2007-TN-003). Softw ar e
Engineering Institute, Carnegie Mellon University, 2007.
http://www.sei.cmu.edu/publications/documents/07.reports/07tn003.html
[Garcia 06]Garcia, Suzann e, Forrester, E ileen, & Alberts, Ch ristopher. Process Considerations
for Interoperable Acquisition (CMU/SEI-2006-TN-033). Software Engineering
Institute, Carnegie Mellon University, 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06tn033.html
[IEEE 00]Institu te of Electr ical a nd Electr onics E ngineers.IEEE 100, Th e Authoritative
Dictionary of IEEE S tand ards Terms , Seventh Edit ion. New York, N Y: IEEE , 2000.
[Levine 03]Levine, Linda , Meyers, B. Cra ig, Morr is, Ed, Place, Pa tr ick R. H., & Plakosh, Dan iel.
Proceedin gs of the S ystem of S ystems In teroperability Workshop (February 2003)(CMU/SEI-2003-TN-016, ADA416429). Softwar e E ngineerin g In stit ut e, Car negie
Mellon Universit y, 2003.
http://www.sei.cmu.edu/publications/documents/03.reports/03tn016.html
[Morris 04]Morr is, Ed, Levine, Linda , Meyers, B. Cra ig, Pla ce, Pa tr ick R. H., & Plakosh, Dan iel.
S ystem of System s Interoperability (S OS I); Final R eport(CMU/SEI-2004-TR-004,
ADA455619). Softwa re E ngineerin g Inst itu te, Ca rn egie Mellon U niversity, 2004.
http://www.sei.cmu.edu/publications/documents/04.reports/04tr004.html
[Maier 96]Maier, M. Architecting Principles for Systems-of-Systems, 567574. Proceedings of
the Sixth An nual In ternational S ymposium of INCOS E. Bost on, MA, J uly 711, 1996.
INCOSE , 1996. http://www.infoed.com/Open/PAPERS/systems.htm
[Meyers 05]Meyers, B. Cra ig, Mona rch, Ira A., Levine, Linda, & Smith , Ja mes D. Including
Interoperability in th e Acquisition Process (CMU/SEI-2005-TR-004, ADA441244).
Software Engineering Institute, Carnegie Mellon University, 2005.
http://www.sei.cmu.edu/publications/documents/05.reports/05tr004.html
[Meyers 06a]Meyers, B. Craig, Smith, James D., Capell, Peter, & Place, Patrick. Requirements
Managem ent in a S ystem-of-System s Cont ext: A Workshop (CMU/SEI-2006-TN-015,
ADA449727). Softwa re E ngineerin g Inst itu te, Ca rn egie Mellon U niversity, 2006.http://www.sei.cmu.edu/publications/documents/06.reports/06tn015.html
[Meyers 06b]Meyers, B. Craig.Risk M ana gem ent Considerations for Interoperable Acquisition
(CMU/SEI-2006-TN-032, ADA465941). Softwar e E ngineer ing In stit ut e, Car negie
Mellon Universit y, 2006.http://www.sei.cmu.edu/publications/documents/06.reports/06tn032.html
http://www.sei.cmu.edu/publications/documents/07.reports/07tn003.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn033.htmlhttp://www.sei.cmu.edu/publications/documents/03.reports/03tn016.htmlhttp://www.sei.cmu.edu/publications/documents/04.reports/04tr004.htmlhttp://www.infoed.com/Open/PAPERS/systems.htmhttp://www.sei.cmu.edu/publications/documents/05.reports/05tr004.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn015.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn032.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn032.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn015.htmlhttp://www.sei.cmu.edu/publications/documents/05.reports/05tr004.htmlhttp://www.infoed.com/Open/PAPERS/systems.htmhttp://www.sei.cmu.edu/publications/documents/04.reports/04tr004.htmlhttp://www.sei.cmu.edu/publications/documents/03.reports/03tn016.htmlhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn033.htmlhttp://www.sei.cmu.edu/publications/documents/07.reports/07tn003.html8/14/2019 Programmatic Interoperability
41/44
SOFTWARE ENGINEERING INSTITUTE |31
[Meyers 06c]Meyers, B. Craig & Sledge, Carol A. S chedule Considerations for Interoperable
Acquisition (CMU/SEI-2006-TN-035, ADA465943). S oftware En gineering Inst itu te,
Car negie Mellon U niversity, 2006.http://www.sei.cmu.edu/publications/documents/06.reports/06tn035.html
[PPBES 03]PPBE S: Planning, Programm ing, Budgeting, and Execution System . Training
Material: DS N 734-8717. ht tp://www.fina nce.arm y.mil/ppbes.ht m (2003).
[Smith 06]Smith , Ja mes D. & Phillips, Mike.Interoperable Acquisition: Th e Ch allenges (CMU/
SEI -2006-TN-034, ADA461385). Softwa re En gineering Inst itu te, Car negie Mellon
Un iversity, 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06tn034.html
[USC 02]
United Sta tes Congress.E-Governm ent Act of 2002, Public Law 107-347, 116 S tat.
2899 (December 17, 2002). http://www.reg-group.com/library/E-GovLaw.pdf
[USC 04]
United Sta tes Code. Tit le 10Arm ed Forces.
http://www.access.gpo.gov/uscode/title10/title10.html (2004).
http://www.sei.cmu.edu/publications/documents/06.reports/06tn035.htmlhttp://www.finance.army.mil/ppbes.htmhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn034.htmlhttp://www.reg-group.com/library/E-GovLaw.pdfhttp://www.access.gpo.gov/uscode/title10/title10.htmlhttp://www.access.gpo.gov/uscode/title10/title10.htmlhttp://www.reg-group.com/library/E-GovLaw.pdfhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn034.htmlhttp://www.finance.army.mil/ppbes.htmhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn035.html8/14/2019 Programmatic Interoperability
42/44
32 | CMU/SEI-2008-TN-012
8/14/2019 Programmatic Interoperability
43/44
REPORT DOCUMENTATION PAGE Form ApprovedOMB No. 0704-0188Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searchingexisting data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regardingthis burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington HeadquartersServices, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office ofManagement and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.
1. AGENCYUSEONLY(leave blank) 2. REPORTDATE
December 2007
3. REPORTTYPEANDDATESCOVERED
Final
4. TITLEANDSUBTITLE
Programmatic Interoperability
5. FUNDINGNUMBERS
FA8721-05-C-0003
6. AUTHOR(S)
B. Craig Meyers and James D. Smith
7. PERFORMINGORGANIZATIONNAME(S) ANDADDRESS(ES)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
8. PERFORMINGORGANIZATIONREPORTNUMBER
CMU/SEI-2008-TN-012
9. SPONSORING/MONITORINGAGENCYNAME(S) ANDADDRESS(ES)
HQ ESC/XPK
5 Eglin Street
Hanscom AFB, MA 01731-2116
10. SPONSORING/MONITORINGAGENCYREPORTNUMBER
11. SUPPLEMENTARYNOTES
12.a DISTRIBUTION/AVAILABILITYSTATEMENT
Unclassified/Unlimited, DTIC, NTIS
12.b DISTRIBUTIONCODE
13. ABSTRACT(maximum 200 words)
Interoperability has traditionally been considered a property of operational systems, where systems are able to exchange information in
some agreed-upon fashion. However, other aspects of interoperability are often overlooked. This report introduces one of those
aspectsthe concept of programmatic interoperability,which is the application of principles of interoperability to the acquisitionmanagement of systems. It shows how programmatic interoperability contributes to fielding interoperable capabilities and relates this
aspect to current trends such as network-centric operations. The report also discussesthe orchestration of decisions and activities thatare applicable to acquisition in a system-of-systems environment. Finally, the report suggests several research topics.
14. SUBJECTTERMS
acquisition; interoperability; system of systems, programmatic interoperability, interoperable
acquisition
15. NUMBEROFPAGES
42
16. PRICE CODE
17. SECURITYCLASSIFICATIONOFREPORT
UNCLASSIFIED
18. SECURITYCLASSIFICATION OFTHISPAGE
UNCLASSIFIED
19. SECURITYCLASSIFICATIONOFABSTRACT
UNCLASSIFIED
20. LIMITATIONOFABSTRACT
UL
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)Prescribed by ANSI Std. Z39-18
298-102
8/14/2019 Programmatic Interoperability
44/44