Every Dashboard, Application and Agent Needs the Same Answers About Your Business

The first is that the meaning of the data has typically never been written down. Things like: what counts as a product; whether four listings describe the same item or four different ones; what an order status implies about whether you can still cancel it; which of five customer records is the customer, and which address is current… All of this is information somebody in the business knows, and every project finds that person, asks them, encodes their answer, and ships. But that means every time, the answer leaves with the project.

The second is that access to the systems that own the data gets negotiated one project at a time. The team that owns the older system carries the risk of your change and receives little of the benefit, so when they say it isn't a priority this quarter, they're making a reasonable call from where they sit. And because every new project turns up asking separately, they're being asked to take that risk several times a year for reasons that have nothing to do with their own roadmap.

The third is that none of it accumulates. The integration gets built for this project. The definitions live in this project's code, or in a spreadsheet somebody maintained for a while. Ten projects in, you've paid for the same work ten times and still can't point at one place where the answer lives.

Any one of those alone is manageable. Together they're why a request that sounds like two weeks comes back as two quarters.

You're hearing both of these terms more often now (usually from vendors, usually without much explanation). They map onto the three problems above, and they're more mundane than they sound.

An ontology is the written answer to the first problem. It records what your business means by the things it runs on—a product, an order, a customer, a promotion, whatever matters where you work—along with which system holds the truth for each one. It captures the relationships too, so a question about an order can follow its way to the customer who placed it and the products on it. An ontology is a document and a model, and most of the effort in producing one goes into getting people to agree.

A semantic layer is the answer to the other two. It sits in front of the systems you already have and uses the ontology to do two jobs: the first is to work out which system holds the answer to an incoming question, and the second is to work out which systems need updating (and in what order) when something changes. Projects talk to the layer instead of wiring themselves into five systems each.

Neither of these replaces anything. Instead, both sit above and work across the systems you run today, which means no migration, and no waiting for one.

Until now, the team that owns the old system fields a stream of individual requests, each carrying its own risk and its own integration. But if the semantic layer is doing its job, each capability in the older system gets integrated once, by people who negotiate with its owners once, and every project after that reaches it through the layer. The owning team's exposure drops from several teams a year asking for access to one interface they helped define.

That streamlined, simplified approach means the team tends to say yes more. The trade leaves them with less risk to carry, in exchange for one conversation done properly.

It sounds like a slam dunk, but it’s important to be honest about when the return on your effort actually shows up: not with the first project, but the second.

The first project through carries most of the work. It pays for the definitions of whatever entities it touches, and for integrating the systems it needs. The second is the one that gets to reuse both, and spend its time on the thing it was asked to build. It also compounds from there— by the third or fourth, standing something up is closer to configuration, because the definitions exist, the access exists, and the questions have been settled.

Getting a foundation funded on its own terms is a harder argument than it looks. It needs alignment across more teams than any single project does, and the benefit lands on work nobody has scoped yet that usually has to wait for a budget cycle. Meanwhile the business has already funded something.

So you need to build the foundation underneath that.

Take the project with a sponsor and a deadline. Deliver it. But hold the definitional work as a shared artifact instead of burying it in that project's code, and put the integration behind a layer where the next project can reach it. You'll spend somewhat more than you would have, but what you get back is that the next project starts from what this one left behind.

Keep the first slice small. Limit yourself to one entity, two consumers, one quarter, and a stated test for whether it worked. Resist the urge to model the whole business before shipping anything, since historically that’s exactly how this work has gone wrong.

One note: the hard part of this is a negotiation between people who currently disagree. Deciding what an “active customer” means is a conversation between the parts of the business that each depend on their own answer, and no architect can settle it for them. Put someone in the room who can make that call.

Look at what's on the roadmap for the next two quarters. Find the projects that will need to read or change data sitting in more than one system, and count how many of them are about to work out what a product or a customer is, separately, for themselves.

Then pick the first one to ship, and do the shared part properly on the way through. Everything after it starts from the somewhere you created en route.