Open Architecture, the Universal Armament Interface (UAI), and the Future of Defense Systems Integration — The Global Transformation, Türkiye’s Position, and a Strategic Roadmap

Introduction

Military superiority is no longer measured primarily by the individual platform.

For much of the twentieth century, the platform was the basic unit of combat power. An aircraft, ship, missile system, or armoured vehicle was judged by its own sensors, weapons, speed, range, and survivability. That logic has not disappeared, but it no longer explains where decisive advantage is moving.

In a plausible conflict today, the decisive question is how quickly different systems can find, decide, strike, and assess together. The speed, flexibility, and jam-resistance of communication between sensors, commanders, and shooters may matter more than the qualitative edge of any single platform. What matters is how short the sensor-to-shooter loop can be made, and how fast it can be rebuilt when a node is lost or a link is jammed.

Recent conflicts have made this trend visible. Assessments of Ukrainian, Gazan, and Iranian theatres show how AI-enabled decision-support and targeting systems compress the sensor-to-shooter cycle by fusing data from multiple sources. Advantage shifts toward the side that can operate inside the adversary’s decision loop: detecting, verifying, striking, assessing, and retargeting before the opponent can react.

Kinetic power still matters, but it no longer stands alone. Firepower gains strategic value only when it is embedded in a resilient decision and integration architecture. The unit of superiority is no longer the platform; it is the ecosystem that platforms form together.

The technical backbone of this concept rests on open architecture — a design and procurement order in which the interfaces between systems are defined not by any single manufacturer’s proprietary ownership but by agreed, verifiable standards. Open architecture began as an engineering preference, yet within the United States and NATO (the North Atlantic Treaty Organization) ecosystem it has hardened into a procurement and industrial policy mandated by law. This study analyses the logic of that transformation, its limits, and the strategic consequences it carries for Turkiye, and opens to discussion the system-architecture and standards-governance layer that represents the next threshold for a defence industry which has, in large measure, already secured platform autonomy.

1. The Anatomy of the Integration Problem

Cold War–era defence systems were built on closed architectures that were federated yet mutually independent — each subsystem carrying its own processor and software, with ownership held by the manufacturer. Such a structure was efficient for wringing maximum performance from a single platform designed to operate alone and self-contained. But as systems multiplied and the need for them to talk to one another grew, the cost of adding a new capability to the whole became, over time, unbearable. Integrating a new munition onto an existing aircraft was a separate engineering project that reached well beyond a physical connection: it required the aircraft’s Operational Flight Program (OFP) to be rewritten, tested, and re-certified for flight safety. On that logic, integrating one munition onto five different platforms meant five separate projects, producing a vendor lock-in that tied the user to the original manufacturer at every update.^{1, 2}

The Universal Armament Interface (UAI) is a structural answer to this problem. Sitting atop the MIL-STD-1760 electrical interface, UAI defines a standard way to integrate guided munitions onto a platform independently of OFP update cycles. The critical insight here is institutional: it treats UAI not as a technical matter but as a discipline of interfaces. By turning integration from a project conceived from scratch each time into a defined standard, it lowers both time and cost and frees the state from dependence on a single supplier. In the years that followed, this logic moved far beyond munitions to become the founding principle of the entire defence-systems architecture.

1.1. The scale of the problem: time and cost

The size of the bottleneck becomes visible in figures. Integrating a single munition onto a single aircraft costs, depending on complexity, somewhere between roughly 20 and 200 million dollars; in the United Kingdom, for instance, the 2018 estimate for integrating the Storm Shadow missile onto the Typhoon stood at 114 million pounds.^{3, 4} The structure of that cost is itself telling: in a typical aircraft–munition integration the largest single item, averaging some 40 percent, is the aircraft software; airframe integration accounts for roughly a quarter, and mission-planning software together with system integration and testing makes up the remainder.⁵ In other words, the most expensive part of integration is not hardware but software. On the time axis, full integration under a closed architecture in the US context generally runs three to five years, and dependence on the aircraft OFP update schedule can stretch it further. This is assessed to be a direct obstacle to responding in time to a threat identified in the field. The difference an open-architecture approach brings is of the same order of magnitude: a program-management metrics study at the US Air Force Institute of Technology (AFIT) reports that, under an Open Mission Systems (OMS) approach, research-and-development integration time can fall to roughly three months, whereas in conventional programs the same figure runs to a minimum of fourteen and an average of thirty-three months.^{6, 7}

2. The Birth of the Policy: Law and Alliance Standardization

