O'Reilly logo

Fundamentals of Software Architecture by Neal Ford, Mark Richards

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Architecture Characteristics Defined

A company decides to solve a particular problem using software, so they gather a list of requirements for that system. A wide variety of techniques exist for the exercise of requirements gathering, generally defined by the software development process used by the team. But the architect must consider many other factors in designing a software solution, as illustrated in Figure 4-1.

Requirements
Figure 4-1. A software solutions consists of both domain requirements and architectural characteristics.

Architects may collaborate on defining the domain or business requirements, but one key responsibility entails defining, discovering, and otherwise analyzing all the things the software must do that isn’t directly related to the domain functionality: architectural characteristics.

What distinguishes software architecture from coding and design? Many things, including the role that architects have in defining architectural characteristics, the important aspects of the system independent of the problem domain. Many organizations describe these features of software with a variety of terms, including non-functional requirements, but we dislike that term because it is self-denigrating. Architects created that term to distinguish architecture characteristics from functional requirements, but naming something non-functional has a negative impact from a language standpoint: how can teams be convinced to pay enough attention to something named “non-functional”? Another popular term is quality attributes, which we dislike because it implies after-the-fact quality assessment rather than design. We prefer architecture characteristics because it describes concerns critical to the success of the architecture and therefore the system as a whole without discounting its importance.

An architecture characteristic meets three criteria:

  • Specifies a non-domain design consideration

  • Influences some structural aspect of the design

  • Critical or important to application success

These interlocking parts of our definition are illustrated in Figure 4-2.

Characteristics Triangle
Figure 4-2. The differentiating features of architecture characteristics.

The definition illustrated in Figure 4-2 consists of the three components listed above, in addition to a few modifiers.

Specifies a non-domain design consideration

When designing an application, the requirements specify what the application should do; architecture characteristics specify operational and design criteria for success, concerning how to implement the requirements and why certain choices were made. For example, a common important architecture characteristics specifies a certain level of performance for the application, which often doesn’t appear in requirements document. Even more pertinent: no requirements document states “prevent technical debt”, but it is a common design consideration for architects and developers. We cover this distinction between explicit and implicit characteristics in depth in “Extracting Architecture Characteristics from Domain Concerns”.

Influences some structural aspect of the design

The primary reason architects try to describe architecture characteristics on projects concerns design considerations—does this architecture characteristic require special structural consideration to succeed? For example, security is a concern on virtually every project, and all systems must take a baseline of precautions during design and coding. However, it rises to the level of architecture characteristic when the architect needs to design something special. Consider two cases surrounding payment in a example system:

third party payment processor: If an integration point handles payment details, then the architecture shouldn’t require special structural considerations. The design should incorporate standard security hygiene such as encryption and hashing but doesn’t require special structure.

in-application payment processing: If the application under design must handle payment processing, the architect may design a specific module, component, or service for that purpose to isolate the critical security concerns structurally. Now, the architecture characteristic has an impact on both architecture and design.

Of course, even these two criteria aren’t sufficient in many cases to make this determination: past security incidents, the nature of the integration with the third party, and a host of other criteria may be present during this decision. However, it shows some of the considerations architects must make when determining how to design for certain capabilities.

Critical or important to application success

Applications could support a huge number of architecture characteristics…but shouldn’t. Support for each architecture characteristics adds complexity to the design. Thus, a critical job for architects lies in choosing the fewest architecture characteristics rather than most possible.

We further subdivide architecture characteristics into implicit versus explicit architecture characteristics. Implicit ones rarely appear in requirements yet are necessary for project success. For example, availability, reliability, and security underpin virtually all applications yet is rarely specified in design documents. Architects must use their knowledge of the problem domain to uncover these architecture characteristics during the analysis phase. For example, a high-frequency trading firm may not have to specify low latency in every system, yet the architects in that problem domain know how critical it is. Explicit architecture characteristics appear in requirements documents or other specific instruction.

In Figure 4-2, the choice of triangle is intentional: each of the definition elements support the others, which in turn support the overall design of the system. The fulcrum created by the triangle illustrates the fact that each of these architecture characteristics often interact with one another, leading to the pervasive use of the term tradeoff amongst architects.

Architectural Characteristics (Partially) Listed

Architecture characteristics exist along a broad spectrum of the software system, ranging from low-level code characteristics such as modularity to sophisticated operational concerns such as scalability and elasticity. No true universal standard exists despite attempts to codify ones in the past. Instead, each organization creates their own interpretation of these terms. Additionally, because the software ecosystem changes so fast, new concepts, terms, measures, and verifications constantly appear, providing new opportunities for architecture characteristics definitions.

Despite the volume and scale, architects commonly separate architecture characteristics into broad categories. Here are a few along with some examples.

