Asymmetric Design

by Philip Boxer

This paper was presented in collaboration with Dr Nicholas Whittall (formerly Strategy Director, Thales UK Aerospace Division) at the 12th Annual NDIA Systems Engineering Conference in San Diego with the following abstract:

Recent studies into the operational use of a UAV system have shown that the variety of mission situations in which the UAV system was used had far exceeded those anticipated at the time it was acquired. In effect, the dimensions of the operational capability space had expanded beyond the particular dimensions of the capability design space constrained by the acquisition paradigm. Whilst this may be regarded as the benefit of network-enabled approaches, which are intended to increase the variety of ways in which capabilities can be combined to create composite capabilities within systems of systems (SoS), this raises the question of whether the engineering of SoS can be addressed adequately from within the perspective of the capability design space.

From the point of view of the supplier, one way of approaching the impact of an expanding operational capability space is to think in terms of its being multi-sided, its multiple ‘sides’ corresponding to the multiple ways in which a supplied system can participate in larger systems of systems. This multi-sidedness yields an additional value to that normally associated with the direct use of a system’s particular capability. This additional value is associated with the system’s ability to support multiple ways of being used in conjunction with other capabilities, creating a multi-sided market in which two kinds of value have to be considered.

For the supplier of a component system within the context of a SoS, “Directed” or “Acknowledged” processes for acquiring SoS establish a single customer for the performance of the component system against a particular capability requirement, so that the supplier’s focus can be on the capability design space alone (referencing OSD’s Systems Engineering Guide for Systems of Systems, v1.0 August 2008). But in the case of “Collaborative” SoS, no such ‘top-down’ requirement is established, and a community interested in the uses of the operational capabilities of the SoS (possibly a Community of Practice) has to define its requirements ‘bottom-up’. In this case, the supplier of a component system faces customer requirements that must span a variety of different ways of being used operationally, making the supplier’s market multi-sided. As a result, the system’s supplier must approach the capability design space from the perspective of an expanding operational capability space in which two kinds of value must be generated for the customer.

The paper will outline an approach to Collaborative SoS in which the multi-sidedness of the SoS is defined in terms of its expanding operational capability space. The paper will use this approach to distinguish the two different kinds of value associated with supporting the SoS as a multi-sided market, and show how these two kinds of value impact differently on the design of its component systems.

by Richard Veryard

An independent review into the way the MOD buys equipment for Britain’s Armed Forces was published yesterday, Thursday 15 October 2009. [Report, MoD News Article, BBC News]. Key finding.

“The Ministry of Defence has a substantially overheated equipment programme, with too many types of equipment being ordered for too large a range of tasks at too high a specification. This programme is unaffordable on any likely projection of future budgets.”

That situation might sound familiar to a lot of managers, not just in the defence sector.

The report makes some favourable comments about the Through Life Capability Management (TLCM) programme, but indicates a lack of hard financial data that would be required to make quantitative decisions. As regular readers of this blog may recall, there has been some discussion along these lines published in the RUSI Journal, including Agility and Innovation in Acquistion (Feb 2008) and The Meaning of Value-for-Money (Feb 2009).

The explanation for the current crisis can be found in the essential multi-sidedness of the defence acquisition ecosystem. Traditional cost accounting approaches (such as activity-based costing) fail to address the complexity of this multi-sidedness, and researchers are urgently seeking alternative cost accounting methods appropriate for complex systems-of-systems.

One of the key issues for Through Life Capability Management is that any errors or omissions in the long-term equipment programme must be repaired through what are known as Urgent Operational Requirements (UOR), which over the long haul can prove far more expensive and inflexible than the planned equipment.

The report also praises the Smart Acquisition programme, and expresses regret that the disciplines of Smart Acquisition have been somewhat diluted by recent reorganization.

***

by Philip Boxer

This paper and presentation were given at a RUSI Defence Programme Management Conference 29th to 30th September. It concludes as follows:

Approaching Through-Life Capability Management from a demand-side perspective uncovers three tempos that drive enterprise success within dynamic demand environments. These tempos are themselves governed by the enterprise’s ability to respond to demands for agility, and its need for operational capability leading to the requirement for equipment and other DLoDs.

