Databases Reference
In-Depth Information
figure out which features you really want and how to weigh each feature to help you
make the final decision. To find the best car for you, it's important to first understand
which features are the most important to you. Once you know that, you can prioritize
your requirements, check the car's specifications, and objectively balance trade-offs.
Selecting the right database architecture for your business problem is similar to
purchasing a car. You must first understand the requirements and then rank how
important each requirement is to the project. Next, you'll look at the available data-
base options and objectively measure how each of your requirements will perform in
each database option. Once you've scored how each database performs, you can tally
the results and weigh the most important criteria accordingly. Seems simple, right?
Unfortunately, things aren't as straightforward as they seem; there are usually com-
plications. First, all team stakeholders might not agree on project priorities or their
relative importance. Next, the team assigned to scoring each NoSQL database might
not have hands-on experience with a particular database; they might only be familiar
with
RDBMS
s. To complicate matters, there are often multiple ways to recombine com-
ponents to build a solution. The ability to move functions between the application
layer and the database layer make comparing alternatives even more challenging.
Despite the challenges, the fate of many projects and companies can depend on
the right architectural decision. If you pick a solution that's a good fit for the prob-
lem, your project can be easier to implement and your company can gain a competi-
tive advantage in the market. You need an objective process to make the right
decision.
In this chapter, we'll use a structured process called
architecture trade-off analysis
to
find the right database architecture for your project. We'll walk through the process
of collecting the right information and creating an objective architecture-ranking sys-
tem. After reading this chapter, you'll understand the basic steps used to objectively
analyze the benefits of various database architectures and how to build quality trees
and present your results to project stakeholders.
12.1
What is architecture trade-off analysis?
Architecture trade-off analysis is the process of objectively selecting a database archi-
tecture that's the best fit for a business problem. A high-level description of this pro-
cess is shown in figure 12.1.
The qualities of software applications are driven by many factors. Clear require-
ments, trained developers, good user interfaces, and detailed testing (both functional
and stress testing) will continue to be critical to successful software projects. Unfortu-
nately, none of that will matter if your underlying database architecture is the wrong
architecture. You can add more staff to the testing and development teams, but chang-
ing an architecture once the project is underway can be costly and result in significant
delays.
For many organizations, selecting the right database architecture can result in mil-
lions of dollars in cost savings. For other organizations, selecting the wrong database
