The Best API Is Sometimes a Raspberry Pi With Two Network Cables

Enterprise architecture diagrams have a wonderful tendency to assume every system has an API.

Then you walk into an actual office.

There is a multifunction printer purchased during the Obama administration, a scanner that works perfectly well but speaks a protocol nobody wants to discuss, a line-of-business application that exports files into a shared folder, and at least one device whose most advanced integration feature is “it can email a PDF.”

You can replace all of it.

Or you can acknowledge reality.

That is the thinking behind a little appliance pattern I keep coming back to with Coverity’s Scan Bridge: sometimes the cleanest integration boundary is a cheap computer sitting physically between the old world and the new one.

Legacy hardware isn’t automatically bad hardware

Companies throw away enormous amounts of perfectly functional equipment because the software around it moved on. A scanner can continue producing excellent images long after its vendor stopped imagining modern workflows. The mechanical device may have years of useful life left while its integration model belongs in a museum.

The usual enterprise answer is replacement. Buy a new device, deploy new software, retrain users and hope the new thing supports whatever the next system needs.

Sometimes that’s correct.

Sometimes the more economical answer is translation.

A Raspberry Pi or similar appliance can speak whatever ugly local language the existing device understands on one side and expose a clean, controlled interface to modern services on the other. It can watch a folder, receive a scan, normalize a file, encrypt it, authenticate upstream and deliver it into the workflow that actually needs it.

To the old hardware, nothing particularly dramatic happened. To the modern platform, it has effectively acquired an API.

Integration happens at boundaries

This pattern isn’t really about Raspberry Pis. The Pi is just cheap, available and wonderfully suited to making questionable ideas become physical objects before lunch.

The architectural idea is an adapter.

Good adapters isolate assumptions. The legacy device doesn’t need credentials for the cloud platform. The cloud platform doesn’t need to understand every scanner ever manufactured. The appliance owns that translation boundary.

That gives us a place to enforce security, perform validation, add retries, cache work during an outage and collect diagnostics. If the Internet disappears halfway through a scan, the document doesn’t need to disappear with it. Queue it locally and deliver it when connectivity returns.

Stop demanding that reality conform to the architecture diagram

I have seen a lot of technology projects become expensive because somebody began with the sentence “first, the customer will replace…”

Replace the scanner. Replace the phones. Replace the identity system. Replace the document repository. Replace the workflow everybody already understands.

Sometimes modernization genuinely requires replacement. But replacement should be the conclusion of an engineering analysis, not the admission price for integration.

If I can put a small managed appliance at the boundary and make a fifteen-year-old device participate safely in a modern workflow, I have potentially saved hardware cost, deployment time, training and disruption.

That is not glamorous architecture. It is useful architecture.

The physical world is full of APIs nobody documented

The longer I build software that touches real operations, the less interested I become in systems that only work when everything around them is greenfield.

Real businesses have history. They have old equipment, weird workflows, vendor contracts, compliance constraints and somebody named Susan who has been using the same scanner since 2012 and can operate it faster than you can explain the replacement.

Good integration respects that reality.

Sometimes the answer is a beautiful REST API.

Sometimes it is a message bus.

Sometimes it is a file watcher, a queue and a secure tunnel.

And sometimes the best API is a Raspberry Pi with two network cables sitting behind a printer.

Engineering contains multitudes.