Some product issues arise from inconsistencies between two systems, where a single source of truth is hard to reach. For example:

• Invoice status synced in two cloud systems
• Code ownership defined in two places
• Customer data living in two systems

Some inconsistencies are ok, some are not. Without clarity on the required degree of consistency, you might find yourself in confusing situations.

If inconsistencies are not ok, then you might need two things:

1. Measuring the degree of inconsistency
2. Ensuring the inconsistency stays within an acceptance range.

Once you open up to the possibility of measuring inconsistency, you might find that measuring could be straightforward. For example:

• A SQL query across two dbs that have already been ETLed to the shared data analytics db
• A script in the CI/CD pipeline scanning for code ownership

Having the measurement at hand also helps communicating your technical work to your non-technical colleagues, who now have a better overview of the problem.

But again, it could be that inconsistencies are ok. Inconsistencies might have low business impact, or the systems are planned to be replaced with something else.

As with other things, you might benefit from understanding the surrounding technical and business context to choose the right action and the level of consistency that is acceptable to your particular situation.