· By Youssef Oubihi
- api
- architecture
- strategy
Most organisations we meet already have an API management platform. Few have an API strategy. The difference is not semantic: it shows up in the adoption rate of the interfaces they publish, and that rate is often close to zero.
The usual symptom
A technical department buys a platform, publishes thirty or so interfaces drawn from the existing application catalogue, and finds eighteen months later that three of them are actually consumed. The other twenty-seven expose internal models that nobody outside can interpret.
The problem is not the tool. It sits upstream: what was exposed is what existed, rather than what someone needed.
Three decisions that determine everything after
Who the consumer is. An API meant for an internal team, a contracted partner or an unknown developer is not designed the same way. Documentation depth, contract stability and the security model all follow from it. Not deciding means designing for the most demanding of the three, at the cost of the simplest.
Which domain model you expose. An API that projects the database structure transfers internal complexity to the consumer. It will be worked around. The design work consists precisely in building an exposure model distinct from the storage model — and that is business work, not technical work.
Who owns the contract. An interface without an identified owner drifts. The question is not which team hosts it, but who has the authority to refuse a change that would break its consumers.
What this changes in practice
An organisation that has settled these three points publishes fewer interfaces, later, and gets measurably better adoption. The platform goes back to being what it is: an execution tool, not a strategy.