The Monolith

The Monolith is probably one of the most common ways people structure systems these days. While this is probably a valid way to build a large majority of small systems, for others, it causes quite a bit of pain.  I would imagine a large number of people don’t realize that it’s not the only way to build systems.

Your typical n-tier or client/server system is a monolith.

Let’s look at a few characteristics of the Monolith:

• Is hard to integrate.  The Monolith prefers to be an island of data.  When the technical problems of integration are solved, you still have data ownership issues.
• Is a poor base for a product line.  Putting pebbles on top does not result in a system with a Cohesive View.
• Is hard to scale.  This usually isn’t an issue until it’s already too late.
• Is easy to grasp mentally.  This is a positive aspect of the monolith.  Developers are inherently familiar with it.
• Is cheaper and faster to build initially than its non-monolith counterparts
• Large changes must be made at design time by a developer
• Reusing internal assets is tedious and requires much effort
• Will succeed or fail as a single unit
• Can not be used to mitigate against a risky language or runtime platform
• Platform or language migrations must happen all at once.  Rewrites are all or nothing.
• Must be versioned and deployed as a whole
• If selling or deploying for multiple user bases, it represents a one-size fits all solution
• May exhibit design-time modularity, but not runtime modularity
• Is either fully available (up) or completely unavailable (down)

In terms of business concerns, we can characterize the monolith as:

• Quicker to market (than it’s non-monolith counterparts)
• Targeting related markets is slow and/or hard as it requires building new monoliths
• Acquiring new monoliths often results in a non-cohesive mess
• Will likely require a full rewrite at a point in its future (even in an Agile team).  This means a shorter lifetime.  A shorter lifetime means the costs must be recouped over a shorter period of time.
• Tied to a particular customer size.  If the monolith targets the large customer base, it will likely be unwieldy and/or too costly for small customers.  If targeted at small customers, the reverse is true.  One size fits all.

If I had to guess, I would say that monoliths are often built even when they do not provide a good fit for the System, Product, or Business Needs.  Building a non-monolith system requires a shift in thinking–a shift that’s not always quite so obvious at first.