I've been involved in a number of attempts to rewrite systems that ticked all of the boxes of Mythical Man Month's second system effect. The main things I've l

I've been involved in a number of attempts to rewrite systems that ticked all of the boxes of Mythical Man Month's second system effect. The main things I've learned over 40 years: * Rewrites will fail. Whether they're called that, or called "lift and shift" or called "refactoring" * The reason they fail is because the focus is entirely on the technology, not the users and how they use the systems * Understanding business systems and users and how they interact is vital. Business processes haven't changed, accounting hasn't changed, company hierarchies and competitive markets haven't changed. * What has changed is that where people used to be the "API" for a process touchpoint, now that is likely to be another system, and will have its own API which expresses how it sees the process. Trying to "force" those systems to interact with yours in the way you want is a fools errand. * Abstraction is really important when defining business domains. "Sales" vs "Fulfilment", "Payment" vs "Charging", "Data" vs "Information", etc. * Software can't solve all of the possible implementations of the business domain abstractions. You have to set constraints to limit the number of "configuration" elements. Things like "Sales are always retail to end user consumers so that we don't have to deal with VAT exclusive invoicing". * Those constraints need to be agreed to by the product owners/managers of the domain. Otherwise, every potential requirement will add yet another "knob" to the control of the domain, yet another testing path etc.