2014/01/27 14:00 Hillary Sillito, “Composable Capacity for Agile Systems of Systems”, Agile Systems and Systems Engineering Working Group

Hillary Sillito (University of Bristol) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Essay based on  INCOSE IW presentation last year in Philadelphia.

  • Agile for military, interoperability
  • An appeal to military to use systems thinking, systems engineering at force level

Problem and context

  • Long conversations over the past 10 years on capability engineering, bringing together with capability management and systems engineering
  • Language barriers, lots of definition of capability
  • Coming top-down gets stuck
  • Mission threads seems most successful, but Brits though too many situations that would never be encountered

Purposes of systems architecture:

  • How many people are actually doing this?
  • In engineering world, don’t quite know how to do this.
  • System-of-systems worlds, get things to work together, without side effects

If don’t achieve, get undesireable emergent properties (against enemies who do things that you said they couldn’t do)

General Sir Rupert Smith, from Bosnia:  In full view of enemy, did manoevers that enemy didn’t think of

  • Can’t plan ahead or fully anticipate

Open system benefits

  • First evidence that you can do this.
  • British vehicles to Afghanistan, trying to put new equipment on old equipment, couldn’t do it
  • So much equipment, couldn’t put on payload
  • Surveillance systems, etc.
  • Electronic architecture, standard data buses that can be updated without having to have controls and switches
  • Simplified version:  on the second or third upgrade, will get the money back, but on the current method for procurement, the open architecture was initially more expensive than alternative
  • Seems to work
  • Electronics and software work better than anyone had previously experienced

Interoperability

  • Definition: systems or units or forces
  • Everyone grabbed the systems or units, and haven’t focused on operational processes and culture
  • Benefit of interoperability is getting system-emergent properties, but it’s almost impossible to put together a business case to pay for the work

When was running integration authority, ran architectural inputs and audit of interoperability in 200 equipment programs

  • Equipment being bought by projects where procurement structure didn’t fit with operational way, so no one was going to own up for the operational architecture.
  • Would have been easier if everything was drawn from an operational architecture, rather than working bottom-up trying to integrated from components

How to specify a force element?

  • Force element as part of the system:  basic behaviour, key paramaters, timing and accuracy
  • But concurrency isn’t well dealt with, e.g. landing aircraft as enemy launches 20 missiles towards you.

Need to clearly separate the platform use cases from the system use cases

  • Not done properly on the systems worked on 10 years ago
  • What do the platform need to do to survive in a military environment?
  • Something things that have to do with logistics.
  • In military terms, apology, joint fires
  • Get a standard pattern for a military force element, rather than trying to integrate up into a force element never specified

Want stable, well characterized building blocks

  • e.g. ship, platoon — it’s the way a military commander puts a force together
  • Then exercise performance, behaviour
  • Something applying to disaster recovery may not apply to consumers
  • Granularity is important

Standard template for force element

Conclusion:

  • The more consistent and well-defined the components, the more you have to do in reconfiguration, will be dealing with system of system emergent properties

Comment:  Providing a system of system capability, might be better to portray as system of system architecture

Yes, using architecture as an approach.

Comment:  Quandary:  thinking of system of system as a system

May be better just to say “architecture” than “system architecture”

Comment:  Like composable systems, that are the active side of agility.  Reactions to the word “composable”?

Comment:  Composable not sufficiently strongly related to agile.  Didn’t hear agile throughout the presentation, didn’t hear composable (although the idea is used throughout).

Comment:  Composable, will this give me insight about whether this will tell how to construct a system of system architecture.  Without that knowledge, people may get lost.  A little pattern example, even if incomplete, would help readers translate.

Word count is 2144, could take something out so could have an example within 2500 words

Comment:  Non-military people should hear about this, because it translated into product architecture.

Comment: Getting closer to operational use case, back to basics.  Bridging to agile, have a lot of the bridges in the article.