Adopt a Design Mindset

Designing a software system requires us to think about the architecture from the perspective of different design mindsets. A design mindset is a way of thinking about the world so that we focus our attention on the right details at the right time.

There are four design mindsets: understand, explore, make, and evaluate. Each design mindset comes with a set of practices. To design the architecture, we’ll choose a mindset, pick a practice in that mindset, apply the practice to learn something new about the architecture, and repeat.

The chapters in Part II will show you how to put each mindset into practice. Look for the icon, shown in the image, at the start of each chapter to tell you what the focus will be. For now, let’s learn what it means to embrace each of the four design mindsets.

Understand the Problem

In the understand mindset we actively seek information from stakeholders and work to describe the problem. The understand mindset is as much about requirements as it is empathy. To understand the problem, we must learn about the people who will be touched by our system and what they need.

To understand the problem, we’ll need to investigate business goals and quality attributes that are important to our stakeholders. We’ll also have to learn how our team operates and get a deeper sense of the priorities and trade-offs among design decisions.

Explore Ideas

In the popular ethos, design thinking is all about brainstorming and sticky notes. Brainstorming is powerful, but it is only one practice in the explore mindset. When we explore, we create multiple design concepts and identify engineering approaches for solving some aspect of a problem.

Exploring software architecture means we try combinations of structures until we find a combination that best promotes desired quality attributes. To find the best mix of structures, we’ll need to survey a broad range of patterns, technologies, and development practices. When we’re planning the architecture, we’ll spend a lot of time in the exploration mindset, but this mindset is also useful when working with stakeholders.

Make It Real

As you learned in ​Make the Architecture Tangible​, ideas are great but if you can’t transfer them from your brain into someone else’s brain, then your ideas are useless. Making ideas real gives us a way to share them but also provides an opportunity for testing an idea. In the make mindset we turn our design concepts into real-world artifacts.

The most common ways we make architecture real is by creating models. Making goes way beyond box and line diagrams. You can make the architecture real by building prototypes, writing documents, crunching numbers, and a variety of other approaches.

The make mindset is useful for communicating our plans. We’ll also make the architecture real as we build the system—for example, by organizing our code so that it’s possible to see module structures in the architecture. Making is also an excellent way to push your team out of analysis paralysis.

Evaluate Fit

How do you know if a design decision will solve the problem? When we embrace the evaluate mindset, we determine the fitness of our design decisions relative to our current understanding.

Evaluation is not an all or none proposition. We can evaluate all or part of the architecture, even only a single model, concept, or idea. The most common approach is to walk through a piece of the architecture with different scenarios, but we can also test design decisions directly by running experiments or examining the risks surrounding a decision.

The evaluate mindset comes in handy when we want to verify the planned or built architecture, but this is only the beginning. This mindset will help us inspect anything we make and decide whether that artifact is serving our need.

Using design mindsets requires a process with a tight feedback loop so we can quickly move from one mindset to the next. In the next section, we’ll learn how to use a simple, iterative approach to help us choose and use design mindsets.

Get Your Hands Dirty: Understand, Explore, Make, Evaluate

The four design thinking mindsets reflect how people solve problems. Even without training in design thinking, you have probably used these mindsets before. What are some examples of how you embraced each of these mindsets so far in your software development career? Try to name at least two examples of how you worked in each design mindset.

Here are some things to think about:

• When have you worked with people to understand a problem? Did you follow a particular method?

• How have you collaborated with others to explore ideas and generated alternatives?

• Looking beyond code, how do the things you make change how you interact with stakeholders and teammates?

• How do you evaluate your designs? What techniques have you used to test solution hypotheses?