Software Qualities

Software Qualities

Software Architecture lives in quality, the hidden part which delights the customer

Functional features are things we discuss all the time while developing software, but what about its reliability or performance?

Software Qualities can be the difference of a great user experience or a product that breaks under pressure, leaks information. These things are important lets see how.


  • Services can impact one another, consider the big picture too
  • What main qualties a service should consider.
  • Qualities are getting easier to implement, i.e. serverless, can take care of some out of the box.
  • you can leverage a common platform, in order to satisfy/improve a number of Software Qualities.

It works for my service

Lets setup a context, and we will use this to discuss.

We work on developing the Basket Service

Our Product owner says, we need to be

  • up and running 24hours a day
  • and we will have upto 300 request per second (this was a discussion, and we estimated it, but to be on the safe side we design to handle 400)

Finally we expose an API, using JSON, for a number of clients to call

At we are looking at a few Software Qualities: Reliability, Performance, and Compatibility.

This yeilds this picture:

WOOO HOO….. and we nailed it…. well no

Software is not an island.

Quality is not an island

Lets revisit the Basket service, once a customer has basket this will need to be turned into an actual order, update Next best buy, reserve stock (and maybe more)

We can observe that

  • the other services also have Software Qualities.
  • Software Qualties can be applied over a number of services as well as at the single service.


Pause, lets look at some quality

Software Quality, is also referred to as Non-Functional, or Ilities.

If we look at wikipedia, there are over 50, its daunting,

Lets be smart, and select a smaller subset, we can take the ISO 25010 as a sensible starting point, and look at qualites which we find valuable to our software

The above is based on the ISO, and we have missed out Functional, as that is a given in this context (for now).

Also we can see the

  • there is a small higharchy, with 7 main areas, which group the qualities we are interested in
  • in the basket example, we can see Reliability, Performance, and Compatibility.

Rewind to the islands

In the simple example we put forward, our basket service and its peer services, we can see an interesting picture now form.

we can see a number of issues arise, to the point where can fail to meet our own measures as the peer to peer connected servcies may be down (either not running, or our service has overwhelmed them)

Lean on the platform? (a possible way forward)

Given an assumption that the down stream services will process at the same speeds (there may be some constraints)

Lets look at using a Event Broker (which could be delivered as part of the platform), to decople the services

The broker would be an extra concern, however the payoff allows the downstream services to process the messages at their own pace

by doing this change we have considered and improved

  • Reliability - basket can continue to work, even if the downstream services are down
  • Preformance - baskest is not limited by down stream
  • Maintainability - we have decoupled the services, making it more modular
  • Compatability - all services use the same interchange (JSON)

overall our service will appear to have more Quality.

© 2022 All rights reserved.