The tempos support the view that our thinking about Defence – and enterprises in general – has rightly moved from equipment to capability, and that a third perspective, that of agility, is beginning to emerge.

“Agility” is the word of the moment, but it lacks content. Here we have offered a definition, which is meeting the campaign tempo. We may summarise this as “doing right things right at the right time”. This brings the need for timeliness into the mix with the needs for efficiency and effectiveness.

However, the full range of agility may not be affordable, and some means of costing it is required. We have presented cohesion based costing as such an approach and drawn on rough orders of magnitude to illustrate our argument in the case of Tactical UAVs.

Further work is required, of course, but it would need the collaboration of those who know the activity-based and alignment costs to strengthen our grasp on Agility and its Value for Defence.

by Philip Boxer

This presentation was given in collaboration with Suzanne Garcia at the Fifth SEI Architecture Technology User Network Conference on Architecture at all Scales, May 4-7 in Pittsburgh.

Software architects are increasingly being asked to address how their architectural representations relate not only to those of systems (of systems) engineers, but also to the views commonly found in DODAF (Department of Defense Architecture Framework) or other enterprise architecture frameworks. In many cases, these requests made to software architects are part of trying to understand how one software system is likely to interoperate with others that are either inside or outside of the enterprise. Understanding some of the limitations of the Zachman framework and DODAF 2.0 in understanding both software architectures and interoperability in complex systems of systems should make it easier for software architects to place their architectures in relation to these other common frameworks. This presentation describes proposed modifications to the Zachman framework that are required to account for the needs for cross-enterprise collaboration and for accommodating new user needs at a rapid pace. The presentation also highlights a set of modeling elements that are commonly found in multi-enterprise situations. These modeling elements are illustrated in reference to DODAF 2.0 entities to emphasize what is currently missing. The presentation concludes with an example from a modeling approach that addresses these gaps, which is used at the SEI to describe not only the social and technical aspects of systems (including software systems), but also their relationship to the changing demands (especially user needs) placed upon them.

by Philip Boxer

This paper was presented at the 3rd Annual IEEE Systems Conference in Vancouver March 23-26 with the following abstract:

The tempo at which an enterprise creates new uses for its systems is different from that of its acquisition or systems development processes. The military continues to confront the issue of how fielded systems can support the agility needed by its deployed forces. This problem of diverging tempos applies to a variety of large-scale, software-reliant enterprises-such as those found in healthcare and digital communications. This paper posits four realities underpinning an approach to this problem space: the governance-demand double challenge, edge-driven perspective, stratification, and demand cohesion. It uses a particular case example to show how these concepts support the modeling and analysis of the enterprise as a socio-technical system of systems. The paper argues that analyses based on this approach are necessary for making this problem space tractable.

by Philip Boxer

This paper was presented in collaboration with Suzanne Garcia at the 3rd Annual IEEE Systems Conference in Vancouver March 23-26 with the following abstract:

An enterprise architecture is an accepted, widely used means for an organization to capture the relationship of its business operations to the systems and data that support them. Increasingly, enterprises are participating in complex system-of-systems contexts in order to meet changing customer demands that require them to collaborate with other enterprises in new and innovative ways. For a complex system-of-systems context, a shortcoming of enterprise architecture is that it presumes a single enterprise or a single, ultimate source of control.

This paper explores an approach to reasoning about distributed collaboration in the complex system-of-systems, multi-enterprise context, in which this single, ultimate source of control does not exist. It outlines the ways in which the long-used Zachman Framework for enterprise architecture would need to be modified to account for multi-enterprise collaboration and decentralized governance. It proposes a concept of stratification to meet this need and puts forward the main characteristics of the methods needed to model the stratified relationships of complex systems-of-systems to their contexts-of-use.

by Philip Boxer

In February 2009, a joint article was published with Nicholas Whittall in the RUSI Journal:

• The Meaning of Value-for-Money

The article argues that costing flexibility of design and valuing agility offer the grounds for new commercial transactions and an approach to the elusive notion of Value-for-Defence.

by Philip Boxer

CrossTalk, The Journal of Defense Software Engineering, has published an article on the Modeling and Analysis of Interoperability Risk in Systems of Systems Environments in its November 2008 Issue.  The abstract is as follows:

