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). A large majority of monoliths are home grown “line-of-business” applications (LOBA). They house all the different problem domains that make up 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
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 case of healthcare, validating if prices will be paid by payers (insurance companies, Medicare, Medicaid, etc). Some times 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 its green field development. Most developers nowadays would build a simple “client-server” application because its fast to hit the grown running, easy to test locally, trivial deployment and development iterations can happen fast. Most of the time the very first version of the LOBA comes fast and 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 it takes longer and costs more to move the LOBA to the next version. 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. A lot of the times a hero developer emerges and is the single human that understands the LOBA. The company promotes the hero developer and the hero developer 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: down times, 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 it is harder for them to get an estimate on required changes to the LOBA. Executives quickly realize it’s time to make 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?
In part 2 of this blog post I will address the way companies can evolve their monolith line of business application during their digital transformation projects. I’ll be talking about 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.
