An Open Architecture Should Survive a Change of Supplier

The best time to discuss changing suppliers is while everyone still likes each other.

At that point, the development team is available. The business relationship is healthy. People remember why the interfaces work the way they do. There is still an opportunity to agree on what the customer will need to operate, maintain, and extend the system without turning a future transition into an archaeological expedition.

That is when I want to ask a concrete question about an open architecture: could another qualified supplier take responsibility for a defined part of this system, using the information and permissions the customer will actually have?

If we cannot give a credible answer, “open” is doing too much work in the presentation. The customer needs an independently usable standard and a credible path to another supplier. Permission granted at the incumbent’s discretion is a poor foundation for either.

A supplier change does not require misconduct. A product reaches end of life. A business is acquired. A company changes its priorities. The application outlives the team that built it. Sometimes the customer simply needs a capability the original supplier is no longer the best organization to provide.

An architecture intended for a long service life should take those possibilities seriously. The original commercial relationship is a condition under which the system was developed. It should not automatically become a permanent operating requirement.

The Department of Defense’s February 2025 MOSA implementation guide treats modular openness as an integrated technical and business concern. Its discussion connects architecture and interfaces with acquisition planning, intellectual property rights, and sustainment. It also calls for evidence that the intended modularity and openness have been achieved. [1] That framing matters well beyond defense acquisition: a technically accessible interface can still be commercially unusable, and a generous license cannot compensate for an interface nobody has adequately specified.

Several different ideas tend to get compressed into the word “open.” A modular product has some division into components. A published interface describes how something connects. Open-source software makes source available under particular license terms. Interoperability concerns whether implementations can work together. These properties can support one another, but none, by itself, establishes that a customer can substitute a supplier in the application that matters.

For the key interfaces in a long-lived system sold as an open architecture, I expect standards developed or formally adopted and maintained by an internationally recognized, vendor-neutral standards organization or industry-wide consortium. Competing suppliers and customers should have a meaningful place in its governance, with government participation where the application calls for it. The process should provide a way to challenge decisions, resolve disagreements, and manage revisions without leaving one company in control of the rules.

A company’s internal standard can coordinate its own products. It does not establish an open industry standard. If the company retains exclusive control of the key interfaces and withholds the specifications or supporting work products needed for independent implementation, the architecture fails the openness test. It may be modular and competently engineered, but the customer still depends on that company’s discretionary permission to obtain an alternative.

This expectation has a basis in established standards practice. ITU-T’s definition connects open standards with public availability, collaborative consensus, balanced participation, and sufficient detail to support competing implementations. [2] The OpenStand principles, affirmed by leaders of IEEE-SA, the IAB, the IETF, the Internet Society, and W3C, similarly call for transparent processes, broad agreement, and protection against domination by one company or interest group. [3]

Public availability needs to be practical. An independent supplier should be able to obtain the specification, freely or by purchase at a reasonable price, and obtain the rights needed to implement and commercially offer a conforming product on reasonable, nondiscriminatory terms. ITU-T expressly accommodates reasonable charges and implementation licensing. [2] I am asking for public availability and independent implementation rights. A standard can retain copyright protection, as ISO publications do, without having public-domain status. [4] The question is whether the information and permissions needed to compete are accessible, without a selective veto from the incumbent.

The place where an idea originated does not settle this question. A company can develop a useful technology and contribute it to a recognized standards body for adoption and continuing governance. What must change is the exclusive control. Posting a document on a website while retaining unilateral authority over its essential terms and evolution does not provide the same independence.

The SOSA Consortium illustrates the kind of arrangement I mean. The Open Group describes an effort in which government participants and industry members reach consensus on a technical standard serving both defense and commercial sensing applications. [5] That provides a concrete model for bringing customers and competing suppliers into the work. Each implementation still has to demonstrate that it meets the applicable requirements.

I also want a credible route from the standard to commercially available alternatives. Independent implementations give customers something they can evaluate and purchase. A new standard may need time to develop that market, but the delivery plan should acknowledge the gap. A consortium’s name on a document is not a substitute for evidence that another supplier can enter the market and deliver a usable product.

Take a hypothetical controller that exchanges data over CAN. Seeing valid frames on the bus tells us something useful. It does not tell us whether a replacement controller will interpret the system correctly. We still need to know what the values mean, their units and scaling, when they become valid, how stale information is detected, and what happens during startup, reset, or loss of communication.

Suppose one device treats a missing message as a request to hold its last command, while another treats it as a fault requiring a different operating state. Both may communicate perfectly well at the transport level. The disagreement is in the behavior, and that is where the application lives.

An interface specification therefore needs to describe the agreement between components with enough precision to support an independent implementation. Depending on the interface, that can include timing, sequencing, resource limits, failure behavior, version compatibility, and physical constraints. A list of function signatures or message identifiers may be part of the answer. It is rarely the whole answer.

Standards help by establishing common agreements, but extensions and implementation choices still need attention. The Internet Architecture Board’s RFC 6709 discusses how protocol extensions can introduce interoperability, operational, and security problems, including changes that leave the on-wire format untouched. [6] The implication for a product team is practical: record which version and options you use, identify extensions, and test the combinations the product actually requires.

