Technically AcceptableIndependent technical publication
← Writing archive
ESSAY

The Cost of Adding One More Supplier

A wider defense supplier base makes integration part of the purchase. The radar has a price. Making it fit has a cost too.

By Travis Shea
  • Infrastructure
  • Tooling

A company can build a better radar and still hand its customer a difficult purchase.

The radar detects what the customer needs to detect. The price is reasonable and fixed. The demonstration goes well. Then somebody asks how it connects to the equipment already installed.

The customer has a display, a network, recording software, other sensors, and people who know how to use the existing system. Adding the radar means making decisions about all of those things. Someone has to work out what data it produces, what can receive that data, and what happens when one of the pieces changes.

The radar has a purchase price. Introducing another supplier has a cost too.

I want to better understand the secondary costs. The Department of War wants more companies participating in the defense industrial base. If that produces more choices, the ability to fit those choices into working systems becomes a larger part of the industry.

A wider supplier base becomes more useful only when customers can afford to introduce another supplier.

The department’s November 2025 Acquisition Transformation Strategy explicitly calls for broader supplier participation, more commercial technology, and competition over components within larger systems. It also calls for earlier integration and testing. Those objectives belong together. A new component needs a practical route into something the customer can use.

September’s Fostering One Strong Industrial Base announcement addresses another part of the problem: the accounting, audit, and compliance burdens that discourage companies from selling to the government. The direction is toward making defense a market more businesses can enter without reorganizing themselves around government-specific practices. How much changes will depend on implementation.

There are established routes to government customers as well. The Defense Innovation Unit, or DIU, uses its Commercial Solutions Opening process to solicit commercial solutions to specific government problems. Companies submit short proposals, selected companies pitch, and prototype agreements can lead to follow-on production. That provides a path from an identified need to a company with something useful.

I see a plausible opening here for smaller companies. A team with a useful sensor, a better algorithm, or a reliable way to connect existing equipment could have something to contribute.

Getting that technology in front of a sponsor is one part of the job. Making it easy enough to adopt is another.

Consider the small company preparing for a demonstration.

Its equipment works in its own setup. Now it needs to contribute to a demonstration involving another company’s camera, somebody else’s radar, and a display chosen by the customer. One of those companies may also be a competitor.

Each participant has a product to sell. For the demonstration, they also have a shared problem to solve.

Who converts the data? Who checks that the systems agree about time and location? Who decides whether an apparent failure belongs to the sensor, the connection, or the software receiving it? How much engineering effort does each company contribute before anyone knows whether there will be an order?

Those questions affect the price and schedule of showing up.

They also affect which companies are attractive partners. I would expect a supplier that arrives with usable documentation, representative data, and a clear account of what its equipment can do to create less work for everyone around it.

Willingness and ability to collaborate is mandatory.

The department’s emphasis on a Modular Open Systems Approach, usually shortened to MOSA, gets directly at this. It combines engineering and business decisions so parts of a system can be integrated, competed, and changed over time. The interfaces matter. So do the rights and arrangements that allow another company to use them.

The practical question is how much of that flexibility survives the actual purchase.

I used to work in radar and maritime domain awareness with a small systems integrator. That domain is where I am going to start pulling this thread.

Take the Furuno DRS4D-NXT maritime radar. It uses Ethernet for data and control, but the network protocol is proprietary. Cambridge Pixel, a developer of radar processing and sensor integration software, documents a commercial integration route that can receive its radar video, support basic control, and produce outputs for other applications. Its documented configuration requires a radar-specific license in addition to the server license.

There is a solution. It comes with another purchasing decision.

I might decide that this is exactly what I want. The radar suits the job, the integration software saves engineering time, and a supported product gives me someone to call when it stops working.

I might also discover that a different radar makes the overall system easier to build and maintain, even if it was not my first choice when I compared the hardware.

That is where a component decision becomes a system decision.

The useful comparison includes the radar, the interface, the processing, the capabilities exposed through that interface, and the people required to keep it working. A cheaper sensor could produce a more expensive system. Paying for software could be the economical choice.

