Planning: Qualities of Services (QoS)

Defining the qualities of service is a key area of the architectural group, as will drive the selection of technologies and will heavily influence the logical and physical design. One important aspect about them is that they need to be measurable. How many times we have found an architect saying “We are re-architecting our system in order to improve the performance.” This type of statement can be difficult to sustain if you need to discuss the funding for your next architectural challenge without falling into the fuzzy area, where the managers do not understand what we are going to deliver, an if budget is not a constrain, they think if is faster then go for it.

Well, you already bought your manager with that statement, now it is time for the developer to build the solution. The developer follows the logical design and sends the solution to the testers. The testers need to test the requirement “performance”... If you were a tester you will think, ok, let’s try the previous application, measure the execution time and let’s execute the same script on the new one. Comparing both applications will tell us if we achieve the objective or not.

Typical scenario don’t you think? But how well the application did perform? If we do not specify targets at the beginning of the project it will be very difficult to measure the successful ratio of the project. Here is where the QoS come into scene. The ex “non-functional requirements” are as important as the functional ones, combined they will create the driving factors for the project.

The business definition can be:

“We are expecting to invest in a marketing campaign that will trigger an extra 25% users into our website. If we can maintain at least 99% availability we can foresee a 15% increase in our sales”

With this information the architect can start to define the QoS that should translate into cost. The programme manager should be able to present this feedback to the product management in order to compare the cost with the expected returns. This seems pretty obvious but many times is omitted from the project, leaving the programme manager and the product managers with a non-tangible results solution.

The QoS requirements can be divided in the following areas:

Performance (Architect)

· Responsiveness
Allowed time between a call and its response. This should note what is acceptable and what is not, the values must be clear.

· Concurrency
Amount of concurrent calls the system will support without affecting other qualities of service. Knowing the amount of concurrent calls can help to estimate the system capability before scaling up.

· Efficiency
How capable to provide the specific performance relative to the resources used. Caching or querying different databases can improve the system efficiency for example.

· Fault Tolerance
This is the capability to maintain the same level of performance relative to the amount of faults on the system. How many or what type of faults will leave the system unavailable.

· Scalability
How easy the system can scale up if the load on the system increases with time. This can also include the cost per user. This item is very useful for managers for estimations

· Extensibility

This item shows how easy is to extend the application without any major re-work or re-investment. Can we interact with add-ins or with a third party component is the main question that this item answers.

Trustworthiness (Architect)

· Security
This is the ability to prevent unauthorized access that can lead to disruptions on the system. The STRIDE model must be followed.

· Privacy
This is the ability to prevent any information disclosure.

User Experience (User Experience)

· Accessibility
On this item is important to define how the application will be accessed by people with disabilities and if it will comply with different standards

· Attractiveness

How the visuals appeals to the user. Nobody wants to deliver a user interface designed by developers, don’t you think?

· Compatibility

Is the application going to be compatible with previous versions? This type of statement is extremely important for designers and developers as they can envision a solution from zero or with compatibility restrictions.

· Discoverability

How the user will discover the new functionality of the application. Microsoft ribbon is an excellent example.

· Ease of use

If the user uses the keyboard to use the application instead of the mouse this should be included. This information is usually sourced by usability analysis.

· Localizability

English is not the only language in the world (indeed as you have noticed is not my first languageJ ). If the application is going to be implemented in other regions the design should take extra considerations with the resources.

Manageability (Release / Operations)

· Availability

Which is the probability that the system will be up at any time, how many “9” after the do? This has a cost implication.

· Reliability

Capability to maintain a specific level of performance under stress conditions or unfamiliar states.

· Installability

How easy the application installs and uninstalls. What kind of footprint leaves the application on the host system.

· Maintainability

Ease of modifications to correct faults. Do we need to put the application off-air in order to implement changes?

· Monitorability

How are we going to monitor the health of the application? Which tools are we going to use? Sometimes the developers and architects need to add extra interfaces (i.e WMI) in order to improve the application Monitorability.

· Operability

How the application will be operated, can the application be controlled automatically?

· Portability

Capability to be portable from one environment to another (i.e. Windows, Linux or Mobile)

· Recoverability

How fast the application can be recovered to perform within the specified levels after a disaster.

· Testability

In which degree the application can be tested. This can include the ability to self-test or to perform production environment checks.

· Supportability

How the application can be supported. This item includes the ability to diagnose and correct the application while in the production environment.

· Reusability

Is the architectural goal to have a set of components that can be re-used in future applications? If it has any SOA model that can be reused for other purposes without re-work.

· Conformance

Adherence to rules, regulations and policies (i.e. SoX)

· Interoperability

Capability to interact with other solutions within or outside the environment.

The list can be prioritized and also can include “N/A” entries, as they are not applicable or the new version should behave at least the same level as the current one. A project can focus only in scalability for example without affecting the other areas. The good thing about having this list is that helps the architect to go through all the areas, and for the testers is an excellent reference to create automated tools that can measure the current values.

There is a clear relation between customer satisfaction and meeting the expectations, this type of document can help you to push the solution to the correct frame where both targets are satisfied.

Comments

• Anonymous
  August 14, 2007
  I had forgotten my Sam Guckenheimer book Software Engineering with Microsoft Visual Studio Team...