Enabling Open Architecture in Military Systems: A Systemic and Holistic Analysis

Abstract

Military systems, with their extended lifecycles, face challenges such as managing obsolescence, adapting to evolving operational needs, and ensuring interoperability in System of Systems contexts. Open Architectures (OAs) have been pursued to address these issues by adopting widely recognized interface standards instead of proprietary solutions, enabling more flexible and cost-effective system modifications. However, establishing effective OA environments—encompassing technical, commercial, and organisational dimensions—remains complex, with much of the existing knowledge restricted to the practices of a few governments. This paper presents a comprehensive analysis of OA in military systems, employing systems thinking tools to examine this multifaceted concept. It integrates perspectives from government and industry, addressing the ‘what’, ‘why’, and ‘how’ of OA, and introduces a framework for identifying enabling actions. Key findings highlight that OA success depends on defining ‘open for whom’, ‘to what level of detail’, and ‘in which parts of the system’. Moreover, achieving an effective OA environment requires strategic investment, the active engagement of a Community of Practice, and maturity in the technical and legal domains. This study provides decision-makers at early stages of adoption with the necessary strategic understanding to support the customisation of OA transformation plans to suit unique contexts.

1. Introduction

Open Architecture (OA) is an approach that, despite lacking a universally harmonised definition, has been widely adopted across various domains. Its origins trace back over four decades to the fields of information technology, computer architectures [1], and commercial aerospace applications [2]. As technology progressed and systems became more interconnected and complex, this approach extended to additional sectors, sparking renewed interest in OA over time. This is particularly evident in the defence sector, where numerous OA standards and policies persist in mandating its adoption within procurement processes as demonstrated in [3].

OA aligns with current trends like Digital Engineering and Digital Transformations [4], which highlight the integration of digital technologies in organisations and the significance of ‘authoritative sources of truth’ to enhance artefact communication. The role of OA in this context is to facilitate rapid and cost-effective technology upgrades throughout a system’s lifecycle by employing standardised interfaces rather than proprietary solutions, thereby expanding the supplier pool and enhancing competition for any given system [5].

A substantial body of literature highlights the anticipated benefits of OA, including but not limited to the following [6,7,8,9]:

• From the operational perspective, OAs allow for flexibility, adaptability, faster time-to-field, capability upgrade, and even reduction in the physical and cognitive burden by avoiding equipment redundancy. These characteristics are paramount in the current rapidly evolving warfare. In the context of System of Systems, interoperability stands as one of the most compelling motivations for adopting the approach.
• The technical benefits include facilitated obsolescence management, faster technology insertion and upgrade throughout the lifecycle, module reuse/commonality, and easier data collection for future automation using AI and ML applications.
• The commercial motivations focus on enabling more competition. This implies lifecycle cost reduction and innovation, as adopting an OA approach can avoid a state of lock-in to specific suppliers, thereby enabling customers to seek products from competitors in the market (e.g., for upgrade) more widely. From the supplier’s perspective, it allows for greater collaboration by identifying more commercial partners to combine capabilities.

Although the potential benefits of this approach are promising, its implementation faces technical, commercial and enterprise barriers [10,11,12,13], such as the following:

• Technically, developing and agreeing on standards is often slow, especially when no existing material can accelerate consensus. The same applies to emerging technologies, which require time to mature before standardisation. Additionally, a highly specific architecture may limit innovation, while one that is too generic may fail to address key openness issues. Balancing openness with performance, security, and safety remains another significant challenge.
• Enterprise challenges include shifting customer priorities due to leadership changes, supplier resistance, evolving industry landscapes, and governance difficulties—issues more pronounced in defence due to its smaller market size compared to commercial sectors.

Moreover, existing research and practices are largely limited to a few nations, such as the USA, the UK, and some NATO members, while other governments seek guidance for initiating or sustaining OA adoption. In addition, the lack of a widely accepted definition and the inconsistent application of OA further complicate these efforts.

These challenges underscore the need for a holistic and systemic examination of OA within the defence sector, leading to the following research questions: What constitutes the OA approach in the military domain, and what are the main factors that enable a move towards the approach?

In this paper, we address these questions by presenting a comprehensive analysis of the OA approach in military systems. Here, military systems refer to any system with military applications, independent of its domain or specific use case. Our focus is on analysing the approach itself, rather than its specific application or mission scenarios. Hence, our contributions are as follows:

• A conceptual representation of OA, presented as a systemigram [14], encompassing technical, commercial, and organisational dimensions, providing actionable insights for governments and industry stakeholders.
• Benefits chain diagrams illustrating how OA contributes to an organisation’s end values, supported by explanatory conditions, designed to foster decision-makers’ buy-in.
• A ‘Triangle of Adoption Conditions’ model identifying key adoption factors for OA—investment, engagement of the Community of Practice, and maturity in technical, legal, and management areas specifically addressing OA—required to evolve over time;
• And a comprehensive framework outlining enabling activities to support these conditions, categorized into personnel, training and education, support, contracting and management, organisation, policies and strategies, and artefacts and practices.

These findings not only provide clarity on the ‘what’, ‘why’, and ‘how’ of OA but also offer a framework to navigate key challenges in its adoption. By addressing gaps in both the academic literature and practice, this paper aims to equip decision-makers with the tools to harness the transformative potential of OA.

This study distinguishes itself from prior research by adopting an holistic systems thinking approach to OA in military systems. While the existing literature predominantly focusses on individual technical or commercial aspects of OA—often within the context of major defence acquisition programmes in leading nations—this paper broadens the scope to include underexplored dimensions such as organisational enablers, cultural challenges, and early-stage adoption strategies. Furthermore, the emphasis on integrating diverse perspectives from governments and industry ensures a well-rounded and actionable analysis.

The remainder of this paper is structured as follows: the Section 2 situates the study within the existing OA research, identifying key gaps and contextualising our approach. The Section 3 outlines the systems thinking tools employed in our analysis. The core findings are presented in the Section 4, where we examine the technical, organisational, and commercial dimensions of OA. Finally, the conclusion synthesises the study’s key insights and proposes directions for future research.

2. Literature Review

This introductory review aims to examine the existing work on the ‘what’, ‘why’, and ‘how’ of the OA approach to provide context for this study. Additional literature will be explored in greater depth as part of the analysis.

A Scopus search for ‘Open Architecture’ and ‘military’ highlights a sustained interest in OA for defence systems. Although some references date back decades, their insights remain relevant, as OA advancements take time to mature. For example, Oberndorf and Sledge [15] noted in 2010 that ‘what is old is new again’, and despite the passage of time, this perspective remains valid as demonstrated by the recent Memorandum mandating the Modular Open Systems Approach (MOSA) in USA defence acquisitions [16]. This is why the timespan in this review was not limited to recent sources.

Although the application of OA standards is observed in the USA, UK, and within the NATO [3,17], the literature remains predominantly focused on the USA, largely driven by efforts related to MOSA. This work utilises these references while striving to expand the concept of OA beyond MOSA-specific implementations. Notably, there is a perception among some international stakeholders that MOSA is exclusively a USA initiative, which may discourage broader engagement.

2.1. Lack of Generally Accepted Definition of OA—What

Different forms to express the concept of OA exist in the literature, including Open System Architecture [18], Open Systems [19], and Interoperable Open Architecture [20]. Additionally, no commonly accepted definition was found within international body standards such as ISO/IEC/IEEE standards. Most of these definitions were elaborated within specific contexts, such as government approaches or working groups. Some focus on the characteristics, while others on the purpose and group of interest.

For example, as described in [10], the Defense Acquisition Glossary defines OA as ‘A technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure’ [21], while a work aimed at identifying forms of assessment of OA within UK defence procurement states that ‘An Open (Systems) Architecture applies to a system in which the architecture is published in sufficient detail to enable change and subsequent evolution through the introduction or replacement of modules and/or components from any supplier’ [22].

Furthermore, while the term OA emphasises openness, references [23,24,25] highlight the importance of incorporating other attributes, such as modularity, reusability, portability, and scalability, to fully realise its intended benefits.

Little research has been conducted on the extent to which these definitions and principles can be converged. This work addresses this gap by synthesising their common aspects in Section 4.1.

2.2. Difficulty in Proving the Value of OA—Why

The sustained use of OA in the military suggests that governments and industry remain committed to its development. However, some stakeholders may still question whether the benefits justify the investments, as quantifying returns remains a challenge. Comparisons between OA and non-OA programmes require similar scopes and occur at the same time to reduce external variables, and long-term observation. Additionally, the disclosure of some details that are often classified or commercially sensitive, such as cost breakdown, can also be problematic [26]. Some estimation tools, such as the SEI Cost-Estimation Toolset for OA in software cost estimation [27], are mentioned in the literature but there is no evidence regarding the extent of their practical application. Additionally, a 2014 European Defence Agency study estimated that implementing OA could reduce lifecycle costs for land vehicles by 10% to 25% [28], although the methods used to derive these estimates were not fully detailed. Chen and Lucyshyn [29] concluded that the economic benefits of OA depend on the technological refresh strategy applied to the system—shorter cycles result in greater cost savings, whereas longer cycles may diminish or even negate long-term economic advantages.

