Modernising the monolith: our experts’ insights

Monolithic applications are becoming an endangered species. They appeared for a number of very good reasons – not least the single codebase helping to simplify initial development. Now though, it’s safe to say that most companies are moving towards modern-era microservices. 

With so much ‘accepted thinking’ about monolithic applications, we thought it was time to debate why they’re under threat, and the best ways to modernise today from a software engineering, delivery, and product perspective.  

We turned to 101 Ways’ Engineering Principal Ray Parkar, Delivery Principal Anikh Subhan and Product Principal Oliver Happy for the answers. 

Here are the highlights.

What’s modernisation going to do for me?

No-one is ringing the death knell for the monolithic application just yet. This hefty, indivisible piece of software has its advantages. But its cons can’t be ignored, and application modernisation across businesses worldwide is advancing rapidly. 

As the team shared on the Team Takeover podcast, modernisation, and the move to microservices, is a pivotal moment in the evolution of any organisation. It requires a new mindset and comes with tough decisions; hence we often see a tendency to kick the whole modernisation can down the road. 

The cons of monolithic applications are well known. They create bottlenecks. They can be brittle. They’re not designed for a world of 20-30 software deployments a day. Still, as the team argue, these applications have much to offer if a business is essentially one product, like a note-taking app, and engineers up and down the stack work more efficiently from the same code base.

Monolithic and modernisation mindsets diverge

According to the panel, working on monolithic applications tends to be output rather than outcome-focused. The health of the tech stack takes a back seat, and technical debt grows. From experience, the team flags the sense of disempowerment this working practice creates, which isn’t great for morale. 

Modernisation changes this approach. Outcome trumps output, reflecting a greater emphasis on value across the broader business. Barriers dividing engineering and delivery teams come down, and a sense of ownership and collaboration pervades. 

Modernisations do go wrong, however, as Ray makes clear. It’s not unknown for companies to start breaking down their monoliths and creating autonomous teams to manage microservices, only to discover they are now in a worse position than before. 

To avoid the pitfalls, start by defining standards and strategies for a successful modernisation — and grasp that modernisation is a long-term strategy. Indeed, in its truest sense, modernisation has no endpoint since it’s about continuous improvement.

Achieving a microservices nirvana

A big-bang approach is unlikely to work. See what happens if you tell development teams to down tools for 18 months while modernisation occurs. Expect some choice words. The truth is that part of the old monolithic estate can probably be scrubbed because organisations don’t have to modernise everything. As the team points out, any form of modernisation is a great opportunity to streamline code.

Any possible doubts about the inefficacy of the big-bang idea were put to rest by one comment from Ray about the pace of technological change right now. Place a moratorium on platform development for even a few months, and a business could be handing an advantage to its competitors that may be impossible to overcome.

Getting modernisation right

The conversation ended with the team sharing ideas on how to maximise the long-term value of modernisation. At a high level, the guys advocated an incremental approach rather than pursuing modernisation end-to-end. 

Good planning was highlighted as a must-have, with every team having access to a single source of truth to know what’s expected of them. Only when teams are fully aligned can work progress effectively. The importance of having a “vision” was also discussed – balancing product strategy against today’s technical realities and tomorrow’s potential architecture. So teams have something specific to work towards. 

Problems will undoubtedly arise along the way. However, overcoming issues will be easier because of the collaborative atmosphere created. Stability or scalability concerns, for example, can be discussed and ideas given practical, iterative consideration. In a world of microservices, engineering, delivery, and product teams all have a real voice. And that makes unlocking true progress much simpler.

Don’t neglect the art of listening

A period of study that includes listening to the teams working on the legacy technology stack is beneficial, say all three podcast participants. Observe the ways the teams are working together and note any apparent siloes. Reconfiguring those teams for microservices so each one has the right skills and capabilities will determine your eventual results. 

And remember, you don’t have to have your route completely planned out. Modernisation is about iteration and flexibility, achieving continuous gains and creating business value while you’re doing it. Ultimately, it’s about recognising that building and running the tech estate is an ongoing process – not a big bang event.

Looking for tips on your modernisation journey? We can help. To hear more from industry experts like Ray, Anikh and Oliver, check out our Team Takeover podcast.