A Model-Based Approach to Joint Capabilities: vocabulary, semantics, and architectural patterns

A Model-Based Approach to Joint Capabilities: vocabulary, semantics, and architectural patterns

Alexander Bocast

April 21, 2023

agenda What is a capability?

• Multiple definitions• Joint perspective• Disambiguating concepts of capability

Joint decision concepts driving notions of capability A behavioral model of capability concepts Defining capability by architecture Specifying key architectural elements of capability

• Ontology• Decision support as architecture purpose• Note on decomposition

Implications for enterprise architecture & federated architectures• Federating to DoD & Joint architectures• Federating to Component components• Note on architectural mechanisms for federation and integration…

Modeling complex systems• Architecture as complex system: process & artifact• Enterprise Architecture as a complex system• Architecting complex systems within the systemic complexity of an EA

– requisite variety– epistemology

Proposals• Terms & definitions• Architectural patterns• Modeling & simulation: executable architectures• SOA? Service-based enterprise architectures• RED TEAM architectures

Title 10 US Code TITLE 10 - ARMED FORCES

Subtitle A - General Military Law PART I - ORGANIZATION AND GENERAL MILITARY POWERS CHAPTER 2 - DEPARTMENT OF DEFENSESection 113. Secretary of Defense Paragraph (i)(1)

The Secretary of Defense shall transmit to Congress each year a report that contains a comprehensive net assessment of the defense capabilities and programs of the armed forces of the United States and its allies as compared with those of their potential adversaries. (2) Each such report shall - (A) include a comparison of the defense capabilities and programs of the armed forces of the United States and its allies with the armed forces of potential adversaries of the United States and allies of the United States; (B) include an examination of the trends experienced in those capabilities and programs during the five years immediately preceding the year in which the report is transmitted and an examination of the expected trends in those capabilities and programs during the period covered by the future-years defense program submitted to Congress during that year pursuant to section 221 of this title; (C) include a description of the means by which the Department of Defense will maintain the capability to reconstitute or expand the defense capabilities and programs of the armed forces of the United States on short notice to meet a resurgent or increased threat to the national security of the United States; (D) reflect, in the overall assessment and in the strategic and regional assessments, the defense capabilities and programs of the armed forces of the United States specified in the budget submitted to Congress under section 1105 of title 31 in the year in which the report is submitted and in the five-year defense program submitted in such year; and (E) identify the deficiencies in the defense capabilities of the armed forces of the United States in such budget and such five-year defense program.

We can trace the use of the term capabilities back to law & statute, but here capability is undefined. The demotic or common dictionary sense appears to be intended:

The ability or power to do something.

— Concise Oxford English Dictionary

QDR 2001 Defense Strategy Quadrennial Defense Review Report (QDR) 2001 (p.13): A

Capabilities-Based Approach

The new defense strategy is built around the concept of shifting to a "capabilities-based" approach to defense. That concept reflects the fact that the United States cannot know with confidence what nation, combination of nations, or non-state actor will pose threats to vital U.S. interests or those of U.S. allies and friends decades from now. It is possible, however, to anticipate the capabilities that an adversary might employ to coerce its neighbors, deter the United States from acting in defense of its allies and friends, or directly attack the United States or its deployed forces. A capabilities-based model - one that focuses more on how an adversary might fight than who the adversary might be and where a war might occur - broadens the strategic perspective. It requires identifying capabilities that U.S. military forces will need to deter and defeat adversaries who will rely on surprise, deception, and asymmetric warfare to achieve their objectives. Moving to a capabilities-based force also requires the United States to focus on emerging opportunities that certain capabilities, including advanced remote sensing, long-range precision strike, transformed maneuver and expeditionary forces and systems, to overcome anti-access and area denial threats, can confer on the U.S. military over time.

Still: The ability or power to do something.

— Concise Oxford English Dictionary

Current DoD usage appears to stem from the 2001 QDR, which introduced the term capabilities-based. Again, specific definition is lacking and the demotic sense remains.

However, we do gain this notion: adversaries may have capabilities and might use them.

waypoint: JP 1-02 DoD Dictionary JP 1-02, DOD Dictionary of Military and Associated Terms, 12 April 2001, as amended

through 22 March 2007.• This publication supplements standard English-language dictionaries (e.g., Merriam-

Webster) with standard terminology for military and associated use.

capability — The ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.)• Removed from the 8 November 2010 (as amended through 15 February 2012) edition.

specified task — In the context of joint operation planning, a task that is specifically assigned to an organization by its higher headquarters.

course of action — 1. Any sequence of activities that an individual or unit may follow.

activity — 2. A function, mission, action, or collection of actions.

intention — An aim or design (as distinct from capability) to execute a specified course of action.• Removed from the 8 November 2010 (as amended through 15 February 2012) edition.

enemy capabilities — Those courses of action of which the enemy is physically capable and that, if adopted, will affect accomplishment of the friendly mission. The term “capabilities” includes not only the general courses of action open to the enemy, such as attack, defense, reinforcement, or withdrawal, but also all the particular courses of action possible under each general course of action. “Enemy capabilities” are considered in the light of all known factors affecting military operations, including time, space, weather, terrain, and the strength and disposition of enemy forces. In strategic thinking, the capabilities of a nation represent the courses of action within the power of the nation for accomplishing its national objectives.

