Every integration project starts with the same promise. There is a connector, it is certified, and the two systems will talk to each other. The connector usually works. The project still runs late, and in the projects we are called into the transport layer is rarely where it went wrong.
The reason is that the two systems disagree about what the words mean.
What breaks when two systems fail to integrate?
Take the word "order". In a sales system, an order often comes into existence when a customer accepts a quote. In a production system, an order may exist only once material availability has been checked and a slot has been reserved. The same split shows up between quoting and order management, which we unpacked in where deals die. Both systems have a table called orders. Both will happily send each other records through a connector. They are describing two different objects.
Before any of this, you need to know which systems are even in scope, which is a separate exercise we covered in mapping your software ecosystem.
Now multiply that by customer, product, price, delivery and status. Every one of those words carries a definition that was written by different people, at different times, to answer different questions.
The connector moves the data. The question of what that data means on the other side sits outside both statements of work.
What is a bounded context, and why does it matter to a buyer?
This problem has a name, and it has had one since 2003, when Eric Evans published Domain-Driven Design.
Evans called the boundary a bounded context. Inside it, every term has exactly one meaning, agreed by the people who work there. Outside it, the same term can mean something else. Martin Fowler puts the buyer-relevant part plainly: "Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration." [1]
The important word there is mechanisms. Translation between two models is a thing somebody builds, maintains and pays for. It does not arrive with the licence.
Fowler also quotes the founding assumption behind all of this: "total unification of the domain model for a large system will not be feasible or cost-effective." [1] The goal of one shared definition across a whole company was abandoned by the people who thought hardest about it, more than twenty years ago. What replaced it was an explicit map of where the definitions differ and how they are reconciled.
That map rarely appears in a proposal, and a buyer can ask to see it.
How can two models be connected?
The reconciliation options form a documented catalogue. The Context Mapper project maintains the working reference. [2] Seven patterns cover the realistic ground.
Anticorruption layer. Your side translates their model into yours. It costs ongoing effort, and your model stays yours. This is the defensive choice, and the right one when your own domain logic is the thing you compete on.
Conformist. You adopt their model as it stands. There is no translation work, and every change they make becomes your work. Cheap at signature, expensive at every upgrade.
Open host service. One side exposes a deliberate integration interface for all comers, rather than a bespoke connection per partner.
Published language. One side publishes a shared contract, and integrations are written against that contract instead of against internals.
Shared kernel. Both sides co-own a small piece of the model. It removes translation for that piece and creates a joint change process for it, which needs an owner.
Customer and supplier. Both stay in a formal upstream and downstream relationship, where downstream requirements are part of upstream planning.
Separate ways. You decide the integration is not worth its cost and keep the systems apart. This is a legitimate answer and it almost never appears in a vendor proposal.
Which of these should you ask for before you sign?
The useful question at the table is not which system is better. It is this:
Which of these patterns describes what you are proposing, and who does the translating when our model changes?
If the vendor names a pattern, you now know where the work sits and roughly what it costs to keep running. Anticorruption layer means a team maintains a translation for the life of the system. Conformist means your process bends towards their model, and their release notes become your project plan.
If the vendor has no answer, you have learned something more valuable than a feature comparison. The mapping will still get built. It will get built later, by whoever is holding the project when the mismatch surfaces, and it will be priced as a change request.
Which model are you treating as the reference?
There is a question underneath all of this that buyers skip, and it decides the answer to every other one.
When two models disagree, one of them usually wins by default. It is the system that has been in the building the longest. Its definition of an order becomes the definition, its states become the states, and the new system is asked to conform.
Sometimes that is correct. The old system encodes a way of working the business depends on.
Often it is an accident of history. The schema was written by a vendor who is no longer involved, to fit constraints that expired years ago, and the company has spent a decade shaping its process around it. Ask why an order cannot exist before a credit check and the answer comes back as a fact about a table built in 2011.
A replacement project is the one moment when that question is cheap to ask. So ask it before the mapping work is scoped:
Does this model describe how we want to work, or how we learned to work around a system?
The answer changes which pattern you want. If your model is the thing you compete on, you pay for an anticorruption layer and keep it. If your model is inherited constraint, conforming to a better one is an upgrade rather than a defeat, and you should say so out loud instead of paying to preserve it.
Technology that follows the process is worth its setup cost. A process that has quietly reshaped itself around someone else's schema is a cost that appears in no budget line.
We build on Open Mercato today. It is an open-source platform, we are a certified partner and a contributor to its core, and the licence is what bears on this article: code written on it stays with the client under MIT. A domain model you are not allowed to change is one you will eventually work around, and working around a model is how the process ends up serving the schema.
A test you can run in a single meeting
Ask the vendor to open one of your real orders inside their system, next to the same order in the system you use today.
If they cannot load your data yet, the test still works on their demo record. Put their example on screen and describe, out loud, how the same object behaves in your current system.
Then ask three questions about each side:
What is an order here. At which moment does it start existing. What has to be true before it can change state.
Write both answers down. If they describe the same object, your integration is a data-transfer problem and the connector is most of the answer. If they describe two different objects, you are buying a translation project, and it should appear in the quote with a name, an owner and a maintenance cost.
This takes fifteen minutes and it happens before money moves. The alternative is discovering the same thing in month four of an implementation, which is where a large share of buyer regret begins. We wrote about that failure pattern in our guide to buying custom software without a CTO.
What this changes in how you buy
Three practical shifts.
Put the mapping in the scope of work, with a named owner on both sides. An unassigned responsibility gets argued about at the worst possible moment.
Ask what happens to the translation when either side changes its model. Your product structure will change. Their platform will version. The contract should say who absorbs each of those.
Price the connector and the translation separately. They are different pieces of work with different lifetimes. The connector is a line item. The translation is the project.
None of this requires you to become an architect. It requires you to ask what the words mean, and to notice when two vendors give you two different answers to the same question.
We build the integration layer underneath sales and production systems for manufacturers, which is where these mismatches surface first. If you are weighing a purchase and want a second read on where the translation work actually sits, that is a conversation worth having before you sign, not after.
Frequently asked questions
Is this the same as an API mismatch?
No. An API mismatch is a transport problem. Wrong format, wrong authentication, wrong rate limit, and you find out on day one. A model mismatch passes every technical test, then surfaces months later when someone notices that the two systems report different numbers for the same week.
Who should own the translation layer?
Whoever owns the model that is allowed to change. If your process is the thing you compete on, your side owns the translation and pays for it as a running cost. If you are adopting the vendor's model deliberately, the responsibility moves to whoever maintains your configuration against their releases. What does not work is leaving it unnamed.
Can we decide this after the contract is signed?
You can, and it will cost more. Before signature the mapping is a scope item you can negotiate. After signature it is a change request against a fixed budget, raised at the point where the project is already behind.
Sources
- Martin Fowler, Bounded Context (bliki). Definitions of bounded context and the shared domain language, quoted verbatim, retrieved 28 September 2026.
- Context Mapper, Context Map. Catalogue of context mapping patterns.
- Eric Evans, Domain-Driven Design, Addison-Wesley, 2003.