Understanding Quality Attributes

Quality attributes are properties of a system by which a stakeholder will evaluate their quality. In simple words, it is about how good a system performs its functional attributes.

Examples: performance, security, availability, modifiability, usability,.. .
Part of stakeholder concerns can be addressed by, and is translatable to quality attributes.

For example if a stakeholders states that he is looking to increase the market share of their product, it maybe translated to Modifiability, Usability.

Stakeholders of the system are the main source for gathering quality attribute requirements. 

The degree to which a software system meets its quality attribute requirements depends on its architecture. This is when the architect makes decisions during the design to satisfy quality attributes. Usually satisfying one quality attribute affects other ones. Almost all quality attributes stand against achieving performance. As a result an architect has to meet some tradeoffs in design the achieve the optimal quality attribute.

Considering the importance of quality attributes to an architect, we need a tool to gather and express and reach a consensus among stakeholders. There is a specific method for gathering, prioritising and expressing quality attribute called Quality Attribute Workshop which is of great help if you are looking to gather quality attributes.

It is worth mentioning that saying "this system should be modifiable, secure or highly available" is not of much value, we need to say the which area of the system should be modifiable against what changes, in other words, they should be measurable, and hence testable.

Also different people based on their different professional background understand various concepts under a quality attribute name.
A possible(,and proven ) solution to this dilemma is using Quality Attribute Scenarios.

Quality Attribute Scenarios

A quality attribute scenario is a short description of how a system is required to respond to some stimulus. In fact a scenario has six parts:

1. source - an entity that generates the stimulus
2. stimulus - a condition that affects the system
3. artifact - the part of the system that was stimulated by the stimulus
4. environment - the condition under which the stimulus occurred
5. response - the activity that results because of the stimulus
6. response measure - the measure by which the system's response will be evaluated 

Let's have a look at an example for modifiability:

A change request for updating a graph arrives, and it should be done, and deployed with in 4 hours.

Source: A customer
Stimulus: Change request
Artifact: code/ UI 
Environment: (Normal)
response: change code, and deploy
response measure: 4 hours

And here is an example for security:

An employee tries to change pay rate from a remote location within normal system operation status, system will keep an audit trail, and correct data will be restored after one day and tampering source is identified.

Can you try to identify the parts for the upper scenario?

Source: An employee
Stimulus: change the pay rate
Artifact: system data
Environment: Normal
response: audit train
response measure: restoring data, identification of source in a day.

General scenarios vs Concrete scenarios

So far all the scenarios we have seen are concrete, meaning they are pointing to a very specific, known story.

However depending on the domain and organisation or even your own experience you notice that some terms and actions start appearing and recurring in scenario parts.

You can take advantage of this fact and build a table and put those recurring and possible terms in a table for each part and quality attribute. This will help you and stakeholders to produce scenarios quicker and more fluently.

Testability General Scenario Generation

Portion of Scenario	Possible Values
Source	Unit developer Increment integrator System verifier Client acceptance tester System user
Stimulus	Analysis, architecture, design, class, subsystem integration completed; system delivered
Artifact	Piece of design, piece of code, complete application
Environment	At design time, at development time, at compile time, at deployment time
Response	Provides access to state values; provides computed values; prepares test environment
Response Measure	Percent executable statements executed Probability of failure if fault exists Time to perform tests Length of longest dependency chain in a test Length of time to prepare test environment

I think this a good time for an exercise, try to find out what QA s are important for the software you are developing or working with, and create a few scenarios. 

Other Quality attributes

There quality attributes of different nature that are also important for an architect.

Business Quality Attributes : these are concerned about cost, schedule, market. Time to market, Cost and benefit, expected lifetime and rollout schedule.
Architectural Quality attributes : 

Factors influencing the software architecture

Software architecture is not just a result of design based on requirements.

Dear developer there is more involved in this, try to zoom out, leave code lines behind, and think about people,business, investment and forces that try to shape the architecture  ;).

The final design is an outcome of technical, business and social factors.

Architecture is influenced by :