The term capability had already been defined for DoD before the 2001 QDR was published. Elaborated definitions provided by the Joint Staff were not to emerge until 2005 and have not been incorporated into the DoD Dictionary.

The only meaningful difference between the demotic and DoD definitions seems to be the DoD notion of specified: hierarchically & specifically assigned.

Notes:

The misplaced parenthetical is at first surprising: would you develop a capability if you had no interest in using it? Only after contemplating the DoD definition of intention does this parenthetical begin to make sense: a capability may be emergent.

JP 03 tells us that “Deterrence should be based on capability (having the means to influence behavior)”.

Joint terms: JCIDS By May 2005, a consequential shift in the definition of capability was being made by

CJCSx 3170.01y series documents concerning the Joint Capabilities Integration and Development System.

capability — The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. It is defined by an operational user… • CJCSI 3170.01H 10 January 2012 now gives: Capability – The ability to execute a

specified course of action. (A capability may or may not be accompanied by an intention.) (JP 1-02) Note the reference to JP 1-02.

• CJCSM 3500.04F Universal Joint Task Manual adds “Also, the ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.”

This JCIDS definition uses terms defined by the Universal Joint Task List [CJCSM 3500.04D, 1 August 2005, Change 1, with changes to UJTL Tasks (Enclosure B) approved 15 September 2006] • Now known as the Universal Joint Task Manual.

effect — A change to a condition, behavior, or degree of freedom.• Now given in JP 1-02 as: effect — 1. The physical or behavioral state of a system that

results from an action, a set of actions, or another effect. 2. The result, outcome, or consequence of an action. 3. A change to a condition, behavior, or degree of freedom. (JP 3-0)

Now the definition begins to get interesting. Concepts of “desired effect”, “specified standards”, “specified conditions”, “combinations of means and ways”, and “set of tasks” are introduced, triggering UJTL/UJTM concepts & definitions.

Joint terms: JCIDS2 standard — Quantitative or qualitative measures for specifying the levels of performance

of a task.

conditions — Those variables of an operational environment or situation in which a unit, system, or individual is expected to operate and may affect performance.• Now given in JP 1-02 as: condition — 1. Those variables of an operational environment

or situation in which a unit, system, or individual is expected to operate and may affect performance. 2. A physical or behavioral state of a system that is required for the achievement of an objective. See also joint mission-essential tasks. (JP 3-0)

• CJCSM 3500.04F adds: “Also, variables of the operational environment, including scenario that affects task performance.”

task — An action or activity (derived from an analysis of the mission and concept of operations) assigned to an individual or organization to provide a capability.

measure — Provides the basis for describing varying levels of task performance.• CJCSM 3500.04F now says: A parameter that provides the basis for describing varying

levels of task accomplishment.

criterion — The minimum acceptable level of performance associated with a particular measure of task performance. It is often expressed as hours, days, percent, occurrences, minutes, miles, or some other command-stated measure.

Now the definition begins to get interesting. Concepts of “desired effect”, “specified standards”, “specified conditions”, “combinations of means and ways”, and “set of tasks” are introduced, triggering UJTL/UJTM concepts & definitions.

Terms of Reference for Conducting a Joint Capability Area Baseline Reassessment, 9 April 2007

capability — The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (CJCSI 3010.02B)

• CJCSI 3010.02C now instead defines: Capability Gaps -- The inability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.

• CJCSI 2170.01H now defines: Capability Gap (or Gap) – The inability to execute a specified course of action. The gap may be the result of no existing capability, lack of proficiency or sufficiency in an existing capability solution, or the need to replace an existing capability solution to prevent a future gap.

condition — Variable of the operational environment, including a scenario that affects task performance. (CJCSI 3010.02B) [CJCSI 3010.02C no longer defines this term.]

effect — A change to a condition, behavior, or degree of freedom. (CJCSI 3010.02B)

• CJCSI 3010.02C no longer defines this term.

endstate — The set of conditions, behaviors, and freedoms that defines achievement of the commander’s mission. (CJCSI 3010.02B)


• However, JP 3.0 (2011) maintains this modified definition: end state — The set of required conditions that defines achievement of the commander’s objectives.

The JCIDS definitions and these terms of reference give us enough now to work with…

Notes:

The JP 1-02 definition of "capability" was “the ability to execute a specified course of action”. The general assessment was that this definition was not adequate for a capabilities-based Department. This was recognized in late 2004 when leadership from the Office of Secretary of Defense and Joint Staff co-sponsored a Military Operations Research Society conference to (in part) redefine "capability" and several other related capabilities-based words. The definition of “capability” used in this terms of reference resulted from that effort, and was subsequently used in CJCSI 3010-02B, CJCSI 3170/01E, and CJCSM 3170.01B. The JCA Baseline Reassessment will apply this definition of “capability” in concert with the “tasks / effects / objectives” relationship set forth in JP 3-0. … Additionally, Joint Staff J-7 will engage with the joint doctrine community to pursue the proper vetting of this definition for inclusion to Joint Publication 1-02.

JP 3.0 (11 Aug 2011) notes: capability. None. (Approved for removal from JP 1-02.)

Joint terms: JCIDS Joint Capability Area Baseline Reassessment

