Architectural Drivers in Modern Software Architecture

Joint work with Marie

Picture by Lance Anderson on Unsplash.com

When talking about the architectural drivers of the design process, one can quickly get confused about the actual meaning of the term, since there are other terminologies such as software requirements that often come into play when searching for this topic.

The goal of this article is to provide you with a broad understanding of architectural drivers and their role within the software architecture design process. Later on, the explanations will be supported by a real world example to give you an even better idea of the importance of architectural drivers during the initial stage of your software project.

What Are Architectural Drivers?

The easiest way to understand the term “architectural drivers” is to think about it in a literal sense. Architectural drivers are a number of early made decisions driving the design process and leveling the path to the resulting software architecture. You can also think of them as guidelines that should be carefully considered by every software architect while pondering all the possible design alternatives.

Before we continue explaining the different types of architectural drivers it is important to know that there is no golden rule for choosing the right drivers for your software architecture. Every decision for or against a certain architectural driver will have a significant impact on the resulting software system and its quality. Almost all drivers are linked in one way or another, so prioritizing one driver quite often leads to the shortfall of another or even a set of others. These trade-offs are unfortunately inevitable, as you will see later on.

This is also the very reason why this article is not to be taken as a complete guide whose instructions only need to be followed step-by-step to end up with the perfect software architecture. The act of selecting architectural drivers is always heavily context-dependent and therefore every decision should be well-conceived in respect to the different targets and their relations. Or, as Kamil Grzybek puts it in his blog:

“Each of our decisions are made in a given context. Each project is different (it results from the project definition) so each context is different. It implies that the same decision made in one context can bring great results, while in another it can cause devastating failure. For this reason, using other people’s/companies approaches without critical thinking can cause a lot of pain, wasted money and finally — the end of the project.”

Functional Requirements, Quality Attributes, Constraints? What About Non-Functional Requirements?

Like stated before, you may have already heard about requirements and the discipline of requirement engineering in many other contexts. Oftentimes requirements are only being divided into functional requirements and non-functional requirements. In the context of architectural drivers however, this differentiation is unfortunate, since people tend to just dump all the requirements they find not to be functional into a single list without a second thought. In order to be able to make the best choice regarding design decisions and the associated trade-offs, architectural drivers should be discussed according to these four groups:

1. Technical Constraints
2. Business Constraints
3. Functional Requirements
4. Quality Attributes

The four groups of architectural drivers

Handling the constraints of your project

Constraints don’t fit into the “classic” categories of functional or non-functional requirements, yet they are extremely important for the software architecture design process. Constraints set the boundaries for your project, they represent the non-negotiable rules of the process that must be adhered to under all circumstances.

Figuratively speaking, they can also be seen as the pillars of your software system once it has been constructed. During the lifespan of your project you may decide for additional features to be implemented without much additional effort, but challenging the established frameworks or programming languages later on would require you to rebuild the entire system from scratch. To understand the importance of respecting constraints from the get go, let’s dive a little deeper into the two different forms of constraints relevant for the design process:

1. Technical Constraints

Technical constraints represent mostly involuntary design choices carried out by your development team that are both fixed and non-reversible in the later stages of the project. They are often brought up by internal or external stakeholders, or maybe even set as corporate standards for every project in your company.

Here are some common examples for technical constraints:

• Programming language: The chosen programming language might be dictated for a number of reasons. These may include your client’s expectations, the experience or knowledge of the development team or a restricted access to software licenses within your company.
• Support of a specific platform: These constraints are often set by the client themselves. If you’re asked to build a software that will be distributed on Windows or iOS operating systems, it must of course run on these given platforms.
• Use of a specific library or framework: Your company might require you to use a specific set of open source libraries or frameworks in your project, e.g. to ensure compatibility with the existing IT-infrastructure during the development process. Even though these constraints are set by business stakeholders, their effect on the project is of technical nature.

2. Business Constraints

Just like technical constraints, Business constraints represent non-negotiable boundaries affecting the business side of your project. Examples include:

• Timing: Software projects usually have fixed schedules defining when a development stage should be completed or specific artifacts need to be delivered to the client. Based on this set time frame you only have a limited amount of time that can be spent debating trade-off decisions or alternative scenarios.
• Budget: Similarly to timing constraints, project teams are usually bound to a specific budget by contract, which limits the number of drivers that can be invested in, necessitating compromises to be made.
• Team composition: The group of team members and included participants might be fixed according to the expectations of the project’s stakeholders, e.g. an intern that has to be included for training purposes.

