Identifying Quality Attributes for Software Architecture

  • Pradyumn Sharma
  • May 23, 2017

Tags: ,

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 with the help of Commercial events RDC Photography.

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 Visit for more info.

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.

26 responses to “Identifying Quality Attributes for Software Architecture”

  1. KxOgdU We stumbled over here coming from a different web address and thought I may as well check things out. I like what I see so i am just following you. Look forward to looking at your web page repeatedly.

  2. click here says:

    You made a number of nice points there. I did a search on the matter and found a good number of folks will consent with your blog.

  3. You generated some decent points there. I looked on-line for that problem and discovered the majority of people will go coupled with with all your internet site.

  4. Wow! Thank you! I continually wanted to write on my blog something like that. Can I include a portion of your post to my website?

  5. Wow, this post is good, my sister is analyzing these kinds of things, thus I am going to convey her.

  6. This site truly has all of the information I wanted about this subject and didn at know who to ask.

  7. wow, awesome blog article.Really looking forward to read more. Awesome.

  8. Title here are some links to sites that we link to because we think they are worth visiting

  9. Wow, that as what I was seeking for, what a stuff! present here at this blog, thanks admin of this site.

  10. themselves, especially contemplating the reality that you simply might have completed it if you ever decided. The pointers also served to provide an excellent technique to

  11. Major thankies for the article post.Thanks Again. Want more.

  12. name says:

    Major thankies for the blog article.Thanks Again. Really Great. this site

  13. This web site definitely has all the info I wanted about this subject and didn at know who to ask.

  14. I used to be recommended this blog by way of my cousin.

  15. we could greatly benefit from each other. If you are interested feel free

  16. sex toys says:

    Really appreciate you sharing this blog.Thanks Again. Great.

  17. sex toys says:

    Natural Remedies for Anxiety I need help and ideas to start a new website?

  18. lingerie says:

    Way cool! Some very valid points! I appreciate you writing this post and the rest of the site is also really good.

  19. lingerie nyc says:

    Very good blog post.Really thank you! Really Cool.

  20. nyc lingerie says:

    Really appreciate you sharing this blog.Really thank you! Really Great.

  21. nyc sex toys says:

    Wonderful blog! I found it while searching on Yahoo News. Do you have any tips on how to get listed in Yahoo News? I ave been trying for a while but I never seem to get there! Thank you

  22. You made some respectable points there. I regarded on the web for the issue and located most people will go together with with your website.

  23. Im grateful for the post.Really thank you!

  24. very nice submit, i definitely love this website, carry on it

  25. Dispensary says:

    slot machines for sale view of Three Gorges | Wonder Travel Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2017 Pragati Software Pvt. Ltd. All Rights Reserved.