The decisive turn for open architecture was the moment it ceased to be an engineering preference and was bound instead to a legal obligation. The United States crossed this threshold with legislation that made the Modular Open Systems Approach (MOSA) the mandatory method for major procurement programs;⁸ openness thereby stopped being a good practice left to each program’s discretion and became a rule the state requires. MOSA’s essence can be defined as a modular design, interfaces specified by agreed open standards, and verification that those interfaces conform.^{9, 10} The aim is for components to be added or replaced from different manufacturers across the life cycle, keeping competition alive. As the following sections show, this structural choice is less an engineering decision than an industrial and competition policy.

A sign that the policy was owned at the level of US military leadership is the 2019 tri-service memorandum, issued under the joint signature of the three services’ acquisition executives, which characterized the open-systems approach as a warfighting imperative.¹¹ The second pillar of the transformation is not national but NATO-level. The roots of this line reach back to the 1990s and the Aircraft Launcher Weapons Interface (ALWI) effort within the NATO Air Force Armaments Group (NAFAG), which pursued aircraft–munition interoperability; the United States turned this effort into UAI through work it launched in 2006, the United Kingdom into its own Weapons Integration UK (WIUK) approach, and Sweden into a SAAB-based bespoke solution.³ The common denominator of all these cases is two principles: the standardization of technical solutions, and the steering of the standard by the state. A defence system carries value not merely because it is internally coherent, but to the extent that it can talk to the rest of the alliance it belongs to; this is why NATO secures interoperability through common standards. Its most concrete expression is the ability of different countries’ unmanned systems to connect to a common control station from day zero.¹² The shared upshot of all this is that open architecture is at once a procurement reform, a competition policy, and an alliance requirement. Treated as a purely technical matter, it is only half understood.

3. The Family of Standards and the Question of Governance

Open architecture rests on two foundational insights worth dwelling on. The first is that it is not a single standard but a family of complementary standards. From the attachment of a munition to a platform, to the exchange of data among mission systems, to the portability of avionics software across different aircraft, to sensor and ground-vehicle integration, each layer has its own open standard. Because every one of these standards covers a different layer, none substitutes for another. On the contrary, brought together, they complement one another to form the whole of the system, so that a single platform can be simultaneously compliant with multiple standards across different layers. The common principle beneath them all is the decoupling of software from hardware. Once mission software is no longer embedded in particular hardware, the same capability becomes reusable across different platforms. For the decision-maker, the conclusion fits in a single sentence: the essence of open architecture lies less in the parts themselves than in bringing the interfaces through which the parts connect to a common standard.

The second and truly strategic insight is that the most important feature of these standards is not technical but a matter of ownership and governance. A significant share of them is developed through shared governance structures — neutral standards bodies and state-led working groups — that guarantee no single manufacturer can bring them under its own domination. The decisive question, therefore, is not which standard is technically best, but who owns and governs the standard. Whether a standard counts as open depends on the neutrality of the authority that governs it; otherwise, a new dependency can be erected beneath the rhetoric of openness. This question moves to the very centre of the Turkish context in Sections 6 and 7.

4. Ecosystem Warfare: Kill Web, Mosaic, and CJADC2

NATO’s Allied Joint Doctrine for Joint Targeting (AJP-3.9)¹³ frames the classic target-destruction loop as a connected, linear chain — the kill chain — whose steps of find, fix, track, target, engage, and assess follow one another in sequence. The structural weakness of this linear design is brittleness: the loss of a single node, or of the data link between two nodes, can render the entire chain inoperative. Adversary forces equipped with advanced anti-access/area-denial (A2/AD) capabilities, by targeting precisely these linear links, have turned that brittleness into an unacceptable risk.

The answer to this problem is to convert the linear chain into a network. In this structure — the kill web — a large number of sensors, decision nodes, and strike elements are linked through open interfaces, and each function becomes performable by more than one node. When a node drops out, the mission does not start over; the system reconfigures itself through another node able to provide the same function. Resilience rests not on the flawless operation of a single chain but on the availability of many alternative paths that can do the same job — network redundancy.¹⁴ The precondition for this structure is that different manufacturers’ systems be connectable through common, open interfaces. In a closed architecture, where each connection would demand a separate integration, such a network cannot be built in practice.

The doctrinal expression of this network logic is Mosaic Warfare,¹⁵ and its industrial counterpart is the concept of affordable mass.¹⁶ The mosaic approach distributes the find–decide–act functions across many small, varied, and inexpensive systems rather than concentrating them in a single costly platform. The distinction matters: what is distributed is not physical mass but function; the aim is not to build more platforms but to spread the same combat effect across many small elements able to operate independently of one another. Its current, concrete form is the low-cost, modular unmanned systems meant to operate alongside high-cost platforms; also known in the literature as loyal wingmen, these systems take shape, in the US context, in the Collaborative Combat Aircraft (CCA) programs.^{17, 18} These programs use open architecture as the precondition for rapidly integrating such inexpensive elements with costly platforms and with one another. From an industrial standpoint, being cheap and numerous carries meaning only with an open interface; otherwise, every new element becomes a separate integration project and the cost advantage of numbers erodes.

