In planning a digital transformation, the CTO of an organization has many decisions to make to reach the final state. In order to achieve the overarching goal of sunsetting a legacy monolithic system, one such decision is whether to go with a brownfield or greenfield approach. 

But that is the last stage, and we have a long road to travel to reach that place. There is a long lapse before the successful sunset, and it is perfectly acceptable to have the systems working midway. Typically, this means brownfield systems using much of the legacy monolith system, wrapped with a modern stack. 

In this article, we’ll share guidance on easing the journey from monolith to a modern system, developing a North Star architecture, and how to adapt if needed at different stages of your digital transformation.

Getting Started: Evaluating Your Options

Once you’ve decided to modernize, there are different paths you can take: move to a completely new system, wrap/refactor your solution, or side-by-side.

Figure: Modernization Choices – GL POV

A lot of the thought leadership on this topic focuses on successfully transforming architecture and new systems. However, there is very little discussion about midway systems. If anything, people tend to talk about the older monolith/legacy systems and the amount of baggage they carry. 

Recommended reading: Digital Transformation 101: Leveraging Technology to Drive Business Growth & Sustainability

But midways systems are complex and come with a lot of baggage. They can be labor-intensive and there are a lot of unknowns that can blow the budget. We’ve worked with many clients during this phase when their systems are midway and have learned important lessons to help make this a smoother process.

Many of these clients have started creating a greenfield system but modified the goal and decided to stay with the midway system for good. There are many reasons this may happen: 

• External threats or change. The pandemic is a great example where organizations found themselves having to invest to keep up with an upsurge in orders during or post-pandemic.
• Lack of adoption. During testing or MVP rollouts, the client may struggle to gain acceptance and adoption from users. 
• Cost factors. The budget runs out, and rather than having no system, clients stick to the half-prepared system, which still functions. This keeps the cash flowing, and the client decides to lose the battle to win the war at a later point in time.

We can indeed modernize the stack beneath before disrupting the actual user experience. This is when the entire monolithic system is not strangled. Seems like it is still alive while the engine underneath has been replaced. The harsh reality of such systems hits us hard – they are more complex than earlier and with more urgency to get to the other side.

The North Star Architecture

Moving towards North Star architecture is a Herculean effort and requires great perseverance. What’s more, a mid-way system needs more effort to maintain. So how do we move away from such a faux pas? 

Here are the steps that have worked for us in the past. A visionary enterprise architect with a strong understanding of the old and new systems can help to come up with a blueprint to achieve this. Use these simple steps to chalk out your blueprint.

1. Continue with such mid-way systems with elan.

Since the mid-way systems are not going away too soon, try to make life more bearable with such systems. Invest in transition technology which will make mid-way systems simpler to operate and maintain.

We partnered with a global leader in veterinary practices software, products and professional services having $4B revenue, in creating a future state microservice based Global Prescription Management (GPM) platform for International expansion with current serving of over 10,000+ practices in North America & ~100K Global Supply Chain customers. This was a Greenfield approach to solve the current struggle of existing monolithic systems.

Recommended reading: Benefits of Total Experience (TX) Strategy in Modernizing Applications

The transition to the new system needs time and we cannot stop the business as usual. That is what funds the new system as well. So, we decided consciously to gear up for the new system with pipelines in place to migrate the data two ways. By “two ways,” we mean the data gets synced from new system to old and vice versa. 

This essentially means that data is duplicated and maintained in sync for the sake of taking the step towards the transition to a new system. So, it looked something like this:

Figure: “Two-way” data sync

This pipeline will eventually sunset but it is worth the effort to keep the new system in sync with the old system and vice versa. The advantage we receive is a breather in our transition, when the enterprise looks at the more tasks in hand to move to a new system, adjusts the budget and timelines and overall makes life a bit easier because things are still running albeit with higher costs. The good news is the shop is still making money.

2. Build the orchestration layer.

The next step is to build an orchestration layer which will route the traffic from existing front end applications to the new backend systems. This layer will make sure users of the system will continue to have a seamless transition. In the background the old system has been replaced but users are still not impacted. Again this step can be executed by different deployment strategies like blue green deployment. And since the data is always synced in the background, you can make a switch back in case of any issues with the new system. 

Figure: The Orchestrator Layer

While creating the set of APIs in the orchestration layer, architect it to be futuristic. The orchestration layer remains in the new system as well and is not a throw away code. For doing so, if there is a need for a wrapper layer or an adaptor for the legacy front end, let it be. This will be a throw away code but still will live its short life to glory. This is because it will keep the design for your orchestration clean and pristine.

3. Bite the silver bullet and migrate to a new system.

There is no easier way to do this than bite the silver bullet now. Create the new modern UI with your technology of choice and make the modern UI talk the same language as the orchestrator service. Phase out the old system in batches. Do an alpha test run, then select a cohort of beta users to migrate and finally the complete set of users can be migrated. This gives enough runway for the final launch.

Sometimes, migration to a new system requires more planning and effort than building greenfield applications. Such a big problem requires that we have to break it down into smaller problem statements and fix smaller problems one at a time. This may be as simple as on-premise to cloud migration and also may involve complex business rules to be applied for the transformation. 

For instance, in our client’s case, we built a custom microservice whose sole responsibility was to ingest data from all disparate sources and place it in the final destination. This service had one time use but was easy to manipulate according to the business rules of transformation.

Figure: The final go live using custom Migration Engine

Conclusion

The monolith legacy system has lived its lives, and strangling the entire monolith is a humongous task. There are solutions to help ease the journey towards the North Star architecture. It is wise to invest in them early and use your budget to make lives simpler. 

These mid-way system patterns are there to simplify your journey, and making use of them will help you avoid the faux pas of strangling the monolithic systems. GlobalLogic’s Digital Advisory & Assessment can help you in your journey from the monolith to a digitally transformed architecture to choose the right path, simplify steps along the way, and reach your end goal with a successful, sustainable solution to take your business forward.

More helpful resources:

• Improving Digital Transformation Outcomes with Hyperautomation
• Detecting Architectural Gaps with Automation (whitepaper)
• A Guide to Composable Applications & Packaged Business Components (whitepaper)