means — Forces, units, equipment, and resources.

measure — The basis for describing varying levels of task performance. (CJCSI 3010.02B)


mission — The purpose (objectives and endstate) assigned to the commander. (CJCSI 3010.02B)


• JP 1-02 now defines: mission — 1. The task, together with the purpose, that clearly indicates the action to be taken and the reason therefore. (JP 3-0) 2. In common usage, especially when applied to lower military units, a duty assigned to an individual or unit; a task. (JP 3-0)

standard — Quantitative or qualitative measures for specifying the levels of performance of a task. (CJCSI 3010.02B)


task — An action or activity (derived from an analysis of the mission and concept of operations) assigned to an individual or organization to provide a capability. (CJCSI 3010.02B)


ways — Doctrine, tactics, techniques, and procedures, competencies, and concepts.

The JCIDS definitions and these terms of reference give us enough now to work with…

Notes:

The JP 1-02 definition of "capability" was “the ability to execute a specified course of action”. The general assessment was that this definition was not adequate for a capabilities-based Department. This was recognized in late 2004 when leadership from the Office of Secretary of Defense and Joint Staff co-sponsored a Military Operations Research Society conference to (in part) redefine "capability" and several other related capabilities-based words. The definition of “capability” used in this terms of reference resulted from that effort, and was subsequently used in CJCSI 3010-02B, CJCSI 3170/01E, and CJCSM 3170.01B. The JCA Baseline Reassessment will apply this definition of “capability” in concert with the “tasks / effects / objectives” relationship set forth in JP 3-0. … Additionally, Joint Staff J-7 will engage with the joint doctrine community to pursue the proper vetting of this definition for inclusion to Joint Publication 1-02.

JP 3.0 (11 Aug 2011) notes: capability. None. (Approved for removal from JP 1-02.)

Joint terms: JCIDS Joint Capability Area Baseline Reassessment2

desired effect — Now, desired effect has a DoD definition — although it is clearly not the one we want: “The damage or casualties to the enemy or materiel that a commander desires to achieve from a nuclear weapon detonation…” Ignoring the circularity of this definition, we can note that wherever we encounter this or similar phrases, the intent is to say: “an effect that a (joint) commander wants.”• RAND’s Paul Davis runs with this as indicating that the scope of meaningful

capabilities is the scope of the commander who uses these capabilities. In other words, capabilities belong in a context of operations, not in a context of national strategy…

specified conditions — a subset of UJTL conditions that has been determined by a commander to be relevant to the performance of a set of tasks assigned by the commander

specified standards — the performance requirements for a set of tasks to be carried out under specified conditions• Conditions are contingent upon missions. Standards are contingent upon contingent

mission conditions. Absent mission, neither conditions nor standards can be specified. Hence the concept of “specified standards and conditions” drives us to construct and analyze mission scenarios. Lots of scenarios…

combinations of means and ways to perform — • Capability apparently means having many tools and being able to pick and choose an

appropriate tool for the job at hand. Note that “appropriate” does not mean “best.” Recalling “intention”, appropriateness might not be at all related to the designed purpose of a tool.

set of tasks — purposive behaviors• That is, behavior that is not random but rather is designed to do something

interesting…

The capability notion of “combinations of means and ways to perform” immediately causes systems engineers to salivate. Here is the JCS’ explicit invitation to think about capabilities using the frameworks of systems-of-systems and the analytics of complex systems.

The capability notion of “perform a set of tasks” immediately causes process architects to pay attention. Indeed, this notion is our entry point for exploring the implications of capabilities as architectural concepts within an enterprise architecture.

Notes:

Much of what I observe here is confirmed (validated?) in Paul Davis’ work at RAND for OSD and USAF.

JP 3.0 (2011) notes: desired effects. None. (Approved for removal from JP 1-02.)

interpreting qualified terms in the JCS definition of capability

let’s revisit JCS intent The notion of “capability” arises from related Joint concerns:

• Acquisition & dollars: are we acquiring resources that will be appropriately effective for specific but as yet unspecified missions

• Operations & resources: can we apply resources that will be appropriately effective for specific but as yet unspecified missions

Critical operational capability concepts:• Mission: something that a commander needs to do• Effect: a change in a commander’s stakeholder’s outputs that is prerequisite to a

successful mission• Tasks: what a commander can do to cause an effect• Conditions: things outside a commander’s control that may effect performance of a

task• Standards: a commander’s measure of minimum task performance that will lead to

a successful mission• Scenario: end-to-end view of what a commander might do to accomplish a mission

under given conditions

We have limited resources.

No single potential adversary has capabilities that we cannot eventually best.

However, we can not predict with certainty who we will fight, when we will fight, what capabilities they will have and use, or under what conditions we will contend.

But we still need to bet on a set of capabilities that will give us the most robust ability to respond across all adversaries and circumstances…

Depending upon the decisionmaker, this bet can be posed in different ways:

Maximum mitigation of riskMaximum possibility of successMinimum possibility of failure

critical concepts of JCS capability • Uncertainty

• uncertainty with respect to everything: effect, risk, task, conditions, standards, and scenarios.• Effect

– changes to someone else’s behavior– desired return on investment

• Risk– likelihood of undesired returns on investment – vs. opportunity: more-than-expected returns on investment