4.1. CJADC2: promise and limit

At the command-and-control level, the name for this vision is Combined Joint All-Domain Command and Control (CJADC2); the concept previously known as JADC2 was updated to underscore the allied dimension.¹⁹ The US Department of Defense announced in February 2024 that CJADC2 had reached a minimum viable capability threshold; in the same period, Open DAGIR — a state-owned, interoperable data-pool approach designed to counter closed systems dominated by a single contractor — came into play. A realistic reading, however, requires seeing the limits as well. In its 2025 assessment, the US Government Accountability Office (GAO) found that the services were running their projects largely disconnected from one another and without common, measurable objectives, and that an overarching framework to hold them all together had still not been established.²⁰ The lesson cuts both ways: ecosystem warfare is an inescapable direction, yet even the most powerful actor building it wrestles with projects advancing in scattered fashion rather than under a common roof. This lesson is especially important for Türkiye, which stands at the very start of the road. Unless the transformation is governed from the outset by a common framework, the cost of scattered progress is paid later — and, as in the US case, far more heavily. Open architecture is not an automatic recipe for success but a demanding program that must be governed correctly.

5. The Industrial and Economic Architecture

Open architecture is an economic order that reshapes the structure of industry, firms’ business models, and the balance of power between the state and industry. This section treats the subject conceptually in that dimension; the corresponding concrete action items are given in Section 7 as part of the roadmap. The order’s first effect is the breaking of vendor lock-in. Under a closed architecture the state depends, at every update, on the original prime contractor, and this dependence hands the contractor a bargaining advantage on price and schedule. Once the interface is defined by an open standard, the module leaves the monopoly of a single manufacturer and different firms can offer competing solutions that fit the same interface; competition descends from the platform level to the module level, and the monopoly pressure on price and innovation dissolves.²¹

The direct winners of this structure are the mid-sized manufacturers and SMEs that cannot build the whole platform but specialize in a particular module. BAE Systems, one of the sector’s leading actors, stresses in its corporate publication on the subject that the modularity at MOSA’s core lets specialized companies offer solutions for particular modules rather than being shut out for not developing the whole vehicle or platform.²² The prime contractor evolves from an authority that holds the whole under its sole domination into an ecosystem integrator that binds modules together through open interfaces. Even so, the transformation has a price, and it would be unrealistic to ignore it. Open architecture disrupts existing business models and, in the short term, is a source of commercial resistance for prime contractors. The field assessment by the US Center for Strategic and International Studies (CSIS) shows that the incentives to move to MOSA are often weak at the level of the individual program, and that success requires solving a coordination problem.²³ For this reason the transformation does not happen on its own; it happens only when the state steers it through procurement policy.

The most critical and least understood dimension is intellectual property and technical data rights. What is open is only the interface; the proprietary technology inside the module is not. The state’s holding the interface definition and test data makes competition possible, while the manufacturer’s protecting its rights inside the module encourages innovation. The US Department of Defense’s Intellectual Property Guidebook for acquisition is aimed precisely at striking this balance.²⁴ When the balance is struck wrongly, a two-way risk arises: if the interface is not opened enough, the lock returns; if the inside of the module is opened more than necessary, the manufacturer loses its innovation advantage. Technical data rights are therefore the real arena of debate and regulation in open architecture. The ultimate question bearing on this is governance: if the standard is owned by the state or by shared governance, the ecosystem stays open to competition; if it is effectively in the hands of a single prime contractor, a new lock forms beneath the rhetoric of open architecture. This question, as detailed below, is an increasingly sharp problem for Türkiye. In an industry concentrated around a few large contractors, unless ownership of the interface standards is clearly bound to the public, the risk of a national monopoly can quietly grow. If this structure is not built deliberately, a rising domestic-content ratio can, instead of reducing inter-system dependence, turn into a new lock that ties the state to a handful of prime contractors.

That implementation is not easy is settled in the institutional record. The GAO’s 2025 MOSA assessment²⁵ found that, although the approach lowers long-term sustainment and modernization costs, programs often cite the short-term additional design cost as an obstacle, and that the Department of Defense does not systematically analyse whether this short-term cost is outweighed by the long-term benefit. Fourteen of the twenty programs examined had implemented MOSA to some degree, the rest cited cost and time barriers, and the GAO offered fourteen recommendations for improvement. In sum, open architecture is as much an industrial order built on ownership, competition, and law as it is a design decision. Without that order being built and governed, open interfaces alone secure no lasting gain.

6. Türkiye: From Platform Autonomy to System Architecture