Existing assessment tools often focus on implementing OA practices across the system lifecycle [30,31] or guiding decisions on which interfaces should adopt openness [32]. However, they frequently fall short of evaluating whether broader strategic objectives are being achieved. Some studies, such as [33], have proposed methods to trace these strategic objectives throughout the architecture process. The Memorandum for Service Acquisition Executives and Programme Executive Officers [16] has renewed attention to this issue by requiring mechanisms to verify MOSA compliance within its guidelines; therefore, further advancements in this area are likely to emerge in the coming years.

While these analytical tools continue to mature, this paper expands the discussion on the ‘why’ in Section 4.2 relying on logical inference, by analysing the key contributions of OA and linking them to broader strategic objectives within a benefits chain. It aligns expectations by addressing preliminary conditions and challenges.

2.3. Discussions on Recommendations and Challenges—How

There have been many studies within the USA regarding the implementation of the MOSA approach. For instance, the National Defense Industrial Association (NDIA) has published whitepapers addressing the challenges faced by suppliers and acquirers, elaborating on recommendations including investments in cultural change and the creation of a library of systems and interfaces [4]. Similarly, Sanders [34] analysed MOSA as a business model, identifying key challenges such as ‘communicating commitment, MOSA-enabled IP and data rights, and choosing interfaces and standards’.

Outside the USA, the Australian Defence Force (ADF) has conducted studies addressing the challenges and opportunities of OAs within their context. Key challenges include the development of indigenous capabilities to support OA, emphasising the need for strong leadership and skilled personnel to drive its adoption [35].

In the UK, studies have similarly explored OA in the context of defence procurement. Notably, a comprehensive report by a working group involving industry, government, and academia examined OAs within UK Defence Procurement [22]. The report highlighted, among many other issues, the importance of appropriate standards in artefacts and practical OA assessment tools for ‘decision support staff’. It also emphasised that ‘OS/OSA should be tailored specifically to the system(s) under consideration’, advocating for generic principles and approaches rather than a ‘one-size-fits-all’ OA solution.

Sanders and Holderness [36] proposed a framework for evaluating the Department of Defense’s (DoD) readiness to support MOSA adoption. Their framework focusses on communication and commitment, enabling environments, and business models, while highlighting the challenges faced by the government in creating an effective OA environment. Similarly, LinuxIT [37] advertised a framework tailored to the UK industry, aimed at ‘investigate the feasibility and impact of moving towards more OA’ across strategy, architectures, systems management, and services management.

These multiple insights from the literature are leveraged in this study within the identification of the key adoption conditions and enabling actions in Section 4.4 and Section 4.5.

3. Methodology

The OA approach is inherently complex, involving not only technical but also organisational, contractual, cultural, and commercial factors that influence architectural decisions. Furthermore, achieving an effective implementation of OA requires balancing the diverse perspectives of multiple stakeholders, within industry and government, on these aspects. To address these challenges, this research adopts Systems Thinking to gain an holistic understanding of the OA approach, and uses a soft systems perspective to capture the pluralistic views of stakeholders.

The investigation is structured into three phases: data collection, thematic mapping, and analysis using a combination of systems thinking tools. Although this article focusses mainly on the analysis, as detailed in Section 4, this section briefly outlines the methods across all phases, the first two forming the basis of the analysis.

3.1. Data Collection

The data collection aims to explore stakeholder understanding of OA, its benefits, motivations, enablers, implementation challenges, applications, and recommendations for adopting the OA approach.

The investigation examines OA usage over time across various domains (land, air, maritime, and commercial), applications, and countries or groups of nations (e.g., the USA, the UK, NATO, and Australia), from different perspectives (government and suppliers). It relies on a combination of secondary (literature) and primary (interviews) sources. This combination is effective for triangulation, addressing gaps, and mitigating the potential biases inherent in each data source. For instance, the literature has a predominance of documents reflecting on the usage of the OA in the USA, whereas the interviews allow the exploration of the UK and NATO views.

3.1.1. Literature

The search employs publicly available information, including ‘grey literature’ and academic databases. The grey literature comprises documents from defence agencies (standards, requirements, acquisition policies, and guidance provided in webpages), standardisation bodies, supplier whitepapers, research laboratories, and defence magazine articles. The academic search yields conference and journal papers, primarily defence-orientated or related to systems engineering). Keywords include ‘Open Architecture’ and variations incorporating terms such as ‘systems’ and ‘approach’, centring on ‘military’, ‘defence’, or ‘defense’. Additionally, specific OA standards also help to refine the search. The most relevant information is sourced from the grey literature.

3.1.2. Interviews

Semi-structured interviews are conducted, following ethical procedures [38], with nineteen individuals possessing substantial expertise in OA, spanning various domains and viewpoints (see

Table 1. Number of interviewees per profile.

Domains
Land	Air	Maritime	Multi-domain	Commercial	Worked in more than one domain
6	2	2	3	3	3
Sector
Industry		Government		Academia/Consultancy
9		6		4
Nation/ Group of Nations
UK		NATO		Worked for more than one country
10		1		8
Role
Technical		Management		Both
9		3		7

). The information gathered from these individuals is important to address gaps in the open-source literature, as most studies and processes adopted by governments for OA implementation are likely unpublished. Furthermore, interviews serve as an effective means to explore the individuals’ experiences and beliefs, which are important for capturing diverse perspectives.

3.2. Thematic Mapping

This phase consists of organising and categorising the data from the interviews and the literature in the form of themes and codes using thematic analysis. This method is recommended for cases where the research strategy seeks particular themes [39] and where investigators need to capture ‘people’s views, opinions, knowledge, experiences, or values from a set of qualitative data’ [40], which is the case of this study.

The themes are predefined based on the questions that guide the data collection but are modified and sub-categorised during the process. The resulting themes are illustrated in Figure 1, with the subthemes and their corresponding codes detailed in [41]. The question of the context of OA, in particular, is organised and structured as a map of OA standards as reported in [3,17].

This step facilitates the articulation of the identified aspects associated with the OA approach and enables the derivation of significant insights for the data analysis.

3.3. Model-Assisted Analysis

This step consists of drawing conclusions and fostering discussions on the what, why, and how of the OA approach. The main themes utilised from the previous step are detailed in Figure 2. The aim is to further examine the connections among the aspects identified in the previous step utilising a range of modelling and system thinking tools as illustrated in Figure 3 and discussed bellow.

The use of multiple tools is supported by [42,43], which highlight that there are a variety of systems thinking tools serving different purposes, and that ‘Combining methods may help tackle complex problems that would be difficult to address with a single tool’ [43]. This perspective is further reinforced by Checkland [44], who notes that while models do not represent reality in its entirety, they serve as valuable tools to help practitioners to structure their thinking about complex systems. Hence, in this investigation, models are not expected to serve as ‘authoritative sources of truth’. Instead, they are regarded as assets for facilitating discussion of the concepts and actions towards the OA approach.

The models undergo meticulous refinement, incorporating feedback from multiple revisions conducted within the investigation’s supervision team. Collectively, they address both conceptual and practical dimensions, offering perspectives that form the contribution of this research to the field.

3.3.1. What

The tool used to express the concept of OA is the systemigram. This type of diagram, which is a portmanteau of the words ‘systemic’ and ‘diagrams’, was created by Boardman and Sauser [45] as an alternative to the Checkland’s CATWOE/root definitions [46] for defining purposeful activities. The systemigram is a widely used tool [47] for communicating complex issues in a comprehensive form such that the problem owners can be advised of this complexity by seeing the ‘big picture’ [14].

In this investigation, the systemigram tool is employed to complement, rather than replace, the CATWOE analysis and root definitions. This approach provides a synthesised overview of the ‘what’ of the system based on the aspects identified in the previous stage and their interrelationships. The root definition serves as the mainstay of the systemigram, forming the central narrative of the diagram, while the CATWOE framework further elaborates on the conflicting perspectives of the main stakeholders involved in, or affected by, the development of the OA environment (the ‘who’). The resulting diagram is discussed in Section 4.1.

3.3.2. Why and Who

A benefits chain is created to illustrate the interrelationships among the various perceived benefits, further expanding the discussion on the ‘why’ while also identifying the conditions necessary to deliver specific values. A similar method was employed by the authors of [48], who used this tool to derive metrics for evaluating Digital Engineering. This approach can help to align stakeholder expectations regarding the conditions to achieve the intended benefits, and how the OA contribute to those. The resulting diagrams are discussed in Section 4.2.

The BATWOVE framework further contextualises these benefits by addressing the question of ‘benefit for whom’—the ‘[B]eneficiaries and [V]ictims’ of the OA approach—while also further describing the stakeholder’s ‘[W]orldviews’. This framework is a variation of the CATWOE analysis [49], replacing the element of [C]lient with [B]eneficiaries and [V]ictims. The mnemonic description is provided in Figure 4. Furthermore, BATWOVE provides insight into the adoption conditions in terms of the transformations needed, shedding light on the ‘how’. This analysis is discussed in Section 4.3.

3.3.3. How