Operational Architecture Characteristics

Operational architecture characteristics cover capabilities such as performance, scalability, elasticity, availability, reliability, and so on; Table 4-1 lists some operational architecture characteristics.

Table 4-1. Common Architecture Characteristics
Term Definition

Availability

How long the system will need to be available (24X7) (in which case steps need to be in place to allow the system to be up and running quickly in case of any failure)

Continuity

Disaster recovery capability

Performance

Includes stress testing, peak analysis, analysis of the frequency of functions used, capacity required, response times etc. Performance acceptance is sometimes requires an exercise of its own taking months to complete

Recoverability

Business continuity requirements (e.g., in case of a disaster, how quickly is the system required to be on-line again?). This will affect the back up strategy, requirement for duplicated hardware, etc.

Reliability/ Safety

To assess if the system needs to be fail safe, or if it is mission critical in a way that affect lives? If it falls over, will it cost the money large sums of money?

Robustness

Ability to handle error and boundary conditions while running (internet connection goes down, power outage or hardware failure)

Scalability

Ability for the system to perform and operate as the number of users or requests increase

Operational architecture characteristics heavily overlap with operations and DevOps concerns, forming the intersection of those concerns in many software projects.

Structural Architecture Characteristics

Architects must concern themselves with code structure as well. In many cases, the architect has sole or shared responsibility for code quality concerns such as good modularity, controlled coupling between components, readable code, and a host of other internal quality assessments; Table 4-2 lists a few structural architecture characteristics.

Table 4-2. Structural Architecture Characteristics
Term Definition

Configurability

Ability for the end users to change aspects of the software’s configuration easily (through usable interfaces)

Extensibility

How important it might be to plug new pieces of functionality in

Installability

Ease of system installation on all necessary platforms

Leverageability/reuse

Ability to leverage common components across multiple products

Localisation

Support for multiple languages on entry/query screens (Mumbai) in data fields; on reports; multi-byte character requirements and units of measure or currencies

Maintainability

How easy it is to apply changes and enhance the system?

Portability

Does the system need to run on more than one platform (e.g., does the front end need to run against Oracle as well as SAP DB? Does the system need to run on UNIX as well as Windows 2000?)

Supportability

What level of technical support is needed by the application? What level of logging and other facilities are required to debug errors in the system?

Upgradeability

Ability to easily/quickly upgrade from a previous version of this application/solution to a newer version on servers and clients

Cross-cutting Architecture Characteristics

While many architecture characteristics fall into easily recognizable categories, many fall outside or defy categorization, yet form important design constraints and considerations; Table 4-3 describes a few of these.

Table 4-3. Cross-cutting Architecture Characteristics
Term Definition

Accessibility

Access to all your users including disabilities like color-blindness or hearing loss

Archivability

Will the data need to be archived off (deleted) after a period of time - eg. Customer accounts to be deleted after 3 months - or marked as obsolete and archived to a secondary database for future access?

Authentication

Security requirements to ensure “you are who you say you are”

Authorization

Security requirements to ensure users can access only certain functions within the application (by use case, subsystem, web page, business rule, field level etc)

Legal

What legislative constraints is the system operating in? (Data Protection, Sarbanes Oxley, GDPR, etc.). What reservation rights does the company require? Any regulations regarding the way the application is to be built or deployed?

Privacy

Ability to hide transactions from internal company employees (encrypted transactions so even DBA’s and network architects cannot see them)

Security

Does the data need to be encrypted in the database? Encrypted for network communication between internal systems? What type of authentication need to be in place for user’s access remotely?

Supportability

What level of technical support is needed by the application? What level of logging and other facilities are required to debug errors in the system?

Usability/achievability

Level of training required for users to achieve their goals with the application/solution. Usability requirements need to be treated as seriously as any other architectural issue

Any list of architecture characteristics will necessarily be an incomplete list; any software may invent important architectural characteristics based on unique factors (see “Italy-ility” for an example).

Additionally, many of the terms appearing above are imprecise and ambiguous, sometimes because of subtle nuance or the lack of objective definitions. For example, interoperability and compatibility may appear equivalent, which will be true for some systems. However, they differ because interoperability implies ease of integration with other systems, which in turn implies published, documented APIs. Compatibility, on the other hand, more concerns industry and domain standards. Another example is learnability. One definition is how easy users can learn to use the software, yet another definition is the level at which the system can automatically learn about its environment in order to become self-configuring or self-optimizing using machine learning algorithms.

Many of the definitions overlap in many cases. For example, consider availability and reliability, which seem to overlap in almost all cases. Yet, consider the Internet protocol UDP, which underlies TCP. UDP is available over IP but not reliable: the packets may arrive out of order, and the receiver may have to ask for missing packets again.