Türkiye’s orientation toward a domestic and national defence industry is the product of an institutional choice grounded in the Principles of Turkish Defense Industry Policy and Strategy (TSSPSE), brought into force by Council of Ministers Decision No. 98/11173 of 25 May 1998.²⁶ In the period that followed, this orientation turned into a marked autonomy at the platform level. According to data from the Presidency of Defence Industries (SSB), the domestic-content ratio in the defence industry, around 20 percent in 2002, reached 83 percent in 2024, while defence and aerospace exports climbed to a historic level of roughly 7.1 billion dollars in 2024.^{27, 28} The sector today is a broad ecosystem of more than 3,500 firms, over a thousand active projects, and roughly 100,000 skilled jobs. This transformation has become visible in concrete platforms: among air platforms, TUSAŞ’s HÜRKUŞ and HÜRJET trainer/combat aircraft, the ANKA and AKSUNGUR unmanned aerial vehicles, the GÖKBEY helicopter, and the national combat aircraft KAAN; Baykar’s Bayraktar TB2, AKINCI, and KIZILELMA systems; and, among land and naval platforms, the ALTAY tank and the MİLGEM-class ships are the foremost examples.²⁹ The backbone of the ecosystem is formed by SSB’s strategic planning, the affiliate structure of the Turkish Armed Forces Foundation (TSKGV), industrial clusters such as SAHA İstanbul and OSSA, and sectoral platforms such as the biennial IDEF International Defense Industry Fair; the international export interest in KAAN, in turn, marks the international counterpart of the scale that has been reached.

Türkiye’s roots in this field are not new and rest on a noteworthy milestone. Türkiye first acquired the capability to perform aircraft–munition integration nationally within the Air Force Command’s 1st Air Supply and Maintenance Center Command (1. HİBMK); at the same time, it took an active part in the NATO UAI (NUAI) efforts that developed the US UAI interface within NATO. In the demonstration project under these efforts, an MK-84 munition fitted with the national Precision Guidance Kit (HGK) was integrated onto a US F-16 Block 40 aircraft using the UAI interface, and the test drop of September 2013 was completed successfully. The HGK thereby entered the record as the first non-US allied system integrated with UAI; moreover, the fact that the external-store certification tests were conducted by 1.HİBMK in accordance with MIL-HDBK-1763 and accepted directly by the US Air Force certification authority demonstrated that an internationally recognized competence had taken shape.³ This experience showed concretely that a standardized interface makes integration possible in less time and at lower cost.

The real significance of this capability becomes clear in its implications for the future. Türkiye has, in parallel, developed a large number of national platforms and national munitions. Pairing every platform with every munition, however, requires a separate integration project, budget, and effort. When platforms such as KAAN, HÜRJET, HÜRKUŞ, ATAK, ANKA, AKINCI, AKSUNGUR, and TB2 are considered together with munitions such as the SOM family, BOZDOĞAN and GÖKDOĞAN, the HGK and KGK guidance kits, TEBER, MAM-L and MAM-C, CİRİT, and UMTAS, the number of integration pairings to be completed grows rapidly — from which it follows that the total integration budget required in the future will be far higher than today’s.³ The platform–munition pairings named here are given for illustration, to convey the scale of the likely integration need rather than any definite project plan. This combination of loads makes concrete why a standards-and-governance layer that would lower the cost and time of integration is not a single technical preference but a structural necessity.

Alongside this success at the platform level, the next frontier is the system-of-systems and open-architecture layer. The following assessment should be qualified as interpretation, since it rests not on a single public document but on a general observation of the sector’s structure: Türkiye’s platforms have largely been developed on a logic in which each is successful in itself but connecting them to one another mostly requires separate integration efforts. A manufacturer-independent national open-interface standard and reference architecture, owned by the state or by shared governance, has not yet been fully institutionalized.

A dimension of this picture that often goes unnoticed is the set of common rules and processes by which the manufacturer base beneath the prime contractors operates. Large contractors such as TUSAŞ, ASELSAN, ROKETSAN, HAVELSAN, and TEI produce within mature systems-engineering processes and staged design reviews (for example, the Preliminary Design Review — PDR — and the Critical Design Review — CDR). But the common interface standards and the design and verification discipline by which the many mid-sized and small manufacturers outside these corporate structures — those supplying modules and subsystems to the ecosystem — produce have not been defined nationally from a single hand. This structure, in which each prime contractor imposes its own requirements on its own supply chain, limits the reusability of modules within an ecosystem and their portability from one contractor to another. Establishing open architecture at the national level requires not only interoperability among prime contractors but also binding this broad sub-manufacturer base to a common standards-and-process framework.

