Modernisation Strategy Selector

Architecture Modernisation 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 modernisation will differ drastically across your business subdomains, so choosing the appropriate modernisation 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 modernisation 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 modernisation ROI for each part of your system (it’s creative commons and contributions on github are welcome).

Platform Modernisation

The Y-axis represents the level of modernisation 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 Modernisation

The X-axis represents the level of modernisation applied to changing the behaviour 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 modernisation, 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 Modernisation: Every aspect of the technology, functionality, and domain model is completely modernised 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 modernising a subsystem, e.g., a subsystem might have security or scalability concerns that could become a problem if not addressed
To find out more about digital transformation, click here.

Similiar Articles

JOIN THE COMMUNITY

Sign up today for monthly newsletters containing:

  • News and insights from your industry
  • Relevant thought leadership articles
  • Engaging video content
  • Notifications of our upcoming events
  • Networking opportunities with C-Suite leaders