Freezing everything and sweeping everything each solve half the problem and stop halfway on the other.
This note is part of the series Two strategies over the same estate. One strategy wants to freeze what runs; the other proposes to sweep it all toward a single platform. Here we see why neither of the two, on its own, manages to solve the whole problem.
The problem is not that one is right and the other wrong. The problem is that each strategy, taken alone to the end, solves the part it sees well and falls short right in the part it does not look at.
The continuity strategy, taken to the extreme of freezing everything, does not preserve the operation: it lets it age. The operation changes even if the software does not: volumes grow, the vendor stops supporting a version, the person who understood the spreadsheet retires, regulation asks for a piece of data the old system does not capture. Freezing does not eliminate risk, it accumulates it out of sight until it blows up, and it blows up with no one left who knows how it was put together. The continuity that was being defended ends up being the first casualty.
The sweep strategy, taken to the extreme of replacing everything with a single platform, falls short on the opposite side, and for three concrete reasons. First, the generic platform flattens what had value: the specific logic of a completions process or a field data flow does not fit into a mold built for everyone, and forcing it means losing exactly the depth that made the operation competitive. Second, the total migration takes years, and during those years you have to live with both worlds in parallel, which was exactly the problem you were trying to solve. Third, betting everything on a single platform and a single vendor makes you hostage to their roadmap, their prices and their timelines, right when you need flexibility most.
The two instincts share the same underlying mistake: they treat modernization as an event with an end. You freeze and you are done, or you sweep and you are done. There is no such end. The modernization of an ecosystem is a process, not a closing.
That is why neither of the two strategies can impose itself on the other without making the operation lose. The guiding strategy is not a lukewarm middle point between the two. It is a criterion that combines what is true in each, the risk of change and the cost of not changing, and rejects the extreme of both. And just when it seems that good data governance could put all this in order, the trap that ruins it appears: applying to the operation the rigor of an accounting ledger. That is what we talk about now.
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.
