Databases Reference
In-Depth Information
slide presentations, colorful wall-sized posters, and quality trees, which we'll
review later in this chapter.
Communicate results
—Once you have your documentation in order, it's time to
present the results. This needs to be done in a way that will focus on building
credibility for your process team. Sending a 100-page report as an email attach-
ment isn't going to generate excitement. But if you present your case in an
interactive method, you can create a sense of urgency using vocabulary the
audience understands.
The communication job isn't done until you've ensured that the stakehold-
ers understand the key points you want to communicate. Creating an online
quiz will usually turn people off. You want to create two-way dialogs that verify
the information has been transmitted and understood so the stakeholders can
move on to the next stage of the project.
9
An example of a weighted scorecard is shown in figure 12.4.
We want to make it clear that we think that selecting an architecture before select-
ing a specific NoSQL product is the preferred method. We've been involved in situa-
tions where a team is trying to decide between two products that use different
architectures. The team must then combine both architectural decisions and vendor-
specific issues in one session. This prevents the team from understanding the real
underlying architectural fit issues.
It might be interesting to compare the steps in the trade-off analysis process with a
similar process developed by the Software Engineering Institute (
SEI
) at Carnegie
Figure 12.4
A weighted scorecard for a software selection process for a statute
management system. The grid shows the ease of performing a task for four
alternative architectures. A score of 0-4 is used, with a 4 indicating the lowest
effort. The most critical features have the highest weight in the total score.
