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 October 3, 2014

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. Joint terms: JCIDS Joint Capability Area Baseline Reassessment 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.)

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. Joint terms: JCIDS Joint Capability Area Baseline Reassessment2 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.)

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 —theperformance 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… interpreting qualified terms in the JCS definition of capability 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.)

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 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. Control shapes transformation. Without control, behavior is random: monkeys pounding keyboards. control transform output input mechanism 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.

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. behavioral notion of effect effect measures your effect your output 1 stakeholder output == your outcome traditional extent of organizational behavior models your control your input do your thing their input A0 their control external stakeholders over here your guys their observed input do their thing their output A-11 their guys

20. behavioral sketch of JCS notions of capabilities your information your controls your output capability measures your guys your effect specify requirements provide resources tasks A-11 A-13 means capability requirement standards selected behaviors conditions ways enterprise architecture tailoring criteria mission designer nominal capability architecture selection criteria their input resources your input architectures mission statement their controls mission guy their observed input acquisition guy DOTMLPF guy their guys your stuff their stuff set strategy tailor behavior pick mission capability A-12 do tailored capability thing A0 do something else wreak effect their output apportion mission system A-14

21. wreaking effects: a simplistic example their controls physical laws behavior feedback your fired bullets your effect their fired bullets their observed guys their alive observed guys shoot their bullets A-142 intercept your bullets their bullets your bullets A-141 their observable guys do tailored capability instance thing A0 shoot at your guys their unobserved guys A-14 their weapons their guys

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 your information your controls resources their input architectures your input mission statement their controls set strategy A-11 pick mission capability A-12 apportion mission system A-13 do tailored capability thing A0 wreak effect their output A-14 expected outcome for this (sort of) mission, under these conditions, orchestrated with other capabilities… candidate architecture means tailored behavior performance candidate architecture means tailored behavior 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… candidate architecture means tailored behavior performance candidate architecture means tailored behavior performance expected outcome for this (sort of) mission, under these conditions, orchestrated with other capabilities… candidate architecture means tailored behavior performance expected outcome for this (sort of) mission, under these conditions, orchestrated with other capabilities…

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.

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 Sheard’s Principles of Complex Systems Engineering: transitioning • 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

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 activity capability

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

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. term space for architectural discourse specified conditions values specified conditions design conditions values design conditions design standards values design 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. capability proposition overarching Joint concept of capability-based requirements capability space all possible missions canonical all defined tasks all allowed values for all defined conditions all allowed values for all defined standards all allowed measures for all defined effects scenario capability requirement specified mission specified task scenario space specified standards specified standards values specified effect specified effects measures architectural patterns nominal capability design task(s) architecture design effect design effects measures

36. terms for architectural discourse the notion of capabilities intended by Joint terms such as “capabilities-based”: intent & doctrinal foundation. capability proposition a set of normative concepts that structures and constrains requirements for mission behaviors in accordance with the capability proposition. capability space a behavioral requirement stated in terms of the capability space to specify mission, task, conditions & their values, standards & their values, & measured effects. capability requirement 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. nominal capability a nominal capability whose design concepts & values approximate the specified concepts & values of a capability requirement. candidate capability a candidate capability that sufficiently satisfices a capability requirement. capability a capability selected for inclusion in the course of action of a mission. mission capability mission capability whose ways and means have been appropriately tailored and made available for a mission: an executable instantiated architecture. tailored capability realized capability the actual ways and means of a tailored capability in action: an executing instantiated architecture.

37. cardinalities of architectural discourse capability proposition mission ? 1 capability space ∞ capability requirement 1 ∞>> p nominal capability candidate capability p > k capability k > c mission capability c > m=1 tailored capability m.t > t realized capability t=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 your information your controls capability measures your guys your output your effect tasks means selected behaviors conditions standards capability requirement ways enterprise architecture tailoring criteria mission designer nominal capability architecture selection criteria their input your input architectures resources their controls mission statement mission guy their observed input DOTMLPF guy acquisition guy their guys your stuff their stuff specify requirements set strategy 1 tailor behavior pick mission capability 2 capability socket 4 do something else wreak effect their output provide resources apportion capability system 5 3

40. capability requirement service requirement convergence with notions of service your information your controls your effect capability measures your guys your output tasks means conditions capability requirement standards selected behaviors ways enterprise architecture tailoring criteria mission designer capability instance architecture selection criteria their input architectures resources your input their controls mission statement mission guy their observed input acquisition guy DOTMLPF guy their guys your stuff their stuff specify requirements set strategy 1 candidate capabilities service discovery tailor behavior pick mission capability 2 capability instance service interface capability socket 4 do something else wreak effect their output provide resources apportion instance system 5 3

41. capabilities & SOA: OASIS SOA Reference Model your guys your output ways your effect capability measures provide resources specify requirements tasks A-13 A-11 means selected behaviors standards capability requirement conditions enterprise architecture mission designer your controls tailoring criteria selection criteria your input architectures their input resources their controls mission statement mission guy their observed input DOTMLPF guy their guys acquisition guy your stuff their stuff 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. execution context your information need service select behavior visibility shared state service descriptions A-12 capability instance architecture service interface service interface do tailored capability instance thing interaction A0 service functionality do something else real world effect their output service means A-14 service consumers contract & policy ?? service provider

42. capabilities & SOA: OASIS SOA Reference Model with brokered contract your information your controls their controls your output capability measures your effect tasks specify requirements A-11 means your stuff enterprise architecture negotiate agreement select behavior tailoring criteria capability requirement standards conditions selected behaviors A-13 A-12 ways defined capability contract selection criteria capability instance architecture architectures their input resources your input mission statement do something else provide resources A-15 A-14 their observed input your guys acquisition guy their guys their stuff mission guy broker DOTMLPF guy do tailored capability instance thing A0 their output mission designer

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

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.