Databases Reference
In-Depth Information
Though this may sound like an overly cautious tone, introducing new tech-
nology into an organization can be a battle between old and new ideas. If you
assume that enemies of change are everywhere, you can adjust plans to ensure
victory.
Technology transfer
—Using an external consultant to build your pilot project
without interaction with your staff prevents internal staff from understanding
how the systems work and getting some exposure to the new technology. It pre-
vents your team from finding allies and building bridges of understanding. The
best approach is to create teams that will pair experienced NoSQL developers
with internal staff who will support and extend the databases.
2
The right types of data
—Each NoSQL project has different types of data. It may be
binaries, flat files, or document-oriented. You must make sure the pilot project
data fits the NoSQL solution you're evaluating.
3
Meaningful and quality data
—Some NoSQL projects are used in pilot projects
because there's high-variability data. This is the right reason to move from a
SQL
database. But the data still needs to have strong semantics and data quality.
NoSQL isn't a magic bullet that will make bad data good. There are many ways
that schema-less systems can ingest and run statistical analysis on data and inte-
grate machine learning to analyze data.
4
Clear requirements and success criteria
—We've already covered the importance of
understandable, written requirements in NoSQL projects. A NoSQL pilot proj-
ect should also have clearly defined written success criteria associated with mea-
surable outcomes that the team agrees to.
5
Finding the right pilot project to introduce a new NoSQL database is critical for a
project's successful adoption. A NoSQL pilot project that fails, even if the reason for
failure isn't associated with architectural fit, will dampen an organization's willingness
to adopt new database technologies in the future. Projects that lack strong executive
support and leadership can be difficult, if not impossible, to move forward when prob-
lems arise that aren't related to the new architecture.
Our experience is that getting high-quality data into a new system is sometimes the
biggest problem in getting users to adopt new systems. This is often not the fault of
the architecture, but rather a symptom of the organization's ability to validate, clean,
and manage metadata.
Before you proceed from the architecture selection phase to the pilot phase, you
want to stop and think carefully. Sometimes a team is highly motivated to get off of
older architectures and will take on impossible tasks to prove that new architectures
are better. Sometimes the urge to start coding immediately overrides common sense.
Our advice is to not accept the first project that's suggested, but to find the right fit
before you proceed. Sometimes waiting is the fastest way to success.
