>  Blog

Identifying Quality Attributes for Software Architecture

Pradyumn Sharma

May 23, 2017

In my blog on Agile Architecture and Design, I had talked about identifying the desired quality attributes for the architecture of a system, in consultation with the Product Owner. I had also talked about prioritizing these desired qualities based on

  • their business value to the customer, and
  • the cost of implementing early vs cost of implementing late.

Related to these points, I have been asked a question: How do we get the customer to specify the desired architecture qualities? And assess their business value? After all, most customers are not likely to be familiar with the technical terminology that we may use in software architecture and development.

Well, the answer to that, as it turns out, is similar to the way you would figure out the functional requirements from a customer. You ask questions. Whenever things are not obvious to the customer, think of scenarios and narrate stories to help move the requirements discussions along.

In addition, you apply your knowledge of the technologies, the domain, the business environment, etc, to be able to assess the importance of the various quality attributes, such as performance, security, usability, availability, internationalization, dependencies on external systems, etc.

Suppose, you are building a stock trading system. Some of the quality attributes should be obvious, if we have some idea about what stock trading systems do, such as:

  • Security would be critical, as there is money involved
  • If the system is going to facilitate trade on various stock exchanges, then dependency on external systems would be important too
  • As stock prices may change in a fraction of a second, based on demand and supply, performance would be very important as well

However, we shouldn't just make assumptions and unilaterally decide what the desired quality attributes for the system should be. We must verify our understanding and all our assumptions with the customer. We must ask appropriate questions, even for the quality attributes that don't appear important to us, because who knows, we may be missing something that could be very important for our customer.

Another related question: how do we validate architecture choices with the customers that are too technical for them to understand?

Suppose we need to deal with concurrency in an application, because more than one user may sometimes want to modify the same data in that application (shared mutable data).

We know that dealing with concurrency typically entails locking some records or resources in a system. There are various approaches to locking, say, a database record, such as optimistic locking and pessimistic locking. Suppose we are evaluating these two approaches for an application.

How do we decide which of the two locking approaches is more appropriate for a system that we are building? Should we (the development team) brainstorm among ourselves, make assumptions and decide on our own? Or should we make the customer decide?

The customer should make the choice. But how do we make the customer understand these two choices, and make a decision? Perhaps they have never heard of optimistic and pessimistic locking or do not fully understand the technical aspects of each locking strategy.

Well, be creative. Weave stories from business scenarios that illustrate the two (or more) different choices, without emphasising the technical terms. Make the customer understand the scenarios and the business consequences thereof. We can, for example, describe and discuss alternative scenarios as illustrated below.

Let's say we are building an airline reservation system. A user, Amar, wants to book two seats for a specific flight. At that point of time, exactly two seats are available for that flight. Amar is satisfied with the price of the seats and decides to book these. It takes him ten minutes to fill up all the details required for making the reservation.

Meanwhile, another user, Betty, also wants to book one seat for the same flight.

Scenario 1

As Amar has not yet finished booking his two seats, the system displays a seat being available to Betty. She starts to fill up the details for her booking as well. Now Betty is faster with her fingers on the keyboard than Amar, and completes her booking before Amar. As Betty has already taken taken one seat, by the time Amar hits the "Submit" button, only one seat is remaining.

The system informs Amar that there is no seat available. Amar is furious for having wasted his time. Consequence: one unhappy customer. Or the possibility of overbooking of seats, which, if not handled well, may result in bad publicity, loss of revenue, and litigation costs. (This scenario happens due to optimistic locking, but we don't need to use the technical terms with the customer).

Scenario 2

As soon as Amar starts filling up his details, we "hold" the two seats for him, and after that, when Betty searches for a seat, we report to her that no seat is available. (In technical terms, this would happen when we do pessimistic locking, but again, we don't need to mention this term to the customer). We don't overbook a seat, nor leave a customer unhappy.

But then, if Amar does not eventually complete his booking and changes his mind, we would lose the opportunity of making that sale to Betty too. And if nobody tries to book that seat later, we face an opportunity loss.

Scenario 3

(Variation on scenario 2) We keep a hold on the two seats for Amar, but only for some fixed duration. When Betty wants to make a booking and the only available seats are on "hold", we inform her about the same, and advise her to wait for some (specific) time period and try again. Or we could offer to inform her later about the seat becoming available as soon as possible, and perhaps even offer her a discount for her "understanding".

Scenario 4

(Variation on scenario 1) We consciously allow slight overbooking, with the assumption that some customers eventually cancel their bookings or don't show up. If in some (acceptably small percentage of cases) no cancellations happen, we offer a very attractive compensation to someone whom we regretfully have to unbook (but, hopefully, not "drag and drop"!)

In summary,

  • Scenario 1: no direct revenue loss or opportunity cost; but one potentially unhappy customer or overbooking
  • Scenario 2: no overbooking, no unhappy customer; but possibility of revenue loss
  • Scenario 3: similar to scenario 2, but with a chance to avoid revenue loss
  • Scenario 4: similar to scenario 1, revenue-maximizing, but occasionally, with a significantly higher cost (financial or reputation)

Based on these scenarios and their consequences, the customer can now make an informed choice which in turn translates into sound architectural decisions.