1 A Systems Engineer’s Perspective on Developing NCO Systems William W. Schoening Copyright © 2005 Boeing All Rights Reserved

2 Collaborative Systems* Definition –Individual systems can operate on their own –Collaborative systems are not owned and controlled as a whole by single entity Examples –Internet –Auto and truck transportation –Air Defense System – maybe –A group of people working on a project *Mark Maier, “Architecting Principles for Systems-of-Systems”, Journal of the International Council on Systems Engineering, Vol. I, 1998

3 Business System Transformation Eastman Kodak Consumer Segment Use with the permission of and thanks to James C. Stoffel, Sr. VP Eastman Kodak Picture Life Cycle for Traditional Technologies Picture Life Cycle for Digital/Hybrid Complex collaborative systems are the way of life in the commercial world

4 NCO and Systems Simple systems (even with NCO) are not very interesting from a systems thinking perspective Hallmark of collaborative and competitive systems is independence of individual systems Change is usually unpredictable and chaotic Collaborative systems must be highly adaptable to change if they are to survive

5 Some Risks for Collaborative NCO Systems

6 IF an individual system-of-interest unilaterally defers some of its capabilities and other individual systems require those capabilities for successful collaboration, THEN the collaborative system will not perform as expected. Multiple individual systems updating on their own schedules –Inconsistent interfaces –Inconsistent behavior Multiple individual systems making unilateral decisions –Surprises -- good and bad –Disruptive technologies Critical features must be understood by all

7 IF a system’s architecture and design are not adaptable to unknown requirements, THEN the system will lose out to those that are more adaptable leaving the developer with less than expected long-term revenue and profit. Parts of a solution Excess design margins Open architecture Architectures that accommodate other kinds of changes easily Alternative futures required to evaluate approaches

8 Some choices –Compromise to reduce proliferation –Accept the consequence IF implementation of requirements for supportability is repeatedly deferred in the interest of quick time to market or prototyping, THEN there will be many copies of the product that are not very supportable leaving a perception of poor supportability engineering by the developer.

9 NCO is more than just hooking a bunch of nodes together More data does not me it is useful We must also help users understand the content IF developers focus on data transfer (because is it easier to study) rather than interpretation by users, THEN users will begin to ignore the NCO system.

10 Where might they attack? –Systems are most vulnerable at interfaces –Internet is vulnerable to spam with viruses –NCO may be vulnerable to overload of meaningless inputs –Threats may be able to actively initiate otherwise- unintended NCO activities What can we do to alleviate this threat? What other threats are there? IF threats can successfully attack an NCO network, THEN its value will be lost (and we might even be worse off than before NCO.)

11 Operations with significant terrain masking –Potential for unusually high rate of drop and rejoin –True content messages delayed or –Grunts toss their NCO devices because they don’t work when needed (and rate of rejoins drops.) Logically correct architecture and design with great “style points” may not be the best choice IF the architecture and design do not adequately consider potential operating contexts, THEN the NCO system will not perform adequately in some highly stressful situations.

12 Concluding Remarks What users want to do determines the nature of NCO –Form must follow function –Technology is only an enabler Function includes being able to deal with the realities of collaborative systems The most successful NCO installations are likely to be those that are the most robust rather than those that have the best performance NCO is an enabler for a system, and seldom the most important part of the system from a user perspective