Alternate futures for the INCOSE Technical Vision

Elliot Axelband

Technical Vision 2020 Topic: General

Why Alternate Futures? INCOSE’s Technical Vision was created by some of its most talented members using a deliberate, interactive, and recursive technique. I had the pleasure of participating in that process. However, the future evolves from the present in a chaotic manner, making predictions about the future – particularly long-range predictions – notoriously wrong. Just look at past examples. For this reason, I offer for your consideration and enjoyment some alternate futures. They are less likely, since they did not undergo the rigor of the Technical Vision 2020 group process, but they are possible, and were written somewhat tongue-in-cheek.

Hardware Intensive Software Systems of Systems and the rebirth of Systems Engineering. This field will succeed Software Intensive Systems-of-Systems (today’s state), which had evolved from Systems of Systems, the child of Systems, the original field that gave rise to Systems Engineering (SE). System-of- Systems was given impetus about 10 years ago when for economic and operational reasons it became clear that – at least for some circumstances - the efficient route to new capabilities would be to link existing and new systems. The dominant technology to make this linkage happen was identified as an amalgam of information, communication and software technologies (more about that later). But as the past has revealed, anything dependent on software – an art form – was fragile and turbulent; likely to cost much more than original estimates, and likely to undergo severe schedule slips. Art forms are demanding and difficult to control. This feature achieved rapid recognition via a rapid transition to a new name – Software Intensive Systems of Systems. At the same time, software companies and conferences quickly changed their names to become system and software companies and conferences. This did not improve the software art, but it did take the pressure off software for a while, and supported a new focus.

But then the unexpected happened, as is often the case in evolution. Sophisticated new Software Intensive Systems of Systems started to experience significant hardware problems in several application fields, as the performance demanded of them stretched their hardware state of the art. [1][2]

As a result, in the near future, the field of Hardware Intensive Software Systems of Systems will be created. Somewhat further in the future there will arise a wide spread recognition that all the types of systems discussed here are variants of systems, and that there are - in addition to special techniques that apply to them as variants – basic principles and techniques that apply to all of them. This will lead to an enrichment of the field of SE to become more encompassing, as its wide application will have been rediscovered. Some already have this view, and they are acting accordingly.

Diminished Expectations for Net Centric Operations (NCO): The core of SE is integrating components to a higher end. NCO applies to systems whose components are physically separated and integrated by information, communication and software technologies. There are examples illustrating the success of NCO in the military (FBCB2) and commercial fields (net enabled just-in-time resupply).

But here I speak of NCO as envisioned for the future widespread, fast-moving battlefield, to be implemented using GIG/NCES (Global Information Grid/Net Centric Enterprise Services). The GIG is planned to be implemented using constellations of broad-band satellites that communicate with mobile ground forces that operate as mobile ad-hoc (MANET) networks, that form and re-form as necessary to best accomplish their mission in the face of changing field realities. NCES are the software-enabled means by which data and processing are provided where and when needed to generate the information required by the ground forces.

But some problems with this vision are emerging. Is there adequate BW to accomplish this vision? Probably not![3] Is the field of MANET networks adequately understood to predict with reasonable certainty that the objectives of this vision of GIG/NCES NCO will be realized? Probably not![4] Therefore, there remains much SE work to be done to learn how to benefit from the probable reduced realizable state of NCO.

In this sense, the vision of NCO will be diminished. But this is a narrow technical sense. The real question is whether the realizable capability of NCO will be valuable. It will be, but only after considerable refinement in the fields of information compression by both technical and operational means, and the development of suitable tactics, collectively, an SE problem.

The Rise of End-to-End Validation: We all know that the operation of innovative unprecedented complex systems is difficult to predict prior to actual operational experience. The development of such systems can be considered a (spiraling) sequence of refined models progressing from concepts born of inspiration and desire, followed by abstract analytical models, leading to simulations, then prototypes, and eventually the final product, in an iterative fashion characterized by increasing sophistication and fidelity. In the end - and there are many ends in the life cycle to include development, manufacture or realization, support, and retirement - to assure that we have what we wanted, we need to compare the end product with what was intended in the form of a capability, a specification, a product description, or customer satisfaction, depending on the application. Of course, we know this; we are systems engineers of one kind or another.

But as systems become more abstract and interrelated, it becomes expedient to substitute intermediate measures, even if the consequences of that substitution are questionable. I offer two examples: Maturity Models and Policy, and the alternative future to which they will lead.

Maturity Models are a specific means to better products via process improvement; improve the process by which products are created by these means and you improve the quality of the product and lower its time to market and cost (development, production, sustainment, pick the target or targets). A family of philosophically related maturity methods has been provided and is being expanded to include CMM (add trade mark symbol) (Capability Maturity Model for Software), and CMMI (add trade mark symbol) (Capability Maturity Model Integrated) that has variants for SE, Acquisition, and other fields. These are not inexpensive tools to acquire and use, as people must be trained in their use and evaluated by assessors who determine the maturity level of the group being assessed on a numerical scale. Having a high maturity rating is, unfortunately, often a de facto requirement for receiving a contract. In the end, however, what is desired is the improved quality of the product and its attributes. Maturity model users generally feel that these methods have value, but their contribution to product excellence is slight,[5], perhaps because the processes which maturity methods assess are not the right processes.

Policy, and by this I am specifically focusing on the policy of the US DoD and the US Armed Services, seems to have a similar construct. There are many examples, but to avoid extensive elaboration I will choose a recent and almost universally acknowledged example, the Acquisition Reform Policy of the 1990-2002 time period. A study of this process[6] reveals that it was very poorly implemented, even though it was very widely acclaimed, enforced and adopted. Today[7][8], it is broadly acknowledged as having been a major contributor to billions of dollars of inefficient and counter-productive program expense.

Maturity Models and Policy are both examples of process improvement efforts that have done little to improve the causes they were designed to address. While considerable effort is still being expended in this direction, it will be different in the future, when it will be recognized that process improvement carries with it the serious risk of unintended consequences that can lead to negative results. To avoid this, the well-known and accepted SE practice of prototyping and experimenting via prototyping to validate a process will be required before mass application. Granted, this can be a laborious process that must be carefully planned and executed, but it is the better alternative. It’s simply “fly before buy” in the non-aircraft realm.

Remember: Predicting the future is perilous. Be aware of the Technical Vision 2020, but do not be captivated by it. Learn and adapt!

[1]GAO report GAO-5-271, 3/05, Page 5, “Tactical Aircraft, Opportunities to Reduce Risks in the JSF Program”

[2]Wall Street Journal, 9/23/05, Page B2, “US Shifts Spy-Satellite Work from Boeing to Lockheed Martin”

3 Joe, L. & I. Porche, “Future Army Bandwidth Needs and Capabilities”, RAND, Santa Monica, MG-156-A, 2004.

[4]3/17/05, RAND Conference on the Science of Networking,

[5]Bob Rassa, “Industry Feedback on SE Implementation on DoD Programs”, slide 17, May 2005

[6]Hanks, Axelband, et.al., “Reexamining Military Acquisition Reform, RANDArroyoCenter, MG-291, 2005

[7]General Martin, AFMC Commander, as quoted in June ’05 issue of National Defense, page 6

[8]“Defense Science Board/Air Force Scientific Advisory Board Joint Task Force on the Acquisition of National Security Space Programs”, OUSD(AT&L), Tom Young, Chairman, 5/03