While the influence of some constraints might be obvious, it is worth noting that the decision of whether or not a requirement is considered a constraint for your project should never be taken lightly. Ask yourself beforehand: Does this really constitute a non-negotiable constraint for the project or is it just a very important requirement?

Michael Keeling offers another, extremely useful tip in his blog when dealing with this issue:

Seperate the constraints you are given from the constraints you give yourself.

This advice should help you distinguish the actual constraints not to be tampered with from those that can be challenged during the course of your project. The latter may not actually be constraints but rather functional or non-functional requirements. You can learn more about constraints in this blog article by Michael Keeling.

3. Functional Requirements

Functional requirements are probably the most established kind of architectural driver because their purpose is easiest to grasp. Every software is created to complete a specific job, and functional requirements define the abilities needed to carry out the intended processes. There are many well-known ways and formats of collecting information about the features the software should provide to the end-users, such as user stories or use cases. But although it is absolutely necessary to have an understanding of the functionalities the stakeholders expect, many software projects place a disproportionate emphasis on this one-sided view of the software architecture during the requirements engineering. Functionality is essential, but it doesn’t actually determine the architecture of your software in any way.

In fact, if functionality was the only thing you cared about, there would be a practically infinite number of possible architecture designs to choose from. You could even throw caution to the wind and put all of your code into a single, monolithic block of software. But while this architecture (or rather, lack thereof) might get the job done from a mere functional point of view, it’s not unlikely that the software would be so slow, insecure or otherwise unwieldy that it would satisfy neither the end-users nor your stakeholders. Not to mention the absolute hassle of refactoring a software that has no kind of internal structure, which would see your maintenance costs go through the roof. This is why in today’s digital age where software products have become increasingly complex, the majority of costs that add up during the lifetime of a system can often be attributed to the need of performing maintenance activities after the software has been released.

Consequently, it’s not enough to make sure that your software does what it’s intended to do. Rather you should compare different design options based on how well they support the stakeholders’ expectations towards the quality of the system.

4. Quality Attributes

This is where quality attributes come into play. Like the name suggests, they describe the fitness or quality of a software and as such can have a significant impact on the architecture design. Just like functional requirements should never be your single source of information during the planning of the software architecture, quality attributes cannot be discussed independently: They always refer to a specific system function in regards to how it should be executed.

As an example, a required functionality of a desktop application could be the appearance of a dialog box after the user clicks on a button. A quality attribute would then state a quantified requirement towards this function, for example “After the user clicks on the button, the dialog box should appear within two seconds.”

This example also shows that quality attributes should always be measurable and specified as precisely as possible, leaving no room for interpretation. Vague statements such as “Our system should be fast” or “We want our software to be user-friendly” are entirely subjective and make it impossible to assess the functions of a system.

The most prominent quality attributes

How to elicit and specify them

If you’re a software architect who is supposed to construct a new or adapt an existing software system, it would obviously make your job a lot easier if your client simply gave you a list that had all the relevant quality attributes neatly lined up and described thoroughly. However, experience shows that while functional requirements are oftentimes described in great detail, many clients either have no clear idea which quality attributes are the most relevant for their particular domain or only have a vague, highly unrealistic notion of all the qualities the system should possess. Because of this, a software architect must actively engage in conversation with different stakeholder groups to explore the most important attributes and try to put them into perspective for those who don’t have a technical background.

What makes this task even more demanding is the fact that not every client seems to be aware of the fact that all quality attributes have an impact on one another, and to complete avoid trade-offs is almost impossible. A system dealing with sensitive, personal data in which security is seen as the most important principle will likely experience extensive protective measures negatively affecting the system’s performance. But if you asked your client directly what their expectations regarding the system quality looked like, the conversation might very well go like this:

Architect: “What are your expectations regarding the availability of the system?”

Client: “Oh, the system should be running 24/7. We can’t have users try to reach the site to no avail.”

Architect: “Okay, and what about the security of the software, what kind of structures do you need to protect user data?”

Client: “All of it, please.”

If this happens, you need to make sure the client understands how different quality attribute combinations affect each other. Ask them to prioritize the captured requirements using techniques such as the MoSCoW method or a simple scale of High/Medium/Low. They might have a hard time distinguishing the necessary attributes from those that fall into the “nice-to-have” category, so try to put things into perspective regarding the business side of the project. As an example, mention how a system that is available 99.999% of the time will increase the project costs compared to a slightly lower availability. They might then realize that this kind of quality isn’t really a priority after all.

After some time, you should have a better understanding of the quality attributes that need to be prioritized during the design of the software architecture.

Possible trade-off between two quality attributes

Scenarios

