Doing large incompatible migrations is unavoidable eventually, so avoiding them doesn't solve the problem either it just postpones the problem until the entire enterprise has to move to an entirely "new system" at fantastic cost. For some reason the old system never really dies so after the multimillion dollar migration the old zombie system still supports some business functions, leading to that replication anyway.
Both solutions are unpalatable: "the database is the integration point we can't ever change" is bad and "no apps have a central ground truth database" is also painful.
I'd prefer the latter with small APIs and more duplication, than the common enterprise solution with a massive holy unchangable db directly serving apps.
Yes. But "adding" is a pretty small subset of changes. If you need to do even a trivial migration like the classic "merge first and last name columns into a single column" is pretty hairy if you have a dozen legacy apps that assume "customers" have "firstname".
In the end it means you give the data an elevated role in the system, and you write the code around the data. When the code would be cheaper to write or maintain with a different data representation - you can't. It's a comfortable situation for a while, but when you eventually grow out of the current system it's a world of hurt.
Like I said - it's two bad (non) solutions but I very much prefer duplication, isolation, inconsistency, a forest of small obscure APIs etc. where I can add/remove/normalize/denormalize/add caching etc - to "the data is the ground truth and the schema we can only change through addition" non-solution.
> In the end it means you give the data an elevated role in the system, and you write the code around the data.
That's how things are meant to be. The structure of a program naturally follows that of the data it manipulates.
> When the code would be cheaper to write or maintain with a different data representation - you can't.
Who says that? The real problem is that most programming languages aren't capable of integrating database schemas into the type-checking process, so when you change a schema, it's difficult to make sure applications follow through in a consistent manner. That's what makes change unnecessarily risky and painful. But it's possible to do better than that: http://impredicative.com/ur/
Both solutions are unpalatable: "the database is the integration point we can't ever change" is bad and "no apps have a central ground truth database" is also painful.
I'd prefer the latter with small APIs and more duplication, than the common enterprise solution with a massive holy unchangable db directly serving apps.