A product needs room to change

A complex machine may remain in use while its computers, software and sensors move through several generations. An architecture that separates components and defines their connections can make some changes easier to manage. The aim is to let an organization improve part of a product without treating every upgrade as a complete redesign. That is the lifecycle promise behind a modular open systems approach.

In its January 2025 review, GAO described potential benefits for maintenance, upgrades and competition. It also found a planning gap: none of the 20 programs examined had formally analyzed the approach's costs and benefits. Some programs cited the additional time and expense of design work. The report is a useful reminder that future flexibility can require decisions and investment before an immediate benefit appears.

Access matters alongside the interface

Consider a hypothetical replaceable computing module. Knowing where it connects is useful, but a future maintainer also needs sufficient information and permission to perform the intended work. Physical interchangeability alone does not settle who can repair, inspect or modify the surrounding system. For readers, the practical question is which future activities the customer can actually support.

GAO examined the information problem separately in its 2025 sustainment review. It reported that gaps in technical data and data rights had left selected programs dependent on single suppliers, with potential effects on repair schedules and costs. It also explained that obtaining more rights than necessary can be costly. The lesson is specific planning for expected support needs, rather than assuming that either complete openness or complete ownership is always required.

Look for a demonstrated change

Our preferred reporting question is concrete: what change has the architecture made possible? A documented replacement or upgrade can be more informative than a diagram of neatly separated boxes. We would want to understand the scope of that change, the work still required and any limitations disclosed. One successful integration would establish a useful example, not universal compatibility with every future supplier.

We would also distinguish the hardware design from the business arrangements supporting it. GAO's reports address related but separate issues; they do not prove that a particular aircraft or robotic system has solved both. A good program record should preserve that separation. Over time, readers can then follow whether an advertised capacity to evolve becomes an observable pattern of maintainable, affordable changes. That is a stronger basis for judging architecture than counting the number of times a release calls it open.

Evidence note

Based on two separate 2025 GAO reviews. The data-rights report was reissued with a correction on 29 September 2025; that is not presented as its original publication date. The computing-module example and proposed reporting questions are editorial illustrations, not a named program assessment or legal advice.

SOURCE REGISTER

Read the evidence.

  1. 01
  2. 02