How architecture becomes the key strategic enabler of requisite agility by - not separating 'design-time' from 'run-time' - continuous assessment and mitigation of hazards to agility - developing a capability for horizontal governance

1. .
Competing within Ecosystems:
determining requisite agility in system-of-system
architectures
UNICOM EA Forum
Philip Boxer BSc MBA PhD
Boxer Research Ltd
September 19th 2013
Copyright © BRL 2013
1

2. .
The demand for agility from
accelerating alignment tempos
Supplier 1
Supplier 2
sub-contract
sub-contract
The Provider
users
orchestration
synchronization
users
customersSuppliers Provider
Socio-technical ecosystem
The demands of customers arise within
their contexts-of-use
The Provider aligns its value propositions to
the demands of its customers
The supplier responds to its users
within the Provider
Demand tempo:
The rate at which new forms of
demand need to be
satisfactorily addressed
Demand
Tempo
Alignment tempo:
The rate at which the Provider is able
to align new value propositions to new
demands from customers
Alignment
Tempo
Acquisition tempo:
The rate at which
new requirements
can be met
Acquisition
Tempo
Copyright © BRL 2013
2

3. .
Key Messages
• ‘Architecture’ becomes the key strategic enabler of requisite agility.
• The risk of lack of agility is that users’ costs are driven up to the point that they are no longer
competitive. Lack of requisite agility limits active life.
– It is not possible to separate ‘design-time’ from ‘run-time’ in developing
supporting systems-of-systems platforms
• A ‘run-time’ focus alters the granularity at which new functionality can be added and creates a
greater emphasis on ‘run-time’ support to dynamic alignment. This limits the ability to
subcontract ‘whole system requirements’.
– There is therefore a need for continuous assessment and mitigation of hazards
to agility based on quantification of risks.
• Procurement of new capabilities has therefore to be driven from a deep understanding of
operational uses, which are inherently socio-technical in nature. ‘Design-time’ has to be
subordinated to ‘run-time’ and not vice versa.
– The leadership challenge is to develop the capability to determine requisite
agility.
• This challenge demands that an organisation develops a capability for governance that can be
driven horizontally from the ‘edge’ of the organisation. The customer situation really does have
to come first!
Copyright © BRL 2013
3

4. .
A CLOSER LOOK AT THE PROBLEM
Multi-sided Demand
Supporting Multi-sidedness
Copyright © BRL 2013
4

5. .
Platform Supplier
Evans, D. S., Hagiu, A., & Schmalensee, R.
(2006). Invisible Engines: How Software
Platforms Drive Innovation and Transform
Industries. Cambridge: MIT.
Multi-sided Demand:
counting the value of indirect customers
Direct value of a
‘one-sided’
relationship
1
2
3
n…
4
Indirect value of a ‘multi-
sided’ relationshipEcosystem
participants
Ecosystem
participants
• Multi-sided demand supported by a platform is demand for
which:
– There is direct value in the platform’s direct ‘one-sided’
relationship with a participant
– The customer of a collaboration between ecosystem participants
is an indirect customer
– With multi-sided demand, there is greater indirect value in the
‘multi-sided’ relationships the platform supports between
collaborating ecosystem participants
direct provision of ‘beds’ and
‘treatments’
the patient-in-their-life needing
a collaboration between
specialists responding to their
condition with a care pathway
the way a hospital provides
support to collaboration
between its clinicians
Copyright © BRL 2013
5
hospital
Doctors and
Patients
Care pathways

6. .
Supporting Multi-sidedness
Copyright © BRL 2013
6
The hospital has to
understand the variety of
clinical collaborations needed
in responding to the variety of
conditions they are meeting
• Capturing indirect value at demand tempo
– The supplier has to consider their relationship to indirect
forms of demand, and the organizational processes by
which their own products and services can be aligned with
those of others to support multi-sided demands.
It becomes critical to analyze
the cost to the patient of their
condition over its life, and
what are its drivers
• Defining the economics at the level of the ecosystem
– The value lies in reducing the costs that fall ultimately on
the indirect customer of aligning suppliers’ products and
services to multi-sided demands.
The agility of the platform is
defined by the variety of care
pathways that it can support
• Developing the platform architecture capable of
capturing indirect value
– The architecture has to be ‘agile’ in the sense that it can
support a sufficient variety of forms of multi-sided demand.

7. .
‘QUANTUM’ ORGANISATION
Responding to customers one-by-one
‘Classical’ versus ‘Quantum’ Organization
Platforms supporting multi-sidedness
Copyright © BRL 2013
7

8. .
Responding to customers one-by-one:
each collaboration defines a ‘quantum’ state
• The actors participating in a particular collaboration define the way they
want their collaboration to be supported by the platform.
• The form of the collaboration will be determined by the way the actors
understand the multi-sided demand.
• The actors in a collaboration can be spread across multiple organizations
within an ecosystem.
Source: Fig 2-1 on the Management Challenge: Systems Engineering
Guide for Systems of Systems, OSD, Version 1.0 August 2008.
A collaboration between actors
Supporting system-of-system platforms
Simultaneous
care pathways
Support
Superposition of
many collaborations
aka ‘quantum’ states
The hospital has to be able to manage
many different things at the same time
Copyright © BRL 2013
8

