- E-mails. Have you ever seen
someone who prints out e-mails, and then tries to manage
them on paper? This is a classic example of duplication.
A common "reason" for doing this is "You can accidentally
delete e-mails, but you can't accidentally delete paper."
That's not true--paper gets tossed all the time. But the
real reason this "reason" fails is you can't find things
that are on paper, unless you're hardly doing enough work to
justify your pay or you like to waste time by rifling
through paper rather than quickly searching e-mail folders..
The consequence of operating this way would appear to be the
sheer inefficiency. Yes, that is a consequence. But it gets
worse. Sooner or later, you have a parallel path of
information. This results in conflicting messages, late
responses, missed replies, and lost information. It's better
to manage one path well rather than two paths poorly.
But what about data loss? Keep your e-mail on the server
(where it's backed up), practice good filing techniques, and
keep your e-mail folders cleaned out. Doing these simple
things will reduce the probability of data loss by 99.9999%.
Having a duplicate system multiplies the probability of data
loss by an order of magnitude.
- Grounding. To electrical
engineers, grounding is very important. Unfortunately, most
electrical engineers don't understand what grounding is.
Consequently, there's a huge problem with creating duplicate
ground paths (also called ground loops).
In the previous example, we mentioned how parallel paths
cause confusion. Parallel paths for electricity can cause
such problems as massive fireballs, electrocutions, and
catastrophic equipment failures. In fact, parallel paths are
normally found where these problems have manifested.
In data centers, you'll often notice "double" efforts in
"grounding" (it's actually "bonding," which is incorrectly
called grounding and that's another source of the
confusion!). For example, there will be grounding (bonding)
straps across metal fittings. The strap serves as a
redundant path. If the first path fails, the strap then
becomes the path. But it's not serving as a parallel path.
That's a critical distinction.
- Network equipment. The idea
that the IT network and plant network should "be on separate
systems" (meaning separate hardware) is misguided, at best.
There is no advantage, whatsoever, to such an arrangement.
It does present huge costs, though. It increase switch
footprint area, cabling requirements, operating costs,
maintenance costs, and downtime.
Using a managed switch to create separate virtual networks
solves all problems that the separate hardware approach
attempts to solve. And, it saves money--on initial
installation, maintenance, operating costs, and later
upgrades. Let's not forget the decrease in downtime, either.
But what if that switch fails? Now both networks are down,
right? Not necessarily Rather than (mis)use hardware to
create two separate physical networks, use one set of
hardware to create a network hardware system--create virtual
networks inside that. With the money saved, you can create a
backup system that you switch over to in the event the first
system fails.
Again, we see there's not a parallel effort here. The second
system isn't duplicating the first system. It's there for
you to switch over to in the event the first system fails.
- Power. Backup power is a good
example for illustrating the difference between duplication
and redundancy. The typical critical facility has electric
power provided by the utility. It also has a backup power
system that consists of a diesel generator (with a UPS
system providing temporary power until the generator can
come online).
Notice that the facility does not have the generator running
during normal operation. That would be duplication.
In an advanced configuration, you would have multiple
generators supporting a fairly large load. Suppose the load
requires 6 generators. Why would the system engineer install
a 7th generator, then? This is called "n+1" redundancy. That
7th generator is there as insurance in case one of the 6
others fails. That's redundancy, rather than duplication.
With duplication, you'd have 12 generators--all running at
once. But there is no need to duplicate. Redundancy solves
the problem, duplication adds cost.
- Reports. Do you save data with
the report? For what purpose? Ask this question carefully.
One of our customers does save data with reports, and
there's a purpose. He creates a daily archive of "snapshots"
of the database. Each is date-stamped to show it's a look at
a specific period. Ask him about the wisdom of sending out
reports with saved data, and you'll get a stern lecture
about how this undermines the reporting system.
If your reporting system degenerates into a collection of
archival reports disguised as current information, you are
better off with no reporting system at all because your
system is distributing misinformation rather than
information. There are circumstances in which saving data
with the report makes sense--none of those involves
duplication.
- Websites. I'm involved in a
non-profit where one of the members (let's call him Derek)
constantly duplicates existing information. With redundancy,
you have a central database or information collection and
point to it. We have a central depository of procedures and
other information--all of which may change as situations
require.
Derek has created a parallel Website, in which he has copied
and pasted the information from the original Website. This
is duplication. I've tried to make him understand that the
information on the main Website is backed six ways to
Sunday, so there is no danger of losing it. I've also tried
to make him understand that the duplication creates a
housekeeping problem, creates confusion among the users (as
duplication of references always does), and will lead to
conflicting information. He insists on duplicating, rather
the simply linking, to the information. As predicted, the
two systems have diverged and are now incompatible.
Duplication and redundancy defined
- Duplication is the
creation of something (information, hardware, pathways,
etc.) that already exists.
- Redundancy provides a
secondary in the event there's a failure in the primary.
You can have any number of primaries, with a single item
serving as the secondary to all of them (n+1).
Redundancy does not create
parallel paths. Redundancy helps avert failure, because
it provides a "Plan B." With redundancy, you deal with
only one "Plan A" rather than multiple and conflicting
versions of the same thing.
Duplication creates parallel paths. One instance of
duplication doesn't provide a "Plan B." It provides a
"Plan A" twice. With duplication, you have to deal with
more than one "Plan A," each differing from the
other(s). Which is correct? Which is the master?
Do the math
Each incidence of duplication
doesn't just double your chances of failure--it raises
it exponentially. Two instances of duplication (two
dupes and the original) raises the chances of failure by
a factor of 8 (2 x 2 x 2). Three instances of
duplication raises the chances of failure by a factor of
16 (2x2x2x2). Duplication, left unchecked, can cause
massive systemic failures.
You want to eliminate duplication, wherever you find it.
In addition to generating huge costs, it confers no
actual advantages--only misperceived ones.
Properly implementing redundancy
Follow these steps:
- Determine the purpose of the
primary system.
- Plan out the primary system.
Identify and resolve problems in that one system,
rather than creating a parallel system in which you
simply hope to get it right.
- Establish performance metrics
and benchmarks.
- Identify access points,
methods, and restrictions.
- Identify what is most
important about the primary system and what
should be backed up and not backed up.
- Identify backup strategies
and methods.
- Review the performance of the
system against the metrics and benchmarks
established earlier, and make any necessary
corrections.
Duplication is never a good
practice. Redundancy, implemented properly, should
be standard practice.
This article is copyrighted by Crystalkeen, Mindconnection, and Chelsea Technologies Ltd.
It may be freely copied and distributed as long as the
original copyright is displayed and no modifications are made to this
material. Extracts are permitted. The names Crystal Reports and Seagate
Info are trademarks owned by Business Objects. |