A system can use a recognized transport standard and still conceal the application interface behind proprietary message definitions, file formats, or mandatory extensions. If the information required to implement the replacement remains unavailable, the dependency remains too. Openness has to hold at the boundary where substitution is promised. An open lower layer does not make an inaccessible upper layer open.

“Uses a standard” is the beginning of that conversation.

The next question concerns what the customer can do with the information. Could the customer give the relevant specification to a replacement supplier? Could that supplier implement the interface? Could a new maintainer rebuild and deploy software that the customer is entitled to modify? Will required development tools remain obtainable? Who can authorize a replacement device to join the system?

These are different questions, and they deserve explicit answers. Source code without the necessary build inputs may be insufficient for maintenance. A documented device interface may be sufficient for replacement without access to the original device’s internal source. The right delivery package depends on the responsibility the customer expects to retain.

That distinction also protects legitimate supplier interests. Customer independence does not require indiscriminate disclosure of every proprietary design. A supplier may have developed valuable algorithms, manufacturing methods, or reusable technology at its own expense. The MOSA guide explicitly recognizes the need to protect private investment while obtaining the interface information and rights needed for the intended flexibility. [1]

I want the business agreement to reflect a sensible boundary: the supplier can retain its valuable implementation, while the customer can exercise the operational and replacement rights it has paid for. Where broader rights are needed, those rights and their price should be discussed while the relationship is being defined.

There is a strong objection to all this. Customers often choose an integrated supplier because they want one organization accountable for the result. Requiring several interchangeable suppliers can create integration costs, disputes over responsibility, and a system nobody fully owns.

I agree with the concern. An open architecture still needs a responsible system integrator. It needs configuration control, a coherent verification strategy, and someone with the authority to reject a component that undermines the system. Opening a boundary does not distribute away that responsibility.

Nor does replaceability mean an arbitrary part can be plugged into safety-relevant equipment without further analysis. A substitute may require new integration testing, timing measurements, fault testing, or changes to the assurance evidence. The goal is to make the scope of that work understandable and manageable. Promising a cost-free transition would be misleading.

There is also an economic limit. Maintaining two fully qualified suppliers for every component can be wasteful. A customer may reasonably choose a single source after evaluating the exposure. The architecture should make that a visible choice, with an account of what would be required to change it. A deliberate dependency is easier to manage than a dependency discovered during an emergency.

For an important boundary, I would like to see at least a modest demonstration of independence before the original team disperses. Give someone who did not develop the interface the delivered specification and the authorized tools. Ask that person to build a small independent client, exercise the required behaviors, or perform a representative maintenance task. Record where undocumented knowledge is still necessary.

That exercise will not prove that every future supplier transition is easy. It can expose a much more immediate problem: the promised handoff may depend on information that exists only in the current team’s memory.

The test should match the claim. If we promise data portability, demonstrate that exported data can be interpreted elsewhere with its meaning intact. If we promise independent maintenance, demonstrate the relevant build and deployment path. If we promise component replacement, define what may change and what the rest of the system is entitled to rely on. Identify the standards body, the applicable specification and version, and the terms under which a competing supplier can obtain and implement it. Make the extensions visible. Then demonstrate the promised behavior. A supplier’s declaration of openness is not that evidence.

A supplier can still be the obvious choice afterward. It may understand the application better, respond more quickly, or offer the best implementation at a fair price. Those are excellent reasons to continue a relationship. I would want my own business to earn repeat work on that basis.

An open architecture gives that choice substance. Its most convincing evidence may be a transition the customer never needs to make, because the original supplier keeps doing a good job. But if the day comes, the customer should have a usable specification, the necessary rights, and a credible way to engage another qualified provider.

If exercising the promised openness still requires the incumbent’s discretionary permission, the customer has not received the independence being advertised. A company’s internal standard can organize its own products. An open industry standard must give other companies a fair opportunity to compete.

Sources

1. Office of the Under Secretary of Defense for Research and Engineering, Implementing a Modular Open Systems Approach in Department of Defense Programs (February 2025). Official guide. See §§1.1 and 3.1; Appendix C, “Intellectual Property Rights,” printed p. 38; and Appendix D, conformance criteria and verification, printed pp. 54–56. This article draws on the guide’s engineering and business principles, rather than making claims about current procurement-law requirements. 2. International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), “Definition of Open Standards,” endorsed by the Telecommunication Standardization Advisory Group on November 11, 2005. Official definition. See the criteria for collaborative governance, balance, implementation rights, sufficient detail for competing implementations, and public availability at a reasonable price. 3. R. Housley et al., Affirmation of the Modern Paradigm for Standards, RFC 6852, Internet Architecture Board (January 2013). Official text. Section 2 records the OpenStand principles, including due process, balance, openness, and availability on fair terms. This is an informational statement of principles. 4. International Organization for Standardization (ISO), “Copyright.” Official policy. ISO publications retain copyright protection; availability of a standard should not be confused with public-domain status. 5. The Open Group, “SOSA Consortium Frequently Asked Questions.” Official FAQ. Describes the consortium’s consensus-based structure and government-industry collaboration for military and commercial sensor systems. 6. B. Carpenter, B. Aboba, and S. Cheshire, Design Considerations for Protocol Extensions, RFC 6709, Internet Architecture Board (September 2012). Official text. See §§1, 2.1, 3.2, and 3.5. RFC 6709 is an informational architectural guidance document, not an Internet Standards Track specification.