Databases Reference
In-Depth Information
bias and using outside consultants, that impact the process. But if you keep these in
mind, you can make adjustments and still make the selection process neutral.
12.2.2
Accounting for experience bias
When you perform an architecture trade-off analysis, you must bear in mind that each
person involved has their own set of interests and biases. If members of your project
team have experience with a particular technology, they'll naturally attempt to map
the current problem to a solution they're familiar with. New problems will be applied
to the existing pattern-matching circuits in their brains without conscious thought.
This doesn't mean the individual is putting self-interest above the goals of the project;
it's human nature.
If you have people who are good at what they do and have been doing it for a long
time, they'll attempt to use the skills and experience they've used in previous projects.
People with these attributes may be most comfortable with existing technologies and
have a difficult time objectively matching the current business problems to an unfa-
miliar technology. To have a credible recommendation, all team members must com-
mit to putting their personal skills and perspectives in the context of the needs of the
organization.
This doesn't imply that existing staff or current technologies shouldn't be consid-
ered. People on your architecture trade-off team must create evaluations that will be
weighted in ways that put the needs of the organization before their personal skills
and experience.
12.2.3
Using outside consultants
Something each architecture selection team should consider is whether the team
should include external consultants. If so, what role should they play? Consultants
who specialize in database architecture selection may be familiar with the strengths
and weaknesses of multiple database architectures. But there's a good chance they
won't be familiar with your industry, your organization, or your internal systems. The
cost-effectiveness of these consultants is driven by how quickly they can understand
requirements.
External consultants can come up to speed quickly if you have well-written detailed
requirements. Having well-written system requirements and a good glossary of busi-
ness terms that explain internal terminology, usage, and acronyms can lower database
selection costs and increase the objectivity of database selection. This brings an addi-
tional level of assurance for your stakeholders.
High-quality written requirements not only allow new team members to come up
to speed, they can also be used downstream when building the application. In the
end, you need someone on the team who knows how each of these architectures
works. If your internal staff lacks this experience, then an outside consultant should
be considered. With your team in place, you're ready to start looking at the trade-off
analysis process.
