Introduction

The topic of the need for a Sovereign Data Layer (SDL) has received much attention since the release of the Data Strategy for Defence[1]. However, ambiguity still exists around the nature and scope of an SDL, its priority in the mix of competing modernisation requirements.

Current situation

Despite a rising volume of information of data from sensors and data feeds, Defence finds it harder than ever to isolate the insight to achieve decisive advantage. Data is inaccessible in internal or contractual silos that often overlap in scope. There is no standardised approach to exploitation and data delivery, approaches to governance and controls are disjointed and inconsistent, and there is a lack of accountability for data[1]. This results in excessive costs to maintain data platforms with unacceptable levels of return on investments.

What is a Sovereign Data Layer?

Firstly, it is important to understand the context of the term ‘sovereign’. There is a view among some quarters that it relates to maintaining Defence data within UK data centres and not allowing its egress to other jurisdictions. Whilst this describes one element of a sovereign data layer, it does not encompass the entirety of the definition. For a data layer to be sovereign it must ensure that all data storage, processing, transmission and exploitation occur within MOD-controlled environments, and that Defence maintains control of its data and control of intellectual property. It should always achieve this without recourse to third-party or commercial providers, and without cost barriers to its exploitation. If data is Defence’s second most important asset[1], it must retain unrestricted access to it to meet its dynamic and changing needs without constraint.

Secondly, it is necessary to explain the scope of a ‘data layer’. A data layer is a unifying architecture within an organisation designed to manage, store and facilitate access to data across different exploitation systems and applications. It serves as a foundational layer that aggregates data from multiple sources, ensuring that data is accessible, consistent, secure and governed according to organisational standards. The data layer separates data storage and management functions from the exploitation applications that use the data, enabling a clear structure where data can be handled independently of specific software or systems. The demarcation between the data layer and exploitation applications/systems is critical for understanding. Exploitation should be considered within a separate data exploitation or analytics layer built on top of the data layer. It should be designed specifically to make use of the data stored in the SDL. Its purpose is to transform, analyse, interpret and present data to support decision-making, insights and operational use. This layer enables users to exploit data. The application layer is typically implemented using transient systems that meet the immediate needs of the organisation, but that can be replaced or augmented without expensive data migration costs when the application is retired. By its nature, the application layer exploits the data, it does not own it. This is an important distinction, as the siloing of data within applications is at the heart of the Defence’s inability to maximise its investment in its information.

Characteristics of a Sovereign Data Layer

The SDL is a logical, horizontal slice through an enterprise architecture that encapsulates all the services required to govern and manage the data assets available to an organisation. It is shaped by an overall data architecture and model that defines how the data will be curated across its lifecycle. This allows for multiple data platforms to cooperate in a consistent way to deliver the solution. Consequently, an SDL may comprise more than one data platform. What is important, however, is that the various platforms that contribute to the SDL do so in a common manner, adhering to common controls for governance, security, use of metadata etc.

Each platform within the SDL will provide consistent mechanisms to coordinate the storage of data (sometimes referred to as ‘persistence’), manage the data through its lifecycle, and expose the data to the exploitation application layer through a set of Application Program Interfaces (APIs). We will explore each of these in turn to elaborate on their role and responsibilities:

Data storage: Provides a unified repository for storing data and metadata in a coherent manner. It enables efficient management of large volumes of structured and unstructured data across relational databases, graph stores, vector stores etc., that is optimised for the organisation’s needs and not constrained by proprietary data models.

Data management services: There are a number of services that each platform within an SDL must consistently provide to remain coherent. These include:

· Data ingestion, cleaning, de-duplication, integration and aggregation services that manage the flow of data into the platform and brings it together in a single, accurate, reliable and accessible format

· Automated enforcement of data governance policies, including access control, data lineage and compliance standards, ensuring that only

authorised users and applications can access specific data, while tracking usage and maintaining compliance with data regulations

· Management of the data through its lifecycle (creation, use, archival and deletion), including policies for data retention and disposal

· Audit and monitoring systems for all data transactions, with access logging and alerts provided to security operations centres for unusual activity

· Coordination across technology infrastructure components to prevent loss or downtime

Data access APIs: The data layer exposes data to applications and users through standardised access methods using APIs. By separating data from applications, it enables interoperability, making it easier for different exploitation application and systems and tools to retrieve, update, or analyse data consistently, enabling a secure, unified platform for authorised personnel to access and share data across departments and formations.

Characteristics of the Exploitation Application Layer

With an SDL defined in the section above, it is necessary to differentiate what sits within an Exploitation Application Layer (EAL) comprising applications and systems. This is important because Defence’s approach to data exploitation to date has focused on the acquisition and use of solutions that manage data, and its exploitation within the boundaries of discrete applications. The discussion is of greater importance when the use of the term ‘sovereign’ has been argued to historically procure applications that silo data and exploitation together, as long as the data and services remain within the UK’s geographic boundaries.

