Hoist Important Qualities

  • architecture

One of the best things you can do for your most important, mission-critical qualities, is to hoist them into the architecture itself. Rather than being a day-to-day coding concern, a hoisted quality becomes a part of the system’s skeleton. Just as certain skeletal structures imply qualities (e.g. a ball-and-socket joint confers a wide range of motion), architectural decisions can strongly promote qualities.

Perhaps one of the simplest examples is TCP (as in TCP/IP, the internet communication protocol). Much of communication on the internet today hinges on the error-free, guaranteed conveyance of information. Those qualities could be implemented ad hoc over the lower-level UDP protocol, but that would be messy and prone to error. Instead, as an industry, we hoist those qualities into a protocol.

Hoisting may take on any number of forms, but ultimately they are underpinned by such protocols–rigid frames that restrict and enable. For example, one could enforce modifiability via the use of a framework such as Ruby on Rails, ensure scalability via elastic clusters of stateless web-servers, or deliver performance through a geographically distributed hierarchy of caches.

All in all, though, each of these examples is about purposeful limitation.

  • Rails applications (good ones, that is) structure themselves in a well-known fashion to remain approachable.
  • Stateless web servers restrict the use of state to maintain horizontal scalability.
  • A hierarchy of caches requires reliable updating to promote fast performance. 

Restrict to enable.

Hoisting qualities into your own architecture is a multistep process:

  1. Identify your most pertinent quality attributes. See Project Kick-off: Quality attributes and scenarios in Application Architecture for Developers for help on this.
  2. Determine if hoisting these qualities is feasible and realistic. Is there a particular architectural style you can choose that will promote that quality? Are there patterns you can apply at lower-levels? Or, do you need to design your own development process to suit the needs of the project?
  3. Deliver. Enact the style, pattern or process that guarantees your desired quality attributes.
  4. Measure, continually. Are you meeting quality constraints now? Tomorrow? Three months from now? In general, it is important to make measurable statements so you can keep track of how you’re doing compared to your desired behavior.

Like this post? Subscribe to my newsletter.

Get fresh content on Clojure, Architecture and Software Development, each and every week.

comments powered by Disqus