I want to understand where those tradeoffs become visible. Ideally before the equipment arrives.

It also matters what we mean by access to radar data.

An image of the radar display, a stream of radar video, and a list of tracked objects give the receiving system different things to work with. A track list may be enough to put contacts on a map. A different application may need earlier data so it can apply its own processing.

Buying more processing hardware does not create access to information the radar never exposes. And access to more information creates work of its own: moving it, interpreting it, recording it, and deciding what to do with it.

That is already a much larger decision than choosing a radar with a network port.

Now add a thermal camera.

The radar reports a contact. We want the camera to look at it. On paper, that sounds straightforward.

But the camera needs to know where to point from its own position. The system needs to know when the radar measured the contact, because a moving object may have changed position by the time the message arrives. The installation needs enough alignment information for the camera to look at the thing the radar actually detected.

A message arriving successfully establishes that a message arrived.

The rest still needs to be worked out.

This is why I am interested in the phrase “we have an API.” An application programming interface provides a defined way for software to interact. It can make integration much more approachable. The next questions concern what the interface exposes and what the receiving system can safely conclude from it.

A position without a clear time reference can be misleading. A confidence value without an explanation can be difficult to use. An interface that reports a sensor’s observations may provide no way to control the sensor.

All of those distinctions can sit behind a perfectly functional connection.

Companies like Anduril make this especially relevant to smaller suppliers. Its Lattice software development kit provides documented interfaces for connecting outside sensors, applications, and data services to the platform. That gives a company a concrete integration path to investigate.

The opportunity I see is to contribute something useful to a system that already has customers.

That requires understanding the receiving environment. What information does it expect? How does our contribution improve what the user can do? What work does the platform company still have to perform before our technology is useful to it?

A successful API call answers a narrow question. A credible integration also needs an explanation of its limits, its failure behavior, and who will maintain it.

That last part tends to follow the sale home.

The equipment will get a firmware update. The receiving software will change. A component will become unavailable. Someone will ask to add another sensor.

The customer then finds out how much flexibility was purchased the first time.

This is where I think the business and engineering conversations need to stay close together. A promise made during business development can become an interface requirement. An interface choice can become a licensing dependency. That dependency can become a support obligation carried by the people delivering the system.

The proposal, the design, and the support plan are describing the same purchase from different directions.

More control is attractive, but somebody has to do the work it brings.

We could choose open software and maintain our own connections. That might reduce license costs and give us more freedom to change the system. It also makes updates, testing, documentation, and troubleshooting our responsibility.

We could pay for a commercial component because its support and maturity are worth more than the time we would spend replacing it.

I want to make those choices deliberately. There is little value in avoiding a license bill by creating a maintenance obligation the team cannot sustain. There is also a cost to accepting a dependency that makes every future change someone else’s decision.

Exploring this topic at large is the next chapter of this publication.

Sentinel is done for now. Maybe my ADHD will bring me back to it in the future.

At its most specific, the program will cover sensor integration. More broadly, it will be an exercise in good systems engineering: defining the problem, understanding the interfaces, comparing complete solutions, and preserving useful options.

Radar is a familiar starting point from my previous experience. The questions extend into maritime awareness, counter-drone systems, robotics, and anywhere else several companies’ equipment needs to behave like one working system.

For this project, I am working with a few friends, who share interest in the subject and also work in the DIB as their day jobs. All of us have varying degrees and experiences in different tech/process domains. At the very least it’ll be a good excuse to work on something with some buddies.

Looking deeper into this helps all of us better understand the spaces we sometimes occupy at our day jobs. I think even with chasing things like this in lieu of a normal hobby leaves me feeling very behind with how fast technology, policy, and industry practices are moving these days. Anything to close that gap is interesting to us.

The program now has a place in the website’s Programs section as Systems Integration.

The question behind it is already clear: if a small company wants to sell one piece of a larger system, how much responsibility does it need to take for making that piece fit?

Sources

Return to writing archive