The analysis of the ‘how’ starts by exploring the dynamics of the OA environment. This aims to illustrate how various factors influence OA adoption over time and to identify the key variables involved, thereby offering valuable considerations for distilling these purposeful transformations into targeted activities. The influence diagram is selected as the tool to facilitate this analysis, as it offers the capability of describing why a situation changes over time by distilling it into interrelated factors [50].

This analysis is further enriched by incorporating competing and external forces and their impact on the dynamics of the OA approach. For that, Michael Porter’s Five Forces model [51] and the PESTEL framework [52] are chosen. Porter’s Five Forces, a widely recognised business strategy tool, examines the dynamics shaping industry profitability through five key factors: industry competition, pressure from substitute products, the threat of new entrants, and the bargaining power of both suppliers and buyers [51]. The PESTEL framework, on the other hand, analyses the impact of external influences—political, economic, social, technological, environmental, and legal factors—on organisational strategy [52]. The Five Forces and PESTEL frameworks complement the perspectives presented in BATWOVE’s Environment [E] and Worldviews [W], offering additional insights into industry conditions and their impact on broader strategic dynamics. The resulting diagram and respective analysis of the dynamics of the OA approach are discussed in Section 4.4.

Next, based on the objective of the fourth step of the Soft Systems Methodology— develop activities to support transformations [44]—a conceptual framework for mapping enabling activities towards the OA approach is derived. These activities are primarily informed by the transformations and insights derived from the BATWOVE analysis, the influence diagram, and the collected data. Furthermore, these activities are conceptualised as enablers of capability and categorised according to Defence Lines of Development (DLOD). This approach is chosen because DLOD is a commonly used framework for capability development in military contexts, promoting both understanding and effective implementation. DLOD varies by country but typically includes elements such as personnel, training, organisation, logistics, and infrastructure [53]. Additional perspectives from the USA’s MOSA environment [7] are also incorporated due to the long history and experience of the approach. The resulting framework is discussed in Section 4.5.

4. Analysis and Discussion

This section analyses the what (Section 4.1), why (Section 4.2 and Section 4.3) and how (Section 4.4 and Section 4.5) of the OA approach in military systems employing the diagramming tools described in the previous section.

4.1. Explanation of What an Open Architecture Approach Is

One of the first questions posed by stakeholders is often as follows: What is an OA? Here, this concept is more accurately described as an ‘OA approach’ rather than simply ‘OA’. This is because it has emerged as a more comprehensive approach rather than a literal interpretation of ‘open’ (meaning universally accessible) and ‘architecture’ (fundamental concepts or properties and principles for realisation and evolution [54]). Analysis of OA standards (e.g., GVA [55], PYRAMID [56], and SOSA [57]) shows that, in practice, additional elements—such as design considerations and specifications—are often included as outcomes, extending beyond the scope of traditional architecture. However, certain aspects, such as system behaviour, are addressed less frequently. Additionally, the availability (‘openness’) of these elements is also restricted to a group of interest. Furthermore, the definition of these elements accounts for both technical and commercial considerations.

Hence, rather than providing yet another definition, this subsection seeks to offer a synthesised yet comprehensive explanation of the concept through the use of a systemigram as shown in Figure 5. Such an explanation is important given the limited discourse in the literature on the concept itself, which could lead to misunderstandings about its implementation or create unrealistic expectations regarding its purposes.

4.1.1. Reading the Systemigram

A systemigram is a visual form of grouping narratives that represent a situation of interest [14]. In this systemigram, blue nodes depict the ‘mainstay’, or central narrative, yellow nodes introduce commercial and enterprise considerations, and green nodes represent the technical perspective of the OA. These narratives are described below (the key terms can be found in

Table A1. Key terms used in the systemigram.

Term	Definition
Policies	‘A set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organisation, a government, or a political party’ [106]
Principles	‘Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which [an organisation] sets about fulfilling its mission’ [107]
Reference Architecture	‘General rules and guidelines, intended to be enduring and seldom amended, that inform and serve as drivers for defining the architecture’ [23]
Requirements	‘Conditions or capability that must be met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents’ [108]
Specifications	‘A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behaviour, or other characteristics of a system, component, product, result, or service and, often, the procedures for determining whether these provisions have been satisfied’ [109]
Community of Practice	‘Organized groups of people with a common interest in a specific technical or business domain. They regularly collaborate to share information, improve their skills, and actively work on advancing their knowledge of the domain’ [110]
Integration	‘Process of combining software components, hardware components, or both into an overall system’ [111]
Interoperability	‘Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged; (…)capability to communicate, execute programs, and transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units’ [111]

—Appendix A):

• Mainstay: This central narrative follows the construction of a root definition—‘A system that does P (what) by Q (how) in order to contribute to achieving R (why)’ [46]. This structure allows the readers to understand the OA in the form of concrete outcomes, the means to achieve these outcomes, and end goals/purposes.
  Open Architecture is an approach that [P] defines architectural/design aspects of the system of interest, which can range from principles, policies and guidelines up to reference architectures, requirements, and specifications, by [Q] discussing multifaceted considerations, including the technical details and commercial/enterprise constraints, within a Community of Practice, which can be composed of members from the government, suppliers, research groups, and allies, to achieve [R]: cost-effective modification and integration of modules from multiple suppliers throughout the lifecycle, interoperability and information sharing, and fostering collaboration among the defence ecosystem.
• Commercial and enterprise: The commercial and enterprise considerations balance the competing interests and opportunities of the Community of Practice, such as the government’s goal to reduce vendor lock-in and to obtain more control over the system with the suppliers’, the dominant suppliers’ intent to secure the marketplace and their intellectual property (IP), and the potential suppliers’ desire to have more chances to compete and collaborate. These interests delimit the defined scope of the architecture/design aspects.
• Community of Practice: The Community of Practice is managed by an authority, which is typically a government agency, a consortium, a group of nations, or an independent standards group. This authority defines the participation and access conditions. The conditions for using the community’s outcomes vary from free access to consulting for a fee and/or being subject to export control regulations. The most common access types are open to the public, requiring registration, or restricted to a specific group (e.g., companies or individuals within a nation). The participation conditions include cases that allow consultation only or cases that also allow participation in the change discussions. Furthermore, this Community of Practice is fundamental, as it will maintain, refine, and enhance the OA approach.
• Technical considerations: The technical considerations define and delimit the data and computing-related details that compose the scope of the architectural/design aspects, which usually include subjects such as software, hardware, network, services, and data models. The architectural/design aspects of an OA include modularity, which reveals key interfaces of the system, which means parts that are subject to fast upgrade pace and/or that are relevant to enable further capabilities. These key interfaces must be defined by non-proprietary standards (open) in cases that do not compromise the critical quality attributes of the system, such as security, safety, and the minimum expected performance. These open standards are essential to achieving the intended purposes of the approach.

4.1.2. Discussion About the Systemigram

The primary contribution of this diagram lies in its ability to synthesise various elements related to the concept identified in this research, drawing from both the literature and interviews while also offering additional insights. It achieves this synthesis by preserving the commonly acknowledged aspects of OA practices, such as the following:

• Conceptualising OA as an approach rather than an architecture, given the need to balance multifaceted considerations—technical, commercial, and enterprise—that define the scope of its outcomes.
• Recognising the importance of a Community of Practice, consisting of diverse stakeholders, in developing, refining, and maintaining the approach to ensure its objectives are met throughout its lifecycle.
• Acknowledging the presence of competing interests among stakeholders.
• Emphasising the relationship between openness and modularity, and the adoption of open standards at key interfaces. Although other quality attributes like portability, scalability, commonality, and adaptability can be incorporated [23,24,58], modularity is the most commonly emphasised.
• The most common purposes of the approach.

The additional insights come from the nuanced exploration of openness, pointing out questions of where openness applies, to what level of detail, and open for whom. These are the aspects that exhibit the most significant variability and encapsulate the core challenges inherent to the approach. There are no simple answers to these questions, as they must be continuously addressed and refined over time within the Community of Practice. Examples of how these aspects are reflected in the existing standards in use by the UK and US governments, such as SOSA [23], GVA [55], and PYRAMID [56], are presented in

Table A2. Example of openness explained as open where and open for whom.

Standard	Description	Open Where	Open for Whom
GVA	The Generic Vehicle Architecture is an effort coordinated by the UK MoD applied to the integration of electronic sub-systems into Land Vehicles Platforms (electronically, electrically, and physically) [55,97].	Infrastructure (data and power), Human Machine Interface, Health and Usage Monitoring interfaces, and Data Model [55,97].	Participation in the CoP and access to the standard is subject to approval by the UK MoD.
SOSA	The Sensor Open System Architecture (SOSA) is an effort coordinated by the US DoD for a C4ISR-focused framework designed to provide a standardised, multi-purpose architecture for radar, electro-optical/infrared (EO/IR), signals intelligence (SIGINT), electronic warfare (EW), and communications systems [112].	Hardware, software, and mechanical/electrical interfaces, with focus on the development of a architectural modules (defining functions and behaviours) and associated key interfaces (physical and logical) [23,112].	Access to the standard is available to anyone through a subscription to The Open Group. Participation in the SOSA Consortium is subject to the discretion of the group’s policies, but includes extensive participation from organisations and individuals within the U.S. government and industry, featuring active working groups [112].
PYRAMID	The PYRAMID Reference Architecture (PRA) is a UK MoD-led initiative that provides a reusable and open avionics system reference architecture. It is designed for software implementation and is applicable to both legacy and future air platforms [56].	‘The PRA is a component-based architecture where the component definitions include roles, responsibilities, and well-defined interfaces. The PRA also includes compliance rules to follow when building mission system deployments that cover the full range of legacy and future aircraft types, roles and mission phases’ [56].	Information about the PYRAMID Exploiter’s Pack is openly accessible at the website [56]. They have the PYRAMID Industry Advisory Group (IAG) to work together as an exploitation community, and, ‘although led by BAE Systems, the team has included specialists from across the UK’s avionics industry’. Participation in the CoP is subject to approval by the UK MoD.