The finding that emerges is directional. Türkiye has largely secured originality in platform production, but it has not yet built the open-interface and standards-governance layer that would unite these platforms in a single combat ecosystem. This leaves Türkiye facing, in the period ahead, a defining choice that points, broadly, to two roads. On the first, each platform and each contractor continue to be optimized in isolation; every inter-system connection remains a separate integration project, and the rise in the domestic-content ratio finds no matching rise at the level of interoperability. On the second, a state-owned open-architecture and standards-governance layer is built; platforms are designed from the outset to be connectable to one another, and industry evolves from a structure that turns out standalone products into an ecosystem whose elements talk to one another. The later this choice is made, the higher the cost of bringing already-built platforms into compliance after the fact will climb. 

7. Strategic Roadmap and Recommendations

The items below are recommendations derived from the findings of the previous sections; they are ordered with institutional ownership and feasibility in mind.

7.1. A national open-architecture standard and a governance board

For munitions, mission systems, sensors, and command and control, a manufacturer-independent national open-interface standard family — compatible with NATO and allied standards (MIL-STD-1760, STANAG 4586, and the like) — should be defined.^{12, 30} What is decisive here, ahead of technical content, is ownership. In the United States, standards governance is shared between state-led working groups and neutral bodies such as The Open Group and SAE (the Society of Automotive Engineers);³¹ in NATO, standardization is carried out through the NATO Standardization Office (NSO). The counterpart in Türkiye should be a high-level governance board that leaves ownership of the standard to no single prime contractor — led by SSB, with MSB, the force commands, prime contractors, universities, and industrial clusters represented. This board should gather in a single hand the authority to define the standard, exercise configuration control (version management), certify conformance, and resolve disputes, and should guarantee that the standard is governed as a public asset. Indeed, some experts in the field likewise assess that, for the existing national integration capability to be used correctly and efficiently, a top-level Stores and Munitions Interface authority should be established under SSB leadership — a body that standardizes technical solutions, steers platform, munition, and mission-planning-software manufacturers toward conforming to that standard, and ensures continuity in the governance of the standards.³

7.2. A mandatory open interface in procurement

As in the MOSA example, the use of open, verifiable interfaces should be made a contractual condition in procurement programs above a certain scale. Contracts should require that the conformance of main system interfaces to agreed standards be proven through test and verification and should guarantee competition and module replaceability across the life cycle. Without this condition, openness is left to each program’s own discretion and is not applied in practice. As each new system is delivered with closed interfaces, the cost and technical difficulty of connecting the national ecosystem together after the fact rise further with every procurement cycle. In other words, not setting the rule today returns as a far more expensive redesign burden tomorrow.

7.3. Reference architecture, certification, and test infrastructure

So that the standard does not remain on paper, a reference architecture against which conformance can be measured, together with an independent certification and test infrastructure, should be established. Common test environments in which a module can prove its interface conformance both ease the entry of mid-sized manufacturers into the ecosystem and lower integration time and cost. UAI’s certification tools and the conformance program of FACE (the Future Airborne Capability Environment) are examples worth examining in this regard.^{31, 32, 33}

In step with the establishment of the test and certification infrastructure, the discipline of configuration management (CM) should also be defined as a binding requirement. COTS components and equivalent software packages procured from different sources can produce an unmanageable configuration tangle when up-to-date records tracking which hardware and software version sits on which platform are not kept. Setting up a System Integration Laboratory (SIL) for each main platform and verifying every change at the LRU/SRU level through regression testing in that environment, is the precondition for safely applying the module replaceability that open architecture envisages.

7.4. An intellectual property and technical data rights policy

A balanced technical data rights policy should be established — one that guarantees the state’s holding of the interface definition and test data while protecting the manufacturer’s rights to the proprietary technology inside the module. The US Intellectual Property Guidebook for acquisition is a reference worth examining for how this balance is framed.²⁴ A correctly struck balance makes both competition and innovation possible at once.

7.5. Activating the industrial dimension

The industrial dimension treated conceptually in Section 5 should be turned into concrete action items. Through procurement rules that open competition at the module level, mid-sized manufacturers and SMEs should be brought into the position of direct module suppliers; the role of prime contractors should be steered, through incentive mechanisms, toward ecosystem integration; and it should be accepted from the outset that this transformation will generate short-term commercial resistance. Industrial clusters and universities should be drawn into the joint development of the standard and the reference architecture, securing broad-based ownership.

7.6. Dual-use technologies and critical technology areas

At the same time, the feasibility of this approach in a market of Türkiye’s scale depends on a procurement volume and a stable budget flow sufficient to sustain the ecosystem. The rigor of interface standards raises the question of whether small-scale suppliers have the capacity to meet them. Standard design should therefore provide for graduated conformance options that encourage SME participation.

