Programmatic Interoperability

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.


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.html


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


4/44

i i | CMU/SEI-2008-TN-012


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


6/44

i v | CMU/SEI-2008-TN-012


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/44

vi | CMU/SEI-2008-TN-012


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.


10/44

vi | CMU/SEI-2008-TN-012


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.


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 .


13/44


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.


15/44


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


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.


17/44


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


Program-1 Program-2


19/44


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.


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://-/?-


21/44


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.)


22/44

12 | CMU/SEI-2008-TN-012


23/44


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].


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.


25/44


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.


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.


27/44


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://-/?-


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].


29/44


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.


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.


31/44


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


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.


33/44


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.


34/44

24 | CMU/SEI-2008-TN-012


35/44


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.


36/44

26 | CMU/SEI-2008-TN-012


37/44


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


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].


39/44


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.pdf


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.


[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.


[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.


[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.html


41/44


[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.


[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.html


42/44

32 | CMU/SEI-2008-TN-012


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


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


44/44

Documents

Programmatic Interoperability