Making Design Decisions

This chapter is from the book

Designing Software Architectures: A Practical Approach, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Designing Software Architectures: A Practical Approach, 2nd Edition

Learn More Buy

Design is the process of making decisions. Which decisions? Ideally, the ones that will lead to project success! But decision-making is hard. It is fraught with uncertainty. We are often uncertain about our project requirements and project resources. We are uncertain about the evolutionary trajectories of the technologies we build upon. We are uncertain about our planning horizon. We may be uncertain about the costs of the choices we are making. We may even be uncertain about our own knowledge (although architects and others often fail in the other direction, being overconfident rather than underconfident—this is known as overconfidence bias).

As architects we are responsible for the decisions that we make. This is as it should be. So which practices are available to us to ensure that the decisions that we make are the best ones, given our abilities? That is the subject of this chapter. We begin by reviewing a set of decision-making techniques. Then we turn to the body of knowledge that we can employ, as architects, to make better, more confident decisions.

3.1 Making Design Decisions

We are seldom explicitly taught how to make decisions. It is somehow assumed that, given a proper education, we will make prudent choices. But this is not necessarily so. The field of design is littered with examples of “What were they thinking?!” The architects who are really good decision makers are often ones with decades of experience. They achieved their status through years of trial and error, by making mistakes and learning from their failures. This is clearly a suboptimal form of training—expensive and inefficient and not very scalable. Can we do any better? We think that we can!

3.1.1 Decision-Making Principles

In what follows we present nine general decision-making principles. By following these principles, or strategies, you are not guaranteed to make a perfect decision. That is clearly too high a bar. But you can certainly increase the likelihood that the decision you are making is a sound, well-reasoned one—which is why we recommend these principles. And while all of them are “common sense”, we see them violated over and over again in practice. The result of these (frequently avoidable) violations is projects with high technical debt, poor performance, poor scalability, stability issues, poor usability, and so on.

Principle 1: Use Facts

A fact is something that we believe to be true. Facts, and the evidence for them, are the foundations of logical reasoning. Incorrect or incomplete information may lead to invalid conclusions. An architect may hear praise for a new technology and base a decision on that, instead of testing it themselves. For example, a colleague of ours chose a NoSQL database in the Query side of a CQRS-based system (see Section 3.3.2) he was designing because he felt it was a good fit; he had not done any prototyping or analysis, but made this decision based on hearsay, experience, and gut feelings. Was this the right choice? Time will tell. To check the facts, he could have consciously considered: “What evidence supports the assumption that NoSQL will meet the system’s requirements now and in the future?” When we cannot have all the facts, we make assumptions, as we will discuss next. We make a similar decision, as you will see, in Chapter 8 (the case study where this decision was made). Was this the right decision?

Principle 2: Check Assumptions

In the absence of facts, we often make assumptions so that we can continue with the process of design. For instance, we may not know if a technology can perform adequately until we prototype the software. When we consciously make assumptions, we are saying that these assumptions will be good ones. Explicit assumptions can be checked. Implicit assumptions, by comparison, are more devious. We may even be unaware we have made them. For example, if we build our application with node.js based on an existing three-tier client-server architecture (which contains a monolithic database) without assessing the compatibility with the database’s performance characteristics, then this implicit assumption would not be checked, and that might create a performance risk for the system.

Principle 3: Explore Contexts

Contexts are conditions that influence software decisions. There are many contextual factors, such as development resources, financial pressures, legal obligations, industry norms, user expectations, and past decisions. For example, we might want to implement a scalable and highly reliable database system, but have a limited budget. Even though the budget is not a system requirement, it affects our decision on database license procurement. Some contexts will end up being constraints on design, such as team experience or expectations. Design contexts shape our decisions implicitly, yet are not necessarily technology related. Exploring contextual factors can broaden our design considerations. To check that we have considered contexts we may ask: “What are the contexts that could influence X?”, “Have I missed any contexts?”, and “Does the team have the experience in implementing X?”

Principle 4: Anticipate Risks

