Discussing and evaluating architectures; pt 1 July 12, 2011

Previously, I discussed how to Lose Weight exercise validation at various points in the software development life cycle, but left out many details pertaining to software architecture.  Software architecture’s sheer depth and influence on a project was the rationale for doing so.  Being able to fluently dissect, analyze, discuss, evaluate, and compose software architectures is a core (and useful) skill for any software engineer or manager of software engineers.1

A system’s architecture is an expression of its characteristics.  It is the combination of all design decisions, tradeoffs, and constraints.2  The validity of an architecture is determined by objectively evaluating how its design decisions and behaviors map to the system’s functional and nonfunctional requirements.3  Let’s walk through some core concepts about software architecture and then enumerate various evaluation strategies.

Every software system has an architecture

Every piece of software has an architecture, whether intentional or not, and was created by at least one architect.  This idea can be seen in other forms of architecture, for example, every building has an architecture.  Not all architectures are elegant or complete, but nonetheless exist.

Architecture appears in the small and in the large

Software architectures are often split up into two categories.  Architectural Styles are named sets of design decisions that result in superior system properties, yielding something that is more “elegant, effective, efficient, dependable, evolvable, and scalable.”4  These decisions are made at the system level and are abstract.  Some examples are client-server, REST, pipe-and-filter, peer-to-peer, and DDS.5

Architectural Patterns, often called Design Patterns or Software Design Patterns, are named sets of design decisions that result in superior properties for a component or within a component.6  These patterns are usually concrete or partially concrete implementations.7

Architecture is independent of technology

Architectural styles are abstract and aren’t tied to any particular piece of software, technology, or language.  Doing so adds unnecessary constraints on the design,8 similar to the result of premature optimization.9  These additional constraints will at best reduce your system’s efficiency and at worst prevent your architecture from being valid.  Additionally, architectural styles need to be abstract to enable composability.

Architectures are objective

Architecture is a continual effort throughout the entire life cycle of software.  A system’s architecture evolves as your team elicits new requirements and gains information in your problem domain.10  Characteristics of an architecture are objectively evaluated, enabling us to say one architecture is more elegant or efficient than another.

Your goal in design and creation is to purposefully apply design decisions, using established styles and patterns, to achieve the best architecture possible. A necessary step in effective problem solving is critically analyzing all possible solutions, and objectively determining the best one.  Evaluating architectures is a software engineering equivalent.

Next installment and further reading

The next part of this blog post will use examples to discuss:

  • Recognizing styles
  • Analyzing an architecture’s completeness, consistency, compatibility, and correctness
  • Applying architectural components to achieve nonfunctional properties
  • Evaluating conceptual architectures

A third and final post will use those skills to design a “real time” web system, like Gmail or Twitter, starting from requirements and delivering a valid architecture.

Interested readers will find more information in Software Architecture: Foundations, Theory, and Practice.  I strongly recommend the book to all software engineers as a great reference.11 Arnon Rotem-Gal-Oz’s Blog is a solid source of higher-level software architecture discussions.  High Scalability and Web Performance Matters are two wonderful sites about internet architectures.

Lastly, reading and studying well composed architectural styles will make you a better architect.  Applying the same lessons when faced with similar requirements or constraints will produce a better systems.  The Architecture of Open Source Applications is great, recent source of architectural walk-throughs of some of the most popular, successful, and widely adopted open source projects.

  1. In a later post I plan on appropriately defining the field of software engineering, as I most often make use of it.  I feel like some people needlessly narrow the scope of “software engineering” – I try to somewhat establish a definition in this comment.  The Parnas paper mentioned in a previous post details it better than I ever could. []
  2. Understanding an architecture is the pursuit of exploring and understanding those decisions.  Reviewing an architecture is similar to reading and reflecting upon someone’s biography or recognizing the quality of construction in a new building or automobile. []
  3. Nonfunctional requirements are often called the -ities. Security, scalability, dependability, adaptability, complexity, efficiency, and robustness are some of the more common nonfunctional requirements.  Being explicit about these requirements allows for a more complete architecture and better visibility with regards to testing/verification []
  4. Software Architecture: Foundations, Theory, and Practice. Taylor. Dashofy. []
  5. I used these styles because they all map to widely used successful system.  Respectively, the Internet, web services, Unix – (including Mac OS X), bit torrent, radar systems and emerging “real time” web.  DDS is data-centric specialized form of another style, publish-subscribe []
  6. Design Patterns are the expression of desired functionality, within the constraints of given language or paradigm (and are therefore language or paradigm dependent).  For example, many of the classical design patterns are obsolete or do not apply in functional languages, largely because they were written for Object Oriented languages. []
  7. Some pieces of architecture fall between both categories, like Model-View-Controller, which is an architectural style that is implemented in frameworks for various languages. []
  8. The constraints are the result of passively accepting the tradeoffs inherent to certain technologies []
  9. In software, premature optimization is often a root cause to inhibiting system flexibility, the cause of integration problems, and a telltale sign of an inexperience software engineer []
  10. Architectures help establish knowledge by applying information from a problem domain into a solution’s architecture []
  11. The book features a matrix that identifies how each style can be composed, and the system properties that result from such a composition.  This matrix is worth the book price alone. []