The scope of open architecture should not be confined to classic weapon systems alone but should be designed to cover dual-use technologies and critical technology areas. In fields such as artificial intelligence, autonomy, advanced sensors and communications, and cyber and space capabilities, the pace of progress is set by the civilian commercial ecosystem; that pace can be matched only through open interfaces — an architecture in which commercial off-the-shelf (COTS) components and civilian innovation can be safely connected to defence systems. The national standard should provide for interfaces through which civilian industry and technology ventures in these fields can contribute to the ecosystem, and for critical technologies it should additionally regulate the balance between openness and security through technical data rights and access layers. A dual-use approach both brings the civilian technology base into defence and lets defence investment spread into the civilian economy.

7.7. NATO/export compatibility and entry into allied ecosystems

The national standard should be kept compatible with allied standards in order to safeguard exportability. As a forward-looking assessment, open architecture is not merely a domestic efficiency tool but a ticket of entry into allied co-development ecosystems. CSIS’s 2025–2026 analyses assess that MOSA will be the main gateway for international partnerships in programs such as CCA, and that partner countries, by contributing to the standard, can open the way toward a global standard.^{16, 23} For Türkiye, this means that designing national systems to be open and compatible with allied standards can support both exportability and participation in high-technology joint programs. On timing, if the open-architecture layer is framed before the next generation of platforms reaches design maturity, the high cost of adding it after the fact is avoided.

8. Conclusion

Défense’s centre of gravity has shifted from the quality of the individual platform to the flexibility and resilience of the ecosystem that platforms form. The technical backbone of this shift is open architecture; its doctrinal expression is Mosaic Warfare and the kill web; its name at the command-and-control level is CJADC2; and its appearance at the industrial level is affordable mass. The truly decisive layer of the transformation, however, is the industrial and legal one that often goes unnoticed — who owns the interface, whether competition is made possible at the module level, and how technical data rights are balanced.

Türkiye has largely secured platform autonomy; the threshold before it is to build, manufacturer-independent and in public ownership, the open-architecture and standards-governance layer that will turn these platforms into an ecosystem. The US experience shows this road to be both inescapable and hard to govern, even the most powerful actor wrestles with the scattered progress of projects and with short-term cost barriers. For Türkiye, therefore, the opportunity lies in framing the transformation early and with correct governance, before the next generation of platforms matures. The next competitive edge should be sought not in better platforms but in a better-governed and more open ecosystem.

Author: Retired Air Force Major General Ateş Mehmet İrez

Appendix A. Glossary

UAI (Universal Armament Interface). An integration standard developed by the US Air Force that sits atop the MIL-STD-1760 electrical interface. Its core function is to bring the communication between a munition and the aircraft carrying it to a common, defined message language. Before UAI, dedicated code had to be written into the aircraft’s mission software for each munition type; with UAI, different munitions conforming to the same interface can be integrated through a defined configuration without reopening the aircraft’s software. Integration thus turns from an engineering project conceived from scratch each time into a standard operation.

MIL-STD-1760 and its family (AS5653, AS6003). The US military standard that defines the electrical connection and data-bus interface between aircraft and munition; UAI is built on this physical/electrical foundation. Extensions such as AS5653 (a high-speed network) and AS6003 (a time-triggered protocol) carry this interface family to higher data rates and deterministic communication.^{34, 35} In short, these standards define how the connection is physically made and how the signal flows.

MOSA (Modular Open Systems Approach). An integrated business and engineering strategy that calls for defence systems to be designed from replaceable modules with interfaces defined by open, agreed standards. Its aim is to let a system’s components be added or replaced from different manufacturers over its life, sustaining competition. In the United States it is a legal requirement for major procurement programs (Title 10; FY2017 NDAA Section 805 and subsequent provisions). MOSA is not a technology but a rule about how procurement and design are to be done.

OMS/UCI (Open Mission Systems / Universal Command and Control Interface). Open standards that let a platform’s mission systems (sensors, receivers, weapons management, and the like) speak with one another and with external systems through a common data language. Where UAI connects the munition to the aircraft, OMS/UCI standardizes the flow of information within and among aircraft. It makes it possible to develop software without it remaining tied to particular hardware.

FACE (Future Airborne Capability Environment). An open software standard aimed at making avionics software components reusable across different programs without being locked to a particular aircraft or hardware. It is jointly governed by government and industry within The Open Group. By letting a capability developed once be carried to different platforms, it lowers cost and development time.

SOSA (Sensor Open Systems Architecture). The standard that defines the design of sensors and the embedded hardware that runs them (at the card, processor, and chassis level) in an open, replaceable architecture. It is the hardware-level counterpart of MOSA logic, allowing an aging sensor or card to be replaced with a new one without redesigning the whole system.³⁶