• Tasks– must be known, standard, predictable, “off-the-shelf” behaviors (“specified”)

• Conditions– a manifold; conceptually, n-dimensional space within which any mission environment may be described– circumstances of a task;– unfortunately, analytically infinite; see scenario…

• Standards– variables that depends upon the mission, properties of the desired effect, the conditions, and the orchestration of other

capabilities– standards are (kinda sorta) the inverse of risk event probabilities (e.g., least acceptable effect)– minimum acceptable proficiency required in task performance

• Although it is not really clear how minimum proficiency relates to desired effect…• Scenario

– course of action through a specified manifold (“scenario space”)– But: scenarios travel in packs… parametric scenario families; statistical affinity families;– Sample sizes are important, because a single sample from an infinite space tells you nothing…

• …there is no such thing as a single best scenario. Because it would involve the concatenation of many elements, even the allegedly most likely scenario is a low-odds projection and a bad bet; therefore, multiple scenarios are the foundation for foresight analysis. The number needed may be very large, especially if the analyses are computer-based, using combinations of many factors, or it may be small if the analyses are largely qualitative…– Davis: Theory & Methods for Supporting High-Level Military Decisionmaking

JCS capability notions address decisionmaking Marginal tradeoffs among candidate capabilities integrated over whole scenario

[space…]• Risk• Effectiveness• Cost

Marginal analyses• Compare candidate capabilities

– As black box substitutes– In combinations sequential & parallel

• In context of a given mission– Driven by scenarios within a scenario space

Joint staff questions: acquisition planning Architecture as decision support

• Portfolio-style thinking & analysis

First priority: what combination of acquisitions: • Maximizes capabilities throughout the scenario space while minimizing commitments• Maximizes the likelihood that needed capabilities will be available when they are

needed across the scenario space while minimizing commitments• Minimizes operational risk integrated across the scenario space while minimizing

commitments

Portfolios:• If you are not uncertain, you can put all your eggs in one basket…• If you are uncertain, you won’t put all your eggs in a single basket. And you ask:

– How many baskets?– How many eggs? All your eggs?– How many eggs go in each basket?– How many eggs of what sort go in how many baskets of which type?

– How big should each basket be?– How strong does each basket need to be?

» Can you mix big strong baskets and small weak baskets?– How many types of baskets should you have?

• Hence, marginal analyses looks at incremental eggs and incremental baskets– How big is an increment? (what do you hold as a constant unit at the margin?)

– One egg?– One basket?– One penny?

Joint commander’s questions: operations Architecture as decision support

• Portfolio-style thinking & analysis• Foresight exercises

First priority: what combination of capabilities in these circumstances:• Minimizes resources while maximizing the minimum probability of success• Minimizes resources while minimizing the maximum probability of failure• Minimizes resources while maximizing the mitigation of risk: minimizing the

magnitude of the bad guys’ effects

• Minimizing committed resources:– Minimizes losses in the worst case– Maintains flexibility & robustness

• Maximizing risk mitigation:– Up to a (threshold) level at which consequences will be accepted

– Which is expressed by performance standards asserted for those tasks in those conditions

behavioral model: introduction

transform

Control shapes transformation. Without control, behavior is random: monkeys pounding keyboards.

Mechanism is the physical means to transform input into output.

Sans mechanism (logical model), this notation signifies requirement.

With mechanism (physical model), this notation signifies implementation.

outputinput

mechanism

control

I introduce this notation to guide you into my thinking process, not to proselytize a method of analysis.

Similarly, we won’t get into sectarian arguments about terms to use for specific bits of behavior (e.g., process; task; activity; function; subprocess). Interesting behavior causes some transform of interest: done.

Notes:

The IDEF0 standard followed here: IEEE 1320.1-1998.

formal concepts of behavior It ain’t interesting unless something happens

• A behavior (or any of its sectarian variants: activity, process, function, task, …) is a transformation of something into something else.

• No transformation: nuthin’ happened. Boring… We’ve got 4 sorts of possible transformation: place, time, state, & form Consequently, we can say some decisive things about architecturally interesting

behaviors:• They start.• They stop.• They stop after they start.• There is some interval between starting and stopping.• A behavior finishes in finite time.

Ergo, we have some more concrete things we can say:• An output must be observable• An input must be observable

Which leads to:• Input gets transformed into output. Furthermore:

– All input gets transformed into output– Only input gets transformed into output

• Conversely:– Output gets transformed from input– All output gets transformed from input– Only output gets transformed from input.– Note: there are certain caveats to these stipulations:

– Ontologically: Creative acts– Representation of input & output in modeling artifacts

The notion of behavior that is interesting to organizations is well stated by several methods. I draw upon the IEEE 1320.1 IDEF0 concepts because they are well defined by a public, consensus standard.

formal concepts of behavior2

These observations constrain what architectural concepts of behavior may be interesting for organizational or management purposes:• If you can see what goes in…• And you can see what comes out…• (which, by the way, means you can also see how long it took…)• Then (and only then) can you manage the behavior!

If you can’t see both gazintas and gazoutas, then you can’t measure it…

Then you can’t figure out the production function: output = f( input, …)

which means you can’t manage it because you don’t grasp essential relationships between gazintas and gazoutas…