9. .
‘Classical’ organization:
design-time conversations separated from run-time conversations
Markets
Operations
Establishing a one-
sided relationship
to Demand
(the value defined
a priori)
Planned
behaviors
(constrained by
architecture)
Accountability
Hierarchies
(defining quality
attributes)
Management
Design-timeRun-time
Hierarchical
Governance
Opportunity to
capture value
‘We know how to
treat necrosis’
Copyright © BRL 2013
9

10. .
‘Quantum’ organisation:
supporting concurrent collaborations
Cohesion of the
response to multi-
sided Demands
(the experience of the
value provided)
Modularity of
behaviors
(constrained by
technical
architecture)
Accountability
Hierarchies
(defining quality
attributes)
Demand-in-its-context
(describes the variety of indirect
demands)
Operations
(the multi-sidedness
which the supporting
platforms are capable of
supporting at a given
tempo)
Management
(organizes the
alignment processes)
It is all going on
at run-time for
demands being
responded to
one-by-one
‘We enable our patients to
manage their diabetes’
Support
Simultaneous
care pathways
Each collaboration has to be
able to collapse out a
different care pathway
Copyright © BRL 2013
10

11. .
Agile platforms supporting multi-sidedness:
the system-of-systems platform has to be able to support superposition
Cohesion of the
response to multi-
sided Demands
Modularity of
behaviors
Accountability
Hierarchies
Support
Simultaneous
care pathways
Demand-in-its-
context
Operations Management
dynamic
alignments
accountabilities
functional
capabilities
The platform has to
support the superposition
of many collaborations
‘Our hospital has to support
our clinicians learning about
effective care pathways’
Copyright © BRL 2013
11

12. .
Triple Articulation:
the articulation of three kinds of ontology
How can care pathways be
aligned to the different
contexts-of-use?
How do these supply-side
constraints over-determine
behaviours?
What will the
cohesion costs* be?
* Cohesion cost =
costs of use of particular components +
costs of alignment to situation.
Accountabilities
Functional
Capabilities
aligned
behaviours
Constraints on
non-functional
characteristics
Constraints on
functional modularity
& coupling
What are the available treatments
and how do they interact?
Who is accountable for cost/quality
trade-offs and securing funding?
Demand-side
Constraints on
cohesionDynamic
Alignments
What variety of care pathways can
be aligned to patients’ conditions?
Copyright © BRL 2013
12

13. .
CONCLUSIONS
Learning-to-date
Implications
Copyright © BRL 2013
13

14. .
Learning-to-date:
focusing on indirect value
Project Direct
Customers
Multi-sided
platform
Indirect
Customers
Potential
Indirect Value
Quantifying
Indirect
Value
MoD surface
capability
MoD
acquisition
C4ISTAR
platform
Mission
Commanders
40% saving on operational
costs, 15% from reduced
variation in costs
Swiss e-
Government*
Federal
Chancellery
Search engine
platform
Respondents to
citizens
80% saving, 50% from
reduced variation in costs
Uninhabited
Aerial Systems*
Royal
Artillery
UAS
platform
Mission
Commanders
40% saving, 30% from
reduced variation in costs
Copyright © BRL 2013
14
Identifying
Risks
BT customer
service
Area
management
Customer
services platform
Phone
user
70% of errors from failures to
align properly
Network Enabled
Capability
MoD
acquisition
Collaborative
SoS
Mission
Commanders
Unable to assess impact of
mission thread variability
AWACS
capability*
NATO
acquisition
Mission systems
of systems
Mission
commanders
Architecture restricting
adaptation to new types of
mission
Mitigating
Risks
Wildland
Fire*
Federal
Agencies
Collaboration
support
Fire
fighters
Missing focus on variation in
forms of collaboration
XSEDE
Supercomputing
centers
Research
SoS
Research
collaborations
Missing focus on variation in
forms of collaboration
NHS
Orthotics*
Healthcare
Trusts
Clinician support
platform
Patients
Managing treatment through-
life meant $1 now = $4 saved
* Some details in public domain

15. .
Implications:
doing more with the same resources
• Responding to multi-sided demands at demand tempo means developing
agile architectures able to support the dynamic alignment of many value
propositions to many different local environments:
• Supporting customers one-by-one
– Shifting the focus to managing cohesion cost in ‘run-time’ across the variety of
indirect demands leads to 30-50% reductions in operating costs
• Identifying hazards and quantifying risks
– Identifying hazards (errors of execution, planning & intent) and quantifying risks
(probabilities and value) guide the continual adaptation of platform architectures
• Managing entangled conversations
– The different organisation needed to support many simultaneous care pathways
challenges Leadership to develop horizontal forms of governance
Copyright © BRL 2013
15

16. .
THANK YOU
Contact details:
Philip J. Boxer BSc MBA PhD
+1 908 458 6588
Philip.Boxer@brl.com
http://www.linkedin.com/in/philboxer
Copyright © BRL 2013
16