If the SDL serves as the foundational repository and management system for an organisation’s data, the EAL’s purpose is to offer tools and interfaces (e.g., dashboards, analytics platforms, reporting tools) that enable users to explore data, run analyses and interpret insights. It underpins advanced analytics, machine learning and AI capabilities to derive insights from the data, enabling real-time and on-demand reporting, intelligence analysis and decision-support systems to make data-driven decisions.

Importantly, applications within the EAL should be considered as replaceable or disposable. As new analytics capabilities emerge into the market, they should be pluggable into the SDL to provide insights, then retired as newer capabilities supersede their contribution.

Characteristics of a Sovereign Data Strategy

Proprietary products often create dependencies on a single vendor’s technology, making it difficult and costly to migrate or modify systems in the future. A Sovereign

Data Strategy should avoid proprietary products to ensure that an organisation retains flexibility and control over its data ecosystem.

Similarly, proprietary systems may limit access or impose restrictions that conflict with an organisation’s data sovereignty goals. As a consequence, open-source or standards-based solutions should be mandated to allow the organisation to maintain full control over its data and systems, ensuring compliance with sovereignty requirements.

Recognising that proprietary products often come with licensing fees, maintenance costs and potential increases over time, a Sovereign Data Strategy should adopt open and standardised solutions to reduce licensing costs, increase fiscal predictability and offer greater flexibility to adapt as data needs evolve.

To ensure long-term interoperability and futureproofing, a Sovereign Data Strategy should mandate open standards to facilitate integration with diverse technologies, avoiding format incompatibilities and simplifying integration with new tools or applications.

Risks to a Sovereign Data Strategy

Even with non-proprietary solutions, relying heavily on industry partners can lead to implicit vendor lock-in, particularly if the data layer is customised by a specific vendor. This dependence can limit flexibility and increase long-term costs if switching vendors becomes necessary. Defence’s governance of any SDL is of paramount importance if its full potential is to be realised. Maintaining alignment on objectives, data security and financial control is critical, as are the requirements for robust contracts, SLAs and regular oversight.

While the overall Total Cost of Ownership (TCO) of an SDL is financially attractive, it may involve higher upfront costs for consultation, setup and integration. Fiscal controls and clear Return on Investment (RoI) structures are key to sound governance and outcomes management in this area.

Balancing industry engagement with sovereignty goals

Whilst the concerns around proprietary lock-in are valid, there are clear advantages to leveraging the experience of industry to conceive and deliver an SDL. To mitigate the proprietary risks while benefiting from industry expertise, Defence should:

· Prioritise open standards and open-source solutions to ensure compatibility and minimise proprietary dependencies

· Negotiate clear contracts with strong SLAs and ownership clauses that prioritise data control, security and long-term flexibility

· Incorporate flexibility into the design to allow the Defence to switch vendors or adjust the SDL or EAL without significant disruption

Summary

In essence, the SDL is the foundational infrastructure for storing, managing and sharing data, ensuring it is secure, consistent and accessible across an organisation. The EAL, on the other hand, sits above the SDL and is dedicated to using that data for analysis, insights and decision-making. It provides the tools and applications that allow users to interact with, and derive value from, the data managed by the data layer. Together, these layers create a structured data ecosystem where data is stored and managed independently of the applications that exploit it, allowing for better scalability, control and data governance.

Proprietary products often create dependencies on a single vendor’s technology, making it difficult and costly to migrate or modify systems in the future. An SDL, by avoiding proprietary products, retains flexibility and control over its data infrastructure.

Proprietary systems may limit access or impose restrictions that conflict with Defence’s data sovereignty goals. Open-source or standards-based solutions will allow Defence to maintain full control over its data and systems, ensuring compliance with sovereignty requirements.

Proprietary products often come with licensing fees, maintenance costs and potential increases over time. Open and standardised solutions reduce licensing costs, increase predictability and offer greater flexibility to adapt as data needs evolve.

Open standards facilitate integration with diverse technologies, avoiding format incompatibilities and simplifying integration with new tools or applications. This interoperability helps future-proof the data layer by ensuring it can evolve without being restricted by proprietary standards.

Conclusions

The utility of data exploitation to support accelerated and accurate decision-making and intelligence analysis is not in question. It is an established fact that the contemporary operating environment is shaped by information advantage and the tempo of the sensor-decider-effector chain. What is in question is how Defence achieves this advantage in a cost-effective manner that it can financially sustain in the long-term.

Proprietary solutions provide short-term outcomes by building information silos that address discrete problems. In the long-term, however, they exacerbate the strategic issues described in the Data Strategy for Defence[1] and increase fiscal liabilities.

If Defence coheres around a common vision and delivery strategy for an SDL, it can achieve cost savings and a reduced TCO whilst significantly accelerating its digital transformation and modernisation. Its flexibility will allow Defence to integrate new technologies at increased tempo without disrupting core infrastructure, maximising the value of its data, enabling innovation, increasing operational efficiency and achieving tangible decision advantage.

---

[1] Data Strategy for Defence, MOD, 27 September 2021