you can’t manage it because you are seeing a random (perhaps chaotic) process

[The behavior probably isn’t really random, but since you can’t see what you might do to control the process, it might as well be…]

traditional extent of organizational behavior models

external stakeholders over here

their input

behavioral notion of effect

your input

your guys

your control

do their thingtheir output

their guys

their control

A-11

do your thing

A0

effect measures

your effect

your output

their observed input

1 stakeholder output == your outcome

behavioral sketch of JCS notions of capabilities

do something else

their output

A-14

your controls

your information

their input

specify requirements

A-11

capability requirement

standards

mission guy mission designer

architectures

their guys

their stuff

resources

tailor behavior

A-12

selected behaviors

provide resources

A-13

their controls

do tailored capability thing

A0

set strategy

wreak effect

pick mission capability

apportion mission system

mission statement

nominal capability architecture

enterprise architecture

means

ways

tasks

conditions

your output

selection criteria

your stuff your guys


capability measures

DOTMLPF guy

acquisition guy

tailoring criteria

your effectyour input

shoot at your guys

wreaking effects: a simplistic example

A-14

their weapons

their guys

their controls

do tailored capability instance thing

A0

your effect

your bullets

their fired bullets

shoot their bullets

A-142

their observable guys

their unobserved guys

their alive observed guys

their observed guys

their bullets

physical laws

your fired bullets

behavior feedback

intercept your bullets

A-141

architectural view of capability ducks Whatever you call it, a duck that satisfies a joint capability requirement will at least look like

this:• It looks like an architecture

– A capability is not itself decomposable– A capability architecture has a capability pattern

– without this pattern, capabilities cannot be compared– Capabilities may be recursive

A duck with such an architecture:

• exists within the context of an overarching (federating?) enterprise architecture– It allows inputs, outputs, & outcomes to be quantitatively contrasted & compared with

other likely ducks– The overarching architecture can be tailored for specific instantiations on the basis of

contrasting & comparing the inputs, outputs, & outcomes of candidate capability-implementing architectures

• defines:– conditions and expectations for capability performance under specific conditions

within a manifold of conditions– a tailoring process to align it with conditions, standards, and available resources

• has been:– verified against the standards of its overarching enterprise architecture– certified by joint stakeholders– validated by empirical data on effects (or by trusted simulation of effects)

A capabilities architecture could be used to consider questions about warfighting capabilities. Such an architecture appears to be useful primarily for decisions supporting strategic planning for warfighting and for decisions supporting operational design of missions.

On the investment side, the Joint Staff gains insight into strategic marginal tradeoffs among capabilities and resources.

On the operations side, the Joint Commander gains insight into tactical marginal tradeoffs across resources and mission success.

architectural view of capability ducks2

• provides process management practices that assess the behavior of instances of this capability

• models stakeholder outcomes (i.e., the boundary of the architecture is not the boundary of the producing activities)

• incorporates behaviors that:– measure effectiveness (i.e., establish stakeholder baselines, monitor stakeholder

effects, compare effects to baselines)– report capability measures of effectiveness, efficiency, relative ROI, & relative risk,

including process measures, performance measures, product (output) measures, and effect (outcome) measures.

A capabilities architecture could be used to consider questions about warfighting capabilities. Such an architecture appears to be useful primarily for decisions supporting strategic planning for warfighting and for decisions supporting operational design of missions.

On the investment side, the Joint Staff gains insight into strategic marginal tradeoffs among capabilities and resources.

On the operations side, the Joint Commander gains insight into tactical marginal tradeoffs across resources and mission success.

blackbox architecture federation

their output

your controls

your information

their input

set strategy

A-11

architectures

resources apportion mission system

A-13

their controls

mission statement

your input

wreak effect

A-14

means

means

means

means

means

tailored behavior

tailored behavior

tailored behavior

tailored behavior

tailored behavior

performance

performance

performance

performance

performance

expected outcome for this (sort of) mission, under these conditions, orchestrated with other capabilities…





do tailored capability thing

A0

candidate

candidate

candidate

candidate

candidate

architecture

architecture

architecture

architecture

architecture


A-12

executable architecture The basic decision need behind the JCS concept of capabilities is to be able to make

marginal tradeoffs for• Identifying & obtaining desired capabilities• Picking & deploying desired capabilities that have been obtained

Architecture features:• Consistent way to integrate/federate architectures around black boxes of potential

behavior:– Observable inputs, tailorable controls, observable outputs, & observable

outcomes– Selected, tailored behaviors specified by controls

• The specification of a blackbox behavioral interface in terms of inputs, outputs, & measures:– can drive architecture integration– enables analyses and comparisons of tailored behaviors

– Across candidate capabilities– For candidate missions– Through a scenario space– Shaped by a conditions manifold

• Executable behaviors:– Compute marginal measures of effectiveness (and marginal risk)

– enables large scale examination of existing capabilities (identify current & emerging capability gaps)

– enables large scale examination of marginal tradeoffs– Drive technical architecture standards through all levels of federation– Effectively verify construction of capability architectures– Provide a means for human validation of capability architectures

By “executable architecture” we mean: an architecture that incorporates an executable behavioral model that may access behavioral data embedded in artifacts of the architecture.

