Monolithic Applications: a 1970s problem; still a 2020s challenge; What to do with Technology Debt

Monolithic applications are with us today because they either do the job (Etsy) or because successive applications of new paradigms have failed to yield a different result. Inevitably, the paradigm is blamed rather than the application of it. We need to address the real problem which is resistance to change rather than settling for the status quo.

Let’s mark the birth of monolithic applications as April of 1965 with the first shipment of the IBM 360. It might be earlier, but for the purposes of this discussion that is far enough down the geologic strata to make the point. It’s more than 50 years. And for most of those 50 years we have been introducing one solution after another to the challenges inherent in monolithic architectures – large applications that are brittle and resistant to any level of significant improvement.

If the challenges were simply technical problems we could add them to the list of technical debts we have accrued and move on. But it is the impact to “The Business” that compels us to keep trying. The Business says they need new functionality. We have to say we can’t because that would impact other critical functions. The Business says we need to reduce cost. We say we can’t because we are tied to a legacy platform and it would cost millions and take years to re-platform. The Business says security is a top priority. We have to say we’re stuck with a business critical application on an out of support platform.

Monolithic applications only started with the mainframe. The skills learned building them turned out to be almost infinitely transferable. College kids today are quite well versed in this architecture pattern. Not surprising since many CS programs are supported by enterprises that need a fresh pool of resources to replace the retiring practitioners of the ancient arts.

The Business is constrained by an architectural pattern that was born decades ago. An incomplete list of proposed solutions would contain procedural programming, modular programming, object-oriented programming, service-oriented architecture, web services and microservices. The last being the current darling that has not yet delivered on the promise of software that runs at the pace of business.

The point is that any of these ideas could have improved the challenges presented by monolithic applications. They have not delivered because they tend to be poorly understood and thus poorly applied. Discussions of changing paradigms are littered with phrases that start with the word “can’t”. Can’t do that because of security. Can’t do that because the database… Can’t do that because we don’t have the skills. The bottom line is we resist change.

But of course we can change. And the first thing we need to change is our concept of the solution. How can it be that an industry with so much talent has not solved this problem. This suggests that we are going about this the wrong way. We need to drop the search for a magic wand solution in the form of a new technology paradigm and begin to figure out how to change.

In this Town Hall Meeting, the ONUG Board invited leading CEOs, CTOs and GMs from the vendor and cloud community to engage in an industry discussion, during ONUG Digital Live, May 6-7, on what to do about technical debt rooted in monolithic applications. As the pace of business innovation driven by new technologies continues to increase, the time to respond to competitive threats shrinks. The technical debt taken on over decades needs to be retired.

Join us for ONUG Digital Live May 6 – 7 for FREE ($695 value), and watch today’s digital revolution unfold before your eyes as the ONUG community presents roundtable discussions, keynotes, proof of concepts and panel sessions on an interactive, state of the art digital platform. Plus leverage the Q & A capability to get answers to some of your most pressing enterprise cloud challenges.

Author's Bio

Mark Eisenberg

Mark Eisenberg

Application Development Manager, Microsoft