We recently ran a workshop with an educational institution to help set the strategy for their modernization initiative. This institution is not unlike most other organizations; they have a central monolithic application built over the course of 15 years that serves as the hub for every student interaction (course registration, billing, transcript request, etc.). As part of their initiative, they want to replace the core application with a 3rd party solution but will need to fill the gaps with custom software. That’s where we come in.

Nuvalence helps organizations design, architect, and implement digital platforms and our aim is always to empower and augment our customer’s capabilities with our experience. The organization engaged us to address some key points:

• What should the next ten years of development within the institution look like?

• What are the architectures that should be considered and embraced as the foundation is laid for these custom-built solutions?

• How to begin decomposing and modernizing what they currently have

As we thought through what the customer was looking for, we wanted to provide a systematic approach to modernization that would be easy to follow but provide them with a blueprint to quickly iterate over their system and start building. If you search online for decomposing a monolith, the number one approach that comes up is the “Strangler Pattern” which provides a high-level process to start breaking off functionality until there is nothing else to modernize. While conceptually this makes sense for the vast majority of applications, it often leaves teams without an answer to the modernization process of each component itself.

What we did is we took the concept of the “Strangler Pattern” and built upon it a decision tree on how to tackle each component.

As you start mapping out functionality within your application, you would run it through the following diagram.

As you can see from the diagram, this process flow allows the team to (a) build a dependency tree of the architecture and (b) decide on how to architect each new component.

Decomposing and modernizing 5+ years of application development does not happen overnight but with the right approach and frame of thinking, you can build a high-velocity loop to traverse your system, start developing and delivering value which in the end is what we all want!

Do you have any other approaches that have worked for you? Feel free to reach out erik@s44407.p1697.sites.pressdns.com or Twitter @elustgarten.