Agility and Value for Defence

March 18th, 2009

by Philip Boxer

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

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.

Modeling and Analysis of Interoperabiliity Risk in Systems of Systems Environments

October 29th, 2008

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.

Understanding and factoring in variability in the execution of SoS functionality

September 29th, 2008

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

Requisite Agility

July 10th, 2008

by Philip Boxer

This article by Bill Anderson and Philip Boxer on Requisite Agility argues that the socio-technical processes required to respond to changing demand can be described (modeled) and better equipped to handle change if the organization is driven from a demand-side perspective rather than from a supply-side perspective.  The ability to do this increases the potential for software services acting as constituent parts to automate more and more parts of the existing geometry-of-use space in order to create new possibilities on the demand side.

A Context-Based Approach to System-of-Systems Challenges

June 17th, 2008

by Philip Boxer

SEI has published a Technical Report on its context-based approach to system-of-systems challenges. This begins to introduce the methods of projective analysis and asymmetric design into their practices.

Systems-of-Systems Engineering and the Pragmatics of Demand

April 14th, 2008

by Philip Boxer

Last week I was joined by Bernie Cohen and colleagues from the SEI to present this paper at the IEEE 2nd International Systems Conference in Montreal, Canada (April 7-10, 2008).

The paper considers how the particular pragmatics of demand ‘at the edge’ determine the forms of interoperability required of complex systems of systems, which we refer to as ‘geometries-of-use’. The importance of this concept lies in its use to determine the requisite variety of geometries-of-use that a systems of systems infrastructure needs to be able to support. From this we can determine the functional granularity required of the supporting infrastructures.

Agility and Innovation in Acquisition

April 4th, 2008

by Philip Boxer

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

The article outlines an approach to meeting the challenges of Through Life Capability Management.

JFSP Software Tools and Systems Study

February 21st, 2008

by Philip Boxer

The Joint Fire Science Program enagaged the SEI to lead an independent examination of current fire management software tools and systems. The approach used by the SEI made use of visual PAN techniques. The project was outlined in a brief from the Joint Fire Science Program in September 2007, and reported on in the Software Engineering Institute Annual Report 2007, pp22-23.

Distinguishing the not-good-enough

January 29th, 2008

by Bernie Cohen

A reaction of one reader to my pragmatics blog was that, pragmatically speaking, it was still possible for a shared EHR to add value, but that it was certainly important to down scope the problem of sharing meaning across an enterprise, knowing full well that artificial boundaries are being drawn within the overall enterprise as a consequence. He goes on to say: “It may be a case where the perfect is the enemy”.

Maybe. But my own view is that this line - that the best may be the enemy of the good - doesn’t take into account the real harm that can be done by the not-good-enough.

Consider another aspect of Healthcare, the Clinical Practice Guidelines (CPG) which is strongly promoted by WHO and supported internationally. The potential benefits are enormous, not just for the patient, who should expect to be treated with best practice by any clinician who has the CPG CDs, but for the practitioner, who will be able to defend against any accusation of negligence by demonstrating adherence to CPG, and, most importantly, for the payer (government or insurance company) who will have the philosophers’ stone: the ability to predict, given the cost profile of the CPGs and the statistical distribution of complaints, the future cost of healthcare.

Unfortunately, this all depends on the ability to demonstrate the mutual consistency of the CPGs, which have been, and are being, drawn up by panels of specialists who have their own ontologies. For example, suppose a patient presents symptoms suggestive of both asthma and angina (both of which already have CPGs), which is not uncommon, and a clinician decides to follow one, or the other, or both CPGs, will the treatment plan, outcomes etc. be similar in each case? And who will take responsibility for damages caused by inconsistency? And how, and by whom, can all compositions of CPGs be so checked?

And while we’re on the subject of insurance companies, we already know that their ontologies differ markedly from those of both practitioner and patient, as demonstrated by the classic Kaiser Permanente example: a researcher who did a longitudinal study of post-partum complications using a large KP anonymised data set discovered that a significant proportion of those complications occurred in male patients, this being due to the fact that KP recorded the gender of the payer, not the patient!

When it comes to sharing meaning, before making the best the enemy of the good, we first need to know how to distinguish the not-good-enough. If we are to develop a care-centric approach to the patient in meeting the challenge of Health Care Reform, we are going to need to share meaning by reference to the patient situation itself and not just by reference to the treatment protocols involved.

10th Annual Systems Engineering Conference

October 23rd, 2007

by Philip Boxer

In October 2007, the SoS Navigator team went to this NDIA Conference to present two papers:

A Tutorial was also given on Modeling Sustainment and Risk Mitigation for Net-Enabled Realities.

Creative Commons License
This work is licensed under a
Creative Commons
Attribution-NonCommercial-NoDerivs
2.5 License
.