in Appendix A.

The aspects of where openness applies and to what level of detail are outlined in the technical details in the diagram. These are reflected in the outcomes of the OA approach (herein called OA artefacts), which this research identifies as policies, principles and guidance, reference architectures, requirements, and/or specifications (definitions of these concepts are provided in the glossary). These outcomes represent the patterns identified in OA standards, with examples provided in

Table A3. Examples of OA artefacts.

Term	Definition
Policy	‘A MOSA is the DoD preferred method for implementation of open systems, and it is required by United States law. Title 10 U.S.C. 4401(b), states all major defence acquisition programs (MDAP) are to be designed and developed using a MOSA’ [7].
Principle	‘What, not How: A component definition is a requirement specification; it says what a component must do (primarily in terms of its services). It does not say how a component should be implemented. This has been an important consideration in deciding what content should be included in the PRA’ [56].
Reference Architecture	PYRAMID Reference Architecture description document, available at [56].
Requirements	‘The User shall be able to configure instances of the PYRAMID System such that mission capability exploits available and emerging hardware, software and data services with minimal impact on the qualified system’ [56].
Specifications	‘In order to ensure that there is physical connectivity standardisation between an NGVA Compliant Vehicle Platform and NGVA Ready sub-systems, a set of common data connectors is defined (…). Where a single Ethernet connection is required the connector shall be of type (…) with the pin out as defined in Table 11(…)’ [113]

in Appendix A.

Technically, the approach is mainly applied to areas involving the system’s data and computing infrastructure, with varying levels of detail expressed in the outcomes. However, it is also acknowledged that competing interests and constraints—such as intellectual property concerns, development time constraints, the uniform adoption of specifications, complexity and novelty of the technology involved, and fitness for purpose—limit the scope of openness. There are also enabling assets and processes that need to be developed as means to support these outcomes, which will be explored in Section 4.4 and Section 4.5.

The open for whom part defines who will have access to the outcomes of the approach established by the Community of Practice and who will be involved in the discussions. Although the term ‘open’ might imply unrestricted access for everyone, most standards operate under certain restrictions, as identified in [17]. Reasons may include protecting industrial or informational secrets within the group or ensuring national security by limiting access for adversarial nations. However, even for more openly available OA standards, a layered access approach can be applied, keeping critical or confidential information restricted while allowing access to specifications relevant to interoperability or logistics. Therefore, a suitable definition of ‘open’ in this context might be the accessibility of the assets to organisations beyond the original developer or supplier.

Overall, this scope of openness shows that the concept of OA is not a simple composition of the words ‘open’ and ‘architecture’. It does not imply unrestricted access for everyone, nor does it require defining and revealing the entire system’s architecture. Instead, it involves identifying key aspects—particularly those related to data—that need to be defined at least at a high level to support future capability evolution. As adoption increases, community engagement deepens, and the application of system architecture practices matures, these aspects can be progressively managed and improved. However, it should be acknowledged that this is a long-term endeavour. This dynamic will be further explored in Section 4.4.

4.2. Perceived Benefits of the Open Architecture Approach

This subsection addresses how OA delivers value in the form of a benefits chain, while also discussing the hurdles and conditions to achieve some of these benefits, ensuring the alignment of expectations.

4.2.1. Description of the Benefits Chain

The development of the benefits chain begins by identifying the benefits assumed to be directly linked to OA outcomes. Using a logic similar to causal mapping [59], connections are established between these primary benefits and other nodes (benefits) that emerge as potential intermediate effects. This process forms a chain of benefits, leading to OA enterprise’s high-level goals.

To improve readability, the nodes are organised into two diagrams (Figure 6a,b), each aligned with specific high-level goals. A colour scheme highlights key focus areas—logistic, operational, programmatic, strategic, technical, and commercial—while additional conditions provide context where necessary.

Connections between nodes indicate potential contributions rather than guaranteed outcomes (i.e., A ‘can contribute to’ B). That is, the diagrams illustrate the potential pathways through which OA can contribute to the enterprise’s overarching goals, while recognising that other unrepresented factors may also need to align to achieve these outcomes. For example, reducing lifecycle costs depends not only on OA but also on factors like effective programme management and external influences, such as economic conditions, political stability, or conflicts. However, OA facilitates cost savings by enhancing system integration, promoting commonality, and fostering competition as illustrated in the diagram.

4.2.2. Discussion About the Benefits Chain

• Primary benefits (Outcome of OA in Figure 6)

More architecture control for the government. OA empowers the government (the system’s client) to gain greater insight and control over the system’s functionalities and capabilities throughout its lifecycle rather than being limited by the constraints of current suppliers. While increased architectural control may seem to conflict with the concept of openness, the intention is to shift control away from a single supplier to avoid dependency, thereby allowing broader participation from potential vendors. This shift, however, requires enabling resources and investment to sustain the architecture, including architectural and technical expertise, personnel, infrastructure, and logistics for configuration management. These aspects are further explored in Section 4.5.

Facilitated systems integration. The ‘architecture’ component of the OA approach encourages the thoughtful consideration of the system’s functional and physical decomposition and interfaces, while the ’open’ aspect establishes open and widely used standards for key parts, avoiding proprietary interfaces that could restrict the integration. These specifications streamline the systems integration process. The extent to which integration is facilitated depends on the considerations of ‘open where’ and ‘to what level of detail’ as discussed in the previous subsection. While more detailed specifications can enhance the ease of integrating other systems, care must be taken not to over-specify, as this could lead to prescriptive solutions that hinder innovation and increase the time required for definition [13,60]. Additionally, these specifications will need to be managed and maintained within the community, and the implementation timelines observed.

Enhanced interoperability. The OA approach enables information sharing with other systems by defining data interface standards that are not restricted by proprietary solutions. The same conditions for integration apply, along with the concern of ‘open for whom’, addressing which agents the system needs to be interoperable with.

While the first benefit may appear more advantageous for the government, the other two are equally relevant to suppliers. Both parties gain from improved systems integration, which reduces the verification risks and accelerates time-to-field. Similarly, interoperability, which enables capabilities beyond those of a single system, is increasingly vital in today’s distributed and interconnected world, especially in the context of systems of systems. This trend is evident in commercial sectors as well, such as the development of AUTOSAR in the vehicle industry to manage complexity and streamline integration [61], and in smartphone applications that leverage interoperability by combining functionalities and data from multiple sources through agreed interfaces to offer a variety of capabilities to the users.

• Following the chain—main points from intermediate benefits.

Avoidance of vendor lock-in. A frequently mentioned benefit of the OA approach is reducing dependence on a single supplier by adopting standardised principles and modular design. This enhances flexibility in system upgrades and modifications while increasing government bargaining power. However, managing multiple contracts and ensuring system integration become the client’s responsibility. Additionally, current suppliers may see this shift as risky, knowing they could be replaced. However, the objective is to minimise, not eliminate, the original vendor’s involvement. Their expertise will still be needed for interface configuration management in their part of the system, and this must be clearly communicated to maintain supplier trust and promote their engagement.

More competition. Avoiding vendor lock-in can increase opportunities for competition. However, without sufficient options, the original supplier may still maintain dominance. In cases where local suppliers are limited, international competitors willing to collaborate with domestic agencies could offer viable alternatives. This is particularly important for governments that strategically prioritise local resources. Additionally, government commitment is crucial to ensuring fair bidding opportunities without favouring established defence industry leaders, including Small- and Medium-sized Enterprises (SMEs), which can offer agility and innovation, particularly in less complex products. Challenges such as complex procurement processes and certification barriers must be addressed to enable broader market participation.

More potential for collaboration. In a vendor lock-in situation, partners are chosen by the company or consortium that supplies the system. In an OA environment, however, it is in the client’s interest to cultivate a broader and more diverse community of suppliers, including SMEs. The defined OA artefacts, which are collaboratively discussed, enable the integration of efforts and capabilities, fostering cooperation. This collaboration can extend to include allied nations, further expanding opportunities for suppliers, such as through export markets. However, government commitment to the OA approach and these emerging opportunities is essential for their success [4,62]. An example of such commitment is highlighted in [63], which describes USD 228 million in DoD contracts that mandated compliance with the SOSA standard.

Enhanced commonality and capability to customise. Standardised OA artefacts improve cross-platform adaptability, allowing for customisation while maintaining a common framework. For instance, the GVA data models provide a structured approach to modifications. This standardisation enhances adaptability and enables suppliers to make client-specific adjustments with minimal effort. However, factors limiting reusability, such as IP licensing and export controls, must be considered [64].

