Mechanisms for Agility - dodccrp.org · A presentation to ICCRTS 2006 September 26-28, Cambridge, UK. 3 Uncertainty and Change • Military ... • C2 systems need to be agile and

Mechanisms for AgilityDr David N AllsoppA presentation to ICCRTS 2006September 26-28, Cambridge, UK

3

Uncertainty and Change

• Military

• Political

• Commercial

• Social/Cultural

• Technical

ICCRTS 2006

4

A “Runtime World”

• A fixed threat -> a fixed defence?– out of touch with reality

• Design for a fixed zone -> limited to that zone– Adversary will push us out of that zone

• Open and “always-on” systems– More like medicine than engineering

ICCRTS 2006

5

Implications for C2 systems

• C2 systems need to be agile and flexible

• Reconfigurable at run-time

• Minimal built-in assumptions

• Greater effectiveness by keeping option space as open and large as possible

ICCRTS 2006

6

Flexibility?• Flexibility of system = integratability and modifiability of parts

• “Loose coupling”

• Attributes and behaviours include:– Not vendor- or platform-specific: use open standards– Components with clear, separate interfaces– Dynamic discovery of components– Composability– Hardware/address/location – independence– Failure as a normal condition

ICCRTS 2006

7

Limiting factor?

• Some believe that technology is the limiting factor or “rate-determining step” in agility

• We argue this is not the case:– We present a proof-of-concept software tool– We discuss technical mechanisms to achieve the

required flexible behaviours

ICCRTS 2006

8

Case Study: Decision Desktop

• Proof-of-concept agile information tool

• Acquire, visualise and manipulate diverse and dynamic battlespace information

• Create and share flexible visualisations to suit task

• Decision-makers can get:– the information they want– when they want it– in a form that suits the task at hand

ICCRTS 2006

9

Design philosophy

• Minimise design-time assumptions to maximise run-time flexibility

• Avoid arbitrary limitations on:– Where information comes from;– What information is required;– The level of detail of the information;– When information must be transferred;– Mode of information transfer (push or pull)– How the information will be displayed

ICCRTS 2006

Plug-in info sources

PalettePalette TimeDecoderTime

DecoderIcon

LibraryIcon

Library

Information

Context

LocationDecoder

LocationDecoder

Views:

Filter

Other plugins:

“Semantic cloud” of information

Filter

11

Technical Work

• Technical work

12

Integrating dataASW data in the Coalition Agents

Experiment

Agents & ServicesPlug-in

information resources

Integrating dataMTI tracks from Shared Tactical Ground Picture (STGP)

ComponentsPlug-ins for

selecting and displaying data

ContextShow areas of knowledge; use targeted queries

Drilldown Interact with

objects and drill down for more

detail

UncertaintyManage multiple

locations or uncertain status

Viewsconfigured to

display chosen information

13

Flexible visualisation

• Coalition Agents Experiment (2002)

• Rapid integration of data from new coalition partner

ICCRTS 2006

14

Key features

• Ability to handle diverse, unexpected data

• Plug in new functionality on-the-fly

• Tailor visualisations at runtime to suit task

• Share visualisations over network

• Not a static “picture” – objects’ data can be explored/browsed in a variety of views

• Plug-in filtering, symbology, data translation…

ICCRTS 2006

15

Discussion: Agility

• New demands on users? New roles?

• How will this form of agility be used?

• How does “bottom-up” agility interact with “top-down”reshaping?

• Can you have too much flexibility?

ICCRTS 2006

16

Discussion: ProcessesICCRTS 2006

Dynamic(run-time)

Fixed(design-

time)

Process-neutral

Process-centric

Decision Desktop

Office automation tools

Conventional C2 software

Agents, SOA?

17

How to get there?

• Technology is not the main obstacle– But C2 technology is not mature or complete!

• Don’t bend technology to fit old processes, then blame technology if little improvement is achieved

• How to design and procure technology that assists human creativity

• What tools and building blocks?

• Obstacles: specification, procurement, accreditation and exploitation of agile systems.

ICCRTS 2006

18

Acquisition

• Must deal with requirements change problem– Timescale of change != timescale of procurement

• Quality attributes such as flexibility – not easily measured– do not figure prominently in procurement requirements

• Evaluate systems not on what they can do one day one– What can they be modified to do in the future, and by

whom– Skills, licences, development tools, IP rights

ICCRTS 2006

19

Pointers for acquisition

• Reduce emphasis on specifying design-time requirements

• Approaches and metrics for assessing flexibility at design-time, build-time and run-time

• Embrace heterogeneity

• Exploit mix of architectures (e.g. Pub-sub, service-orientation)

• Bold experimentation; early deployment

ICCRTS 2006

20

Accreditation• Traditionally: off-line analysis of fixed configuration of a

stove-piped system– untenable in a network-centric design

• Complex open system -> emergent properties– Qualities of parts -> desirable behaviours of the whole

• New opportunities for security, as well as new challenges– Disciplined, compartmented architectures– Difficulty of attack

• D3C: run-time risk management / domain-based security

ICCRTS 2006

21

Conclusions

• We inhabit a “run-time” world of uncertainty and change.

• -> C2 systems need to be agile and flexible

• Improve agility by shifting from design-time “optimisation”towards run-time reconfiguration

• Such run-time tools are possible: Decision Desktop proof-of-concept

• -> Technology not the leading constraint – Experimentation, procurement, accreditation

ICCRTS 2006