Databases Reference
In-Depth Information
Business
drivers
Quality
attributes
User
stories
Analysis
Architecture
plan
Architectural
approaches
Architectural
decisions
Tradeoffs
Impacts
Sensitivity
points
Non-risks
Distilled info
Risk themes
Risks
Figure 12.5
High-level information flow for the SEI ATAM process.
Although this process isn't specifically targeted at NoSQL database
selection, it shares many of the same processes that we recommend in
this chapter. Business requirements (driven by marketing) and
architectural alternatives (driven by your knowledge of the NoSQL
options available) have separate paths into the analysis process. The
outcome of this analysis is a set of documents that shows the strengths
and weakness of one architecture.
Mellon. A high-level description of the Architecture Trade-off Analysis Method
(
ATAM
) process developed by Carnegie Mellon is shown in figure 12.5.
Originally, the
ATAM
process was designed to analyze the strengths and weaknesses
of a single architecture and highlight project risk. It does this by identifying the high-
level requirements of a system and determining how easily the critical requirements fit
into a given architecture. We'll slightly modify the
ATAM
process to compare different
NoSQL architectures.
12.4
Analysis through decomposition: quality trees
The heart of an objective evaluation is to break a large application into smaller discrete
processes and determine the level of effort each architecture demands to meet the sys-
tem requirements. This is a standard divide-and-conquer decomposition analysis pro-
cess. To use decomposition, you continue to break large pieces of functionality into
smaller components until you understand and can communicate the relative strengths
and weaknesses of each architecture for the critical areas of your application.
Although there are several ways you can use decomposition, the best practice is to
break up the overall functionality of an application into small stories that describe
how a user will interact with the system. We call these the system's
scenarios
or
use cases
.
Each process is documented in a story that describes how actors will interact with a sys-
tem. This can be as simple as “loading data” or as complex as “upgrading software with
new releases.” For each process, you'll compare how easy or difficult it is to perform
this task on each of the systems under consideration. Using a simple category (easy,
medium, hard) or 1-5 ranking is a good way to get started.
