Discussing and evaluating architectures; pt 2 July 30, 2011

In the last installment of this series, I presented the foundations of software architecture.  To recap, they were

  • Every piece of software has an architecture, whether intentional or not
  • Every architecture is created by at least one architect
  • Architecture appears in the small (software design patterns) and in the large (architectural styles)
  • Architecture is independent of technology choice.  Abstract styles allow for composability
  • Architectures are objective, allowing us to say one architecture is more elegant, efficient, or better than another

This installment will cover how to recognize the styles being applied in an architecture through a process of analyzing for completeness, consistency, compatibility, and correctness.  The post will finish with how to evaluate an architecture after it’s gone through appropriate analysis.  The main goal here is to use purposeful, objective decision making and problem solving skills, to move forward in building the best possible system and enable us to have a higher chance of software project success.1

Analyzing an architecture

Most often architectures need manual analysis, however, there are automatic and semi-automatic analysis techniques and tools.2  I’m primarily going to be discussing how to use general inspection and review based analysis and specifically Architectural Trade-Off Analysis Method (ATAM).  Both of these methods are manual, involving discussion,3 and usually include iteration.  As always, this is just a foundation for these two methods, please feel free to adjust them for your own purposes or seek out more resources.

Terms and goals

Here is simple language used discuss and analyze architectures in an objective way:

  • Completeness – The system captures all functional and nonfunctional requirements.  The architecture itself fully captures all views and components of the system, as well as dynamic behaviors, interfaces, and contracts.
  • Consistency – The absence of contradictions within the system.  These can appear as naming or interface inconsistencies with components or connectors, behavioral inconsistencies between components, and interaction or protocol inconsistencies.
  • Compatibility – The system correctly applies and adheres to the constraints of the styles and reference architectures.  That is, you’re not trying to compose styles in an inefficient or incorrect way.
  • Correctness – A relative property that refers to if an architecture captures all design decisions and if a system’s implementation fully captures the architecture, correctly implementing all design decisions

When analyzing an architecture using this language, highlight:

  • The data exchange within the system or subsystem – most systems (especially web-based systems) are data-intensive or data-centric.  The structure of the data, the flow of data, and its general properties and characteristics should all be analyzed
  • The structural characteristics of the architecture, ie: how everything connects or if components are missing necessary connections
  • The behaviors of components
  • The interaction between components
  • The nonfunctional characteristics of all components and connectors – often the critical dimension of all software systems

Given this language and framework, architectures can be objectively inspected, discussed, compared, and analyzed.

Inspection and review

An architecture inspection and review can be thought of like a code review, but for the system’s architecture and design decisions.  Just like in a code review, quality and knowledge transfer are the two major takeaways from the process.  That is, inspection and review will find defects and shortcomings, better address design decisions, and allow all team members to fully understand the entire system’s architecture.  The scope, goal, and concern of the review is determined by the team and project, but the process is the same no matter what.

Individuals first conduct their own review, creating whatever artifacts (models, notes, written assessments, reference architectures) they feel they need.  A group then conducts a review together guided and supported by the individuals’ reviews.  This can be done in any fashion, but there are specific formats, such as the ATAM.

Architectural Trade-off Analysis Method

The details of the method can be found at the Software Engineering Institute’s site but a graph will be sufficient:

ATAM's flow

ATAM centers on a scenario based approach, which include:

  • Use-case scenarios – how the system is envisioned to be used
  • Growth scenarios – planned and envisioned modifications to the system and architecture
  • Exploratory scenarios – the limits of the architecture’s adaptability when given major changes to the functionality, operational profiles, and underlying platform

ATAM then uses technical constraints, external and integrated systems, and architectural approaches, to find the best possible match between the scenarios (which determine quality attributes of the system while expressing the requirements) and the best design decision.  ATAM is useful in that it inherently includes capacity planning, which is critical for most web systems that get deployed.

Evaluating a candidate architecture

It’s sometimes helpful to have a tangible working artifact when designing, analyzing and evaluating an architecture.  Creating a prototype or architectural skeleton are two ideal techniques, but are not substitutes for the methods described above.4  A prototype is useful in understanding how an architecture or reference architecture “holds together” or “stands up.”  For some architects, it’s an easier visualization of multiple components and connectors without getting lost in the functional and non-functional requirements.  As a consequence, prototypes prematurely force you into technology choice before a real architecture can be distinguished.  Prototypes come in two major forms:

  • Horizontal prototype – which models wide aspects of a single layer, i.e. many features with little details. The most common example for Horizontal prototype is a  user interface prototype which is used to test the overall interaction with the system.
  • Vertical prototype -Implementing some sub-system or a limited set of features across all layers /modules.

An architectural skeleton is the first iteration of a candidate architecture, trying to loosely tie together the various technology choices that make up your components and connectors.  I strongly suggest all architects do this, as it gets you to a useable product early on and allows for experimentation and exploration within a live version of the architecture.

  1. A successful project is most often defined as being on time, under budget, meeting all functional and nonfunctional requirements, and being constructed in a way that enables ease of maintenance and desirable evolution. []
  2. Automated analysis usually comes from using formal or semi-formal architectural methods, like xADL or one of SEI’s methods []
  3. Any sort of collaborative communication will work, I prefer a wiki because it documents the history of the analysis nicely []
  4. These terms were lifted from Arnon Rotem-Gal-Oz’s blog []