Greater value out of the existing assets. OA improves data accessibility across systems, optimising resource use. A practical example can be drawn from the first author’s experience of developing a multi-functional display to enhance the commander’s situational awareness in Armoured Personnel Carrier (APC) vehicles, inspired by the human–machine interface component of the GVA standard [55]. The APC had driver and gunner cameras from different suppliers. Initially, each proposed adding separate monitors for the commander’s access. Instead, a shared video streaming standard was established, enabling integration into the multi-functional display and eliminating the need for redundant hardware.

• Overarching goals

Lifecycle cost reduction. The benefit map illustrates how OA can contribute to lifecycle cost reduction, which emerged as the most frequently mentioned benefit in the thematic analysis. This reduction can be achieved by shortening the time needed to integrate new capabilities, avoiding redundant equipment, and maximising reusability. Additionally, OA enhances negotiating power by fostering competition and preventing vendor lock-in, as previously discussed. It also supports the use of Commercial Off-The-Shelf (COTS) products—when compatible with the requirements—by encouraging the adoption of widely used interface standards, which can further promote economies of scale.

However, OA is recognised as a long-term investment with substantial upfront costs as discussed in [13], which can challenge organisations with a culture focused on short to medium-term returns. Investments are necessary for foundational and enabling activities and for the governance of OA artefacts and ongoing community support. Nevertheless, these investments can be shared across programmes with similar applications or distributed among the Armed Forces (e.g., the SOSA standard [65]) or broader communities (such as NATO standards), thereby avoiding the duplication of effort [18].

Increased opportunities to export the products. This end goal is introduced as a potential perspective from industry. As discussed in the context of expanding collaboration, participation in a multinational OA community—or at least adopting this approach—increases the likelihood of identifying clients in other countries [12,22]. This is particularly advantageous in the military market, where the client base is smaller than in the civilian sector but offers higher purchasing power. However, additional factors may also influence this decision, including competition with other major players in countries with strong adherence to the standards, as well as trade policies considerations and market risks in nations that are just beginning to adopt these standards.

More diverse industrial base. Building a stronger and more diverse industrial base to support military capabilities is a common objective for governments. Both the UK and the US incorporate OA into their industrial strategies to achieve this goal [66,67]. A diverse industrial base is essential, as no single solution can meet all military capability needs [66], and OA serves as the ‘glue’ that enables the integration of various systems. Moreover, OA fosters competition while simultaneously enhancing collaboration, contributing to the development of combined capabilities.

Reduced Supply chain risk. The supply chain is a critical factor in supporting military system capabilities and is closely tied to the strength of the industrial base, as previously discussed. OA can mitigate supply chain risks by aiding in obsolescence management—specifically by reducing reliance on single suppliers (vendor lock-in) and promoting the use of COTS products. Additionally, OA simplifies the systems integration process, further enhancing supply chain resilience.

Rapid adaptability and capability evolution. Adaptability is increasingly important in today’s VUCA world. OA contributes to this by facilitating the customisation of solutions using OA artefacts as a baseline. Additionally, OA fosters innovation through greater data availability [68], increased competition, and a stronger focus on end functionalities rather than low-level integration tasks. However, achieving this level of agility also depends on optimising mechanisms to expedite the procurement process [69].

Improved operational effectiveness. OA can also benefit end-users, particularly combatants, by enhancing the operational effectiveness of systems. As previously noted, OA avoids the need for additional equipment [55], thereby reducing the cognitive load on operators and the training required since they no longer need to manage multiple devices. Additionally, by enabling data sharing, OA can provide the necessary resources for AI-driven decision-making, leveraging information gathered from system sensors. Moreover, the system’s rapid adaptability and capability evolution discussed above ensure it remains fit for purpose, further improving overall effectiveness.

• Final remarks on the benefits chain

The literature review highlights the difficulty of quantifying the value of OA and the need for more effective assessment tools. Consequently, this investigation is limited by the lack of publicly available quantitative evidence, requiring the conclusions presented here to be based on logical inference. Nonetheless, until such tools are improved, stakeholders can still leverage this benefits chain to assess the potential risks of not making these investments. In other words, recognising the current limitations. Capabilities would remain siloed, impeding the swift integration of new technologies. Vendor lock-in would persist, leading to elevated costs and dependency on specific suppliers. Interoperability would be hindered due to the lack of standard agreements for data sharing, as well as the potential of AI applications due to insufficient data for data training. In addition, as technology advances, systems become increasingly complex, and software integration grows steadily. It is important for stakeholders to recognise that supporting these investments is necessary to remain current. Without such support, their systems risk becoming less efficient and potentially unfit for their purpose.

Although the discussion of the benefits of OA is not new, these diagrams contribute by demonstrating how the benefits can form a chain effect, influencing each another, while emphasising that these outcomes are contingent on specific conditions and subject to other complex factors. As such, the diagrams provide a useful tool for understanding the potential value of investing in the OA environment.

4.3. Exploration of Different Perspectives About the Open Architecture Approach

The previous subsection examined the potential benefits of OA; however, industry and government may perceive these benefits in different ways. Building on this, the current subsection applies the BATWOVE framework to recognise different worldviews concerning the OA approach. Such analysis is crucial in equipping decision-makers with a comprehensive understanding of the various perspectives and potential conflicts of interest inherent in the proposed transformations.

4.3.1. Description of the BATWOVE Models

To begin, drawing from the interviewee’s profiles, their responses, the researcher’s experience with the Brazilian Army, and a consideration of who benefits or may be disadvantaged by the benefits outlined in the previous subsection, the most relevant perspectives on OA adoption are identified and summarised in

Table A4. Perspectives (worldviews) over the OA approach. The texts in blue represent positive views, while brown texts represent negative ones.

Stakeholder	Perspective
1- Governments engaging with the approach.	OAs can enhance understanding and control over the entity of interest, reduce vendor lock-in, lower through-life costs (TLC), and enable more efficient and adaptable delivery of capabilities.
2- Group of Nations.	OA can facilitate interoperability to improve operational effectiveness, and it aligns with current efforts toward commonality in logistics and harmonisation of requirements.
3- Governments that are not engaging with the approach.	There is either a lack of awareness or OA can appear complex and may be perceived as ‘just another way to spend money’. Implementing OA will require internal changes, may create friction with existing suppliers, and could take considerable time to yield any return on investment (ROI), making it a potentially high-risk endeavour. Furthermore, these governments often lack the budget of more advanced nations and are not frequently engaged in external conflicts, reducing the need for constant upgrades to state-of-the-art systems.
4- Current suppliers (primes/integrators) that are resisting to engage with the approach.	While OAs give clients more control over their systems, they may also be perceived as a threat to the market position of existing suppliers. Mandating OAs as standards can limit solution options, and ultimately, it is the company’s responsibility to develop solutions at their discretion, meeting requirements, and pricing their work accordingly.
5- Current suppliers (primes/integrators) that are engaging with the approach.	Engaging in the OA environment may be an opportunity to influence the development and maintenance of the architecture while also adhering to the customer’s policies. It may also foster opportunities for collaboration.
6- Potential suppliers (primes/integrators/other tiers/SMEs).	OA can create opportunities for market expansion and increase the potential to reach additional customers, including through enhanced exportability.

(Appendix B).

Developing a BATWOVE for each worldview identified in Table A4 could result in an overly extensive and potentially redundant analysis. Instead, perspectives can be grouped into the categories of ‘beneficiaries’, ‘victims’ (opposing views), ‘actors’, and ‘owners’. Following this principle, two BATWOVE models are developed to identify the conditions necessary to advance OA, adopting a progressive worldview as the baseline. The first BATWOVE model (Figure 7) focusses on the government’s perspective, while the second adopts the industry’s viewpoint (Figure 8), emphasising a collaborative approach.

The first model (Figure 7) is grounded in the perspective of governments already engaged with OA or those with individual and localised initiatives striving to advance. Owners, government decision-makers, may have an established commitment to OA (as seen in the US and the UK) or hold a more sceptical view. Alternative worldview [W] and transformation [T] statements to capture this sceptical view might include the following:

W: 

The OA approach is too complicated to understand and is ‘just another way to spend money’. It will require a significant change in the enterprise model, will possibly cause friction with the current suppliers, and will require a long time to see any ROI.

T: 

Transitioning from the current workload to increased demand to understand, develop, and implement the OA. Transitioning from already-known solutions to more complicated systems with OA. Transitioning from already expected costs to more difficulties in estimating the cost of developing, maintaining, and delivering OA. Transitioning from a regular relationship with the suppliers to an uncomfortable state that will need to be dealt with.

In such cases, parts of the government, particularly technical teams or regulatory bodies, may experience challenges, potentially feeling like victims of the OA transition due to the perceived disruptions. A path forward for addressing this conflicting view involves foundational work to drive cultural transformation, educate stakeholders, and demonstrate early successes to build momentum.

The group of nations is translated as beneficiary, as well as suppliers interested in engaging in the approach. Lastly, the suppliers not engaging are seen as victims in this model.

