Tending to what runs and sweeping everything toward a single platform are two different strategies, each half right. This series combines the true half of each.
In the previous article we framed the modernization of an application estate as guided evolution, not as a replacement. This series brings that conceptual foundation down to a case that repeats inside almost any large operation. It is not one customer's story. It is a pattern that appears again and again, with the same faces and the same arguments.
Inside the organization, two different strategies coexist. They are not at war: they are two legitimate ways of solving, and each solves a part. One tends to what runs: the owners of the technology and of the systems that hold the operation up today, who value continuity and know where the wires are that must not be cut. Their line is "this works, do not touch it". The other comes from outside, often from a different methodology, and proposes to sweep everything toward a single platform: clean slate, one vendor. Their line is "this cannot scale this way".
Each strategy sees clearly what the other cannot quite see. The one that tends to what runs sees the risk of change. The one that proposes to sweep sees the cost of not changing. Both look at the same picture from different angles, and each is right in its half.
On top of that tension, a third problem tends to come down, quieter and more expensive: a data governance designed with the logic of an accounting ledger, applied to data that has to move at the speed of the field. With the best intentions, it ends up suffocating the operation it claims to protect.
The thesis of this series is simple. Neither of the two strategies solves the whole problem, and the operation needs both halves. The guiding strategy, the one from the previous article, does not pick one of the two: it combines the true half of each and rejects the extreme of both. And good data governance is not the one that controls the most, it is the one that makes trustworthy data flow.
But before combining the two, you have to see why each strategy, on its own, stops halfway. That is the next note.
Glossary
- System of record
- The official, auditable source of a piece of data: accounting, assets, contracts. It needs rigor, immutability and traceability, and can afford to be slower because its value is that no one can dispute it afterward.
- Operational data stream
- The data flow that is born in the field and has to move at the speed of the operation: reports, sensor readings, progress, crew events. It is useful even when incomplete and is corrected downstream; demanding record-level rigor of it suffocates it.
- Data contract
- Explicit agreement at the interface between two systems on the data schema, the meaning of each field, and the quality and frequency guarantees. It decouples producer from consumer, so each can evolve internally without breaking the other.
- Fit-for-purpose governance (by consequence)
- A governance model that classifies data by how it is used and by the consequence of it being wrong, and applies rigor in proportion to that consequence. It avoids both the lack of control where the decision is grave and the pointless ritual where it is not.
- Quality at the source
- Validating the data where it is born, with simple rules and immediate feedback to whoever enters it. It costs far less than rebuilding quality downstream and is the cheapest way to keep an error from propagating.
- Progressive rigor
- A governance strategy that starts light, with visibility and contracts over the few highest-consequence flows, and adds control where the consequence justifies it. It is the opposite of a total program that tries to govern everything at once and never finishes.
- Vendor lock-in
- A situation in which the operation ends up tied to the roadmap, prices and timelines of a single vendor or platform, because it bet everything on it. Standardizing the connective tissue instead of the application is what preserves optionality and avoids being held hostage.
- Connective tissue
- The set of connections through which the pieces of the ecosystem talk to each other: interfaces, identity, data contracts, observability. Standardizing the connective tissue, and not the application, is what lets you change any piece without redoing the whole.
- AS-IS (current state)
- The honest map of how the application estate stands today: what exists, what is obsolete, what depends on what. The real starting point, unretouched.
- TO-BE (target state)
- The direction the ecosystem is meant to be taken in, drawable and debatable, corrected as you go. Not a fixed snapshot, but a firm heading.