Well, ok, what’s an executable behavioral model? Recall our fundamental notions of interesting behavior: countable input & countable output with total transformation of input to output. This means that production functions that execute in finite time can be assigned to each interesting bit of behavior. Interesting bits of behavior can not start unless their inputs are available. Conversely, these bits of behavior can not complete until their outputs are available. (Which necessarily implies general notions of precondition & postcondition.)

In other words, this bit of formality maps directly to discrete simulation methods (e.g., Petri-nets).

It would be extremely interesting to explore agent-based simulation of capabilities, especially because our guys and those stakeholder guys (those “effect”ed) can be assumed to decide and to act guided by quite different and often conflicting motivations.

Notes: For more on formal exposition of preconditions and postconditions, see discussions of IDEF0 activation statements and the IEEE 1320.2 (IDEF1X) constraint language.

enterprise architecture as complex system Modeling complex systems

• Architecture as complex system: process & artifact– loose coupling– multiple competing agents– ambiguous boundaries

• Enterprise Architecture as a complex system– systems of systems– capability manifolds: fuzzy couplings; non-deterministic outcomes– competing decision complexes

– minimizing X while maximizing Y…• Architecting complex systems within the systemic complexity of an EA

– requisite variety– epistemology

– local intelligence– global awareness

order—chaos spectrumFigure 2. Order—Chaos Spectrum. From Sarah Sheard’s Principles of Complex Systems for Systems Engineering, INCOSE 2007.

OrderNewtonian lawsBell curvesPlansPredictabilityControlHigh overheadLittle communication

ChaosLaws of chaos

Strange AttractorsReactionsFlexibility

VarietyLow overhead

Instability

ComplexityCapability

Power LawsPriorities

AdaptationLeverage

AgilityCritical Point

OrderNewtonian lawsBell curvesPlansPredictabilityControlHigh overheadLittle communication

ChaosLaws of chaos

Strange AttractorsReactionsFlexibility

VarietyLow overhead

Instability

ComplexityCapability

Power LawsPriorities

AdaptationLeverage

AgilityCritical Point

architecture as complex system Definition of complex systems

• Complex systems have many autonomous components, i.e., the basic building blocks are the individual agents of the system– The elements are heterogeneous (differ in important characteristics), i.e. have

variety– The system boundary is often hard to pin down

• Complex systems display emergent macro-level behavior that emerges from the actions and interactions of the individual agents. – They are non-deterministic, i.e., exhibit unpredictable behavior, including chaotic

behavior under certain conditions• Complex systems are self-organizing (show a decrease in entropy due to utilizing

energy from the environment) • The structure and behavior of a complex system is not deducible, nor may it be

inferred, from the structure and behavior of its component parts– Generally the behavior involves nonlinear dynamics, sometimes chaos, and rarely

any long-run equilibrium– Often the agents are organized into groups or hierarchies; in which case the

structure influences the evolution of the system. However, the complex system is not run by a central authority, nor could it be, in most cases.

– Such structures tend to highlight a number of different scales, any of which can affect the behavior of the complex system.

• Complex systems adapt to their environment as they evolve– In particular, as they evolve they continually increase their own complexity, given a

steady influx of energy (raw resources) and feedback among elements. Over time, they display increasing specialization and increasing capability.

– Their elements change in response to imposed “pressures” from neighboring elements.

Notes:

Thanks to Sarah Sheard’s Principles of Complex Systems for Systems Engineering, INCOSE 2007

Think hard about Ashby’s Law of Requisite Variety.

Does this description of complex systems sound like your organization?

Does it sound like your Enterprise Architecture?

Does it sound like the architecting of the your Enterprise Architecture?

capabilities & complexity• Given the notion of architecture integration founded upon fuzzy binding of tailored instance capabilities to mission scenarios,

we can recast Sheard’s propositions in light of an enterprise architecture that explicitly models capabilities. – Note that it is irreducible that an architecture is a model; here we equate complex system behavior to the behavior of an

executing architecture (simulation model).• An EA has many autonomous components and candidate capabilities are the basic building blocks of the architecture.

– Capabilities are heterogeneous (differ in important characteristics), i.e. have variety. The architecture allows heterogeneous candidate capabilities to be compared, contrasted, and selected to construct instance architectures that build the behavioral schemas of mission scenarios.

– The architecture boundary is often hard to pin down• An EA displays emergent macro-level behavior that emerges from the actions and interactions of individual capabilities.

– An EA is non-deterministic, i.e., exhibits unpredictable behavior, including chaotic behavior under certain conditions• An EA is self-organizing (a) through the propagation of architectural patterns (DNA?) and (b) in the construction of executable

instance architectures.• The structure and behavior of an EA is not deducible, nor may it be inferred, from the structure and behavior of its component

capabilities– Generally the behavior involves nonlinear dynamics, sometimes chaos, and rarely any long-run equilibrium– Often agents are organized into groups or hierarchies; in which case the structure influences the evolution of the

architecture. However, the architecture is not run by a central authority, nor could it be, in most cases.– The enterprise architecture highlights candidate capabilities at a number of different scales, any of which can affect the

behavior of the architecture.• An EA adapts to its environment as it evolves (is evolved?)