The second BATWOVE model (Figure 8) reflects the perspective of suppliers interested in engaging with the approach. Suppliers with opposing views are identified as victims, though they could also function as owners depending on their strategic influence over the defence industrial base. An alternative Worldview [W] and Transformation [T] capturing these concerns might include the following.

W: 

Opening up the systems may cause current suppliers to lose their market share, as it will increase competition. Furthermore, it introduces additional requirements that could stifle innovation by limiting the solutions available.

T: 

Transitioning from a state of closed systems which are dependent on the support from the supplier to a situation where other companies become capable of providing services that were performed by the organisation before. Transitioning from being free to develop the way the supplier wants (or is used to) to a more constrained solution space determined by the OA artefacts (different from what they are used to doing).

To further address this resistance, these suppliers could be encouraged to join the Community of Practice as influential leaders, actively shaping the development of artefacts—similar to the role BAE Systems plays in the PYRAMID initiative [56]. This involvement would allow them to retain a degree of influence over government decisions regarding the requirements of the product. If resistance persists and they remain unwilling to modify their business model, gateways could be a potential workaround to integrate with other parts of the system.

The next subsection will provide a more detailed analysis of the industry’s perspective, using Porter’s Five Forces framework [51] to examine how these external factors influence the engagement of the Community of Practice.

4.3.2. Final Remarks on the BATWOVE Models

The value of the BATWOVE framework lies in its structured approach to analysing complex situations. While it does not directly propose a solution, it enhances awareness of how the intended transformations are perceived by the affected stakeholders, the individuals or groups responsible for the change, and the enabling or obstructing conditions involved. No prior research is found in applying this framework to OA; therefore, this subsection contributes by synthesising in the form of worldviews the key motivations driving industry and government toward OA while also briefly discussing possible strategies to address these conflicts. The following subsections will delve into the actions, discussing the dynamics of the OA landscape and distilling the environmental conditions into enabling areas that need to be developed to support these transformative efforts.

4.4. Adoption Conditions for the Open Architecture Approach

This subsection addresses the ‘how’ of the OA approach by examining the dynamics of the approach and its main adoption conditions. It integrates insights that emerged from the BATWOVE analysis (transformation and environment), as well as elements from the PESTLE analysis [52] and Porter’s Five Forces [51]. This reflection culminates in the diagram Triangle of Adoption conditions for the OA approach (Figure 9), described and discussed below.

4.4.1. Description of the Diagram Triangle of Adoption Conditions

The process of developing an influence diagram helps to identify key variables, understand their interconnections, and analyse how these relationships influence the behaviour of the system under study [50]. Through multiple iterations, three variables emerge as the primary conditions for adoption: investments, engagement of the community of practice, and maturity in the technical, legal, and management aspects related to OA. Consequently, the diagram is refined into a triangular structure, with these variables positioned at the vertices and their interrelations—how one contributes to the other—represented by the sides. The enablers of the approach are represented as a central element circulating within the triangle, while considerations affecting the dynamics are represented as external factors.

Although this configuration deviates from the traditional form of an influence diagram, it effectively captures the core elements and dynamics of the OA environment, highlighting the adoption conditions and illustrating how the variables influence each other along with specific conditioning factors.

4.4.2. Discussion About the Diagram

• Choice and description of the main variables.

This subsection begins by discussing the meaning and choice of the three main variables that emerge from the analysis of the dynamics of the OA environment as adoption conditions. It is important to reiterate that these conditions require sustained commitment and that progress is gradually achieved over time as seen in the evolution of approaches in established countries, such as the UK and the USA [10].

Technical, legal, and management maturity: This is the maturity to comprehend, define, communicate, and document the functional and logical decomposition of the systems of interest and the respective standards, reflected in the artefacts of the OA approach, as well as to address the legal barriers (e.g., Intellectual Property) and relevant management considerations to sustain these elements throughout the system lifecycle. This maturity will reflect on the ‘open where’ and ‘to what level of details’ parts of the OA approach. Ensuring such maturity is fundamental, as the quality of these artefacts directly influences the adoption of the approach. This capability can be enhanced through experience and practice, as well as through training and diverse expertise, which can be contributed by the Community of Practice.

Engagement of the Community of Practice: This is the number and diversity of participants adopting the approach (i.e., developing products or systems conformant with it) and providing feedback to optimise and maintain its artefacts. Feedback, gathered through working groups and symposia, sustains adoption by enabling knowledge exchange, best practice sharing, and iterative improvement. This mechanism drives the approach’s continuous evolution and momentum. This will reflect on the ‘open for whom’ part of the OA approach. Engagement can begin within a single program, expand to multiple programs within the same military domain, evolve into a standardised practice across that domain, extend to other domains, and ultimately foster collaboration among nations and allies.

Investment: This is the budget to support OA initiatives, particularly to enable the development and sustainability of artefacts. Adequate investment is fundamental to providing the financial backing necessary for the initiative’s success. In line with this, is the vital role of supportive leadership in championing the budget.

The interrelation among the conditions operates as a long-term cyclical dynamic. Investments provide the financial resources necessary to sustain the enablers, which foster maturity. This enhanced maturity leads to more refined artefacts, potentially driving greater adoption within the community. As adoption increases, the resulting benefits—such as lifecycle cost reduction—are likely to offset, at least partially, the initial investments. Moreover, investment in the enablers supports community engagement as noted earlier, which generates returns in the form of products conforming to the approach and opportunities for cross-programme investment sharing. Finally, the engagement of the Community of Practice contributes to the maturity of the artefacts by offering valuable feedback derived from the implementation challenges and lessons learned. It is important to emphasise that this dynamic is an evolving process and requires a long-term commitment as previously underscored during the exploration phase of the research.

• Enablers and External Factors.

At the centre of the diagram, supporting these three variables, are the enablers of the approach, which will be explored in detail in the next section. These include fostering training and education, attracting and retaining skilled personnel, and managing infrastructure and tools—critical for building maturity. Organisational strategies and policy commitments further strengthen community engagement and play a vital role in securing resources and justifying investments.

Key external factors influencing OA adoption and broader military investments include the following:

Political factors (P in PESTEL): Necessity of collaborating with coalition partners and responding to emerging threats.

Societal and economic factors (S and E in PESTEL): Budget pressures from competing national priorities like healthcare and education.

Technical factors (T in PESTEL): Increasing demand for distributed operations, reinforcing the need for interoperability.

Legal aspects (L) are not explicitly covered but may relate to competition law. Environmental factors (E) have limited relevance to OA, though reducing redundant equipment can help minimise waste.

For example, the United States, which maintains the largest defence budget globally [70], prioritises military spending due to the persistent threat posed by other military powers, the need to collaborate with NATO and allied forces, and reasonable public support [71]. As a consequence, they are the country with more efforts in OA approaches [17].

Continuing with external factors, engagement in the OA Community of Practice requires balancing industry interests with government objectives. Industry players prioritise market dominance and profitability, which can be analysed using Porter’s Five Forces [51]:

Competitive Rivalry: The willingness to engage in a Community of Practice for OA is significantly shaped by the nature of the existing market. In markets dominated by established companies, particularly those with strong client loyalty due to long-term contracts or domestic manufacturing facilities, these companies hold considerable influence. This dominance can make it difficult to persuade them to adopt open standards that differ from their customary proprietary practices. However, there is an opportunity to involve these companies in shaping the development of OA-related artefacts as highlighted in the BATWOVE analysis. Furthermore, emphasizing the potential for diversifying the client base with countries that seek similar OA approaches (NATO members, the USA, and the UK) can be a compelling argument to encourage their participation in the Community of Practice.

Threat of new entrants: The defence market is challenging for new entrants to compete in major roles, such as integrators, primes, or major systems suppliers. This complexity stems from the specialised nature of required technologies, high switching costs from the buyer, significant capital demands, and established relationships with incumbent companies [72]. Consequently, existing suppliers tend to have an advantage in these areas. While the OA approach has a limited impact in supporting or hindering new entrants, it provides opportunities for differentiation through modular systems or combined capabilities offered by substitute products or services as will be discussed in the next factor.

Threat of substitute products or services: One of the key objectives of the OA approach is to reduce vendor lock-in by modularizing systems and adopting open standards, enabling the identification of substitute products throughout the lifecycle. This includes integrating COTS and Military Off-The-Shelf (MOTS) solutions when requirements are met, as well as dual-use technologies such as cybersecurity solutions and AI applications [73]. This approach may create significant opportunities for emerging players, and is often perceived as a threat by established companies. Nonetheless, these emerging players have persistent challenges, such as ethical conflicts with the use of their products in the military domain [74], the preference for dominant players (as previously discussed) and the stringent compliance demands of traditional procurement processes, including requirements for prior experience and standard certifications. These factors can act as substantial barriers for SMEs, for instance. If these opportunities do not materialise as expected, these potential substitute organisations may lose interest in engaging with the Community of Practice. To overcome these challenges, governments could delineate the roles of various suppliers, including system integrators, providers of major systems, and SMEs delivering innovative yet less complex solutions, and adopt policies to address the procurement barriers accordingly.

