When Systems Drift and Meaning Goes With Them

What looks like a systems problem is often a meaning problem hiding underneath.

We worked with a company in the home servicing industry.
On the surface, the issue looked familiar: multiple systems, disconnected teams, limited visibility.

They were running several instances of Microsoft Dynamics. Support, scheduling, and operations were all active—but not connected in any meaningful way.

Most vendors would start with integration.

We didn’t.


The First Question: What Is an Account?

Across the systems, one entity dominated: Account.

But it didn’t mean the same thing.

  • sometimes a customer
  • sometimes a service context
  • in some cases, even appointments had been modeled as accounts

At that point, the problem wasn’t fragmentation. It was definition.

The same object described different realities.

That explains the multiple instances. Each team adapted the system to its own needs. Over time, those adaptations diverged. Instead of reconciling them, the systems were isolated.

Four interpretations. Four systems.


Why Integration Would Have Failed

If you merge systems without resolving meaning, you don’t fix the problem—you scale it.

You end up asking:

what exactly are we merging?

If “Account” represents different things, then combining them produces a larger system with the same ambiguity.

The issue wasn’t connectivity.
It was semantics.


Step Back: Define the Business

We started by defining stable concepts:

  • customer
  • property
  • equipment
  • appointment
  • service event

These already existed in practice. They just weren’t consistently modeled.

From there, each system became a source of interpretation, not a source of truth.


A Translation Layer, Not a Migration

We built a unified layer using Gyroscope that connected to each Dynamics instance independently—separate APIs, separate credentials, separate models.

Each one was mapped into a normalized structure:

  • “Account” resolved differently depending on context
  • identities reconciled across systems
  • relationships reconstructed
  • fields aligned through mapping dictionaries

The systems stayed in place.
Their meaning changed.


What Emerged

Once the model was consistent, capabilities followed:

  • aggregates across the full population
  • direct access to any record
  • consistent search across systems
  • continuous timelines instead of fragments

These are properties of a transactional data layer.
They didn’t exist before—not across systems.

We didn’t replace the platform.
We restored the ability to work with the data as a whole.


What Actually Took the Time

This wasn’t an integration project.

It was data remodeling:

  • resolving conflicting definitions
  • aligning similar but non-identical fields
  • mapping roles and access across systems
  • working around API constraints
  • building shadow indexes for reliable access

The effort was not in moving data.
It was in making it mean the same thing.


A Pattern, Not a One-Off

This isn’t specific to Microsoft Dynamics.

You see the same pattern in Salesforce, in CMS backends like WordPress, and in any system that gradually absorbs responsibilities it wasn’t designed to model explicitly.

The sequence is consistent:

  • local optimizations reshape core entities
  • meanings drift
  • systems diverge
  • data fragments
  • computation moves outside

The solution is equally consistent:

  • define concepts
  • normalize the model
  • treat systems as inputs
  • translate, don’t merge
  • rebuild data capabilities centrally

Closing

The systems didn’t fail.
They evolved.

But they evolved without a shared model.

The work was not about integration.
It was about restoring definition—and building on top of it.

ITopoly
Go Back Top