Modernization Strategy Selector
Architecture Modernization is far more than just rebuilding the old system with new technologies and the latest architectural patterns. It’s an opportunity to completely rethink the UX, product functionality, business processes, and the domain model (and remove unneeded complexity).
But a portfolio-based approach is crucial. The ROI of modernization will differ drastically across your business subdomains, so choosing the appropriate modernization strategy for each subdomain is key.
A lift and shift approach may be suitable in subdomains with little potential for future innovation. Over-investing in low-value subdomains will result in increased costs and modernization taking longer, while drawing away investment from your crucial strategic core domains.
The Modernization Strategy Selector, discussed further in my book Architecture Modernization, can help you to choose the optimal modernization ROI for each part of your system (it’s creative commons and contributions on github are welcome).
Platform Modernization
The Y-axis represents the level of modernization applied to the technologies used to build the subsystem. It includes:
- Infrastructure: e.g., from on-prem to the cloud or from VMs to Serverless
- Programming language and runtime: e.g., from C# .NET to Kotlin on the JVM
- Data storage and integration: e.g., from Oracle SQL to a Mongo DB and Rabbit MQ
- Libraries and frameworks: e.g., adopting new web frameworks, persistence frameworks, and testing frameworks
A simple option for producing an overall score is to choose high (3 points), medium (2 points), or low (1 point) for each criteria above.
Product, Domain, and Software Modernization
The X-axis represents the level of modernization applied to changing the behavior and design of the code so that it provides more value or is easier to work with. This is more of a range:
- Expose: Making existing functionality from the legacy subsystem available to other subsystems (e.g., by creating an API or publishing an event), with the least amount of effort and invasive changes possible
- Polish: Cleaning up some of the low-hanging technical debt without addressing more fundamental issues
- Replicate: Rewrite the subsystem maintaining the existing functionality but cleaning up all the technical debt
- Remodel: Rewrite the subsystem maintaining existing functionality but investing in a complete redesign of the domain model so that it is easier to evolve
- Rethink: The functionality and domain model are totally recreated from a blank canvas, typically involving large amounts of user research and domain discovery & modelling
Example Strategies
The following are some example strategies. This isn’t an exhaustive list, so don’t feel a need to try and fit what you are doing exactly into one of these:
- Sunset: The subsystem will be discontinued and shutdown (there is no modernization, but this could still involve a large amount of effort and risk)
- Maintain: Try to keep the current subsystem running for the least cost. There will still be some effort involved in keeping the technologies up to date with the latest security patches etc
- Legacy Encapsulate: As above, but expose the legacy capabilities to other subsystems
- Legacy Polish: Similar to the above but also addressing small amounts of technical debt
- Extract and Remodel: Pulling a subsystem out of the legacy system and rebuilding with a brand new domain model (existing functionality and tech stack remain largely the same)
- Lift and Shift: Move the current code onto new infrastructure with minimal or no changes to application code
- Lift and Reshape: As above, but cleaning up some parts of the code so that new features can be added more easily or it runs more reliably in production
- Rehost and Remodel: Rebuild the system with a fresh domain model and deploy to more modern infrastructure, using largely the same programming languages and frameworks
- Total Modernization: Every aspect of the technology, functionality, and domain model is completely modernized to the highest degree possible. Likely to be a very expensive option but justifiable for subsystems that are a major source of competitive advantage or innovation.
Caveats
- This model is a bit of an over-simplification in the assumption that effort, value, and risk all increase the further along each axis you move, e.g., sometimes a rewrite is less risky and less effort than making changes to the legacy
- This model does not capture the risk of not modernizing a subsystem, e.g., a subsystem might have security or scalability concerns that could become a problem if not addressed
If you have modernization challenges and would like me to help, get in touch
