Databases Reference
In-Depth Information
Select top
four architectures
Find
architecturally
significant
requirements
Score effort
for each
requirement for
each architecture
Gather all
business
requirements
Total effort
for each
architecture
Figure 12.1
The database architecture selection process. This diagram shows the
process flow of selecting the right database for your business problem. Start by
gathering business requirements and isolating the architecturally significant items.
Then test the amount of effort required for each of the top alternative architectures.
From this you can derive an objective ranking for the total effort of each architecture.
architecture could mean they'll no longer be in business in a few years. Today, busi-
ness stakes are high, and as the number of new data sources increases, the stakes will
increase proportionately.
Some people think of architecture trade-off analysis as an insurance package. If
they have strong exposure to many NoSQL databases, senior architects on a selection
team may have an intuitive sense of what the right database architecture might be for
a new application. But doing your analysis homework will not only create assurance
that the team is right, it'll help everyone understand why the fit is good.
An architecture trade-off analysis process can be completed in a few weeks and
should be done at the beginning of your project. The artifacts created by the process
will be reused in later phases of the project. The overall costs are low and the benefits
of a good architectural match are high.
Selecting the right architecture should be done before you start looking at various
products, vendors, and hosting models. Each product, be it open source or commer-
cial license, will add an additional layer of complexity as it introduces the variables of
price, long-term viability of the vendor, and hosting costs. The top database architec-
tures will be around for a long time, and this work won't need to be redone in the
short term. We think that selecting an architecture before introducing products and
vendors is the best approach.
There are many benefits to doing a formal architecture trade-off analysis. Some of
the most commonly cited benefits are
Better understanding of requirements and priorities
Better documentation on requirements and use cases
Better understanding of project goals, trade-offs, and risks
Better communication among project stakeholders and shared understanding
of concerns of other stakeholders
Higher credibility of team decisions
These benefits go beyond the decision of what product and what hosting model an
organization will use. The documentation produced during this process can be used