This article describes the use of a set of modeling and analysis techniques in an interoperability risk probe that found gaps in the ability of a North Atlantic Treaty Organization (NATO) modernization program to react to changing demands. The modeling and analysis techniques were used to create models of the people, processes, and technologies of the program and to represent the way demands were placed on this complex socio-technical system. Analysis of the models revealed interoperability risks that were manifested in the linkages between operational requirements of functional capabilities and the way in which those capabilities were being maintained. The risks identified in this probe were typed as mission, composition, and performance risks. The structural models produced by the techniques bring a welcome engineering rigor to the process of examining interoperability.

The article, by Bill Anderson and Philip Boxer, summarises work done originally in 2006 by Boxer Research Ltd under contract to the Software Engineering Institute at Carnegie Mellon University.

by Philip Boxer

This paper was presented in conjunction with Suzanne Garcia, Bill Anderson and Pat Kirwan at the 11th NDIA Systems Engineering Conference in San Diego.  The abstract was as follows:

New kinds of threat and much wider varieties of demand on mission capabilities are requiring the military to achieve unprecedented levels of agility and responsiveness, and are driving the transformation of military capabilities. The great benefit of net-enablement in this new strategic environment is that it enables mission capabilities to be orchestrated and composed from constituent capabilities within the context of systems of systems.

The presentation outlines three essential ways in which the foundational nature of the systems engineering task needs to be transformed to take advantage of these new possibilities, and uses examples from various military contexts to illustrate their applicability. First, it discusses how the definition of systems-of-interest has to be extended to include their socio-technical nature. Second, the definition of systems-of-interest also has to give an explicit account of the contexts-of-use from which emerge new forms of demand for mission capability. Third, it has to be possible to analyze how these new forms of demand translate into new patterns of interoperability (geometries-of-use) across systems of systems, thus defining the agility of systems of systems in terms of the required varieties of geometry-of-use that they must support. The presentation concludes by considering the impact this has on the suppliers’ role, the acquisition process, and in particular the changes it introduces into how value is defined.

by Philip Boxer

The Office of the Secretary of Defense (OSD) has released a Systems Engineering Guide for Systems of Systems.  It “addresses SE considerations to meet capability needs through integrating independently useful systems into a larger system that delivers unique capabilities - a system of systems (SoS) - within the Department of Defense”.

The guide references the work on the Pragmatics of Demand as follows:

The architecture of an SoS is somewhat constrained by the structure and content of the individual systems, particularly the extent to which changes in those systems are affordable and feasible, since systems will typically need to continue to function in other settings in parallel with participation in the SoS. The functionality that the individual systems contribute to the SoS can be described in a functional architecture that puts the key functions in order, thereby sequencing the SoS tasks. An example is the ballistic missile defense end-to-end process through boost, mid-course, and terminal phases of ballistic missile threats which would serve as the framework for this functional process in the case of one SoS. The functional architecture provides a functional ‘picture’ of the system. It details the complete set of functions to be performed within the SoS as well as the relationships among the functions. The output of the design process is the design of the SoS, or the physical architecture that defines the physical components (constituent systems) of which the SoS will be composed. The variability in the execution of these functions in the field also needs to be understood and factored into the SoS architecture [Boxer, 2008].

This version of the document does not go on to describe the methods for analysing this variability, outlined in the work with Thales UK in terms of agility and innovation. However, it does reference the earlier work on the Navigator approach to managing system-of-systems interoperability:

Finally, the SoS systems engineer is challenged to develop approaches to evolve the ensemble of systems to meet new needs while accommodating the independently owned and funded constituent systems, which themselves are often evolving to meet their own system users’ needs. To attain this delicate balance and support decisions that are typically outside of the SE purview, the SoS systems engineer must understand systems and their relationships from multiple perspectives, including technical and organizational relationships. These decisions include analysis of options and trades for SoS design/architecture given current characteristics and development plans of systems; assessments to determine which requirements can be addressed in what time frame given system objectives, funding, and development schedules; and analysis of how internal and external changes will affect the SoS. Several activities, including the Software Engineering Institute’s SoS Navigator initiative, are examining these needs and approaches [Brownsword, Fisher, Morris, Smith & Kirwan, 2006].