– In particular, as candidate capability architectures evolve they [may] continually increase their own complexity, given a steady influx of energy and feedback among elements (e.g., candidate capabilities, missions, conditions, standards, effect). Over time, candidate capability architectures [may] display increasing specialization and increasing capability.

– Candidate capability architectures [will] change in response to imposed “pressures” from neighboring candidate capabilities.

Focus on creating an environment and process rather than a product Continually build on what already exists

• It’s a complex system after all; it must evolve• Evolution from scratch is slow; start from something close to what you want

Gradually increase utilization of more effective components Utilize multiple parallel development processes Operational systems include multiple versions of functional components Individual components must be modifiable in situ Evaluate experimentally in situ

Our EA process and EA artifacts seem to be de facto on this course. However, organizing principles that focus on capability patterns would seem to naturally reinforce most of Bar-Yam’s transition principles…

Highlighted in brown is the Bar-Yam principle that appears especially appropriate for orchestration of enterprise architecture…

Although not explored here, explicitly considering these principles is structurally consistent with a service-based technical architecture for an executable enterprise architecture…

Notes:

Again, re-ordered but taken from Sarah Sheard’s Principles of Complex Systems for Systems Engineering, INCOSE 2007

Sarah bases these transition principles on Bar-Yam, Yaneer, “Engineering complex systems: multiscale analysis and evolutionary engineering,” in Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam. Complex Engineered Systems. Cambridge, Massachusetts: Springer, 2006

Sheard’s Principles of Complex Systems Engineering: transitioning

a modest proposal for terminology Missions and capabilities Condition manifold, scenario space, & standards Identifying capabilities Term space Proposed terms & definitions Cardinalities of terms

MODAF M3

A high level specification of the enterprise's ability.

Note: A capability is specified independently of how it is implemented. For example, a "target acquisition" capability might be implemented by a forward observation team, a UAV or an aircraft targetting system.

Note: Capabilities are dispositional. A given system or organisation that has a capability (i.e. it is disposed to do something) may never actually have manifested it.

IDEAS defines a capability as being the set of things that are disposed to achieve a particular effect.

mission & capabilities

take that thar hill at dawn

capability

activity

condition manifold, scenario space, & standards

tasks

tasks

mission

conditions

scen

ario

s

standards

identifying capabilities The JCS notion of "capability" generally seems to be taken to mean that each "desired

effect" is associated with a "capability" — that is: one effect/one capability. But that is clearly inadequate to the intent. You may have a capability if you can achieve some measured effect under some complex of conditions. But that capability may not be effective given another complex of conditions or different measure of effect. In other words, you may need more than one set of ways and means to cause a specified effect as (a) the relevant set of conditions changes; (b) the values of relevant conditions change; and (c) the relevant measures of effect change...

A capability is tied to an effect only through a specific configuration of conditions and a specific range of values for the conditions within that specific configuration. Standards are analogous with respect to ways & means within a capability: as measures of performance change and as acceptable values for those measures vary, different ways & means will become more or less acceptable• especially in relation to their availabilities and their costs, which seems to be

missing from the JCS operational view of capabilities).

Then, of course, there are various combinations of ways and means, each of which is often called a "capability". However, the JCS notion of capability is with regard to missions, conditions, standards, effects, costs, tailoring of ways and means, and considering possible alternatives.

And after all this, the actual use of a specific combination of ways and means to achieve an effect goes unnamed, largely because the notion of "being able to do" is largely conflated with "doing" by a can-do attitude. • This can be easily traced back to elementary organizational dynamics.• See the slide “whining: but I hafta be a capability too…”

Real-options issues may include, e.g., deciding whether to invest in variants of a product’s principal design or in alternative products. [Davis & Henninger, Analysis, Analysis Practices, and Implications for Modeling and Simulation, RAND 2007.]

canonical

scenario space

scenario

term space for architectural discourse

capability proposition


overarching Joint concept of capability-based requirements

capability space all possible missions

all defined tasks

all allowed values for all defined conditions

all allowed measures for all defined effects

specified mission

specified task

specified standards specified standards values

specified effect specified effects measures

specified conditions specified conditions values

nominal capability design task(s)

design standards design standards values

design effect design effects measures

design conditions design conditions valuesarchitectural patterns

architecture

all allowed values for all defined standards

Now this gets messy because we need to be able to uniquely identify anything that might show up in our architectures, both as named concept and as instance of a named concept…

The space itself cannot be exhaustively defined because there are an infinite number of possible missions…

Proponents of threat-based analyses argue that the only way to rationally sample capability space is to posit scenario spaces. Others suggest that computational power can be harnessed to explore capability space to discover scenario spaces, especially wrt emergent capabilities.

Potential capabilities are not designed for specific missions but as building blocks of a federated mission architecture (e.g., SoS). Note that architectural models of these building blocks can be in turn the building blocks of federated analytic architectural models.

terms for architectural discourse

candidate capability a nominal capability whose design concepts & values approximate the specified concepts & values of a capability requirement.

capability a candidate capability that sufficiently satisfices a capability requirement.

tailored capability mission capability whose ways and means have been appropriately tailored and made available for a mission: an executable instantiated architecture.

realized capability the actual ways and means of a tailored capability in action: an executing instantiated architecture.

capability proposition


capability space

nominal capability

