Defence 4.0 and Enabling Capabilities in an Ecosystem

Share this post:

Previous IBM defence blogs we have talked about the paradigm shift to Defence 4.0 which impacts a range of business and technical dimensions.

A particular challenge in this transformation, for both industry and defence, is to clearly articulate and operationalise a ‘digital ecosystem’ which is underpinned by collaboration.

The benefit of an ecosystem is that it delivers creative and rapid innovation, bringing together diverse and entrepreneurial business entities from the public sector, industry and academia. It aims to combine a range of capabilities from different organisations to yield synergies that derive a critical mass of differentiated capability and product value. This synergistic innovation might be the blending of data management, analytical tooling plus engineering to deliver predictive maintenance for example. But, ecosystems do add greater complexity in almost every dimension; the opportunity now is to utilise open digital solutions, with standards, make the transformation viable.

Blending ecosystem capabilities and the Component Business Model

IBM would typically look at capabilities in terms of a Component Business Model (CBM) to understand an enterprise (e.g. a company) or an extended virtual enterprise, in the form of a digital ecosystem. The CBM presents the set of capabilities that deliver the end-to-end horizontal value chain. The CBM also shows three levels of organisation roles:

• Direct = Strategic,
• Control = Management and coordination, plus
• Execute = Doing things (operations).

‘The Building Block Thesis’(1) presents an interesting way of viewing capability that can be aligned to the CBM. It postulates that solutions are developed and consumed in bundles of value. Thus, the ecosystem needs the offer the right dynamic mix of components to make bundles of value.

‘The Building Block Thesis’ also differentiates between ‘solutions’ and ‘complements’. A ‘solution’ might be the Apple platform, whilst Apple Music is a ‘complement’ that adds customer value to the core ‘solution’. In the world of defence one can see how a core solution linking sensors and assets can enable complements to be delivered e.g. analytics to understand the status of assets. The differentiation between a solution and complements is important because it aids strategic thinking in developing solutions that enable more readily deliverable complements; so being a catalyst for innovation.

Figure 1 illustrates a basic defence CBM with conceptual illustrations of solutions and complements. It also shows the different horizontal layers of Strategy, Control and Execution that informs the components of capability in white.

Figure 1 IBM’s Component Business Model – a illustration of Defence 4.0 capability

When using a CBM, the components can be assessed in whatever level of detail needed. For example, inputs, outputs, controls, KPIs, technology, data and resources. Gaps in capability can be identified, especially when reviewed in the light of business processes.

‘The Building Block Thesis’ talks about commoditisation of capabilities that can then be iterated by others in a loosely connected ecosystem. Commoditisation, on an open platform allows solutions and complements to be designed and built to enable interoperability and repurposing (e.g. leveraging APIs and common data models).

In the commercial world a company like Apple can perform the role of a ‘market aggregator’ where their solution supports innovative apps (complements) from partners. This model can also be applied in Defence, where the aggregator could be the defence organisation or a lead ecosystem partner. A complement might be analytical model provided by a specialist member of the ecosystem.

In the commercial world innovation is entrepreneurial and focused on profit. In defence, the innovation needs to be more controlled and targeted to address particular strategic needs. Here, a Design Authority has a role to play in shaping innovation in line with a strategy and orchestrating the delivery and realisation of value in a managed and coordinated way. However, there is also an opportunity to encourage and incentivise the ecosystem to develop novel ideas through targeted domain competitions for example.

Gupta references the following interesting case study of ecosystem innovation. In 2013, National Aeronautics and Space Administration’s (NASA) scientists were struggling to resolve a technical problem regarding the International Space Station and positioning it relative to the sun to maximise the power generation of solar panels. A competition was run jointly with Harvard University which yielded 2,185 solution options in only a few months, almost half of which, were better than the NASA solution (2). The Design Authority probably has a role in a competition like this to facilitate, or perhaps broker, an optimum bundle of two or more components.

Figure 2 below brings some of this thinking together. It shows how different capabilities, from different organisations combine to produce solutions and complements. It also shows the proposed role of a Design Authority in linking business strategy, design and the coordinated execution of value plus progress/project management.

Figure 2 How capability, reflected in the CBM, might be delivered

The reality of delivering capabilities across an ecosystem platform

In an ideal world, a greenfield single collaborative engineering platform would be created. However, in practice this is likely to be a brown field environment with a mix of legacy applications and diverse data sets offered by the ecosystem. The ecosystem platform would be enabled by shared data, fed from the legacy, plus a common DevSecOps capability, supported by an integrated automated workflow to trigger coordinated actions. This capability supports the end to end value chain from engineering concept, to build, MRO and operate; the latter embracing MDI; all enabled by the digital thread.

Key to making this work is the sharing of information within the platform, taking account of national security and IPR. Conceptually, it would seem that blockchain may have a role here, with trust and permissions managed as part of a digital workflow. IBM has pioneered this technology in trading platforms which might be relevant.

The Design Authority would establish principles like interoperability and standardisation, but they would also, importantly, drive an approach to value chain excellence which would embrace digital twin and designing to meet sustainability needs from the start. The Design Authority needs to consider scalability too; so that innovation delivers against enterprise needs. However, the role of the Design Authority needs to be suitably light and facilitative with ability to reward the right behaviours and outcomes; heavy bureaucracy will not work.

Concluding thoughts

An ecosystem is at the core of the paradigm shift in Defence 4.0. The ecosystem enables innovation by delivering elements of capability that can be combined to add value to develop differentiated products quickly.

Rather than a free market model, there is a role for a Design Authority to set the strategy and design principles and to facilitate and encourage collaboration, and the combining of components, on a platform.

References

1. ‘The Building Block Thesis’ – Sangeet Paul Choudary and Shankar Maruwada (2022)
2. ‘Driving Digital Strategy’ – Sunil Gupta (2018)
3. Component Business Models Making Specialization Real – IBM Institute of Business Value (2020) https://www.ibm.com/downloads/cas/8RB5RWVE