• stakeholders
• the development organisation
• the technical environment
• the architect's background and experience

Stakeholders have an interest in the design of an architecture, they maybe : costumers, users, developers, project managers, marketers,.. each of which has different concerns.

For example customers are the people who pay for the project's development, and they are concerned about cost ,functionality, lifetime, development time to market,.. .

On the other hand management (i.e: development org. or customer org.) might be concerned about adhering to the development schedule, maintaining product quality, investing to achieve strategic goals.

Customers' quality attribute requirements are rarely understood and documented, which may result in : business goals not achieved, inevitable conflicts between stakeholders.

An architect must :

• understand the real constraint of the system
• manage stakeholders' expectations
• negotiate system's priority
• make tradeoffs

Depending on the technical environment the architecture is affected.(.NET, Java, EJB, COM, REST,Aspect Oriented Programming,SOA,WWW,..)

An architect has to be aware of these concerns as early as possible. All those people expect to have their concerns address.

Architect's own experience with systems he has successfully/ unsuccessfully designed, influences the architecture, they are less likely to use a failed architecture for a solution.

Architectures in turn affect the factors that influences them

Once the architect is created and the system is built, they affect the stakeholders requirements, architect's experience and technical environment.

For example a stakeholder who has seen the architecture of similar systems will ask for particular kind of features - such as SOA.

Occasionally, a system or architecture, can change the technical environment in which system builders operate.Again SOA, or EJB and above of all WWW could be an example.

This introduces a cycle called(by SEI) Architecture Business Cycle(ABC), the following image depicts this concept:

Define Software Architecture

In the following lines I will provide some definitions , however I need to express that there is no globally accepted definition in the world of architecture. Different organisations and individuals tend to have their own definition. In any case this should give you an idea of the concepts.

  

To provide a definition of Software Architecture , I need to give you and understanding of a few terms:

•  Enterprise Architecture : describes the business structures and the processes that connect them. This maybe supported by computer systems. It is about flow of information and activities that concerns different groups to achieve a business goal.
• Systems Architecture : describes elements and interactions of a system including hardware and software pieces. A system's architect deals with elements of the system and their contribution towards the systems's  goal.

Enterprise and Systems Architecture provide a context (requirements and constraints) for software architecture.

What is Software Architecture?

"The software architecture of a program or computing system is the structure or structures of the system, which comprise the software elements, the externally visible properties of those elements, and the relationships among them." Bass, L.;Clements, P. & Kazman,  R. Software Architecture in Practice

There are a few facts embedded in this definition:

1. Software Architecture is an abstraction of a system. Defines elements and how they relate to each other. Hides the details of elements internals.
2. "externally visible properties" refers to those assumptions that one element can make about  another element: services it provides, performance, handle faults,.. .
3. Systems can and do have many structures. Relationship among those structures can be runtime or non-runtime.
4. Every system has an architecture. though it may or may not do what you want if you don't explicitly develop one.
5. Box-and-line drawings alone are not architectures: they are just a starting point.

Update: It's worth mentioning that the border for these three roles is fuzzy. meaning that 

they can negotiate trade-offs(, well ideally). the following figure tries to visualise this overlapping between different levels of architecture.

Let's Start

"You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes"

The Intro

Are you a software developer who is interested in software architecture?

Do you find it odd that technology vendors define 'what software architecture' is ?(who sell you their products eventually.)

You wonder what an architect does and how they do it?
You have seen those diagrams with boxes and line? and you have been told that is architecture?

--------------------------------------------------------------------------------------------------------------

I was a Microsoft developer, learning what architecture is from Microsoft published books and articles, while they were useful, they were tuned to make me use Microsoft products.
They created your world( ,the need),  and they sold it to you.(The matrix)
I assume this is pretty much the same with every other vendor.
   
In these series I will write about the fundamentals, definitions,.., buzz words  to make you comfortable with Software architecture without being tied to a specific vendor

Thanks to SEI who thought me great lessons and opened my eyes. I will be quoting some of their phrases later on.

Enjoy!
Kaveh