The day after the mini-quality attribute workshop (see Activity 7, Mini-Quality Attribute Workshop), our team gathers to discuss architecture options. We knew we were building a data-driven web application, but beyond that we didn’t have much else to go on. What overall patterns would we use to organize the system? What technologies will we use for the web application? How will the code be deployed and hosted? How will the code be organized?
You review the constraints with the team as well as some of the more interesting functional requirements. Looking at the influential functional requirements you point out that we’ll need a database and a search engine. Most of the team has prior experience with MySQL, so you guide the team into choosing that for the database. After the review meeting you create a task in the backlog to explore search engine technologies and select one.
Before we start coding, we still needed to make some basic decisions about organizing the code and how the coarse-grained components in the system will come together. Using the think-do-check cycle as a guide, you take a moment to think and plan our next steps.
You start writing open questions on the whiteboard and ask the team to share their concerns too. Soon there is a long list of questions and risks on the whiteboard. You shift to the do part of our design process. “We’ll cover more ground if we divide and conquer (see Activity 15, Divide and Conquer) to find answers,” you say. “Half the team will explore patterns that let us achieve our quality attributes. The other half will explore our technology questions.” To check, you decide that everyone will reconvene in one week to share findings and make decisions.
18.218.135.227