No complete list of standards exist. The ISO (International Organization for Standards publishes a list organized by capabilities, overlapping many of the ones listed above, but mainly establishing an incomplete category list. The following are some of the ISO definitions:

Performance efficiency

Measure of the performance relative to the amount of resources used under known conditions. This includes time behavior (measure of response, processing times, and/or throughput rates), resource utilization (amounts and types of resources used), and capacity (degree to which the maximum established limits are exceeded).

Compatibility

Degree to which a product, system or component can exchange information with other products, systems or components, and/or perform its required functions, while sharing the same hardware or software environment. It includes co-existence (can perform its required functions efficiently while sharing a common environment and resources with other products) and interoperability (degree to which two or more systems can exchange and utilize information).

Usability

Users can use the system effectively, efficiently and satisfactorily for its intended purpose. It includes appropriateness recognizability (users can recognize whether the software is appropriate for their needs), learnability (how easy users can learn how to use the software), user error protection (protection against users making errors), accessibility (make the software available to people with the widest range of characteristics and capabilities.

Reliability

Degree to which a system functions under specified conditions for a specified period of time. This characteristics includes sub-categories such as maturity (does the software meet the reliability needs under normal operation), availability (software is operational and accessible), fault tolerance (does the software operate as intended despite hardware or software faults), and recoverability (can the software recover from failure by recovering any affected data and re-establish the desired state of the system. Parenthetically, we think the maturity criteria listed above has a terrible name, but it is part of the specification.

Security

Degree the software protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization. This family of characteristics includes confidentiality (data are accessible only to those authorized to have access), integrity (the software prevents unauthorized access to or modification of software or data), non-repudiation, (can actions or events be proven to have taken place), accountability (can user actions of a user be traced), and authenticity (proving the identify of a user).

Maintainability

This characteristic represents the degree of effectiveness and efficiency that developers can modify the software to improve it, correct it or adapt it to changes in environment and/or requirements. This characteristic includes modularity (degree to which the software is composed of discrete components), reusability (degree to which developers can use an asset in more than one system, or in building other assets), analysability (how easily can developers gather concrete metrics about the software), modifiability (degree to which developers can modify the software without introducing defects or degrading existing product quality), and testability (how easily can developers and others test the software).

Portability

Degree with which developers can transfer a system, product or component from one hardware, software or other operational or usage environment to another. This characteristic includes the sub-characteristics adaptability (can developers effectively and efficiently adapt the software for different or evolving hardware, software or other operational or usage environments), installability (can the software be installed and/or uninstalled in a specified environment), and replaceability, (how easily can developers replace the functionality with other software).

The last item in the ISO list addresses the functional aspects of software, which we do not believe belongs in this list.

Functional Suitability

This characteristic represents the degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions. This characteristic is composed of the following sub-characteristics:

Functional completeness: Degree to which the set of functions covers all the specified tasks and user objectives.

Functional correctness: Degree to which a product or system provides the correct results with the needed degree of precision.

Functional appropriateness: Degree to which the functions facilitate the accomplishment of specified tasks and objectives.

These are not architecture characteristics but rather the motivational requirements to build the software. This illustrates how thinking about the relationship between architecture characteristics and the problem domain has evolved. We cover this evolution in Chapter 7.

Tradeoffs and “Least Worst” Architecture

Applications can only support a few the architecture characteristics listed above for a variety of reasons. First, each of the supported characteristics requires design effort and perhaps structural support. Second, the bigger problem lies with the fact that each architecture characteristics often has an impact on others. For example, if an architect wants to improve security, it will almost certainly negatively impact performance: the application must do more on-the-fly encryption, indirection for secrets hiding, and other activities that potentially degrade performance.

A metaphor will help illustrate this interconnectivity. Apparently, pilots often struggle learning to fly helicopters because it requires a control for each hand and each foot, and changing one impacts the others. Thus, flying a helicopter is a balancing exercise, which nicely describes the tradeoff process when choosing architecture characteristics. Each architecture characteristic an architect design support for potentially complicates the overall design.

Thus, architects rarely encounter the situation where they are able to design a system and maximize every single architecture characteristics. More often, the decisions come down to tradeoffs between several competing concerns.

Least Worst Architecture

Never shoot for the best architecture, but rather the least worst architecture.

Too many architecture characteristics leads to generic solutions that are trying to solve every business problem, and those architectures rarely work because the design becomes unwieldy.

This suggests that architects should strive to design architects to be as iterative as possible. If you can make changes to the architecture more easily, the architect can stress less about discovering the exact correct thing in the first attempt. One of the most important lessons of agile software development is the value of iteration; this holds true at all levels of software development, including architecture.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required