VICTORY. The open framework that lets the reconnaissance-surveillance, command-and-control, and electronic-warfare systems on land vehicles be integrated through a common architecture rather than one by one. It aims for each new system to connect to a shared infrastructure instead of being bolted onto the vehicle as a separate cable and box.

STANAG 4586. The standard that provides interoperability among the control systems of unmanned aerial vehicles within NATO. It is the basis on which different countries’ unmanned systems can connect to a common ground control station from day zero; it is a precondition for agility in coalition operations.

OFP (Operational Flight Program). The main mission software that manages an aircraft’s flight and mission functions. In a closed architecture it is the bottleneck of integration, because every new munition or capability requires this software to be extensively rewritten, tested, and certified.

Decoupling (separating software from hardware). The principle of removing mission software from being embedded in particular hardware. Through interposed abstraction and middleware, the software need not be rewritten when the hardware changes; the same software can run on different platforms. It is the technical foundation beneath open architecture.

MDO (Multi-Domain Operations). An operational approach based on using the land, air, sea, space, and cyber domains not separately but simultaneously and in integrated fashion. It calls for an effect in one domain to be produced in coordination with the others.

CJADC2 (Combined Joint All-Domain Command and Control). A US command-and-control concept aimed at accelerating decision-making by fusing data from all combat domains and from allied forces. The “combined” (allied) dimension was added to the concept previously known as JADC2. The United States announced in 2024 that a minimum viable capability level had been reached. In short, it is the realization of the kill web at the command-and-control level.

Open DAGIR. A state-owned, open and interoperable data/integration-pool approach designed in the United States to keep command-and-control data from being locked into the closed system of a single prime contractor. By keeping the standard in public hands, it aims to preserve competition.

Kill Chain and Kill Web. The kill chain is the linear chain of steps from a target’s detection to its destruction; the breaking of a single link can halt the whole process. The kill web is the network structure that distributes the same functions across many sensor, decision, and strike nodes and links them through open interfaces. When a node drops out, another node able to do the same job steps in; resilience rests not on a single chain but on the multiplicity of alternatives.

Mosaic Warfare. A concept developed by DARPA that calls for distributing combat functions across many small, inexpensive elements able to operate independently of one another, rather than concentrating them in a single costly platform. Its name alludes to small pieces coming together to form a flexible whole; the aim is to amass not physical mass but distributed combat effect.

Affordable Mass and CCA. An approach to gaining numerical and operational depth by adding low-cost, modular unmanned systems alongside expensive, few-in-number platforms. Its concrete counterpart in the United States is the Collaborative Combat Aircraft (CCA) programs; these systems are also known in the literature as loyal wingmen. The original rendering used by the Turkish Air Force in the early period was “Otonom Kol Uçucusu (OKU).”

Vendor lock-in. The situation in a closed architecture in which the system’s owner remains dependent on the system’s original manufacturer for every update, maintenance, and capability enhancement. Because it eliminates competition, it raises prices and slows innovation; it is the core problem open architecture seeks to break.

Technical data rights. The framework regulating how information and usage rights concerning a system’s interface definition, test data, and internal design are shared between the state and the manufacturer. It is the real arena of negotiation in open architecture: the state’s holding the interface information opens competition, while the manufacturer’s protecting its rights to the design inside the module encourages innovation. Striking the balance correctly is decisive.

COTS (Commercial Off-The-Shelf). A commercial component or product bought ready-made from the market rather than developed specially. By letting an aging module be quickly replaced with a new-generation commercial product, open architecture enables defence systems to keep pace with the fast commercial technology cycle.

Dual-use. Technology usable for both civilian and military purposes (such as artificial intelligence, autonomy, and advanced communications). Open architecture is the main channel for safely connecting civilian innovation in these fields to defence systems; it carries critical importance in areas where the civilian ecosystem largely sets the pace of progress.

PDR / CDR (Preliminary and Critical Design Reviews). Formal control points in systems engineering that audit a design’s maturity in stages. The Preliminary Design Review (PDR) is the stage at which the conceptual design is verified; the Critical Design Review (CDR) is the stage at which the production-ready detailed design is verified. All manufacturers in an ecosystem adhering to these common disciplines is the precondition for modules being mutually compatible and reliable.

Author: Retired Air Force Major General Ateş Mehmet İrez

Appendix B. Bibliography

1.      RAND Corporation. Assessing Aegis Program Transition to an Open Architecture.

2.      SAE International (2024). Modernizing Legacy Defense Systems to be Compliant with Open Architecture Standards. Technical Paper 2024-01-3894.

3.      Dereli, O. S., & Kuşku, N. (2020). “Farklı Mühimmatın Cankurtaranı: Milli Arayüz.” C4Defence, Issue 89.

