In an architecture design studio, we take advantage of the group’s collective wisdom and experience. During a design studio you’ll place a strict time constraint on exploration activities so that the group generates as many different ideas as possible, as quickly as they can. We accomplish this by guiding the group first to explore and then quickly narrow down the field of ideas to a few likely candidates.
A design studio creates buy-in for design decisions and improves team communication by letting everyone have a hand in designing the architecture. We achieve this by keeping the workshop fast, effective, and fun—the three “Fs” of design exploration. Fun amplifies engagement, which in turn acts as a force multiplier for the speed and effectiveness of exploration activities.
Our job as a design studio host is to plan a workshop that results in a strong set of actionable ideas. Three types of ideas come out of a design studio:
Some ideas will seem promising. The next step for these ideas is to flesh out details by making models or prototypes.
Some ideas will seem right but consist of broad assumptions or miss important information. Plan to investigate these ideas further by running experiments or performing research. Depending on what you learn during the investigation, some ideas might be scratched whereas others become candidates for the architecture.
Sometimes you might only end up with new questions about the problem we’re solving. This is a fantastic outcome for a design studio workshop. It’s better to have these questions now than when we’ve been heads down coding for a few weeks. Take these questions back to stakeholders to improve our understanding of the problem.
A typical workshop lasts anywhere from a few hours up to a day. It’s also possible (and in some cases preferable) to let the spirit of your design studio guide your work over the course of several days. No matter how much time you spend, all design studio workshops follow the same basic structure.
Let’s take a closer look at each stage of the workshop.
Before kicking off a design studio workshop, we’ll need to choose goals and decide who to invite (see Invite the Right Participants). Gathering a group to design architecture is not a good use of anyone’s time until you at least partially understand the problem you’ll to explore.
Preparing for a workshop can take serious time and should not be underestimated. Talk to stakeholders. Do your research. Work to define the business goals. Refine quality attributes and other architecturally significant requirements (ASRs). Before starting the workshop, you should understand enough of the problem and context so that you can articulate useful workshop goals.
Define one or two workshop goals that clearly describe what the group will explore during the workshop. You don’t want one person designing a database while someone else is working on deadlock problems. It’s OK if you only partially understand the problem before starting the workshop. Exploring solutions is one way to gain a deeper understanding of the problem.
Workshop goals tell participants how they will spend their brainpower during the workshop. There are a few examples in the table.
If your goal is to explore… | You might say… |
---|---|
A specific set of quality attributes | “Scalability and reliability are our top two quality attributes. How can we promote these at the same time?” (You’ll share the specific scenarios with everyone.) |
Interfaces between components | “We’ve decided to use REST for our APIs. Let’s figure out what that really means for our system.” (Assumes everyone knows what is involved with RESTful architecture) |
Domain models | “Based on our stakeholders’ business, we need to define some common abstractions that we’ll use throughout the system.” |
How to get out of a jam | “We’re seeing a size and scale of data we didn’t anticipate ten years ago when we first designed the system. Let’s figure out as many options as we can.” |
Allocation structures | “We need to partition the system so we maximize parallel development effort.” |
Pattern selection | “We need to decide how we’re going to get data from point A to point B. Before we go into pros and cons, let’s understand the options.” |
Many different ideas | “Today we want to see as many different ideas as possible. Everyone should try for at least 5 ideas.” |
Preparing for the workshop might take a few days or even weeks. You should at least have draft business goals and architecturally significant requirements before starting. Once you have a handle on the project context and a reasonable workshop goal, you’re ready to run the workshop.
Start the workshop by setting the stage for a successful collaboration. Make sure everyone has the proper context by sharing what you know so far about the problem and the architecture. Review anything relevant to the area you plan to explore. The amount of workshop time devoted to sharing context should be commensurate with the group’s background knowledge. If this is the first time some people have seen business goals or ASRs, spend more time describing the context.
After reviewing the context, outline the workshop goals. These goals are used throughout the workshop and keep the group focused. During the workshop, everyone will create designs to satisfy the goals. We’ll also critique design ideas with these goals in mind.
We’ll spend most of the workshop in the create-share-critique cycle.[14][15] Each iteration through the cycle explores more of the design space and improves the group’s understanding of what is possible. We’ll talk about specific activities we can plug into this cycle in Choose Appropriate Design Activities.
During the create step, participants work alone or in small groups to address workshop goals by sketching and modeling their design ideas. Keeping it analog works best during a workshop. Using pens or fat markers and paper encourages people to focus on ideas rather than precision. At this stage of the game, you value ideas, not perfection.
The create step is always time boxed. Short workshops might spend only 5--7 minutes in the create step. Longer workshops can allow for more time. Keep in mind that more time does not always lead to more or better ideas! Architecture exploration requires deep thought, so adjust time relative to your goals. Anything less than 5 minutes is not enough time for most software architecture topics.
After everyone has created something, it’s time to share it with the larger group. This step is sometimes called pitch, as in make a pitch for your idea. Give each group 3–5 minutes to share what they created and describe how their design satisfies the goal. Groups should hit only the main points and avoid giving a full briefing. Participants will learn quickly not to create more than they can share.
During the share step, workshop participants listen and may not ask questions. Everyone will have a chance to ask questions and share comments during the critique step.
Immediately after a group shares their design, give the other participants an opportunity to critique the ideas. Feedback during the critique should focus on the merits of the design relative to the workshop’s goals. The idea is to lay the foundation for a constructive dialogue. How does the design fall short of satisfying a goal? Why does the design not meet the specified need?
During the critiques, encourage everyone to be specific and focus on facts.
Do this | Avoid this |
---|---|
Do: Focus on the goals the designers said they addressed. | Don’t: Get defensive about your design. |
Do: Be specific; focus on facts. | Don’t: Share personal opinions—“I like XYZ, it’s my favorite.” |
Do: Ask clarifying questions. | Don’t: Get sidetracked by problem solving. |
Do: Point out risks and new problems introduced by the design. | Don’t: Be a jerk (your turn is next!). |
Do: Point out benefits about the design. | Don’t: Focus only on downsides. |
Critiques should point out good things about a design as well as things that can be improved. Even terrible designs have a few good ideas, and there is always room for improvement even in the best designs. Every design should receive a mix of positive feedback and constructive criticism. Once all groups have shared their ideas, do it all over again.
The purpose of the create-share-critique cycle is to promote rapid divergence and convergence of thinking as described in Diverge to See Options, Converge to Decide. During the create step, we generate new ideas. During the share step, we create opportunities for cross-pollination and serendipitous inspiration. During the critique step, we eliminate dead ends and nudge people toward better (or at least different) solutions.
Iteration allows participants to build on what they collectively learn. Move through the create, share, and critique steps as quickly as you can while remaining effective.
With each iteration, tweak the group dynamics. Tweaking group dynamics between iterations encourages broader exploration while simultaneously building a sense of shared ownership. If participants are working alone, have them work in pairs or small groups. If they are working in groups, try mixing up the groups. Plan for at least three iterations of the full create-share-critique cycle for each set of goals in the workshop.
A strong finish can mean all the difference between a productive workshop and a fun waste of time. Allow time at the end of the workshop to reflect on emergent themes and discuss general observations as a group. Also, decide on specific action items. Which ideas seem promising and should receive more attention? Were any significant risks raised that should be addressed? Are there any experiments that should be started?
Take pictures of all the material produced during the workshop. Create write-ups in a shared repository while the ideas are still fresh in everyone’s minds. Most importantly, record the action items and follow up with individuals to make sure they take the next steps.
3.144.82.26