the notion of capabilities intended by Joint terms such as “capabilities-based”: intent & doctrinal foundation.a set of normative concepts that structures and constrains requirements for mission behaviors in accordance with the capability proposition.

a behavioral requirement stated in terms of the capability space to specify mission, task, conditions & their values, standards & their values, & measured effects.

a tailorable configuration of ways and means characterized by designed behaviors, design ranges of operating conditions, design ranges of performance standards, and design expectations of effect measures given these designed behaviors, conditions, and standards: an architecture whose patterns satisfy the capability proposition.

mission capability a capability selected for inclusion in the course of action of a mission.

cardinalities of architectural discourse

candidate capability p > k

capability k > c

mission capability c > m=1

tailored capability m.t > t

capability space ∞

capability proposition ?

nominal capability ∞ >> p

realized capability t=1capability requirement 1

mission 1

analytic & simulation requirements: the service pattern Parametric models of scenario spaces over condition axes Executable architectures Families of federated models Portfolio management

• “portfolio management tools should make it easy not only to see gaps, but also to help decisionmakers decide how to adjust the portfolio so as to fill the gaps, balance risks and opportunities, prioritize by groups rather than by discrete activities, and even to conduct investment analysis, such as marginal or chunky marginal analysis.”

Modeling & simulation: executable architectures• SOA? Service-based enterprise architecture

RED TEAM architecture

Quote from Paul K. Davis & James P. Kahan, Theory and Methods for Supporting High Level Military Decisionmaking, RAND 2007.

capability as architectural pattern: capability proposition

do something else

their output

5

your controls

your information

their input


1


standards


architectures

their guys

their stuff

resources

tailor behavior

2

selected behaviors

provide resources

3

their controls

capability socket

4

set strategy

wreak effect


apportion capability

system

mission statement

nominal capability architecture


means

ways

tasks

conditions

your output

selection criteria



capability measures

DOTMLPF guy

acquisition guy

tailoring criteria

your effect

your input


service requirement

candidate capabilities

service discovery

capability instance

convergence with notions of service

do something else

their output

5

your controls

your information

their input


1


standards


architectures

their guys

their stuff

resources

tailor behavior

2

selected behaviors

provide resources

3

their controls

capability socket

4

set strategy

wreak effect


apportion instance system

mission statement

capability instance architecture


means

ways

tasks

conditions

your output

selection criteria



capability measures

DOTMLPF guy

acquisition guy

tailoring criteria

your effect

your input

service interface

service

capabilities & SOA: OASIS SOA Reference Model

do something else

their output

A-14

your controls

your information

their input


A-11


standards


architectures

their guys

their stuff

resources

select behavior

A-12

selected behaviors

provide resources

A-13

their controls

do tailored capability

instance thingA0

mission statement



means

ways

tasksconditions

your output

selection criteria



capability measures

DOTMLPF guy

acquisition guy

tailoring criteria

your effectyour input

services are the mechanism by which needs and capabilities are brought together: (pg.9)

the offer to perform work for another

the specification of the work offered for another

the capability to perform work for another

the performance of work (a function) by one for another

Also see Section 4: Conformance Guidelines.

need

visibility

real world effect

interaction

service means

service interface

service consumers

service provider

service descriptions

execution context

shared state

service functionality

contract & policy ??

service interface

capabilities & SOA: OASIS SOA Reference Model with brokered contract

do something else

A-15

your controls

your information

their input


A-11


standards


architectures

their guys

their stuff

resources

select behavior

A-12

selected behaviors

provide resources

A-14

their controls

do tailored capability instance thing

A0

mission statement



means

tasksconditions

your output


capability measures

DOTMLPF guy

acquisition guy

tailoring criteria

your effect

your input

your stuff

contract

negotiate agreement

A-13

ways

their output

broker

selection criteria

your guys

defined capability

BLUE TEAM ARCHITECTURE

RED TEAM ARCHITECTURE

their input

behavioral notion of effect, revisited: RED TEAM architecture

your input

your guys

your control

do their thingtheir output

their guys

their control

A-11

do your thing

A0

effect measures

your effect

your output


1 Our current practices of architecture essentially ignore the active engagement of external actors. Building on the recognition that architectural patterns of capabilities can be represented by service-based executable architectures, we might improve our analyses of outcomes by introducing independent RED TEAM architectures to model the behaviors of external actors. Such RED TEAM architectures would counterpoise their own capability patterns to BLUE TEAM capability patterns.

conclusions The JCS notion of capability may be best described by an architectural pattern.

• A capability is not a system. A system is but one of many available means to realize a capability.

• This presentation suggests an architectural pattern that fits the JCS intent. The architectural pattern of capabilities is largely isomorphic with canonical patterns

for services. This convergence of capability and service patterns suggests an approach to

architecture federation through service-oriented executable architectures.

We have examined the emergence of the specialized JCS sense of the term “capability”.• We have also seen that this term may be falling from grace.• However, the architectural pattern of capability suggests that the semantics of

capabilities remain valuable and useful.• We have also looked at terms that can help us talk about capabilities within the

context of enterprise architectures that model capabilities.

Thank you for your time, attention, and patience.

Documents

A Model-Based Approach to Joint Capabilities: vocabulary, semantics, and architectural patterns