Selecting the right NoSQL solution - Making Sense of NoSQL - page 260

12.3 Steps in architectural trade-off analysis

Now that you've assembled an architectural selection team who'll be objective and
represent the perspectives of various stakeholders, you're ready to begin the formal
architectural trade-off process. Here are the typical steps used in this process:

Introduce the process —To begin, it's important to provide each team member with
a clear explanation of the architecture trade-off analysis process and why the
group is using it. From there the team should agree on the makeup of the team,
the decision-making process, and the outcomes. The team should know that
the method has been around for a long time and has a proven track record of
positive results if done correctly.

1

Gather requirements —Next, gather as many requirements as is practical and put
them in a central structure that can be searched and reported on. Require-
ments are a classic example of semistructured data, since they contain both
structured fields and narrative text. Organizations that don't use a require-
ments database usually put their requirements into MS Word or Excel spread-
sheets, which makes them difficult to manage.

2

Select architecturally significant requirements —After requirements are gathered, you
should review them and choose a subset of the requirements that will drive the
architecture. The process of filtering out the essential requirements that drive
an architecture is somewhat complex and should be done by team members
who have experience with the process. Sometimes a small requirement can
require a big change in architecture. The exact number of architecturally sig-
nificant requirements used depends on the project, but a good guideline is at
least 10 and not more than 20.

3

Select NoSQL architectures —Select the NoSQL architectures you want to consider.
The most likely candidates would include a standard RDBMS , an OLAP system, a
key-value store, a column family store, a graph database, and a document data-
base. At this point, it's important not to dive into specific products or imple-
mentations, but rather to understand the architectural fit with the current
problem. In many cases, you'll find that some obvious architectures aren't
appropriate and can be eliminated. For example, you can eliminate an OLAP
implementation if you need to perform transaction updates. You can also elimi-
nate a key-value store if you need to perform queries on the values of a key-
value pair. This doesn't mean you can't include these architectures in hybrid
systems; it means that they can't solve the problem on their own.

4

Create use cases for key requirements —Use cases are narrative documents that
describe how people or agents will interact with your system. They're written by
subject matter experts or business analysts who understand the business context.
Use cases should provide enough detail so that an effort analysis can be deter-
mined. They can be simple statements or multipage documents, depending on
the size of the project and detail necessary. Many use cases are structured

5