Critical Success Factors for system-of-system architecture / engineering

1. Critical Success Factors for system-of-system architecture / engineering 25 October 2006 Neil Siegel Sector Vice-President, Technology Northrop Grumman Mission Systems

2. SoS design basics – one person’s view • Understand the work-flow and dynamic behavior of the system • “Long mission threads” • Simultaneous operations • Capacity • Port-to-port timing • Etc. • Separate the implementation of the structure from the implementation of the “meat” • Exercise the structure at scale early and often • Design for allowed / unallowed dynamic behavior • “DC timing diagram” analogy • Establishing boundaries and linkages • Tight versus loose coupling • Where to use each A small number of abstractions (“views”) are helpful. Science + engineering + art. Simplicity is a virtue.

3. Fitting the work to the distribution of skills in a real team • Implementation can vary significantly in complexity • In any large team, skill level across the team will vary significantly • Matching significantly improves the likelihood of a desirable outcome • Specific, tangible design steps to partition the design into “zones of pre-determined implementation complexity”

4. Design for quality factors • We are better as an industry at designing for highly-visible factors (e.g., functionality) than for underlying quality attributes (e.g., MTBF) • Real-world practice seems to result in a huge variance in achieved quality • Probably an indication of an immature state-of-practice across our industry • Not clear if the underlying cause is lack of skill or lack of focus • A big killer of programs!

5. Accept the limitations of our intuition • The relationship between improvement in a technical factor and improvement in observed system performance is not always obvious • Yet we all too often depend on intuition, or make use of hidden assumptions that do the same thing • Link technical predictors to operational predictors

6. Integrating people into the system’s business process • Building successful system-of-systems is a process that must include a business-process-reengineering aspect • Understand the sociology of your user community, not just what they say • Perform a careful partitioning of what the human can do best, and what the computer can do best • Effective and credible • Don’t ask the human for data the computer can figure out • Support the stressed user • Crossing security domains

7. Summary • At system-of-systems scale, things sometimes scale badly / non-intuitively • Unplanned dynamic behavior is the source of many of the hard problems • Not all people are equally skilled, so designs that are based on a tacit assumption that they are all equally skilled are risky • The large dynamic range of quality outcomes is a sign of immature state-of-practice Informing the system-of-systems design through domain knowledge seems essential