Two camps still clash around data microservices and the BI monolith. On one side, the monolith: one warehouse, models, reports. On the other, dispersion: each domain exposes its APIs. Both are right about part of the problem, and wrong as soon as they become ideology.
The consumer as criterion
Central BI remains relevant for cross-cutting reporting, compliance, long history. It is less suited when an application or agent needs a fresh business read, with fine-grained rights and low latency. Conversely, a jungle of APIs without contracts or governance recreates the chaos the warehouse was meant to solve. A data API layer exists precisely to frame that exposure.
The useful criterion is the consumer. Monthly report: warehouse. Operational action or agent: domain API with clear semantics. Both coexist in healthy IT landscapes. What must be unique is not storage. It is the meaning of business objects. Without that shared meaning, each camp builds its local truth, and agents go astray.
Team capacity and timing
Timing matters too. A warehouse can absorb a reporting wave in a few months. A fine API mesh demands continuous contract and version discipline. Choosing grain without looking at the team’s capacity to hold it is a classic mistake. The ideal architecture on paper quickly becomes debt if nobody operates it.
If the internal debate pits everything in the DWH against everything in microservices, refocusing on the next six months of use cases is often more productive. Teams then discover they did not need to pick a camp. They needed to pick, for each consumption, the most honest path. To frame that trade-off, see also our solutions.
