March 1999
Y2K: Should It Be Bugging You?
BY MARC ROBINS and CHRIS DONNER
Go to sidebars on:
What To Do?
Y2K And SS7
Y2K And CTI Hardware
Y2K Web Sites
Haiku Y2K?
The date: January 3, 2000. You arrive at work early and feeling groggy after a long
weekend of millennium madness. Your key card doesn't work, leaving you out in the freezing
cold with your ears going numb. Finally, a security guard lets you in through a side door
that still takes those old-fashioned metal keys. Making your way through the building and
up the stairs (for some reason the elevators aren't working), you notice that it is
unusually dark - and you also notice that the emergency lighting system has been
triggered. You make it to your desk, and with reflexes conditioned like one of Pavlov's
dogs, the act of sitting prompts you to start checking your voice mail. Usually, your
phone blinks uncontrollably with the constant influx of messages - today it's dark. You
took Thursday and Friday off, and you think to yourself that there should be dozens of
messages to listen to. What a way to start the week…!
Not to mention a new millennium! A new Y2K survey by the Information Technology
Association of America (www.itaa.org) paints a pretty
grim picture of what's to come in about 300 days. More than 33 percent of the 400 CIOs,
engineers, CEOs, and attorneys surveyed for the study have already reported Y2K-related
problems, including systems crashes and embedded systems failures. Problems ranged from
database file corruptions to accounting and data exchange errors. To compound the issue,
71 percent of those surveyed disclosed that tests of "fixed" code turned up
problems that had been overlooked or newly created during the debugging process. Other
interesting statistics: 87 percent feel that Y2K will be a national and global crisis, 52
percent believe their companies will suffer financially, and only 3 percent have completed
their contingency plans.
Pressure is also mounting on telecommunications technology companies to disclose
potential Y2K problems with their wares and to fix them. Recently a group of customers
sued AT&T and Lucent Technologies for selling products that supposedly weren't
Y2K-compliant, basing their suit on New York State's consumer protection laws. Expect to
see more of this type of activity in the coming months.
So call me optimistically paranoid. While I agree with Rich Tehrani (our overly
optimistic publisher) that the Y2K bug represents potential boom times for CTI (due to the
unleashed desires of cash-laden IT departments to spring for new generation, Y2K-compliant
CTI solutions), I also believe that left unsquashed, the bug will wreak havoc with CTI
systems and applications that have not been upgraded and patched. We're talkin'
mission-critical here - phones, voice messaging, ACDs, fax processing, contact and sales
management applications - the systems we have come to depend on as the very lifeblood of
our businesses.
It's not that these things can't be fixed, because of course they can. The problem is
that most humans procrastinate when it comes to deadlines - especially when those
deadlines involve the prospect of spending oodles of money. The onus is not just on the
CTI technology vendor to upgrade, but also on the user community to be diligent and
proactive.
There are numerous other adjunct systems and systems components to put on your Y2K
checklist that are increasingly linked by data connections to other systems for signaling
and control purposes - especially in call center environments. One bad link in the chain
can set off a panoply of errors, and the next thing you know, a system that has been
secure and reliable suddenly goes wild and begins behaving unpredictably. So while
individual systems may comply, connections to non-compliant resources could still cause
serious problems.
Most of the CTI vendors we have spoken with seem fairly well prepared for the impending
reset to 00, especially when discussing applications and coding developed relatively
recently. For example, Ning Ning Yu, vice president of engineering for Net Effect Systems
(www.neteffect.com), had the following advice
regarding solutions involving multiple vendors: "Multi-vendor solutions will
experience third-party Y2K exposure, as there are multiple systems and software involved,
which may include non-compliant code. The multi-vendor solutions do have multiple business
dependencies, which pose some Y2K operational risks as business interruptions that may
occur if a third party fails to solve its Y2K problem. Most multi-vendor solutions are not
associated with older programs that contain older, fragile mainframe code. Legacy
applications have been around for a long time and often are based on undocumented code.
Multi-vendor solutions based on current code with source code more readily available to
troubleshoot as needed should be more readily Y2K-compliant. The Y2K problem is too
complex, however, to claim that any one type of solution will guarantee complete
elimination of risk."
John Belville, post sales manager of Williams Communications Solutions' Call Center
Applications Team (www.wilcomsol.com) also
expressed concern regarding call centers based on legacy equipment: "If the
application is no longer supported by a local technical staff, I would recommend securing
the services of a call center integrator now! These highly skilled technicians are gaining
in popularity with existing resources currently committed to Y2K projects through year's
end. If you're in this situation, locate any and all documentation on the various
hardware/software platforms. From the known information, contact each vendor to obtain a
statement of compliance for each component. Then create and execute a comprehensive test
plan that will verify the system's integrated compliance."
Mike Whitmer, director of architecture at Witness Systems (www.witsys.com), expressed similar views: "We don't
really envision Y2K affecting customer interaction centers, especially the newer ones.
There is, however, the chance that older centers with more dated systems could experience
challenges. The reason older centers could be affected is because they were more likely
built on a legacy platform rather than a client/server platform. On the client/server
side, it's much easier to ensure compliance - and if issues do arise, it's easier to make
the necessary changes and conform to meet the set standards."
When discussing more recent applications and programs - say, those developed within the
past 10 years - most CTI vendors have posted Y2K-compliance information to their Web
sites. Additionally, many applications are reliant upon the operating system for date/time
information, meaning that if the OS is compliant, the application should be too, at least
in theory.
This idea is supported by Mike Coffee, president of Commetrex Corporation (www.commetrex.com): "Computer telephony (aka open
telecommunications) is characterized by its being based on an open-computing platform, the
PC. So the issue of Y2K readiness in CT is, for the most part, an issue of the readiness
of the underlying computing platforms. It is also an issue of how applications-level
software, such as messaging systems, use those platforms. For example, most messaging
systems time-stamp messages. If an installed system is based on an older PC that
improperly reports dates, will voice messages next January come out '4:00 p.m. on January
twentieth, 1900'? Maybe, but most messaging systems don't include the year. If the system
does include the year, would it matter whether the system were integrated by the developer
of the application, a VAR, or the end user? It probably would if the end user were looking
for a vendor to certify the system."
INTEGRATION
However, with integration being a key part of CTI, the fact is that there are many
multi-vendor solutions out there that have performed acceptably until now, and yet may
threaten to be somewhat less than reliable in the coming year. With this in mind, we at
CTI� decided to focus on the issue of integration, as is our wont, and see what kind of
response we could get from vendors and other resources in the CTI community.
To begin, we decided to query the ECTF on integration and Y2K, and Roger Huffadine,
chairman of the ECTF technical committee (www.ectf.org),
replied: "In the UK - whilst every supplier is seeking to satisfy their clients that
supplied systems are Y2K-compliant - the legal position is still caveat emptor (let the
buyer beware). Interestingly, the British Standards Institute requirement for Y2K
compliance is that 'systems will operate for any date prior to and including Jan 1, 2000,
and for any date after Jan 1, 2000.' Clearly this means that compliant systems must work
with: BC dates, single-digit year, double-digit year, three-digit year, four-digit year,
five-digit year, and so on. I'm sure that this is not what they mean by the statement, but
it does show how silly things can get when Y2K statements are made up out of context.
"Very few integrated systems pass data as information - the norm is to pass key
field information between the applications so that the issues of Y2K are basically
isolated in the discrete applications. This could still be a problem if a critical
business application that services a call center fails. Most businesses have schedules to
ensure that all of their critical components are Y2K safe before Jan 1, 2000."
After hearing from the ECTF, we decided to turn to the vendor community, and we asked
them to address the CTI industry as a whole, rather than the specific Y2K compliance of a
particular board or application. One of the most exhaustive (and humorous) responses we
received came from Dr. Mehmet Binal, president of BICOM (www.bicom-inc.com):
"The Y2K problem represents an extremely serious problem for the computer
telephony industry. In fact, even if all the vendors claim that they conform with Y2K, it
may not be a guarantee that the totality of the system built by using these products will
work properly. As most of the time these systems remotely interact with other systems via
modems, analog and digital line interfaces, each and every connection may be the cause of
a particular problem. For example, an ISDN network interface communicating through the D
channel may be affected by a software package with a Y2K bug (e.g., SS7) which may cause
an unidentified problem in the system. The difficulty of guaranteeing a system's integrity
and protecting it against Y2K may well turn out to be a formidable undertaking due to
possible connection combinations through the network to different software applications.
It is impossible to know beforehand where the connection will be made and what type of
application will be connected to the system at the other end.
"These systems must be methodically investigated against such possibilities. Of
course, this creates a real problem for turnkey system suppliers as well as for all the
vendors who supply the components for the product. The probability of any DSP-based,
low-level hardware being impacted directly by the Y2K bug is very low. However, these
components provide a pipeline for the Y2K-related bug - a free passage to the intelligent
parts of the system, making the system vulnerable. It is almost impossible to predict what
kind of information will be able to pass through the DSP platforms that may cause Y2K
problems.
"The Y2K problem must be addressed at the application software level where all the
intelligent system-level decisions are made. However, it is impossible to assume that all
the products in the market allow high-level applications to make such decisions. There may
be operating system, driver level, and even hardware level implementations that cause Y2K
bugs. Therefore, a thorough analysis of time-related decision-making processes must be
made before attempting to solve the problem.
"If you ask me what I want to do this New Year's Eve, here is my answer: I will be
at home with my family enjoying a good dinner like I always do, and I will avoid using
equipment with potential Y2K bugs."
Ed Wadbrook, vice president of product management and marketing for NBX Corporation (www.nbxcorp.com), also addressed the issue of
integration directly: "Multi-vendor solutions are more likely to cause problems - the
weakest link in the chain theory. Controlling the quality standards is made more difficult
if the design specs didn't specifically address the need. The areas of biggest concern
will be the IVR systems in their ability to recognize a four-digit date range from various
read/listen and write/play sources. In addition, there may be issues with the capabilities
of the diverse database systems to effectively deal with Y2K date ranges. I think that the
interfaces between systems, often conducted with IVR systems, pose the biggest area of
concern. Many, many vendors are involved, as well as new and legacy systems…."
MULTI-VENDOR SOLUTIONS
While integration is often the name of the game when putting together a CTI solution, we
wondered if opting to use open platforms and integrating multiple vendors' products would
help or hurt a business in surviving the beginning of the coming year. On one hand, the
integration points would seem to be obvious weak points, but on the other hand, open
systems and discrete components might be easier to fix independently of one another. We
received a variety of responses.
For example, John Belville of Williams Communications Solutions' Call Center
Applications Team favored a single-vendor solution where possible: "CTI solutions
based on multi-vendor platforms unequivocally increase the potential for Y2K
complications. The application as a whole is only as compliant as its individual
components. Our Y2K experience is that each vendor will only certify that their piece of
the pie is compliant. Few vendors are conducting integration testing with outside
equipment. Y2K testing of multi-vendor solutions will require the expertise of an
integrator who can develop a test plan specific to that customer's environment. Hardware
and operating systems will be the most challenging areas for quick turnaround for
solutions in multi-vendor environments. Deciding who to turn to in a multi-vendor
environment compared to a single solutions vendor will be more difficult. The same applies
for application software.
"The end user must be diligent in identifying the technical and business impacts
of Y2K. Only a detailed inventory and assessment will determine the impact. If you have in
operation a known non-compliant component per the manufacturer, and it fails come January
1, 2000, then the consumer will ultimately be responsible. If you have a third party
verify your readiness, and all is compliant, then pursue a letter of compliance for the
entire application. The litigation issues are starting to mount, primarily in the area of
manufacturers charging for upgrades and alternatives, not in the area of consumers
experiencing failures caused by not upgrading non-compliant equipment. The best prevention
is to comply with what the manufacturer recommends. Given all the choices in today's
converging marketplace, a single vendor for integration is the best way to go if you want
to avoid the vendor wars."
Rob MacLeod, senior product manager of Brooktrout Technology (www.brooktrout.com), seemed to agree that a unified
solution would be the best alternative, if such a solution really existed: "Dealing
with a single vendor will theoretically reduce the complexity of Y2K compliance, but it's
unrealistic in today's environment to expect single-vendor systems. Computer telephony is
by definition multi-vendor, because it takes advantage of the open market for hardware,
operating systems, and application software. Typically, the application layer is
responsible for a lot of other date-related functions, such as time-stamping play, record,
fax send and receive events, activity logs, billing reports, etc."
Mike Whitmer at Witness Systems was more supportive of multi-vendor solutions:
"Multi-vendor solutions will not necessarily cause more problems. The greater
likelihood is that they'll be less problematic. The vast majority of vendors are required
to address Y2K issues and provide proof that their products are compliant. And customers,
by nature, are requiring that those vendor solutions meet that same basic prerequisite. A
great deal of our integration with CTI is real-time based - meaning the date associated
with it is not really relevant and therefore is not a…major concern.
"In developing and implementing your organization's Y2K action plan, it's
important on the front-end to ensure that all of the system applications that interface
with your CTI systems are compliant. If that step is passed over, your CTI system could be
adversely affected. However, the date factor is of relatively low importance in the CTI
realm. It's also important to keep in mind that Y2K-compliant CTI systems, when
interfacing with other (Y2K or non-Y2K) external systems, can run 'validity checks' to
avoid having outside erroneous data enter into your system."
John Landau, vice president of strategic marketing at Dialogic Corporation (www.dialogic.com), was quite clear in stating how he
saw Y2K compliance affecting integration: "The issue is compliance in each system,
not between systems. The only way to deal with it is to inquire with each vendor and/or to
test. The more disparate the systems, the more places that must be contacted for the
answers (hence, more work). The CTI industry has pretty much the same risks related to Y2K
as any other IT infrastructure."
And John's statement really seems to sum it all up. Whether you are optimistic or
pessimistic, or even downright paranoid, the Y2K issue really just means an increased
amount of work. The catch is that it may all have to be done on January 1, 2000 - although
there may be time to perform some repairs after January first. Dealing with Y2K might
remind us of the fable involving the ant and the grasshopper. You can ignore the problem
altogether and play in the sun for now, but winter is coming, and whether it is harsh or
mild, it is best to be prepared.
|
| What To Do? John
Andryuk, a principal Y2K consultant with Xerox Connect's Telephony Integration Services
Group, just finished a five-month stint with a major insurance company. Here are some of
John's suggestions, both big and small, for dealing with the Y2K bug, based on what he
uncovered during his cleanup:
Worry About Everything: This means all standalone systems, and then systems in
combination. Check the operating system (OS), CMOS, databases and other applications,
system clocks, and clocks that might be "hidden" on circuit boards, and other
internal system components. This is no joke: some CTI components and hardware resources
employ their own on-board clocks to keep track of things.
Check Your Voice Mail: Voice mail systems, if not brought into compliance, can
experience all sorts of failures and problems. Messages can be unceremoniously deleted by
the automated purge routine, incoming messages could be stamped with the wrong date,
making them irretrievable, and in the worst cases, the entire system could crash.
Don't Overlook Downstream And Ancillary Systems: Call center equipment such as
PC-controlled wallboards, automatic dialers - all the stuff with timers that connect into
the centers, and all the equipment on the floor - should be on your checklist.
Check The Contact Management Linkage: Are you doing screen pops? Or dialing
out of PIMs running on your PCs? Make sure that the OS, BIOS, CTI hardware, and
application and contact management software/PIMs are Y2K-compliant. Running off a network?
Better check that too. One loose link could cause a number of screwy things to happen.
Follow-up and reminder notices could be disabled. And, more seriously, your entire contact
database could go kablooey.
Pagers And Paging Systems: These systems are used in increasingly
sophisticated ways to alert internal and external staff about real-time problems, required
action items, and problem status. Because these systems are increasingly incorporated into
unified messaging systems, this is a linkage that must be checked.
Billing/Scheduling And Forecasting Systems: Pay special attention to those
with client accounting routines and links to management information systems.
Digital Voice Recorders: As with your voice mail system, Y2K bugs here can
cause problems on recorders that are activated by date/time schedules, affecting the
playback timing of the right recordings and the storage and retrieval of messages.
Administrative Terminal Software And Event Loggers: Check, check, check. And
then check again!
|
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
