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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to The Monolith

  1. Mickael says:

    “Must be versioned and deployed as a whole “…sounds ok. BTW Versioning is a tricky part for distributed systems.

  2. Fernando says:

    Nice post.
    Then, the natural question follows: How do we architect non-monolithic systems ?

    The newest round of technologies such as WCF, LINQ (especially LINQ to SQL), and ADO.NET Data Services promote and enable non-monolithism. However, it seems that everyone and their brother (not your case) blogs and/or writes books on the technologies for the technologies sake.
    What’s missing are examples of the design of simple, end-to-end systems that leverage decoupling/non-monolithism with these modern technologies.
    I haven’t found yet any books/blog posts/MSDN articles targeted at the independent developer (e.g. Micro ISV), freelance IT consultant or architect that “coaches” him throughout the thought process required for the successful design and implementation of such non-monolithic solutions.

    What would you recommend ?