What you should do now is formalize them in a way that allows you to measure and later on test the degree to which the system fulfills these demands. A great method of describing quality attributes in software systems is the use of scenarios made up of the following elements:

1. Stimulus: This term refers to an event triggering a specific reaction by the system. Common examples are incoming user requests or even attacks, although more abstract events taking place inside the development team, such as the completion of a project stage, can incite specific actions regarding the quality of the software.
2. Stimulus source: The origin of the incoming event oftentimes determines how it will be treated by a system. Requests by trusted, authenticated users will not get the same reaction as those made by uncertified sources.
3. Environment: Just like the source of a stimulus, the circumstances of its arrival sometimes influence the system’s response and therefore need to be considered during the scenario elicitation. A software in repair mode may be more susceptible to attacks and therefore more likely to shut down in order to protect its data whereas the defense of systems in normal operation mode may be more resilient.
4. Artifact: In some cases, a quality requirement doesn’t affect the entire system, but rather parts of it, which need to be specified if you want to make sure that your system can be assessed precisely.
5. Response: This specifies how the system should react to a new stimulus.
6. Response measure: As stated before, the requirements towards quality attributes need to be quantified in order to be able to evaluate the system’s capabilities accordingly. The system’s ability to satisfy these restrictions (e.g. reaction times or a specific throughput) while performing the predetermined response decides whether or not the software is fit to use, complying with stakeholders’ expectations.

General scenario structure

To give you a more practical idea of the possible requirements that software systems need to fulfill, we will take a look at six of the most prominent quality attributes. This list is of course non-exhaustive with many more relevant sub-categories and further quality attributes that might be necessary to consider for your particular business environment and type of system, but these represent the basic drivers that most software systems adhere to in some way or another. Scenarios for quality attributes are described in greater detail in the book ‘Software Architecture in Practice’ by Bass et al..

Performance

The quality attribute of performance relates to a system’s ability to meet timing requirements by responding to events such as incoming requests or user inputs. Historically, this requirement dominated the non-functional side of architecture design for a long time, although the decreasing price of powerful hardware has allowed companies to focus on other, equally important quality aspects. Yet performance remains a critical quality attribute whose shortcoming can negatively affect the entire system and its perception by users. Common methods of measuring performance requirements include:

• Latency: Delay between the arrival of a stimulus and the observable system response.
• Throughput: Number of transactions that can be processed in a specified time frame.

Interoperability

Interoperability is needed when a system is supposed to communicate with one or more systems. It requires both the ability to exchange data (syntactic interoperability) and the ability to interpret the information correctly and extract meaning from it (semantic interoperability). I’ts always necessary to evaluate the required interoperability by examining the particular context of use and design the architecture accordingly. There are well-established standards and external APIs to choose from, although these do not always guarantee a long-term flawless integration of multiple systems: Challenges range from legal issues regarding privacy or security concerns to expensive maintenance costs after a new software version has created problems in the system communication.

Maintainability

An integral part of being a successful software architect is the understanding that change is inevitable. The development process doesn’t end with the release of the system, and in many cases, this is when the real work starts to add up. Bug fixes, new functional requirements or technical updates need to be included, so a well-arranged, concise system that supports future changes makes it a lot easier to adapt your design, especially if you have newcomers in your team that are unfamiliar with the actual code. In order to allow the modification of a software system without introducing a drop in quality, it’s generally advided to create smaller, loosely coupled modules with great cohesion.

Usability

Usability is one of the most important quality attributes because it has a direct influence on the user satisfaction that may ultimately decide if the user will stick to your system or be frustrated and search for an alternative elsewhere. It describes the extent to which a system’s design allows a user to accomplish their goals efficiently and the subjective user experience that comes with navigating the software. As such, there are a number of strategies to make a system more user-friendly, including:

• Learnability: The system should be designed in such a way that people unfamiliar with the software quickly and intuitively learn how to use it while experienced users should easily pick up new functionalities.
• Visual design: A layout that is concise and consistent in its use of colors or fonts not only improves readability but also makes it a lot easier to successfully work with a system.

Reliability

Reliability is concerned with the ability of a software system to continue operating over time and under predefined conditions. An important sub-category that is often used to define the reliability of a system is availability, because software systems mostly fail to operate due to the inaccessability of one or more components. Metrics such as the availability percentage (ratio of available system time to total working time) are commonly found in so-called “Service Level Agreements” defining a specific amount of downtime that is tolerated and can be used to plan for system upgrades, scheduled maintenance or unexpected failures. This uptime can also be achieved if the system is able to either mask or repair faults in time so they don’t result in a crash visible to the outside world.

