CVP Modernization Framework: Slay or Split the Monolith (Pt. 2 of 3)

by | Jan 18, 2018

In our previous blog post in this series, we talked about the first prong in our three-prong modernization approach: Make the Shift to Continuous Everything. In this blog, we will discuss the second prong: Slay or Split the Monolith.


Slay or Split the Monolith

What is a monolithic system? In short, most IT systems are monoliths. From the perspective of other systems within the organization, a monolith is a large, unitary black box that performs a tightly coordinated, integrated set of steps. The different features of the system directly connect to one another, are optimized to work together, and use internal communication procedures that only the software developers know. A good example of a monolithic system is the traditional IT used by banks.

Let’s envision for a second the IT needed for a local bank. The teller terminals and desktop PCs run a desktop application that allows them to look up customer information, deposit money, and perform other routine tasks. ATMs, while vastly different on the outside, are not terribly different under the hood. They are likely running Windows XP and use XFS to communicate back to the central transaction system, similar to the terminals and PCs. Additionally, the bank has a website targeted at home PCs with a Java back-end that has a custom set of programs to interface with the back-end system.

Now suddenly it is the 21st century and the bank needs a mobile app. Given their current system, they can’t:

  • Use their desktop software like in the branch because customers don’t want to install programs and the bank doesn’t want to support the patching of it
  • Use their traditional website, because it is written for 15″+ monitors and doesn’t use Responsive design.

They have a monolith.

The bank’s traditional systems cannot expand to keep up with the demands of the increased rate of change and innovations in technology. They now need to build middleware with which the mobile apps can communicate. This is an expensive undertaking, and now means they have four different systems feeding data into a customer’s balance: the in-branch software, the ATMs, the website, and now the mobile app.

They need to slay (remove) or split the monolith!

Now, for a second, let’s assume they have a microservices architecture. Instead of a large black box, the different pieces of the back-end system have been decomposed into loosely coupled, interoperable subsystems, all communicating over open, well-documented RESTful APIs. Instead of undocumented procedures, they use highly tested interfaces via web service calls that all modern device or programming languages now support. When an ATM, teller, bank manager, or mobile app wants to know a customer balance, they:

  1. Prepare a “GET” request to an API endpoint with a friendly name like /customer/balance.
  2. Pass a session token and an account ID.
  3. Receive back a JSON object with the customer’s balance information.

If in 2019, the bank wants to make a new customer balance widget for a augmented reality headset that doesn’t run iOS or Android, the developers simply need to look up the API specification for getting a balance and they can have the same, reliable data with a few minutes of setup.   

This is a way to keep up with advancements in technology and processes, or continuous improvement. And we haven’t even discussed the other benefits of a microservices architecture yet, which include:

  • Ease of development – Have you ever been a programmer on a 20-year-old monolithic application with 100,000 or more lines of code? No one person understands the full application and any change becomes risky for regression.
  • Ease of scalability – When an application is decomposed into smaller parts, the parts can be individually scaled up or out instead of having to vastly overprovision the monolith for rare events.

Migration to the next generation architecture can require organizations to slay or split monolithic applications that do not support interoperability. The key here is the development of a carefully thought-out technology transition roadmap to move from the legacy, monolithic applications towards a group of purpose built modular services using various appropriate architecture and design approaches. These technologies may include microservices, APIs, distributed ledgers, or containers.

At CVP, we develop such transition roadmaps based off a detailed analysis of the current state and the customer’s future vision. Our approach is to arrive at an optimal balance of the modernization implementation patterns including re-architecting, remediating or re-factoring, re-platforming, and/or retiring the legacy applications/environments.  In some cases, we can use our pre-defined solution frameworks to accelerate this process. Through these frameworks, we help our customers adopt the right way to get to the Minimally Viable Product (MVP) to help realize immediate value while minimizing development costs.

A combination of understanding our customer’s needs and keeping up with constant change and advancing technologies along with approaches like slaying the monolith help maximize benefits for our clients. But we don’t stop there.

Be sure to read our last part of this three part series to understand how to boost value even further by building an adaptable infrastructure.


by Raj Hegde, Cal Zemelman, and Shamaa Ahmad

Pin It on Pinterest

Share This