Bargaining power of suppliers: In this context, suppliers refer to lower-tier entities providing components or services to major system suppliers (e.g., prime contractors). The defence sector often depends on a limited number of specialised suppliers [72], giving them high bargaining power and making OA adoption challenging, similar to major suppliers in competitive rivalry. However, there is potential for the prime contractors to benefit from the advantages of OA in cases where less specialised and more easily customisable solutions are acceptable. Their influence can drive supply chain adoption—if major players push for open standards, suppliers will likely adapt to maintain key client relationships. A notable example is the AUTOSAR initiative [61], where leading manufacturers established standards, compelling suppliers to comply due to their market power.

Bargaining power of customers: The government’s bargaining power in promoting or mandating the OA approach for suppliers is closely tied to its buying power and its role as the primary customer for these suppliers [72]. For example, the USA, with its extensive industrial base that relies heavily on government contracts, can more effectively mandate initiatives like MOSA [72]. Nations where the industrial base is more export-oriented or lacks significant domestic demand may struggle to exert similar influence. While they may lack the leverage to mandate OA practices for external suppliers, they could potentially impose OA requirements on domestic companies that face challenges in competing internationally. In such cases, mandating OA domestically could provide these companies with a competitive edge in the country and foster local innovation.

• Final remarks on the Triangle of Adoption Conditions.

Finally, the Triangle of Adoption conditions for the OA Approach provides a synthesised yet comprehensive form of understanding the dynamics underpinning the adoption of the OA approach. As no equivalent model or similar exploration of these dynamics has been identified in the existing literature, this model brings a contribution to the body of knowledge, particularly in providing guidance on the environment of the approach prior to implementing actions.

4.5. Mapping Enabling Activities Towards the Open Architecture Approach

Building on the previous subsection, this part analyses the enablers of the OA approach, drawing from areas emphasised within the DLOD, particularly as utilised by the UK (TEPIDOIL) [75], USA (DOTMLPF-P) [76], Canada (PRICIE+G) [77], and Australia (FICS) [78]. These nations adopt a similar approach to mapping capability enablers as detailed in [53,75]. It also incorporates insights from the overarching MOSA initiative in the USA as represented in [7].

This analysis culminates in a framework that focusses on enabling areas without delving into specific details. The task of refining and elaborating on these areas is left to organisations within their respective Communities of Practice. However, by identifying key areas and high-level activities, this framework equips stakeholders to develop tailored transformation roadmaps and corresponding plans for the phased adoption of the approach.

4.5.1. Description of the Framework

The framework categorises the enablers into distinct areas of focus—personnel, training and education, support, contracting and management, artefacts and practices, policies and strategies, and organisation—and outlines the corresponding high-level activities as detailed in Figure 10. The enablers are further categorised into types that align with those used in the benefits chain to ensure consistency: amber denotes programmatic, green represents technical, and blue signifies strategic.

A detailed description of these areas will follow, including concise examples of national approaches, the United States serving as a benchmark for being the most prominent advocate of the approach [3,41], and the United Kingdom, positioned as an intermediary and likely the second most advanced adopter. Finally, recommendations for countries in the early stages of OA adoption, such as Brazil, will be outlined.

• Personnel

Description: Availability of motivated and qualified personnel, from leaders to developers, both within the government and industry, to support the adoption and continuous improvement of the OA efforts.

Contextualisation: Personnel are crucial, as they are the driving force behind organisational momentum. A competent workforce significantly enhances the likelihood of achieving strategic goals and fosters continuous improvement. Additionally, motivation is essential for attracting and retaining top talent, ensuring sustained success and growth.

In the context of the USA, the Office of the Under Secretary of Defense for Research and Engineering (OUSD(R&E)), which has been actively advancing efforts toward MOSA, recently developed a competency framework for the Engineering & Technical Management (ETM) workforce [79], which also considers skills relevant to support MOSA initiatives (e.g., digital literacy, architecture design, leading change, and design considerations, among others).

No public documents outlining a specific competency framework for OA initiatives in the UK have been identified. However, the UK’s Ministry of Defence Digital Strategy for Defence emphasises the need for a transformed workforce under the ‘People’ element, calling for ‘the right skills, roles, and mix of people in Defence Digital’ [80].

• Training and Education

Description: The availability of training modules and courses to build the necessary skillsets for OA deliverables, fostering both promotion and broader cultural adoption. This training will better prepare the workforce that will constitute personnel, equipping them for effective implementation. It is important to include both government and industry stakeholders across the initiatives.

Contextualisation: Training and education equip the workforce with the essential skills to implement the required capabilities successfully.

The USA has been actively investing in education aligned with the MOSA framework, supported by institutions such as the Defense Acquisition University and other research-focused organisations. Additionally, supporting fields like systems engineering and digital engineering are offered across the country [81]. Furthermore, standards like SOSA and FACE are supported by companies offering specialised training courses [82].

There is no evidence in the open literature of an organisation-wide approach within the UK MoD comparable to MOSA, nor is there a structured training programme for these concepts. However, universities and institutions in the UK provide training in related fields, such as systems engineering and digital engineering [81]. Furthermore, training is available for key competencies, including system architecting (delivered in-house by major organisations), frameworks (e.g., UAF), modelling languages (e.g., SysML and ArchiMate), methods (e.g., TOGAF and MDA), and tools. In addition, training is provided for the implementation of specific OA standards, such as PYRAMID, although it appears to be restricted to successful bidders [83].

• Support

Description: Supporting logistics, infrastructure (repository), and processes to enable the creation, access control, maintenance, configuration management, and upgrading of OA artefacts.

Contextualisation: No specific support measures for OA were identified in the UK or USA, though such support is anticipated to align with the needs for existing Digital Engineering/Model-Based Systems Engineering artefact support and IT infrastructure, with the USA also progressing initiatives like Model-Based Acquisition (MBAcq [84]).

Both countries maintain repositories for OA standards; in the USA, some standards are managed by international standardisation groups with sponsorship from various DoD organisations. Additionally, laboratory infrastructure to support the development and/or selection of the OA standards has been suggested by [35] in the context of adapting OA for Australia.

• Contracting and Management

Description: Development of guidelines to incorporate OA into contracts, including considerations for data rights and intellectual property within artefact definitions, along with strategies for managing these elements throughout a system’s lifecycle.

Contextualisation: The USA is the only country that appears to have recommendations for contracting and IP made publicly available in the context of OA. Examples of publications with helpful resources are the Open Systems Architecture Contract Guidebook for Program Managers [18], Open Systems Management Plan [85], Intellectual Property Strategy Brochure [86], and the Army Data & Data Rights Guide [87]. The same is valid for assessment methods, where constant efforts are made to improve these tools. Examples are described in [30].

• Artefacts and practices

Description: This is the comprehensive development and standardisation of the OA artefacts, implementation guidelines, and conformance process, incorporating best practices from relevant supporting areas (Systems Engineering, Systems and Enterprise Architecting, Digital Engineering) and subject matters. Recalling from the systemigram, these artefacts include principles, reference architectures, requirements, and specifications.

Contextualisation: This area represents the production of the actual outputs of the OA approach. Engagement from the Community of Practice is crucial in this process to maximise the adoption potential.

Both the UK and the USA have made substantial investments in these artefacts over the years, as outlined in [3].

The USA has adopted a more direct approach to developing implementation guides, driven by policy mandates. Key examples include the MOSA Reference Framework [88], the Air Force Materiel Command (AFMC) Guidebook for Modular Open Systems Approaches [89], and the SOSA Reference Implementation Guide [57]. The FACE Conformance Guidance [90] provides conformance-specific documentation.

The UK offers similar resources, such as the PYRAMID Deployment Guide [56]. The Defence and Security Accelerator (DASA) recently launched a competition to improve supplier compliance with these PYRAMID guidelines, demonstrating commitment to adoption, validation, and community engagement [83].

Both the UK and the USA are continuously working to incorporate emerging technologies and safety and security considerations into standards in collaboration with the Community of Practice. Examples are the standards SAPIENT [91] for integrating AI across sensors, and MAPS [92] to improve survivability systems.

• Policies and Strategies

Description: Development and promotion of policies and strategies to support the adoption of the OA approach within the Community of Practice.

Contextualisation: Government policies signal strong support for the approach, helping to ease suppliers’ concerns about the risks involved in adapting to these new requirements.

The United States appears to be the only country where OA (through MOSA) is mandated by law [93]. Additionally, another legislative act [94] directs the Department of Defense to issue regulations and guidelines to facilitate MOSA adoption within military departments. This legislative framework reflects a strong commitment to OA principles within the USA defence policy.

Although the United Kingdom does not appear to have explicit widespread policies on OA, it has integrated OA principles into its broader industrial and digital strategies [66].

• Organisation

Description: These are initiatives to adapt the culture, structure, and relationships within the organisation and the Community of Practice to facilitate the adoption of the OA approach. This includes leadership towards OA, a significant factor to support the approach and any transformation process [95].

Contextualisation: Organisational involvement and restructuring are fundamental to successfully integrating OA efforts.

(1) An OA-supportive culture can be developed by showcasing the value of these concepts to the organisation. This can be accomplished through training sessions, webinars, seminars, and case studies demonstrating practical benefits.

