Data Integration Discovery: Which Definitions Must You Settle First?

The Problem Discovery Solves

Two systems hold duplicate customer data. Manual rekeying happens daily. Finance and operations reports conflict, and nobody can say which is right. A connection proposal arrives, and it names the tool. What it does not name is which system is trusted when the data disagrees, who owns the meaning of the shared fields, what freshness the business actually needs, or what compliance constraints close options before the architecture conversation.

Discovery resolves those five definitions per entity before platform selection, with a named person responsible for each. The reason each definition names a person rather than a group is that a definition owned by a committee is a definition that gets reopened every time the committee changes.

The Five Definitions, at a Glance

System of Record: Field-Level Designation

Rather than naming one system as the source of truth per entity, designate the winner field-by-field. Answer four questions per field: which system creates the value, which copy the business acts on, which copy regulators would see, and what happens to other copies. The external-facing copy typically wins because the organization must be able to reconstruct it, and inconsistency between what regulators are shown and what internal teams work from is the failure mode designations exist to prevent.

Test the designation by asking the losing system’s owner what they lose. If they identify reports, workflows, or local fields, the designation is incomplete and needs another pass. If they cannot name anything, the designation is settled.

Data Contract Elements

A maintainable data contract has six components. Skip one and the contract stops holding.

Shape. Fields, types, optionality. The mechanical description of what crosses.

Meaning. Business definitions for each field. “Customer” means what, in this contract, between these two systems.

Validity. Acceptance rules. What the receiving system will refuse.

Cadence. Timing and assumptions. When the data moves, what triggers the movement, and what silence means.

Change terms. Notice requirements and consumer accommodation. What has to happen before the sending system can change what it sends.

Names. Accountability on each side. Who signs the contract, who is called when it breaks.

A contract nobody maintains is worse than none, because the phantom contract lets everyone claim they were operating from it while nobody was. Keep it short enough that the ownership survives.

Owner Accountability

The owner must be an individual, not a committee. Three tests verify real ownership. First, authority: the owner can approve a change without escalation. Second, expectation: the owner expects to be called on disputes, and everyone knows it. Third, succession: someone else knows enough about the entity to hold ownership if the current owner leaves.

The distinction between system owner and data owner matters. System owners manage infrastructure; data owners govern meaning and usage. They can be the same person, but they are not the same person by default, and a decision that treats them as interchangeable ends with the platform team owning definitions they cannot defend to the business.

Movement Requirements: Measuring Reality

Capture measured facts, not preferences. Record count, daily change volume, and peak-day volume from source-system reporting. Peak day is what breaks a capacity plan: month-end close, fiscal year end, an acquisition. If the capacity plan is built for the average day, it fails on the day that mattered.

For freshness, ask about tolerance rather than preference. Hour-old data: where does that break down? Day-old? Week-old? The real threshold is somewhere on that scale, and the question is which decision breaks first when the data ages. Document the answer with the consequence attached, not as a stated preference.

Constraint Set: Compliance First

Three constraints close options before architecture discussion, and settling them at discovery is cheaper than discovering them at design review.

Data classification. Determined by the regulated content the entity holds, not by the technology it moves through. A PHI field is PHI regardless of the platform.

Physical residency. Documented per service. Where the data physically sits, and whether the destination service can hold it under the applicable regime.

Access permissions. The receiving system’s access model may widen exposure. A synced integration to a system with looser permissions is a design that leaks the source’s controls.

Discovery Process

Participants: business entity owner, contributing system owners, a compliance and security representative, and a person whose only job is to document what is said. Without a writer the meeting produces alignment nobody can reproduce.

Output: one document per entity containing five definitions with named owners, plus two lists. The first list is unsettled disputes with owners and timelines. The second is discovered gaps: entities lacking a business owner, conflicting creation claims, undocumented constraints.

Completion condition: every entity in scope has five definitions with names, or an explicit deferral with an owner and a date. The scope is bounded by the actual system boundaries in the contemplated work, not by the whole estate. Extending scope past what the project needs is how discovery turns into a program that never ends.

What This Work Is Not

Discovery is not an architecture assessment. No patterns are selected, no tools chosen, no reference architectures drawn. It produces per-entity artifacts, and it stops when those artifacts are complete.

Discovery is not a governance program. It is discovery. A standing governance function is warranted only if contracts are being reopened faster than owners can maintain them, and the discovery output is what tells you whether that is happening.

When Discovery Is Not Appropriate

Stop if the question is which integration pattern suits which workload; that is a design decision, not discovery. Stop if integrations already exist and nobody knows what they do; that is dependency mapping and risk triage, which comes before discovery on the same entity. Stop if the entity has no business owner and no candidate to become one; the first move is naming the owner, not documenting the definitions.

How i3solutions Runs Data Integration Discovery

i3solutions has integrated Microsoft estates since 1997, with senior, 100 percent US-based teams working under the compliance standards regulated environments require. Discovery runs the same discipline every governance-first program does: name the owner, write the contract, measure the movement, close the constraint set, and stop when the artifacts are complete rather than extending until nobody remembers what the project was for.