A risk is the possibility of an undesirable outcome. A documented risk contains an estimate of the size of the loss and the probability of the loss. There are many risks that an architect needs to estimate, such as extreme spikes of demand and security attacks. Anticipating and quantifying risks is the process of exploring the unknowns, including estimating the possibility of risks occurring and, if they occur, their impacts. Architects may reflect on risks by asking questions such as “What are the potential undesirable outcomes?” or “Is there a chance that X would not work?”

Principle 5: Assign Priorities

Priorities quantify the relative importance of choices, choices such as which requirement to implement or which solution to use. If we can afford to implement only one of the two requirements, which one is more important? Prioritization is required when the things that we desire are competing for the same limited resource (e.g., time, money, developer skills, CPU, memory, network bandwidth). Some of these priorities emanate from contextual factors. To sort out our priorities, we can ask: “Which requirement is more important?”, “What can we do without?”, and “What should we use this resource for?”

Principle 6: Define Time Horizon

The time horizon defines the time period relevant to a decision and its impacts. Risks, benefits, costs, needs, and impacts can change over time, and we want to anticipate how they might change. For example, we might estimate that the system processing load will reach 85 percent capacity in 3 years, or we might choose to deploy the system on premises in the short term while keeping alive the option to deploy it on a public cloud if that becomes more cost-effective.

Defining the time horizon allows architects to explicitly state and evaluate the pros and cons of specific actions (and nonactions) in terms of their short- and long-term impacts. Without explicit considerations of the time horizon and the reasoning that goes along with it, long-term considerations may be undermined, or short-term needs may be ignored. To define the time horizon, the architect may ask questions such as “What would be affected in the short and long term if I decide on X?” or “What needs to be considered in different time horizons for X?”

Principle 7: Generate Multiple Solution Options

Some architects will go with the first solution they think of without considering further options. If the architect is experienced and the problem is well understood and low risk, this approach may be ideal. But in more challenging contexts, considering only a single solution may be risky; the first solution is not necessarily the best one, especially when an architect is inexperienced or faces an unfamiliar situation. This behavior may be due to anchoring bias—a refusal to let go of the first idea. Generating multiple solution options helps an architect broaden the menu of solution choices and stimulate creativity. We can create a larger set of solution ideas by asking ourselves questions such as “Are there other solutions to this problem?” or “Can I find a better solution than X?”

Principle 8: Design Around Constraints

Constraints are limitations that set the boundaries of our design options. Constraints may come from requirements, contexts, technologies, and existing design choices. For instance, a CPU can compute only W instructions per second; the budget of the project is $X; the number of concurrent users supported by a software license is Y; platform Z doesn’t support a certain protocol; developers have no experience with some technology; and so forth. In software development, we often find interconnected sets of constraints: If we choose component A, we must also use component B. When there are no apparent solutions, architects must design around constraints and introduce novel solutions, relax constraints, or manipulate the contexts. An architect can check on constraints by asking, “If I choose X, would it limit other design options?” or “Are there any constraints that could impede this design choice?”

Principle 9: Weigh the Pros and Cons

Pros and cons represent the arguments for and against each of the choices in a selection. Weighing the pros and cons is heavily bound up with examining tradeoffs. The evaluation of the pros and cons allows architects to decide what to choose and what to avoid. A quantitative evaluation can be based on measurable elements such as costs, benefits, priorities, immediacy (i.e., time horizon), and risks. However, some pros and cons cannot be easily quantified. Consider the navigation menu design of a mobile app: How can one quantify the pros and cons of a hamburger menu versus a set of tabs? In this case, qualitative arguments such as ease of access, ease of learning, and effort to implement can be marshaled. Weighing the pros and cons offers architects the chance to think about the relative benefits and drawbacks and who they might affect. To check tradeoffs, the architect can ask questions such as “Are there more benefits from solution X than from solution Y?” or “Have we done a thorough tradeoff evaluation?”

Now that we have enumerated a set of principles, let us turn our attention to the design concepts that we use to structure the system and to support our most important quality attributes.