Security

Security describes the extent to which a system is able to protect sensitive data from unauthorized access and deal with exterior attacks of different forms. Therefore it is one of the most integral quality attributes for many business applications, especially web-based systems. Security measures can be categorized as follows:

• Confidentiality: Data or services can’t be accessed by unauthorized systems, persons or processes.
• Integrity: Information can’t be manipulated by unauthorized systems, persons or processes.
• Availability: The system remains intact and available for legitimate use despite attacks such as Denial-of-Service.

Bringing It All Together, an Open Source Example With Web Applications & Firefox

After having talked about the basic concepts and principles of architectural drivers in the software design process, let’s now focus on a real world example to illustrate how trade-offs and scenarios might be applied in actual software projects. We’re going to limit this example to the portrayal of quality attributes due to the fact that functional requirements and related techniques have already been extensively discussed in various studies and scientific works. Similarly, constraints are not only heavily context-dependent, but also constitute rather sensitive data regarding the financial and organizational layout of a project, which is why they aren’t readily available from an outside perspective. To try and give you a sense of quality attribute design we will explore how the security prioritization of the open source web browser Firefox might affect other quality attributes and look at scenarios directly derived from Firefox’s security practices.

Security and its trade-offs

Because web browsers serve as a vehicle for users wanting to navigate the Internet, their requirements regarding the quality of the service somewhat mirror those that web applications using this infrastructure need to fulfill. Naturally, the complexity of today’s web applications requires a wide array of quality attributes that need to be considered, but to make things concise we are going to examine the three most important quality attributes according to recent studies, namely security, reliability and usability.

As an integral aspect of the fierce competition between the dominating web browsers, the prioritization of security measures is essential to Firefox, especially considering the fact that nowadays all kinds of business transactions and personal data are handled via the web that need to be protected in order to gain the user’s trust. However, putting security at the center of the design process comes with a number of trade-offs, whereas other quality attributes benefit from this prioritization.

The latter is the case regarding reliability: Web applications regularly become subject to systematic attacks attempting to render their services unavailable by flooding it with requests. As the gatekeepers of any type of web application on the Internet, web browsers that employ a number of security mechanisms in order to prevent these denial-of-service attacks automatically improve the availability of its services that will likely experience less down time. As a result, it can be stated that investing in a system’s security inherently satisfies its reliability goals.

The same can’t be said for the relationship between security and usability that comes with numerous trade-offs. As an example, the Firefox team decided to implement a sandbox environment that is activated whenever the user performs financial transactions of any kind. This sandbox environment protects the user’s data from malicious attacks or man-in-the-middle exploits, but it also forces the user to open an extra window that can only be used for this action and needs to be closed manually after the session has ended. Although created to enhance the user’s security during the process, the lack of automation is rather cumbersome and may hamper user experience. Another design choice that highlights how Firefox prioritizes the security of all users over some people’s satisfaction with the service is its handling of Java plug-ins. In order to safeguard the users, Firefox deactivates Java plug-ins by default if known issues with said plug-in haven’t been fixed by the manufacturer, leading to unportrayable content on many web sites and applications.

These examples illustrate the significance of comprehensive security strategies for Firefox’s business model and competitive capacity, accepting trade-offs where reducing the user experience is deemed necessary while the reliability of its services is improved without much additional effort.

We now want to provide you with two exemplary security measures specifying Firefox’s internal standards towards this quality attribute in the form of scenarios. As stated before, these are derived from Firefox’s security practices that are available online (more information here). The first scenario takes a look at the organizational handling of bug fixes, describing how discovered system vulnerabilities are being treated internally. The second scenario examines the system’s reaction towards attempted attacks on the user’s computer on a technical level.

1. Scenario (Security): ReDoS Attack Exploiting Vulnerable Javascript Plug-Ins

• Source of stimulus: Currently unknown. Propably a human attacker from outside the organization.
• Stimulus: An attack exploiting weaknesses in a JavaScript plug-in that could drastically reduce server availability and might even lead to a server crash on the affected website. So-called ReDoS attacks tamper with regex information-based protocols and the systemic vulnerability during the execution of those scripts (exponential related to input size). These kinds of attacks can’t be prevented by using classic DDos defence mechanisms.
• Environment: The attack can take place when the system is online and connected to a network. Firewalls can’t prevent these kinds of attacks regardless of the exposed network.
• Artifact: The attack is targeted at the services of the system.
• Response: After the potential security risk has been reported, it will undergo a formal process inside the Firefox organization: It will be tested if the person alerting the team to the vulnerability is eligible for the bounty program rewarding reports of security-related bugs. The bug fix will then be passed on through the proper channels including a module owner responsible for the handling of the bug and a surrounding team of peer advisors etc. A security fix will then be established and distributed either with the next Firefox update or as a hotfix, depending on the criticality.
• Response measure: In the Firefox Vulnerability Report this would be considered a moderate or low vulnerability. Known bugs to parts of the web browser’s components are usually being fixed within a time frame of at least 21 days.

