COTS Is Not a Shortcut If It Cannot Be Exported

The “Black Box” Procurement

We needed a new library management system. The timeline was tight. The Procurement Officer suggested a popular COTS (Commercial Off-The-Shelf) solution.

“It is used by 500 cities,” she argued. “We just install it and go. No custom development.”

It sounded perfect. Then I asked to see the Data Schema.

“The what?” the sales rep asked.

“The map of the database,” I explained. “If we use your software for ten years, we will create millions of records. I need to know that if we cancel the contract, I can take those records and load them into a different system.”

“Oh, the database is proprietary,” he said. “It’s encrypted for your security. But you can print reports to PDF.”

“So,” I said, “You are selling us a roach motel. The data checks in, but it does not check out. This is unacceptable.”

The Trap: Speed Now, Ransom Later

COTS software is seductive. It solves the problem today. But for a municipality, the timeline is not fiscal quarters; it is generations.

The trap of COTS is Proprietary Encapsulation. The vendor wraps the Citizen’s data in a layer of code that only they possess.

• They dictate the format.
• They dictate the access.
• They dictate the migration price.

If we buy a COTS solution without a strict export clause, we are not buying a shortcut. We are deferring the work. We are saving 100 hours of development time today to pay 10,000 hours of migration pain in five years.

[TO EDITOR: Diagram showing a “Glass Box” (Open Standards) vs a “Black Box” (Proprietary COTS). The Glass Box allows data to flow out; the Black Box has a padlock.]

The Exit Strategy: The “Open Storage” Mandate

We still buy COTS. We are not software developers; we are public servants. But we have changed the rules of engagement.

We now require Decoupled Data.

1. The SQL Requirement: The application may be proprietary, but the underlying database must be standard (PostgreSQL, MySQL, MariaDB) and accessible to us. We hold the root password to the database, even if the vendor manages the app.
2. The Schema Warranty: The vendor must provide updated documentation of the data structure. If they change the table structure in an update, they must update the map.
3. The “No-Fault” Export: The system must include an API or feature to dump the entire dataset in a machine-readable format (JSON/XML) without vendor intervention.

We tell the vendors: “We will rent your car. But we will not let you weld the doors shut while our Citizens are inside.”

Buying off-the-shelf is fine. Being locked inside the shelf is not.

FAQs

Should we build everything ourselves then?

No. That is waste. We buy the vehicle (software), but we must own the passengers (data). We buy COTS, but we demand open storage.

What is a proprietary database?

It is a file that can only be opened by the vendor's software. If they go bankrupt, your data becomes a string of useless binary code.

Is a CSV export enough?

For a simple list, yes. For a complex case management system, no. We need the relationships, the metadata, and the logs.