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

1. A Model-Based Approach to Joint
Capabilities: vocabulary, semantics, and
architectural patterns
Alexander Bocast
May 16, 2023

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

3. Title 10 US Code
 TITLE 10 - ARMED FORCES
Subtitle A - General Military Law
PART I - ORGANIZATION AND GENERAL MILITARY POWERS
CHAPTER 2 - DEPARTMENT OF DEFENSE
Section 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

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

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

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

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

8. 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)
• CJCSI 3010.02C no longer defines this term.
• 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

9.  means — Forces, units, equipment, and resources.
 measure — The basis for describing varying levels of task performance. (CJCSI 3010.02B)
• CJCSI 3010.02C no longer defines this term.
 mission — The purpose (objectives and endstate) assigned to the commander. (CJCSI
3010.02B)
• CJCSI 3010.02C no longer defines this term.
• 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)
• CJCSI 3010.02C no longer defines this term.
 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)
• CJCSI 3010.02C no longer defines this term.
 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

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

11. 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 risk
Maximum possibility of success
Minimum possibility of failure

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

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

14. 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?

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

16. 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.
output
input
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.

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

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

19. traditional extent of organizational behavior models
external stakeholders over here
their input
behavioral notion of effect
your input
your guys
your control
do their thing
their 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

20. 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
their observed input
capability measures
DOTMLPF guy
acquisition guy
tailoring criteria
your effect
your input

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

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

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

24. 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…
expected outcome for this (sort of) mission, under
these conditions, orchestrated with other capabilities…
expected outcome for this (sort of) mission, under
these conditions, orchestrated with other capabilities…
expected outcome for this (sort of) mission, under
these conditions, orchestrated with other capabilities…
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
pick mission
capability
A-12

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

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

27. order—chaos spectrum
Figure 2. Order—Chaos Spectrum. From Sarah
Sheard’s Principles of Complex Systems for
Systems Engineering, INCOSE 2007.
Order
Newtonian laws
Bell curves
Plans
Predictability
Control
High overhead
Little communication
Chaos
Laws of chaos
Strange Attractors
Reactions
Flexibility
Variety
Low overhead
Instability
Complexity
Capability
Power Laws
Priorities
Adaptation
Leverage
Agility
Critical Point
Order
Newtonian laws
Bell curves
Plans
Predictability
Control
High overhead
Little communication
Chaos
Laws of chaos
Strange Attractors
Reactions
Flexibility
Variety
Low overhead
Instability
Complexity
Capability
Power Laws
Priorities
Adaptation
Leverage
Agility
Critical Point

28. 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?

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

30.  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

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

32. mission & capabilities
take that thar hill at dawn
capability
activity

33. condition manifold, scenario space, & standards
tasks
tasks
conditions
standards

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

35. canonical
scenario
space
scenario
term space for architectural discourse
capability proposition
capability requirement
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 values
architectural 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.

36. 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 requirement
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.

37. 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=1
capability requirement 1
mission 1

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

39. capability as architectural pattern: capability proposition
do something
else
their output
5
your controls
your information
their input
specify
requirements
1
capability requirement
standards
mission guy mission designer
architectures
their guys
their stuff
resources
tailor behavior
2
selected behaviors
provide resources
3
their controls
capability socket
4
set strategy
wreak effect
pick mission
capability
apportion
capability
system
mission statement
nominal capability architecture
enterprise architecture
means
ways
tasks
conditions
your output
selection criteria
your stuff your guys
their observed input
capability measures
DOTMLPF guy
acquisition guy
tailoring criteria
your effect
your input

40. capability requirement
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
specify
requirements
1
capability requirement
standards
mission guy mission designer
architectures
their guys
their stuff
resources
tailor behavior
2
selected behaviors
provide resources
3
their controls
capability socket
4
set strategy
wreak effect
pick mission
capability
apportion
instance
system
mission statement
capability instance architecture
enterprise architecture
means
ways
tasks
conditions
your output
selection criteria
your stuff your guys
their observed input
capability measures
DOTMLPF guy
acquisition guy
tailoring criteria
your effect
your input
service interface

41. service
capabilities & SOA: OASIS SOA Reference Model
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
select
behavior
A-12
selected behaviors
provide
resources
A-13
their controls
do tailored
capability
instance thing
A0
mission statement
capability instance architecture
enterprise architecture
means
ways
tasks
conditions
your output
selection criteria
your stuff your guys
their observed input
capability measures
DOTMLPF guy
acquisition guy
tailoring criteria
your effect
your 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

42. capabilities & SOA: OASIS SOA Reference Model with brokered contract
do something
else
A-15
your controls
your information
their input
specify
requirements
A-11
capability requirement
standards
mission guy mission designer
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
capability instance architecture
enterprise architecture
means
tasks
conditions
your output
their observed input
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

43. BLUE TEAM ARCHITECTURE
RED TEAM ARCHITECTURE
their input
behavioral notion of effect, revisited: RED TEAM architecture
your input
your guys
your control
do their thing
their output
their guys
their control
A-11
do your thing
A0
effect measures
your effect
your output
their observed input
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.

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