Open data and APIs: why your company should think like a platform now
An API is not a trendy interface and not a way to look technical. It is an integration discipline that determines how easily your systems will work together a year from now.
When the topic of APIs comes up, executives usually hear one of two things. Either it is something for developers - a technical matter not worth getting into. Or it is something fashionable - "we need to open an API because Google and Amazon do it".
Both readings miss the real point. An API is first of all a discipline for how systems inside a company - and between companies - exchange data. And that discipline has direct business consequences.
What an API means in practice
An API is a contract. System A tells System B: "here is how you can request something from me, here is what I will return, here is what will not change". Everything else is internal plumbing that can be rearranged freely.
When that contract does not exist, integrations are built differently. Systems read each other's databases directly. Files move on a schedule over FTP. One developer knows "how it currently works" and holds it in their head. When that developer leaves, the integration becomes a mystery.
I have seen companies where upgrading one system broke five others - precisely because there was no contract. There was just a hard dependency on a specific database schema.
Why "we'll do it later" costs more
Architectural decisions made at the start live for a long time. A company that built integrations without API contracts for three years discovers three years later that it has:
- several "sources of truth" for the same data;
- integrations nobody dares to touch;
- no way to add a new partner or channel without a separate large project;
- a dependency on specific people who "understand how it works".
Moving from that state to a normal one is expensive refactoring. Not a technical heroic feat, but long, boring work done in parallel with current priorities.
Open data as a specific case
The open data movement, which is now gaining momentum in the public sector and in technology companies, is built on the same idea. Data becomes accessible through stable, documented interfaces. Others can build products and services on top of them - without negotiating with each source separately.
For a commercial company this can mean: if your data about products, orders, or partners is accessible through a proper API, integrating with a new marketplace, aggregator, or partner becomes a matter of days rather than months.
This is not "openness for openness's sake". It is lowering the cost of every subsequent integration.
Where to start if you have no APIs yet
There is no need to rewrite everything at once. A reasonable approach:
- identify the most painful integration points - where things break most often or require manual intervention;
- define a contract for those points - even if the underlying implementation is still old;
- on any new project, set a requirement: no direct database connections, only through the contract.
This is not a revolution. It is the gradual replacement of implicit dependencies with explicit ones.
Three questions for a manager
Before approving the next integration project, it is worth asking the team:
- What is the contract for this integration and who owns it?
- What happens if one side changes its internal schema?
- Can a third system be added to this exchange without a rewrite?
If there are no answers to these questions, the project is probably creating a new hard dependency that will be dangerous to touch in a year. That is the price companies pay when they think of APIs as interfaces rather than as a discipline.