Standardize the connector, not the appliance. Modularity so that no piece is irreversible.
This note is part of the series Two strategies over the same estate. Here is the clearest answer to the strategy that proposes sweeping everything toward a single platform. Flexibility is not a luxury: it is what lets you negotiate and correct the heading later on.
Standardize the connector, not the appliance. What has to be standardized is not the application, it is the connective tissue: the interfaces, user identity, data contracts, observability. An everyday analogy helps. The plug is standardized so that any appliance connects to the grid, but the fridge and the drill are still different appliances. No one would unify them because they share the plug.
With applications it is the same. If what is common and stable are the connections through which the pieces talk, then any piece on the inside can be changed without redoing everything. That is what preserves optionality, and optionality has concrete value: it is what lets you negotiate with a vendor from the position of someone who can walk away, and not from that of someone who has already bet the whole operation on their roadmap.
Modularity, so that no piece is irreversible. It is the corollary. If you modernize in replaceable modules, with clear contracts between them, then no decision made today mortgages tomorrow's. Each module can evolve, or be replaced outright, without forcing a complete redo, as long as it respects the contract with its neighbors.
And each domain's depth is preserved at the ends. The drilling application can go on being deeply what it is as long as it speaks the common language where it connects with the rest. That is the reconciliation with the continuity strategy: the domain is not flattened, it is connected.
Modularity is what turns a large irreversible bet into a series of steps that can be audited, measured and, if needed, undone. It is the opposite of the preconceptions of wholesale replacement, and it is what makes change bearable for the operation. One piece the brief asked us to work on seriously is still missing: a data governance that can really be put to run. We start with what to separate and who answers for it.
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.
