Welcome to this lesson on Tactics. We will explain what tactics are, how they differ from patterns, and how you can use them when building your architecture. In the requirements phase, we defined functional and non-functional requirements. When creating the architecture, we start by looking at the non-functional requirements. And more specifically, to the quality attributes. Quality attributes need to be embedded in the core of the architecture. How can you make sure your system is scalable if the architecture is not made for it? Functional requirements will be added when [INAUDIBLE] the tactics and patterns. This is the core of the attribute driven design methods. First, we design the architecture based on the key quality attribute requirements. And then, we map the functionality on this architecture. Although both tactics and patterns are used to bring architecture design, there is a clear distinction between them. Architectural patterns describe the high-level structure and behavior of software systems as the solution to multiple system requirements, whereas tactics are designed decisions that improve individual quality attribute concerns. It is important to understand the differences between architectural patterns and tactics. The relations between them and how they interact. Tactics that are selected during initial architecture design significantly impact the architecture of the system to be designed. Such as, which better is to use and how they must be changed to accommodate the tactics. Architectural tactics are design decisions that influence the achievement of a quality attribute response. They affect systems' response to a stimulus. Different tactics can influence the same stimulus response pair. This is similar to soccer, where multiple tactics can be used to support an offensive or defensive strategy. Pass and move is a tactic that enables quick progress across the playing fields. While pace play always keeps the ball moving with quick dribbles and false passes to keep the opposition in difficult positions. As we mentioned, the focus of a tactic is on a single quality attribute response, which results in many different tactics for each response of each quality attribute. Since the tactic is focused on one single response, they stand on their own and no trade-offs need to be made within the tactic. This is different from patterns, where each pattern already includes trait of decisions. There are a couple of reasons why there is a need for tactics and not only for patterns. The first reason is that architectural patterns are complex, which makes it hard for an architect to make the right decisions. Tactics help an architect to make a decision when choosing patterns. The second reason is that there are problems for which there is no suitable pattern, and sometimes an architect needs to build an architecture from scratch. Tactics can be used as the most basic building blocks to create such an architecture. As a last reason, a catalog of tactics can help find inspiration and guidance when designed an architecture. We can distinguish two types of tactics. Tactics can be design time tactics, which mean their overall approach is to design an implementation, such as using intermediaries to improve modifiability, when two systems must interact with each other. By using intermediaries, you can more easily make changes in one system without affecting the other. Design time tactics have a big impact on the architecture itself. Tactics can also be run time tactics, which are features erected at a particular run time aspect of a quality attribute, such as authenticate users to improve security. Authentication of users is a responsibility that must be added to one of the components of the architecture, but that doesn't have big impact on the architecture itself. It does have a big impact on the processes since each time a user wants to execute a certain action, the system has to make sure the user is authenticated. Runtime tactics have an impact on the behavior or processes of the software. Let's look at some example tactics for Interoperability. Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context. The goal of Interoperability tactics is to handle and information exchange request in such a way that the request is correctly handled. There are two categories of Interoperability tactics called, locate and manage interfaces. Each of these categories contains specific tactics. The first tactic is called discovered service and is used to run the systems that interoperate, must be discovered at run time. You locate the service through searching a known directory services. There can be several directories to consult and different ways to test for the type of service that is needed, such as by name, by location, or some other attribute. The automatic discovery of devices with universal plug and play is an example of this tactic. Orchestrate is a tactic that uses a control mechanism to coordinate, manage, and sequence the invocation of particular services, which can be ignorant of each other. It is used when systems interact with other systems in a complex way. The orchestrator scripts the interaction between the different services. The sales process and business software can for example make use of many other services such as payment and invoicing services. But is often orchestrated from a central component that knows the business rules and where these rules can be changed easily. The last tactic for interoperability is called, tailored interface. It is a tactic that adds or removes capabilities to an interface. Capabilities, such as buffering, or analytics of data can be edit or removed based on certain parameters. For example, an API can offer more functionality to authenticated users, than to anonymous users. These tactics give you some hints and tips on how to solve common problems or how to achieve quality attributes. All of these still need to be concretized to a specific situation, in relation to the rest of the architecture and the different components. One tactic can this result in different architectures according to the way it was applied. During the ADD process, we will look at the different tactics that are available. I make a selection of these that can help us to achieve the requirement. Based on these tactics, we can look for patterns that already combine several of them.
