How to go to Headless from a Monolith

The problem that we are faced with today, is that for decades building monoliths really was the right approach and now many of us are left to deal with the consequences. In my last articles, I discussed how and why cycloptic monoliths are completely useless in fulfilling the demands of today’s multi-headed hydra experiences. Cyclopes are roaming our technical landscapes and given that they cannot be hydras how can we deal with them and move to the right platform we need to deliver the hydra UX.  

Beheading the cyclops

Going headless means removing all forms of presentation (e.g. HTML rendering) from the content, data and functionality you deliver to the front end and replace it with a set of REST/web-based APIs. The pattern here is to wrap the monolith in REST APIs so that you can decouple the frontend from the backend business logic. This lets you build multiple heads for on top of those APIs.

Headless systems are the foundation for delivering the digital architectures of the.  Often the first approach taken by technical architects is to go full Game of Thrones, sharpen their large Valerian steel swords and cut off the head of the monolith. Although the process is not so dramatic as it often requires months of mind-numbing development to refactor the backend systems, slap on an API layer, and rebuild the current frontends - hopefully in a modern JS framework.

For our customers, this is often the starting point on the journey towards a new architecture as it reduces risk and has plenty of quick wins 

Pros

• Reuse of existing business rules and logic
• No change to back office UI and processes 
• Integrations into business-critical backend systems and 3rd parties remain intact 
• You can build other heads based on a common set of APIs
• You can build a new web experience using modern front-end technology

With this approach, you are ultimately still left with a monolith providing the backend where all the systems in the monolith have fused together over time creating a spaghetti of interdependencies throughout the platform.  

Cons

• Inflexible monolith platform means very slow and difficult to develop backend reducing agility
• The APIs are often specific for existing UX and not be designed for wider use cases 
• Loss of features as gaining complete API coverage is often not feasible 
• Scaling and maintaining independent areas of the system is impossible 
• Despite being decoupled, you may find functionality often slices through every layer from frontend to the database resulting in tightly coupled but separate applications
• The data models and content models will not be flexible enough in these older systems to fulfill the interactions required by the UX hydra 

Strangulation 

One of the benefits to the headless and API first approach is the ability to implement features and functionality in gradual steps. There is no need to go for full platform replacement day one, you simply choose to replace the parts of the system that have the most pain or are necessary for other Apps and experiences. The approach is to gradually replace pieces of your system with new services. Over time, the old platform will slowly suffocate and a new microservice platform will emerge..  

This sounds great and you could say a rehash of the old standard phased approach and in some ways it is. However, it’s the application of this approach with the tech of today that makes it interesting and really plays to the strength of the hydra UX. Here are some examples: -

• Rather than replace your eCommerce platform all at once why not replace just the checkout first. Implement a new checkout microservice and build a platform dedicated Single Page App (SPA). Now when a customer clicks checkout just reroute to the new App. This SPA can be used in any other web-based experience and the Microservice can be implemented with any other non-web technologies – following this, move to other areas like basket and the product details page. 
• If rebuilding the entire front-end to improve the UX and add richer content is too risky why not implement a headless CMS and inject content into slots across your current experiences. This way you can progressively target areas of your existing experiences and reuse this content consistently in any other UXs and architectures – as the content is headless it can be reused when you decide to switch to new front-end technologies 

Pros

• Low risk as the base platform remains intact. Discrete functions are replaced outside and around the monolith –and these services can be delivered by SaaS vendors rather than being built from scratch
• Building multiple heads for a single application like an e-commerce site prevents developing a monolith in the front-end. 
• Faster more agile development as each area can be developed, tested and released independently of each other
• Reuse of all functionality and content into other types of UX – gradual formation of a UX hydra
• Perfect for progressively building a new Headless Architecture 

Cons

• Long term costs for development could be higher than doing all at once 
• Need to focus on ensuring the individual development of SPAs provide consistent UX across the wider applications
• Building a microservice architecture is difficult and easy to get wrong. You need to have solid devops and processes or you risk swapping one maintenance problem for another.

Big Bang

No list of development approach is complete without the big bang. If you are an adrenaline junky and like to live life on the edge, then this is the approach for you. Basically, you build a completely new headless architecture from the ground up while running the old monolith system in parallel and when it's ready you just take a deep breath and flip the DNS switch. If it doesn’t go bang and just fizzles out, you can always switch back – assuming you haven’t taken any orders in a completely different system.

Pros

• Lower development cost to the final goal – the UX hydra
• Full architecture available day one to build all the UX heads you need for all your digital experiences 
• Benefit from a much more flexible extendable architecture earlier for developers although business users don’t realize the benefits until the release.
• Starting fresh lets you choose the best technology for the job, combining Multi-tenanted SaaS vendors with homegrown services and apps.
• Independent services, SPA, and Apps promotes product development as opposed to project development – ultimately UX improves across all your touch points 
• No legacy to maintain and support

Cons

• Its high risk developing, integrating and standing-up an entire working system architecture 
• Your existing platform will be neglected, potentially letting competitors get ahead.
• Integration with backend systems ERP, CRM, Logistics need to be revisited ensuring business logic is fully maintained
• Extracting the Inherent business and operational logic across an entire system monolith that has evolved over many years is very tricky
• Mass migration of data and content to be synchronized at go-live could be problematic

All these approaches are used in the wild but rather than purely following one approach our customers use all three approaches at varying levels and at different points in their move towards a fully headless architecture. 

1. Replacing content areas in the monolith using our headless CMS and reuse this content in new SPAs and native Apps – going forward all content for any will be delivered from the headless CMS
2. Cut off half the head of the commerce platform and start moving towards a front-end framework such as React
3. Start building out a full Headless architecture and at the same moving areas such as checkout and basket away from the monolith
4. Start building out the UX heads that the monolith couldn’t manage
5. Rather than wait for the Cyclops to strangle completely make a full switch to the new architecture when you confident its ready

When you make the decision to move to a headless architecture you need to decide what the is the ultimate goal for the business (hydra based UX?), your target digital architecture and shorter terms objectives. Then given the resources, appetite for risk and short terms objectives create your own headless approach cookbook and plan based on the three approaches I outlined.