Promote Desired Quality Attributes

Selecting structures for the architecture is like making a smoothie. Smoothies (like software) are tasty but difficult to make well. While many things must go right to create great software, there is only one thing you need to get right for a great smoothie: use the proper blender. OK, there are lots of things that can wrong with smoothie making too (berry seeds, ugh!), but the blender is a crucial smoothie-making tool.

You’d think picking a blender would be easy. It’s not. Do you want one that’s easy to clean? Something that stores easily and fits on your countertop? Something quiet? Or powerful? Or portable so you can blend on the beach? We can express these needs as blender quality attributes.

Here are three types of blenders capable of making smoothies. Each blender is designed to promote different quality attributes and, as you can see, no two blenders are the same.

Chainsaw Blender photo credit: Mike Warren

The standard blender is dishwasher safe and has a sturdy base for sitting on a kitchen counter top. But it requires electricity, so you’re limited to the kitchen. The battery-powered hand blender is small, portable, and easy to clean, but trades power for portability. Finally, the gas-powered chainsaw blender has the best power and portability.^[6] Too bad the 37cc two-stroke, motorcycle-throttle-controlled chainsaw engine is a tad loud and emits an exhaust unsafe for indoor use.

Here is a summary of how well our top-quality attributes are promoted by each blender:

Each blender performs the same basic function (blending). They have interchangeable parts. For example, the same glass pitcher works with the standard and gas-powered chainsaw blenders. In addition to the blender quality attributes, the designers considered costs, manufacturing techniques, interfaces with external systems (human and machine), and other properties. The structures we see in the final designs were chosen to promote properties the designers highly valued.

Just like the blenders, architects choose structures to promote quality attributes in the software system. The most common way to select structures is by exploring patterns. Remember, all design is redesign! Find patterns that promote desired quality attributes and use those patterns as a starting point for the architecture.

Explore Patterns with Quality Attributes in Mind

We’ll explore architecture patterns in greater detail in Chapter 7, ​Create a Foundation with Patterns​. For now, let’s see a simple example of how we can use quality attributes to choose an appropriate pattern.

Say we want to build a web-based, data-driven application. What patterns would you choose for this application? There are three decent options: 3-tier, publish-subscribe, and service-oriented as shown in the figure.

Option A: 3-Tier Pattern.

Introduced, each tier is responsible for different application concerns. For a web application, the display tier renders the UI, the business tier operates server side to verify business rules, and the database stores data.

Option B: Publish-Subscribe Pattern.

Introduced, each element publishes messages to an event bus. Interested components may subscribe to message types. Depending on the rules of the message system, events might not be delivered in order and delivery might not be guaranteed.

Option C: Service-Oriented Architecture Pattern.

Introduced, services register with a central registry so that callers can find them. Components look up and call those services directly and the service responds with the requested information—or doesn’t if something goes wrong.

Each of these patterns promotes and inhibits different quality attributes. Which one would you choose?

The 3-tier pattern is ideal in many situations. It’s easy to test, easy to deploy, and easy to describe. This simplicity comes at a cost. The multi-tier pattern does not promote quality attributes such as scalability and availability. Depending on other quality attribute scenarios, this pattern may not address all our needs without augmenting the architecture with other patterns.

The publish-subscribe pattern is highly modifiable and extremely flexible. This flexibility makes it easy to build loosely coupled systems. While this flexibility and modifiability are attractive, there is a downside. Message order matters to the events in our data-driven application, but the publish-subscribe pattern alone can’t guarantee message order. With the right message bus technology, we might make this pattern work, but it feels awkward.

Like the other patterns, service-oriented architecture is modifiable, flexible, and testable. Service-oriented systems are also scalable and promote availability easier than our other options. It’s also the most complex of the three patterns under discussion and has the steepest infrastructure curve. Depending on our specific quality attribute scenarios, this pattern could be overkill.

We could successfully implement the functional requirements with any of these patterns. The quality attributes are what really drives our decision making. With quality attributes, there is rarely a single right or wrong design, only designs that are better or worse relative to desired system properties. To make a decision we need to do some analysis.

Create a Decision Matrix

The decision matrix is a simple tool for summarizing the trade-off analysis among architecture design options. Use it to make decisions about any architectural choice from patterns to functional responsibilities to technology choice. Here is an example:

To use a decision matrix, list properties you plan to use for the analysis in the first column of a table. Each row represents a particular property. Each column represents your analysis of a design option.

Summarize the results of your analysis with an easy-to-read notation such as words, arrows, symbols, or colors. The idea is to create a visual representation that shows how each option influences properties you think are valuable. Here is an example:

The best decision is often obvious once it’s in the matrix. Use a scale like the following to summarize the analysis of each architecture design option. Immediately eliminate any design option that prevents you from achieving a required system property.

We already saw a decision matrix for smoothie blenders. Let’s create another decision matrix, this time for the Project Lionheart patterns discussed. Here is a decision matrix, which shows some of the analysis for the quality attribute scenarios we defined in ​Capture Quality Attributes as Scenarios​:

Looking at the decision matrix, which pattern would you choose? Are there other factors not captured in the matrix that might influence your final decision?

The work that goes into creating the matrix is more important than the matrix itself. The decision matrix is a convenient way to summarize findings and facilitate discussions with stakeholders. We want stakeholders to have a robust discussion about trade-offs among design decisions. Be prepared to explain the scores in the matrix.

Using numbers in the matrix is tempting. Don’t. Numbers give a false sense of confidence and precision in the analysis. Eventually, someone will try to adjust scores with weighted stakeholder preferences, sum the columns, consider aggregate averages, or some other dreadful idea. It’s just bad news.

See Activity 32, ​Decision Matrix​ for further details on this method. An alternative method for helping discuss trade-off priorities is the trade-off sliders activity described.