The Monolith
Monolithic applications are everywhere. Many companies can’t function today without them. Some are the products a company sells, while others are the legacy (15+ years old) “off-the-shelf” applications that are the heart and soul of the enterprise (e.g. ERPs, EHRs, CRMs).
Most monoliths are homegrown “line-of-business” applications (LOBA). They house all the different problem domains that comprise the company’s business model. They have tailored workflows specifically for the company’s processes. They are the company’s secret sauce and special spices. The LOBAs have allowed for growth from a startup company into a multimillion-dollar enterprise.
The Birth of Monolithic Applications
At some point, successful, evolving companies realize that the organic business processes they have grown are inefficient and take too long. Take for example, a company the configures, prices, and quotes products. Their products may be incredibly complicated. Their CPQ process may take days. Why? Because of the sheer number of parts that make up the product, the rules around compatibility, the variations of cost for each part, regulations, and in the case of healthcare, validating if prices will be paid by payers (insurance companies, Medicare, Medicaid, etc). Sometimes, these problems can be handled by ERPs and CRMs, but often times, these applications are too generic to meet the needs of the business.
To address this, many companies will choose to build a “line-of-business” application (LOBA) precisely tailored to address the problems and fill in the gaps for their ERP. They gather subject matter experts, department heads, and information technology resources to build the LOBA fast and within a budget.
Usually, the initial requirements are to address a single part of the overall business process. This is done to get a “big win” and address a single area in the process of most pain. This works out well because they are starting from scratch, and it’s green field development. Most developers nowadays would build a simple “client-server” application because it’s fast to hit the ground running, easy to test locally, and trivial deployment and development iterations can happen fast. Most of the time, the very first version of the LOBA comes fast, addresses a single need, and is successful. The monolith is born.
The LOBA is a big hit with management. Quickly, there are plans to add more and more to the LOBA. In the above example, “configure, price and quote” (CPQ), the company decides to stuff even more of the business process domains into the LOBA. The company adds domain aspects from Order Management, Product Catalog Management, Inventory Management, and Delivery Management. Slowly, the LOBA development process becomes a tractor pull.
As more is added, moving the LOBA to the next version takes longer and costs more. The big wins are no more. The LOBA has large amounts of “code debt” and complexities. A change in one problem domain breaks other parts of the application. Often, a hero developer emerges, the single human who understands the LOBA. The company promotes the hero developer, who adds to their team to help maintain the monolith.
Executives start to grow concerned because the IT cost of the LOBA is high. They also hear from department heads about the problems: downtimes, performance problems, errors in the data, and the big one, “We need more staff to do our job.” Also, they find it hard to make strategic decisions because getting an estimate on required changes to the LOBA is harder. Executives quickly realize it’s time to make a significant investment in the company to take it to the next level. So begins the “digital transformation project” journey. The question arises during the early phases of the project. How do we upgrade the LOBA and do it in a way that helps us get as much ROI from it?
Part 2 of this blog post will address how companies can evolve their monolith line of business applications during their digital transformation projects. I’ll discuss how companies can break them apart along business problem domains, moving them out into separate micro-services. Finally, I’ll touch on how they can use Microsoft Azure technologies and enterprise design patterns to take a measured approach versus a Big Bang approach.
