Databases Reference
In-Depth Information
CPU utilization
Airline check-in
Customer A
Customer B
Customer C
This is like the situation
when many people are
forced to go to the longest
line, even when other
agents are not busy.
This customer is running a report that takes a long time
to run on a single system. With a NoSQL solution,
the report would be evenly distributed on all servers
and run in half the time.
Figure 12.7
Rather than only creating a report that describes how one option
provides better distribution of load over a cluster, use graphs and metaphors to
describe the key differences. While many people have seen CPU utilization charts,
waiting in line at the airport is a metaphor they've most likely experienced.
automatically without the need for programmers and operations staff. If they did, we
would already be using them. In the real world, we need to make hard choices.
12.5.3
Using quality trees to communicate project risks
As we mentioned, the architectural trade-off process creates documentation that can
be used in subsequent phases of the project. A good example of this is how you can
use a quality tree to identify and communicate potential project risks. Let's see how
you might use this to communicate risk in your project.
A quality tree contains a hierarchy of your requirements grouped into logical
branches. Each branch has a high-level label that allows you to drill down into more
detailed requirements. Each leaf of the tree has a written requirement and two scores.
The first score is how important the feature is to the overall project. The second is
how well the architecture or product will implement this feature.
Risk analysis is the process of identifying and analyzing the gaps between how
important a feature is and how well an architecture implements the feature. The
greater the gap, the greater the project risk. If a database doesn't implement a feature
that's a low priority to your project, it may not be a risk. But if a feature is critical to
project success and the architecture doesn't support it, then you have a gap in your
architecture. Gaps equal project risk, and communicating potential risks and their
impact to stakeholders is necessary and important, as shown in figure 12.8.