4.      UK Ministry of Defence (2018). The Defence Equipment Plan 2018 — Financial Summary (Storm Shadow/Typhoon integration cost estimate).

5.      Rigby, K. A. (2013). Aircraft Systems Integration of Air-Launched Weapons. John Wiley & Sons (esp. Chapter 13, “The Universal Armament Interface,” and cost breakdown, p. 230).

6.      Air Force Institute of Technology (AFIT). A Case for Open Mission Systems in DOD Aircraft Avionics (master’s thesis). AFIT Scholar.

7.      Air Force Institute of Technology (AFIT). An Analysis of a Modular Open System Approach on Program Management Metrics for Cost and Schedule (master’s thesis). AFIT Scholar.

8.      U.S. Code. Title 10 U.S.C. §§ 2446a–2446c and 4401 (FY2017 NDAA, Section 805; FY2021 NDAA expansion).

9.      U.S. Navy, Naval Air Systems Command (NAVAIR). Naval Modular Open Systems Approach Guidebook. navair.navy.mil.

10.  U.S. Department of Defense, Office of the Under Secretary of Defense for Research and Engineering (OUSD R&E) (2025). Implementing a Modular Open Systems Approach in DoD Programs — MOSA Implementation Guidebook. cto.mil.

11.  U.S. Departments of the Air Force, Army, and Navy (2019). Modular Open Systems Approaches for our Weapon Systems is a Warfighting Imperative (Tri-Services Memorandum).

12.  NATO Standardization Office (NSO). STANAG 4586 — Standard Interfaces of UAV Control System (UCS) for NATO UAV Interoperability.

13.  NATO Standardization Office (NSO). AJP-3, Allied Joint Doctrine for the Conduct of Operations, current edition (Ed. D, 2025); STANAG 2490.

14.  RAND Corporation (2021). Distributed Kill Chains: Drawing Insights for Mosaic Warfare. RR-A573-1.

15.  Defense Advanced Research Projects Agency (DARPA). Mosaic Warfare. darpa.mil.

16.  Center for Strategic and International Studies (CSIS); Sanders, G., & Aldisert, A. (2025). Burden Sharing via Modular Open Systems Approaches: A Collaborative Path to Affordable Mass. csis.org.

17.  Defense.info (2026). An Update on Collaborative Combat Aircraft: January 2026.

18.  Institute for Defense & Government Advancement (IDGA). One Year On: How the Armed Forces’ CCA Programs Have Matured.

19.  RAND Corporation. Universal Command and Control Language Early System Engineering.

20.  U.S. Government Accountability Office (GAO) (2025). Defense Command and Control: Further Progress Hinges on Establishing a Comprehensive Framework. GAO-25-106454.

21.  RAND Corporation. Competition and Innovation Under Complexity.

22.  BAE Systems. What is MOSA? (corporate technical explainer). baesystems.com.

23.  Center for Strategic and International Studies (CSIS) (2026). Readiness for Open Systems: How Prepared Are the Pentagon and the Defense Industry to Coordinate? csis.org.

24.  U.S. Department of Defense. Intellectual Property Guidebook for DoD Acquisition. acq.osd.mil.

25.  U.S. Government Accountability Office (GAO) (2025). Weapon Systems Acquisition: DOD Needs Better Planning to Attain Benefits of Modular Open Systems. GAO-25-106931.

26.  Principles of Turkish Defense Industry Policy and Strategy (TSSPSE). Policy document brought into force by Council of Ministers Decision No. 98/11173 of 25 May 1998.

27.  Presidency of Defence Industries (SSB). Sector statistics and strategic plan: domestic-content ratio (2002–2024) and defense–aerospace export data (2024).

28.  Turkish Exporters Assembly (TİM). Defense and aerospace sector export statistics (2024–2025).

29.  Turkish Aerospace Industries (TUSAŞ) and Baykar. Platform fact sheets and technical data sheets (HÜRKUŞ, HÜRJET, ANKA, AKSUNGUR, GÖKBEY, KAAN; Bayraktar TB2, AKINCI, KIZILELMA).

30.  NATO. MIL-STD-1760-compatible allied interface standards and Federated Mission Networking documents.

31.  The Open Group. FACE Technical Standard and FACE Conformance Program Overview. opengroup.org.

32.  U.S. Government Procurement System. Universal Armament Interface (UAI) — Request for Information. SAM.gov.

33.  Curtiss-Wright Defense Solutions. Future Airborne Capability Environment (FACE) — Technical Overview.

34.  SAE International. AS5653 — High Speed Network for MIL-STD-1760.

35.  SAE International. AS6003 — Deterministic Time-Triggered Protocol (TTP) Databus Standard.

36.  The Open Group, SOSA Consortium. Sensor Open Systems Architecture (SOSA) Technical Standard. opengroup.org.