- 3.1 Making Design Decisions
- 3.2 Design Concepts: The Building Blocks for Creating Structures
- 3.3 Design Concepts to Support Performance
- 3.4 Design Concepts to Support Availability
- 3.5 Design Concepts to Support Modifiability
- 3.6 Design Concepts to Support Security
- 3.7 Design Concepts to Support Integrability
- 3.8 Summary
- 3.9 Further Reading
- 3.10 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2 Design Concepts: The Building Blocks for Creating Structures
Design is not random, but rather is planned, intentional, rational, and directed. The process of design might seem daunting at first. When facing the “blank page” at the beginning of any design iteration, the space of possibilities might seem impossibly huge and complex; however, there is some help here. Over the course of decades, the software architecture community has created and evolved a body of generally accepted design principles that can guide us to create high-quality designs with predictable outcomes.
For example, some well-documented design principles are oriented toward the achievement of specific quality attributes:
To help achieve high modifiability, aim for good modularity, which means high cohesion and low coupling.
To help achieve high availability, avoid having any single point of failure.
To help achieve scalability, avoid having any hard-coded limits for critical resources.
To help achieve security, limit the points of access to critical resources.
To help achieve testability, externalize state.
. . . and so forth.
In each case, these principles have been evolved over decades of dealing with those quality attributes in practice. But these principles are rather abstract. To make them more usable in practice, a set of design concepts have been cataloged. These concepts serve as the building blocks of architectures. Different types of design concepts exist, and in the following subsections we discuss some of the most commonly used, including reference architectures, patterns, tactics, and externally developed components (such as frameworks). Whereas the first three are conceptual in nature, the last one is concrete.
3.2.1 Reference Architectures
Reference architectures are blueprints that provide an overall logical structure for particular classes of applications. A reference architecture is a reference model mapped onto one or more architectural patterns. Its utility has been proven in business and technical contexts, and it typically comes with a set of supporting artifacts that facilitates its use.
An example of a reference architecture for the development of service applications (such as microservices) is shown in Figure 3.1. This reference architecture establishes the main layers for this type of application—service, business, and data—as well as the types of elements that occur within the layers and the responsibilities of these elements, such as service interfaces, business components, data access components, service agents, and so on. Also, this reference architecture introduces cross-cutting concerns, such as security and communication, that need to be addressed. As this example shows, when you select a reference architecture for your application, you also adopt a set of concerns that you need to address during design. You may not have an explicit requirement related to communications or security, but the fact that these elements are part of the reference architecture guides you to make design decisions about them.
)
FIGURE 3.1 Service application reference architecture
Reference architectures may be confused with architectural styles, but these two concepts are different. Architectural styles (such as “pipe and filter” and “client-server”) are patterns that define types of components and connectors in a specified topology that are useful for structuring an application either logically or physically. Reference architectures, in contrast, provide a more detailed structure for entire applications, and they may embody multiple patterns. Reference architectures are preferred by practitioners—which is also why we favor them in our list of design concepts.
Many reference architectures are available, but there is no single authoritative catalog of them. In the context of cloud development, providers have created a number of useful catalogs that collect reference architectures focused on cloud resources. In addition, many catalogs of patterns have been created across the years, and new ones appear periodically.
3.2.2 Patterns
Design/architectural patterns are conceptual solutions to recurring design problems that exist in a defined context. Although design patterns originally focused on decisions at the object scale, including instantiation, structuring, and behavior, today there are catalogs of patterns that address decisions at varying levels of granularity. In addition, there are specific patterns to address quality attributes such as security, availability, performance, and integrability.
Some people might differentiate between what they consider to be architectural patterns and the more fine-grained design patterns. However, we believe there is no principled difference that can be solely attributed to scale. We consider a pattern to be architectural when its use directly and substantially influences the satisfaction of some of a system’s architectural drivers.
Another important type of pattern that has significant implications for the architectural design process is deployment patterns. These patterns package key decisions that shape the system’s infrastructure and have profound implications for quality attributes such as availability, performance, modifiability, and usability. Such decisions are often bound early in the product life cycle. We will discuss deployment patterns in Chapter 6.
We provide examples of patterns for a number of quality attributes in Sections 3.3 through 3.8. Note that these are just examples—many more patterns exist for each quality attribute, and for other qualities.
3.2.3 Tactics
Architects can also employ fundamental design techniques to help achieve a response goal for a particular quality attribute. We call these architectural design primitives tactics. Tactics, like patterns, are techniques that architects have been using for years. We do not invent tactics, but simply capture what architects have done in actual practice, over the decades, to manage quality attribute response goals.
Tactics are design decisions that influence the control of a quality attribute response. For example, if you want to design a system to have good usability, you would need to make a set of design decisions that support this quality attribute, as represented in Figure 3.2.
)
FIGURE 3.2 Usability tactics mediate user interactions and responses
Tactics are simpler than patterns. They focus on the control of a single quality attribute response (although they may, of course, trade off this response with other quality attribute goals). Patterns, in contrast, typically focus on resolving and balancing multiple forces—that is, multiple quality attribute goals. By way of analogy, we can say that a tactic is an atom, whereas a pattern is a molecule.
Tactics provide a top-down way of thinking about design. A tactics categorization begins with a set of design objectives related to the achievement of a quality attribute, and presents the architect with a set of options from which to choose.
For example, in Figure 3.3, the design objectives for usability are “Support user initiative” and “Support system initiative”. An architect who wants to create a system with “good” usability needs to choose one or more of these options. That is, the architect needs to decide if they want to support a user in their tasks by allowing for features such as undo, cancel (for long-running or hung operations), aggregation (of similar UI objects so that a user-issued command applies to all of them), or pause/resume (again, typically used for long-running operations). The architect may also want to support system initiatives, such as maintaining a model of the task (so that, for example, context-appropriate help and guidance can be given), maintaining a model of the user (so that user-appropriate feedback is offered; for example, a novice user might want far more guidance, whereas an expert user might want shortcuts for common operations), or maintaining a system model (for example, being able to accurately estimate time remaining for long-running operations).
Each of these tactics is an option for the architect. They may be instantiated via coding, via patterns, or via external components such as frameworks—but they are architectural. To offer undo capabilities, the system must maintain a set of transactions, representing changes to the system state, and be able to roll back any of those transactions to undo—that is, to return the system to its prior state. To be able to offer cancel capabilities, the system must be able to revert its state to whatever it was before the operation was initiated. These sorts of capabilities require architectural thinking, and tactics provide a starting point for this decision-making process. As we will see in Chapter 4, the choice, combination, and tailoring of tactics and patterns are some of the key steps of the ADD process.
)
FIGURE 3.3 Usability tactics categorization
Tactics categorizations have been established for the quality attributes of availability, deployability, energy efficiency, interoperability, modifiability, performance, safety, security, testability, and usability. Collectively, these categorizations cover the vast majority of the design decisions that an architect needs to make in practice.
3.2.4 Externally Developed Components
Both patterns and tactics are abstract in nature. When you are designing a software architecture, however, you need to make these design concepts concrete and closer to the actual implementation. There are two ways to achieve this: You can code the elements obtained from tactics and patterns, or you can associate technologies with one or more of these elements in the architecture. This “buy versus build” choice is one of the most important decisions you will make as an architect.
We consider technologies to be externally developed components, because they are not created as part of the development project. Several types of externally developed components exist:
Technology families. A technology family represents a class of technologies with common functional purposes. It can serve as a placeholder until a specific product or framework is selected. Examples include a relational database management system (RDBMS) and an object-oriented to relational mapper (ORM).
Products. A product (or software package) comprises a self-contained piece of software that can be integrated into the system that is being designed and that requires only minor configuration or coding. An example is a relational database management system, such as Oracle or PostgreSQL, which belongs to the RDBMS technology family. APIs (application programming interfaces) from external systems are one commonly encountered type of product; we discuss them in Chapter 5. We discuss another type of product, cloud capabilities made available by cloud provider platforms, in Chapter 7.
Application frameworks. An application framework (or just framework) is a reusable software element, constructed out of patterns and tactics, that provides generic functionality addressing recurring domain and quality attribute concerns across a broad range of applications. Frameworks, when carefully chosen and properly implemented, increase the productivity of programmers. They do so by enabling programmers to focus on business logic and end-user value, rather than on the underlying technologies and their implementations. As opposed to products, framework functions are generally invoked from the application code or are “injected” using some type of dependency injection approach. Frameworks usually require extensive configuration, typically through XML files or other approaches such as annotations in Java. One example of a framework is Hibernate, which is used to perform object-oriented to relational mapping in Java. Several types of frameworks are available: Full-stack frameworks, such as Spring, are usually associated with reference architectures and address general concerns across the different elements of the reference architecture, whereas non-full-stack frameworks, such as JPA (Java Persistence API), address specific functional or quality attribute concerns.
Platforms. A platform provides a complete infrastructure upon which to build and execute applications. Examples of current cloud platforms include Amazon Elastic Beanstalk, Google App Engine, and Azure App Service, all of which are Platform as a Service (PaaS) offerings.
The selection of externally developed components, which is a key aspect of the design process, can be a challenging task because of their extensive number. Here are a few criteria you should consider when selecting externally developed components:
Problem that it addresses. Is it something specific, such as a framework for object-oriented to relational mapping, or is it something more generic, such as a complete platform?
Cost. What is the cost of the license? If it is free, what is the cost of support and education?
Type of license. Does it have a license that is compatible with the project goals?
Vendor lock-in. Will the inclusion of the technology result in a dependency on the organization that produces it?
Learning curve. Is this a technology that is difficult to learn? Is it difficult to find developers who have some expertise with it?
Community support. Is this technology well supported by a robust community or by its vendor?
In the following sections, we focus our attention on two categories of design concepts: tactics and patterns. We intentionally omit externally developed components, even though the choice of these components is clearly an important design decision. However, the rapid evolution of technologies makes externally developed components prone to becoming quickly outdated, which is why we do not discuss them extensively here.