We still underestimate the cost of “just getting the data”. ERP, CRM, files, legacy databases: each source has its rights, formats, and intermittence. As long as every project crafts its own connector, the organization pays for the same work several times. No agent or workflow is truly reliable under those conditions. A data API layer changes that starting point.
Make the landscape addressable
A data API layer does not replace the IT landscape. It makes it addressable. Unified authentication, stable payload contracts, pagination, error handling, logging of reads and writes: the boring details that decide whether an automation lasts six months or six weeks. Without that layer, you rebuild the plumbing for every initiative. The data microservices vs BI monolith debate is about the same grain of exposure.
The classic trap is aiming too wide too early, a bus for the whole estate. Better to expose first the business objects actually consumed by two or three use cases, measure the load, then widen. Product discipline applies to internal APIs too. An API without a clear consumer quickly becomes an expensive abstraction.
Read, write, and what comes next
Read versus write also needs a deliberate trade-off. Many projects start read-only, which is wise. The day writes arrive, validation, idempotence, and ownership suddenly become central. Anticipating them avoids discovering too late that a “simple” connector was simple only because it changed nothing. Without clear semantics, even a stable API still lets agents go astray.
Bricks like Hivity exist to connect without imposing a big bang. If AI or automation projects stall on integration, the first useful map is not the model map. It is the access map: who reads what, where, under which contract, and how often the data actually changes. For the product, see also hivity.com.
