A modernization strategy connects changes to software architecture and ways of working with business outcomes. It gives stakeholders a reason to invest, then guides which initiatives to prioritize and sequence. Technology choices and fashionable architecture patterns are not goals in themselves. section 2.2.3 section 16.0
Invest where software differentiates
For a transport company, software that optimized freight loading and calculated live arrival times helped win business, retain customers, and reduce costs. Its invoicing system offered little competitive advantage. Both needed to work reliably, but they warranted different levels of modernization investment. section 10.1
Choose a strategy for each part of the portfolio, rather than prescribing one transformation for everything:
- Ask whether the supported business capability differentiates the organization. Invest more where better software can create more value; keep utility software reliable without assuming that more features will pay off. section 10.1
- For each subdomain, weigh the return against the cost and delay of deeper modernization. Options range from exposing existing functionality or polishing it to replicating, remodeling, or rethinking it. section 12.4 section 12.4.1
- Account for migration constraints. A tightly coupled monolith may first move as a whole before its subdomains can follow different paths; migration need not be a big bang. section 12.4.1
Use the Modernization Strategy Selector per subdomain to compare how much to change the code’s behavior and design with how much to change its technology. section 12.4.1
Develop the strategy with business and technology participants; a Wardley Mapping session can help them explore the connection between architecture and business goals. Turn the resulting vision into an evolutionary roadmap: deliver a small first slice, check whether decisions produce value, and adapt. Different parts of a product may need their own roadmaps tied to the larger purpose. section 2.2.3 section 16.0 section 16.5
