Accidental Architecture: Fatal Attraction Of The Hourglass

June 16, 2009 at 12:48 am Leave a comment

Inspired by,  I was doodling to find a notation to describe evolution of software architectures over time.  A number of database-centric systems I have seen in recent years could be depicted  along the lines of:



1. The designers put a layered architecture with UI, service- , business- and data tiers in place. This produces:


2. Implementation proceeds. Time is short and developers have not had sufficient opportunity to learn about the intentions of the designer(s) (or their own, if they happen to be the designers) and practice applying object-oriented techniques. This leads to:


In effect, this is an accidental move towards the Transaction Script pattern, complicated by the need to work around the original architecture. Key characteristics are:

  • Service- and business tiers which do little except calling the tier below in order to move data between the UI and stored procedures where the actual logic resides. Typical reasoning which leads to this is that there seems little point in passing data back and forth between the DB and the rest of the application – we’d just get more network traffic and nothing much is being done in the middle tiers anyway (a self-fulfilling promise), so one might as well do more in stored procedures.
  • Over time, functionality related to user input validation, non data-centric business logic and (in non-MVC designs) control flow accumulates in the UI tier. The reasoning here is that in cases where there is little or no data access involved and where there is no domain model with obvious candidates where the functionality should reside (see above,  “self-fulfilling promise”), one might as well put it there.

3. Over time, this perpetuates the already inherent tendency towards an  Anemic Domain Model and leads to a gradual slide towards the Smart UI Antipattern, resulting in an  hourglass shape:


A lot of code resides at the top (in the UI) and there is a lot at the bottom (in stored procedures). The middle is anemic and sickly.

I have never seen a case where this devolution over time didn’t lead to a lot of coupling, code duplication and lack of cohesion. As a result, maintenance and enhancements became time consuming and expensive.

I suppose one could depict a successful refactoring and subsequent happy end:HourglassArchitectureRefactored


Entry filed under: Architecture & Design. Tags: , .

Deliberate Unmaintainability: Burning Bridges To Fight The Cold

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: