The fear behind every integration project is the rip-and-replace: one giant system, one forced vocabulary, a three-year migration. boTec’s approach is the opposite. Every system keeps its own language - a shared model simply makes them understand each other.
In Brief
- The same object is “part” in PLM, “material” in ERP and “sample” in the lab - every system correct in its own language.
- Forcing one standard vocabulary breaks the systems built on the old one, and the project never finishes.
- boTec harmonises meaning through Business Integration Models; each system keeps its own wording underneath.
- No rip-and-replace and no migration - the shared model sits above the systems you already run.
Part of the series , Data mesh & the boTec DataBridge
- Part 1 - Data mesh, since 1998 - 20 years before it had a name
- Part 2 - Link, don’t copy - why referential integration beats copying
- Part 3 - Harmonise, don’t standardise - Business Integration Models - you are here
- Part 4 - From data maturity to AI - getting the sequence right
Why “one system to rule them all” fails
Different systems conceptualise the same reality through different lenses. What PLM calls a part, ERP calls a material, and the quality lab calls a sample. Engineering units differ from commercial units. Classification schemes diverge. The instinct is to force everyone onto one standard - but that breaks every system and workflow built on the old vocabulary, and the standardisation project never actually finishes.
The boTec principle
Harmonisation, not standardisation
boTec bridges the gaps through persistent mapping models instead of forced vocabulary changes. Each system keeps its own words; a shared model lines up their meaning.
- Business Application Models give each connected system a light abstraction layer - it keeps its native concepts and wording.
- Business Integration Models establish the shared understanding between systems, with automatic translation between their terminologies.
- Units of measure and time are transformed centrally and consistently, once - not re-implemented in every interface.
- The mapping lives in the model, not in a few experts’ heads or a fragile Excel macro - so it survives staff changes and audits.
You don’t standardise the business. You harmonise its data.
→ See it on your own data - book a modelling session
Why it de-risks everything
No big-bang, no lock-in
Because the shared model sits above your systems rather than replacing them, you keep your best-of-breed applications and your existing investments. Adoption is incremental - start with one high-value object, prove it, expand. And because you can export both the data and the model at any time, you end up less locked in than the tangle of point-to-point interfaces you have today, not more.
One apple, harmonised
| PLM keeps | “part” - Gala 70/75 |
| ERP keeps | “material” - APPLE GALA 70/75 BIO |
| Lab keeps | “sample” - calibre 70-75 mm |
| The shared model adds | one object: Apple , variety Gala , calibre 70-75 mm , organic , class I |
Nobody had to rename anything. Each system still speaks its own language - and every department finally reads the same apple.