Schema Evolution and Adaptability
Designing for the certainty that the operating model will change
Part IX: Schema Evolution and Adaptability
The operating model will change. This is not a risk to manage. It's a certainty to design for.
Teams reorganize. Strategic priorities shift. New ways of working emerge. The artifacts that matter in year one may not be the ones that matter in year three. An Operating Context System that can't evolve without breaking is not a system. It's a constraint.
The operating ontology should be versioned, so that historical context remains interpretable even after definitions change. New artifact types should be additive and non-breaking. Migration from old definitions to new ones needs tooling and a deliberate approach, not manual re-entry.
Graph-native architectures help here significantly, but they don't make the problem go away. Even in a graph, schema changes that weren't anticipated can be disruptive. The right model is a small number of people with the authority and judgment to evolve the model, with a clear process for teams to propose changes when the model doesn't fit their reality. Evolution should be the default, not the exception.