A possible modernization risk is slower delivery without a clear single cause. Structural assumptions are one area to examine alongside staffing, dependencies and changed requirements. A domain model that no longer matches the organisation can make new features harder to implement.
The symptoms are organisational before they are technical
- The same business concept has three names across three systems, and reconciliation is a job someone holds.
- New reporting requests require an export and a spreadsheet, because the relationship the question depends on is not represented.
- Integration mapping takes unexpected effort.
- Shadow spreadsheets carry state the system cannot hold.
What actually went wrong
Some models are shaped around initial screens rather than enduring domain entities. That works while the screens and the business agree. When the business changes shape — a new channel, a new regulatory class, a second operating region — the model cannot express the change, so the change is expressed in application code instead. Do that a dozen times and the code becomes the model, distributed and undocumented.
The correction is bounded, if it is deliberate
Full rewrites can carry substantial delivery and migration risk. Incremental replacement may reduce risk where suitable: establish a corrected model alongside the existing one and migrate a bounded capability at a time. A rewrite can still be justified by constraints and evidence; choose the approach after reviewing dependencies, migration and recovery.
Decide these four things first
- The entities the business actually transacts on, named as the business names them.
- Where authority lives: which system is the source of truth for each entity, with no exceptions granted informally.
- The access boundary: who may see and change what, enforced in the database.
- Events needed for an agreed purpose, with minimisation, access and retention limits; do not retain everything permanently.
Delivery problems merit investigation across the domain model, people, dependencies and operating constraints.
Further reading
Primary references for relevant design principles, not evidence of DeftSpan deployment, certification or measured outcomes. Read these in context: general safety guidance cannot remove all risks, and privacy-risk guidance is not certification.