Competing within Ecosystems: determining requisite agility in system-of-system architectures

.

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

.

The demand for agility from accelerating alignment tempos

Supplier 1

Supplier 2

sub-contract

sub-contract

The Provider

users

orchestration

synchronization

users

customers Suppliers 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


.

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!


.

A CLOSER LOOK AT THE PROBLEM

Multi-sided Demand

Supporting Multi-sidedness


.

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’ relationship Ecosystem

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


hospital

Doctors and Patients

Care pathways

.

Supporting Multi-sidedness


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.

.

‘QUANTUM’ ORGANISATION

Responding to customers one-by-one

‘Classical’ versus ‘Quantum’ Organization

Platforms supporting multi-sidedness


.

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


.

‘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-time Run-time

Hierarchical Governance

Opportunity to capture value

‘We know how to treat necrosis’


.

‘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)


(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


Each collaboration has to be

able to collapse out a

different care pathway


.

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


Support


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’


.

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

cohesion Dynamic Alignments

What variety of care pathways can be aligned to patients’ conditions?


.

CONCLUSIONS

Learning-to-date

Implications


.

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


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

.

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


.

THANK YOU

Contact details: Philip J. Boxer BSc MBA PhD

+1 908 458 6588 [email protected]

http://www.linkedin.com/in/philboxer


mailto:[email protected]

http://www.linkedin.com/in/philboxer

Business

Competing within Ecosystems: determining requisite agility in system-of-system architectures