This discussion led me to reflect on my work as a business analyst and team leader over the past five years. I realised that a significant portion of my time had been dedicated to application modernisation projects, but contrary to the common perception, we had approached these projects in various ways. In fact, out of all the modernisation efforts I had been involved in, only one followed the "big bang" approach.

Recently, I came across an insightful presentation by Sam Newman on Monolith Decomposition Patterns https://www.youtube.com/watch?v=Q8Uw7iZDQbw

This talk shed light on the challenges and strategies involved in modernising monolithic applications, and it resonated with my own experiences and the "aha!" moment I had about the importance of choosing the right approach.

For those unfamiliar with the term, a monolith is a single, large application that contains all the functionality of a system. While monoliths can be well-structured and modular, they often become difficult to maintain and evolve over time. This is where application modernisation comes in, and where Sam Newman's insights are particularly valuable.

At Enlighten Designs, our preferred approach to monolith decomposition is the Strangler Fig pattern. This pattern involves gradually replacing functionality in the monolith with new services, while still keeping the monolith operational. The new services "strangle" the monolith, taking over more and more of its responsibilities until the monolith can be safely retired.

We favour the Strangler Fig pattern because it allows for a controlled, incremental modernisation process. By focusing on small pieces of functionality at a time, we can mitigate risk, get faster feedback, and deliver value to our clients sooner. It also enables a more gradual transition for users, as they can start benefiting from new features and improved performance without having to adapt to a completely new system all at once.

However, the Strangler Fig pattern is not without its challenges. One significant complication arises when dealing with join operations. In a monolithic architecture, joins are typically performed in the database, which is highly efficient. But when functionality is extracted into separate services, those joins need to be handled at the application level, which can lead to increased latency and complexity.

To tackle this issue, we employ a range of strategies. One approach is to denormalise data, storing redundant information in each service to avoid the need for joins. Another is to use event-driven architectures and eventual consistency, allowing services to communicate and synchronise data asynchronously. In some cases, we may also choose to keep certain tightly coupled functionality together in a single service, rather than splitting it apart.

By carefully analysing the data dependencies and access patterns within the monolith, we can make informed decisions about how to decompose the system while minimising the impact of distributed joins. It's a balancing act, but one that pays off in terms of improved scalability, maintainability, and agility.

If your business analyst is considering modernising your monolith, I highly recommend exploring the Strangler Fig pattern and reaching out to us at Enlighten Designs. Our experienced team can help guide you through the process, from identifying the right decomposition strategy to implementing and deploying your modernised system.

For more content on Modernising Legacy Applications visit out website at App Modernisation (enlighten.co.nz) or sign up for our 2 hour speed roadmap session below.

Remember, application modernisation is a journey, not a destination. If you are a Brandon Sanderson fan like myself think 'Journey before destination'By embracing incremental decomposition and proven patterns like the Strangler Fig, you can set your organisation on the path to a more agile, adaptable future.