Scenario for Security ReDoS attack

2. Scenario (Security): Malware Attack via Download of Corrupted Files

• Source of stimulus: An attack from outside the organization. Passive attack aiming at a large number of users using the web browser to access web sites, that are unaware of the site’s downloadable files containing malware.
• Stimulus: The attempted download of a corrupted file by a user.
• Artifact: The attack is targeted at the infection of the user’s computer, resulting in various possible outcomes including data theft, further installation of malicious content or spam mail.
• Environment: For a successful execution of the attack the victim needs to be connected to a network and actively trying to download the corrupted file from the web site.
• Response: Firefox compares each visited website to a stored list of websites known to contain malicious content and will actively prevent users from downloading files from these detected websites. Before blocking the download, Firefox will perform a double-check to ensure that the reported site has not been removed from the list since the last update. This request does not include the complete address of the visited site, it only contains partial information derived from the address.
• Response Measure: The stored list is updated every 30 minutes from an online database and receives its contents either from user feedback or due to the automatic scanning of web sites.

Quick Recap

We hope this article has given you a basic understanding of the importance of architectural drivers and their possible use in different situations. Keep in mind that the given example only takes a look at one of the many drivers that might be important to consider for your project. We are aware that this isn’t exactly a simple task that can be dealt with quickly, nevertheless it is important to carefully examine all the possible drivers of your software system and discuss them with your team. The more time you invest specifying the drivers and their respective trade-offs during the early stages of the design process, the more likely your finished product will satisfy your stakeholder’s expectations and remain successful throughout its life cycle.

We also created this checklist to remind you of the most important principles and rules that you need to consider during the design process. Feel free to expand this list based on your own experiences.

Your Personal Checklist

Identify all the fixed, non-negotiable constraints regarding the technical and business side of your project. If in doubt, ask your team, your company or the clients whether there are any restrictions limiting your choices during the architecture design. Discuss and document them.

Define the key features the system must possess and any other functional requirement that is deemed necessary by the stakeholders. This can be facilitated exploring user needs with methods like use cases or user stories.

Make yourself familiar with the most important quality attributes of your domain and type of system. Find out which of these are applicable to your project and keep them in mind for later discussions.

Talk to the different groups of stakeholders in your project and find out about their expectations regarding the quality of the system. If they only have a very vague or unrealistic idea of the necessary system qualities, be patient and try to put them into perspective by explaining how different alternatives will affect the timing or budget constraints of the project.

Prioritize the emerging quality attributes together. Make sure the stakeholders are aware of any existing trade-offs and accept the resulting limitations of the software system.

Specify the collected quality attributes by using scenarios.

You should be able to answer all of these questions positively:

• Have all relevant technical and business constraints been identified and documented?
• Is it clear which features must be enabled by the architecture and what is the main purpose of the system?
• Does everyone have a clear understanding of the quality attributes our architecture design needs to fulfill?
• Is everyone aware and accepting of the resulting trade-offs?
• Are these decisions in accordance with the technical and business constraints? Can we stick to the schedule and budget of the project? Can our plans be realized using the available technical resources?
• Are all of our quality attribute scenarios S.M.A.R.T (specific, measurable, achievable, relevant, timely)?
• Do our scenarios allow us to test the software quality at a later stage in the product life cycle?

For Further Reading

• Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice. Addison-Wesley Professional.
• Brown, S. (2013). Software Architecture for Developers. Coding the Architecture.
• Ingeno, J. (2018). Software Architect’s Handbook: Become a Successful Software Architect by Implementing Effective Architecture Concepts. Packt Publishing Ltd.
• Offutt, J. (2002). Quality Attributes of Web Software Applications. IEEE Software, 19(2), 25–32.
• Satish, P. S., & Chavan, R. (2017). Web Browser Security: Different Attacks Detection and Prevention Techniques. International Journal of Computer Applications, 170(9).
• Silva, Antonio Cesar Brandao, et al. (2017). “The Influence of Software Product Quality Attributes on Open Source Projects: A Characterization Study.” International Conference on Enterprise Information Systems. Vol. 2. Scitepress