In the United States, the Defense Acquisition University (DAU) hosts regular web events on various topics, including MOSA through its ‘Let’s Be Modular & Open’ series [96], actively promoting MOSA principles at multiple events. Notably, the 2024 INCOSE International Symposium featured an entire day focused solely on MOSA. Similarly, UK defence organisations consistently emphasise the significance of OA within their programmes and initiatives, including GVA [6,97], PYRAMID [98], and UK MOSA [99], particularly at defence events, conferences, and symposia. Hence, in both the UK and the USA, strong leadership support is evident, with high-ranking military officials and suppliers frequently discussing and endorsing the approach.

(2) Changing the structure of an organisation is a complex and time-consuming process, often requiring sustained effort and resources over many years [100]. Both the US and the UK have committed to the OA journey for decades [10], gradually establishing systems, supporting roles, and working groups that reinforce this initiative. The presence of these support structures indicates a mature stage in their OA efforts, reflecting both the long-term dedication to the initiative and the institutionalisation of supporting roles to sustain it.

The United States includes various working groups within its OA initiatives and the MOSA framework as a whole, such as the Modular Open Systems Working Group (MOSWG) [7]. Additionally, the Office of the Under Secretary of Defense for Research & Engineering (OUSD R&E), which is the department responsible for Systems Engineering and Systems Architecture efforts, recently drove the formulation of a MOSA implementation guidance for the Department of Defense [101]. Furthermore, they also have Offices dedicated to coordinating the transformation towards MOSA, such as the Army PEO Transformation Office [102].

No publicly available data were found in the literature detailing how the UK structures its OA practices. However, as observed in conferences, both LOSA [103] and PYRAMID have established dedicated functional structures to support this approach. In both the UK and the USA, leadership support for OA is evident, with high-ranking military officials and suppliers frequently discussing its significance.

(3) Similar to organisational transformation, the creation and engagement of a Community of Practice is also a long and continuous effort as discussed in the previous section. The mechanisms for promoting the engagement of the Community of Practice include mapping relevant companies and tiers within the defence industrial base, implementing initiatives to attract additional partners, and coordinating efforts with other programmes and military branches. An effective approach to engagement could involve promoting and investing in symposia, meetings, and the establishment of working groups as previously mentioned.

The United States has established the MOSA Community of Practice [104] and additional communities dedicated to specific standards, such as SOSA [105] and FACE [8], both managed by The Open Group as open-access communities. These initiatives bring together members from various branches to foster a coordinated approach.

The literature lacks public data on how the UK manages these communities; however, it is known—based on standard pages and conference presentations—that communities exist within each OA initiative. Nevertheless, it appears these efforts are still not highly integrated across the different branches of the armed forces.

4.5.2. Using the Framework to Build Recommendations for Early-Stages Adopters

Early-stage adopters are likely to encounter challenges such as limited investment, low maturity, and the absence of an OA Community of Practice. As seen in other countries, OA adoption will likely progress in phases—beginning with individual projects, expanding to programmes, then within the Armed Force, and eventually evolving into a tri-service approach. While the USA and the UK provide valuable references, these adopters must navigate challenges first-hand, learning through experience and adapting OA to their specific context.

Personnel. To build a capable workforce, these organisations should likely start by developing a competency framework that fosters soft-skills such as holistic and critical thinking, alongside foundational competencies in supporting areas and subject matter expertise—particularly in data-related fields. As maturity increases and training programmes expand, this framework can evolve to include specialised fields like systems engineering and systems architecting.

Securing qualified personnel may be challenging, making investment in continuous training programmes essential. Additionally, contracting companies with personnel already meeting these competency standards can provide interim support.

Training. Organisations will likely begin by enrolling individuals in existing domestic or international courses to establish foundational expertise, and seeking training in specialised modelling tools. As OA adoption progresses, tailored training programs can be developed to address specialised skill requirements within the competency framework.

Support Infrastructure. Early steps should focus on establishing localised repositories and basic laboratories for testing the standards and developing proofs of concept. Over time, capabilities can expand, including shared repositories with the Community of Practice, and particular attention to managing product configurations subject to artefact rules and adoption timelines, preventing issues caused by conflicting versions.

Management and Contracting. Governments should reference existing frameworks to guide contractual requirements, ensuring key OA considerations are addressed. However, refining these practices will take time and experience. Over the medium to long term, organisations can enhance their compliance and evaluation tools to support more rigorous OA implementation.

Artefact Development. While organisations may have agreed-upon protocols, standardised ones are often lacking. Initial efforts should focus on identifying standardisation opportunities, drawing on established international efforts where feasible or developing domestic standards. Adopting foreign standards can enhance interoperability and streamline implementation by leveraging existing Communities of Practice, but it may also limit flexibility for future adaptations and introduce dependencies on external policies.

Policies and Strategies. Formal OA policies and strategies are often absent in early stages and tend to develop as localised efforts gain traction.

Organisational Considerations. Cultural aspects play a crucial role, particularly in securing leadership support for OA adoption. Raising awareness through workshops, presentations, and integration concept demonstrations can be an effective starting point, but it must be sustained, as leadership changes approximately every three years. Consistently reinforcing that OA represents a long-term vision requiring ongoing commitment is essential, especially in overcoming organisational challenges.

In terms of building the Community of Practice, organisations can begin by engaging current suppliers and partners while identifying potential new suppliers for future capabilities. Initial steps may include sponsoring meetings, workshops, and symposia to foster dialogue on integration, inviting foreign experts, and participating in international events. These efforts can gradually evolve into a structured Community of Practice to collaboratively develop OA artefacts.

Additional recommendations can be found at Figure A1—Appendix C, extracted from the dataset supporting this investigation.

4.5.3. Discussion About the Activity Mapping Framework

This framework presents a structured method for representing enabling actions to support the adoption of OA approaches over time. Combined with the Triangle of Adoption conditions (Figure 9) it effectively addresses the ‘how’ of this process. In addition to offering initial guidance on enablers, the contextualisation demonstrates how this framework can serve as a valuable tool for analysing the progress of nations adopting OA approaches and assessing their current state in the context of their own environment and adoption conditions.

It is essential to highlight that not all actions will unfold simultaneously, nor should the environment wait for their completion before the adoption process begins. This is a long-term endeavour, in which actions evolve and improve over time, with each area potentially advancing at its own pace.

To conclude, it is important to observe the interdependence of these areas. For instance, the availability of qualified personnel relies on effective training; the competency framework should be reflected in the organisation’s roles; and both the organisational environment and the quality of activities within the support areas play a critical role in influencing personnel motivation. This idea is also highlighted in the element ‘Generate’ of the Canadian PRICIE+G capability framework [77].

5. Conclusions

The Open Architecture approach has emerged as a transformative strategy for enhancing interoperability, promoting information sharing, and facilitating cost-effective modular integration throughout the lifecycle of defence systems. This paper presents an holistic analysis of the OA approach in military contexts, elucidating its technical, organisational, and commercial dimensions. By exploring the complexities and multifaceted nature of the OA environment, the study offers key insights into the benefits, challenges, and enabling factors critical to its successful adoption. The key contributions derived from this analysis are as follows:

• Conceptual clarification: This work synthesises and articulates the commonly accepted aspects of OA, emphasising the necessity of defining openness in terms of ‘for whom’, ‘where’, and ‘to which levels of detail’. Such definitions must be collaboratively refined within a Community of Practice to ensure alignment with evolving stakeholder needs and system goals.
• Benefits chain of OA: The benefits chain provides a cohesive pathway from the contributions of the OA approach to an organisation’s goals, enabling decision-makers (in both customer and supplier organisations) to understand how the benefits they seek from OA may be realised. The models also show the necessary conditions and challenges for achieving particular benefits, allowing for the alignment of expectations. The BATWOVE models complement them by addressing the question of benefit for whom while examining how various stakeholders are affected.
• Actionable models: The ‘Triangle of Adoption conditions’ emphasises the key points for sustaining progress in the OA environment: engagement of the community of interest, investments, and technical, legal, and management maturity. Furthermore, the ‘Framework for mapping enabling activities towards OA’ synthesises the primary areas and high-level activities necessary to establish the enablers for the environment of this approach, offering recommendations to navigate the complexities of OA implementation and develop tailored transformation roadmaps.

By discussing the concept and actions towards the OA approach, it is expected that this analysis will provide decision-makers with a better overall understanding of the approach and to address their strategies, particularly for early-stage adopters in under-represented defence sectors. Furthermore, it enriches the literature by offering a holistic perspective as an initial form of guidance.

The study reveals avenues for further research, including dedicated investigations into the sequencing and interdependencies of enabling activities required to refine the adoption process. Additionally, advancing the conceptual understanding of OA through collaboration with standards bodies could foster the development of widely accepted definitions and artefacts.

In conclusion, this paper underscores that adopting the OA approach is a long-term endeavour requiring sustained commitment, collaborative engagement, and a strategic balance of technical, organisational, and commercial considerations. By providing both theoretical insights and practical tools, this research catalyses progress in the adoption of OA, thereby enhancing the resilience, adaptability, and effectiveness of defence systems and enterprises.