Quality Attributes in Software Architecture | 3Pillar Global

There are two very important questions to ask when talking about software architecture: “What are the business drivers behind our initiative?” and “How is the application is supporting them?”.

Software architecture is the foundation that helps building a system that satisfy business requirements. Organizations often think that designing applications consists only of its capabilities and behavior; however, this is a shortsighted perspective. Users are not only affected by the lack of proper functionality but also from the missing required software quality attributes that influence the viability of any software solution. When a system isn’t reliable or secure or scalable, it will inevitably fail the same way as if we forget a critical functional requirement.

Software Quality Attributes Are Invisible, Until Things Go Wrong…

Software quality attributes are one of the two types of non-functional requirements. Commonly identified as the software “ilities” (security, availability, scalability, and more), are often considered part of the work that isn’t visible for the users but provides positive value for them. Sure, it can be classified as invisible when it’s working correctly, but when it isn’t, your users will surely notice.

The DevOps Handbook – Figure 11: Invest 20% of cycles on those that create positive, user-invisible value (Source: “Machine Learning and Technical Debt with D. Sculley,” Software Engineering Daily podcast, November 17, 2015.)

Let’s say that, for example, your goal is to increase e-commerce sales. Still, your application keeps crashing when the user load spikes (like in holiday season). Or maybe your users’ credit card data gets stolen. In any case, there’s a mismatch between your organization’s needs and the ability to fulfill them. Attributes like performance or security are many times overlooked until it’s too late. Software applications become slower, emergent failures end up being catastrophic, or massive security breaches affect the company’s reputation.

Business goals often lead to quality attribute specifications. A successful architecture considers all the essential requirements; this means knowing what will have a profound effect on the application.

Poor Quality Attributes are the Source of Legacy Pain

When we talk about legacy applications, most of the challenges they face are regarding architecture and non-functional requirements, not about functionality. Since it is something that your stakeholders can see and use, it’s often somehow up to date with the business requirements. We frequently hear requests to create new applications, still, they keep most of the same functionality of the legacy system they replace, they just need to work better.

Finding a Balance Between Quality Attributes is Critical

Like many things in life, when it comes to software quality attributes, you can’t have it all. Several tactics can help in the goal of achieving a desired quality level, but they will inevitably conflict with another attribute. A typical example is security. Many times, trying to make a system more secure means encrypting data, which consequently translates into slower processing times (affecting performance). Sometimes it also means adding controls and verifications that make a process that otherwise would be simple, cumbersome by affecting usability.

Tradeoffs are part of a robust architecture design. A proper analysis is required to determine the right attributes for the application, their priority, and how they will affect the rest.

The Right Attributes, at the Right Level

There are quality attributes that are common to most applications, like performance, security, or availability. Others may only apply to specific scenarios, like interoperability, cost, time to market, or safety. Any organization needs to identify the right attributes for the application, so they can use resources efficiently.

Moreover, not all quality attributes will have the same priority; we need to think of them as different scenarios refined at the right level of detail so we can plan accordingly. A scenario describes a system response to a specific stimulus under particular conditions and the desired response. Quality is, by nature, a subjective concept. Expressing it in objective and succinct terms makes it easier to achieve.

Timing is also important. There is no value on planning for a user load of a million on an application that is only starting; it might be better to think on time to market instead. We need to be conscious about where we are and our plans for the near future and plan accordingly.

Software Functionality and Quality Attributes

Additionally, software quality attributes don’t live on their own; they have a tight relationship with functional requirements and application behavior. For example, we don’t expect the application to be fast, but carefully think about when do we need high performance and what exactly means to be fast. Do we need to respond within 500 milliseconds when a user logs in? Or does it need to be 200? Depending on the type of operation, the expected responses may vary.

We also need to think of the specific conditions where we want to achieve a quality attribute. Probably an application needs to be able to respond both in normal operations and under a heavy load, but the accepted response times might be different. The application architecture will be designed on this type of decisions; either by adding more resources when required or by limiting the system capabilities until normal operation conditions resume. Again, it all relates to the business’ needs that are being covered by the application design.

Measure What Matters

Defining scenarios is a great way to start thinking about why the application requires to have a particular quality attribute; they all need to be measurable in a way that we can test it.

A good acid test for any software quality attribute is asking if measuring adds value to your organization. If it doesn’t, the effort of considering the quality attribute in your design might be a waste of time and resources. It is worthless to design an application to achieve specific quality attributes if they aren’t measured.

Degrees of Freedom

Of course, certain things can’t be changed. In software architecture, we call these constraints; we say that we have zero degrees of flexibility to operate. They are the second type of non-functional requirements.

We usually think about constraints like regulations, standards, or laws that we must comply with, or mandated technologies within a company. But maybe your organization is stuck with a particular provider or tool because of an extended contractual agreement. Or you can’t easily replace the existing infrastructure due to budget reasons.

In any case, architectural decisions need to accommodate these kind of scenarios; it is the job of the software architect to satisfy the business’ needs by designing the best system possible within the faced constraints.

Communication and Test Automation is Key

Once you select the desired software quality attributes and existing constraints, they must be communicated to the engineering team. Having a clear goal from the beginning will make things easier for everyone.

Additionally, automating all the tests related to the quality attributes will help to ensure that everything is on track when making changes, even when we consider they are not connected.

Pay attention to the test results. If you use these as a feedback loop, it will become a valuable source of continuous learning. This, in turn, will help your organization identify what the next stage of your application architecture is.

Keeping an eye on both the functional and non-functional requirements for your planning efforts will help on keeping your end-users happy.

Most of us can’t predict the future, so designing an application based on facts and not on assumptions will help you achieve your organization’s goals through software architecture in a better way.

Free!

A Business Leader’s Guide to Software Development

Download Now!