UNKNOWN YEAR 2000 UNKNOWNS
The Viagra economy
of 1998 makes it easy to ignore the Year 2000
Problem. Yet
there is reason to surmise that we have passed the
point of no return
-- that we are likely to have serious systems
failures as we transition
to the Year 2000.
How serious?
We don't know.
Some of these are
likely to be of the expected,
first order variety
-- bank screw-ups, supply chain problems,
air traffic control
delays, etc. -- but we might also experience
emergent, higher-order
unravelings, with consequences that could
be economic, social,
medical, geopolitical.
On the other hand,
we might *not* experience such emergent,
society-shaking consequences
-- and I *hope* not -- but contingency
thinking today beats
being surprised and unprepared tomorrow.
Complex adaptive
systems - such as ecologies or markets - rarely
progress in a smooth
linear fashion for long. The space folds. If there
are too many rabbits,
suddenly coyotes appear. Virulent strains of
disease course through
populations, decimating their host until resistant
individuals meet weaker
strains of disease to establish a new dynamic
balance. Markets
feed on their own enthusiasm, bubble and burst, then
"correct"
and regain temporary, perhaps illusory stability.
Yet we have progressed,
apparently smoothly, from a world of isolated
8 kilobyte machines
to a gigalink society, a network of pervasively
networked networks,
whose methods and meanings are emerging faster
than we can discover
them - let alone understand their implications.
Moore's Law was
a wild card. Nobody planned how the individually
hand-crafted computer
programs of the 1970s would acrete to form the
Just-in-Time Economy
that supports today's industrialized world.
We who wrote Fortran
in that era are surprised that our morsels of
kludgey code, painstakingly
crafted to use expensive memory with utmost
efficiency, would still
be running today.
ONCE PERVASIVE PRACTICES ARE NOW OBSOLETE
The Year 2000 Problem
is born of well understood, widely accepted, once
omnipresent programming
practices that were established when memory was
expensive. (Remember
how we named a variable D instead of DAY, or S
rather than SUM, to
save memory? I do.)
Memory got cheap,
but the code we wrote is still running.
Thus, the Y2K problem
is widely sown in older code.
Often it appears in
mutated, hard to recognize patterns. Or in
systems that are three
miles under the ocean or 300 miles out in space.
EASY TO IGNORE
It is easy to overlook,
ignore, and minimize the disruptive potential
of the Y2K Problem.
I was reminded how easy Y2K is to deny when the
May 4, 1998 issue of
the new, otherwise technologically savvy webzine,
The Industry Standard
(http://www.industrystandard.net/)
scoffed that
Y2K was being over-hyped
by greedy, scare-mongering consultants.
Why so easy?
A few reasons. In isolation, it is supremely boring
whether the year is
a 2-digit or 4-digit field. And nobody likes to
dwell on bad news,
especially in good times. And facts about Y2K, when
you can find them,
are either boring and technical, or overly dramatized
and, indeed, over-hyped.
And good observations on the emergent, systemic
nature of the problem
are difficult to find. And sometimes known facts
are actively suppressed
by good people who fear litigation.
So here are some
observations:
Observation #1: PEOPLE
WHO KNOW MORE BECOME MORE CONCERNED.
People who have not
been involved in Y2K assessment are prone to say,
"No problem."
In contrast, the people with the longest faces, who
speak of Y2K in the
gravest tones, belong to the firms that are
furthest along in the
remediation process. Over the last year,
four out of five corporate
Y2K budgets have been increased upon re-
evaluation. As
FCC Chairman William Kennard said recently, "Every company,
every government agency,
and every organization that has looked into the
problem has found that
it is more complicated, more serious and more costly
than originally estimated."
(April 28, 1998)
Observation #2:
THE BIGGER A SOFTWARE PROJECT IS, THE
LESS LIKELY IT IS THAT
IT WILL BE DONE ON TIME. Empirical
data, collected over
30 years by software project expert Capers Jones,
shows that as the size
of a software project increases, the more likely
it is to be delayed
or cancelled. Thus, a 100 line project has an 92%
probability of being
completed on time, a 10,000 line project has a 62%
chance of on time completion,
and a 1,000,000 line project has a mere
14% chance of on time
completion (and a 24% chance of outright
cancellation).
Repeat: A
one million line project has a 14% chance of on time
completion. The
FAA has 23 million lines of code, Prudential Insurance
has 160 million lines,
Chase Manhattan Bank has 200 million, Citibank
has 400 million, and
AT&T reportedly has 500 million.
Observation #3:
THE JUST-IN-TIME ECONOMY MEANS THAT
WAREHOUSES HAVE BEEN
REPLACED BY INFORMATION SYSTEMS.
The farmer's fertilizer
is manufactured under computer
control. It is
delivered by a truck that is dispatched by an information
system. The planting
and harvest are guided by information systems.
The food is processed
and shipped under the control of information
systems. The
feed and seed store, the farmer, and the middleman are
paid by information
systems. The shelves in the store are stocked
according to a web
of information systems. The vast commodity market,
the "magic hand"
that stabilizes this process is but a brittle skein of
interrelated information
systems.
How many of these
systems will be whittled by Y2K termites -One
percent? Five percent?
More? Which of the weakened links are critical
in holding society's
meshwork of value chains together?
OBVIOUS AREAS OF CONCERN
People who have
been studying the Year 2000 problem are concerned
about the system that
brings food to our tables, the payment systems that
support this process,
and the financial systems that underlay stock and
bond markets.
They are also concerned about the systems that bring us
gasoline for our cars
and run the electric power grid, the systems that
heat and cool our buildings,
our healthcare system from HMOs to heart
monitors, and the systems
that deliver government functions like Social
Security, Air Traffic
Control, and local police, fire and ambulance
services.
In each of these
systems, information cascades from one system to
another, and another.
The date is often critical, though sometimes in
less-than-obvious ways.
For example, the date might be used as the seed
for a random number
algorithm. Or a date field like 9/9/99 might be
used to indicate the
end of a list of numbers. Each component might
depend on the correct
operation of the systems that logically precede it.
Failure of one program
has the potential to disrupt the superordinate
system to which it
belongs.
TELECOMMUNICATIONS SYSTEMS
Communications is
a critical concern. Microprocessors run virtually
every telecom system.
Arthur Gross, the former CIO of the US Internal
Revenue Service, is
less concerned about the hundred million lines of
IRS application code
than he is about the IRS's communications
capabilities.
"The Achilles heel for IRS . . . is going to be its
telecommunications
problems," he said (4/14/98).
The Gartner Group's
Howard Klein states publicly that customer premises
equipment is a critical
concern. He projects that at year-end 1988, 80%
of private telephone
switches (PBXs), automatic call distributors
(ACDs), and interactive
voice response (IVR) systems will not be Y2K
ready (10/1/97).
Bell Atlantic is
less quantitative, but more dramatic: "Network
management tools and
network hardware, such as bridges and routers,
built before 1996 may
have been programmed with two-digit date fields
that will not respond
to the Year 2000 change, causing networks to crash
at the dawn of the
new millennium. If the Year 2000 problem is not
addressed from a network
perspective, network administrators will be
unable to access mission
critical applications. It is estimated that
networks installed
before 1996 have a 90 percent chance of having a
Year 2000 problem"
(Bell Atlantic Network Integration News Release,
November 3, 1997).
A THOUGHT EXPERIMENT ON "EMERGENT" EFFECTS
Yet, when it comes
to the public telephone network, Bell Atlantic
assures us, "We're
working systematically to make sure that January 1,
2000 is just another
day for the (public) network" (http://www.bell-
atl.com/about/faqs_main.htm#BELL1).
And AT&T says, "We don't
anticipate any Year-2000
related problems in providing service to our
customers before or
beyond January 1, 2000"
(http://www.att.com/year2000/goal.html).
Let's take it at
face value, then, that the public switched network will
remain intact and functional.
But for heuristic value, let us assume that
the Year 2000 problem
will hose a significant proportion of customer
premises systems.
And let's also assume that for some period(s) of time
beginning in 1999,
and continuing into the Year 2000, that the operation
of the airlines, the
Social Security System, the banking system, etc., is
sporadic and uncertain.
Now imagine yourself
wondering whether your scheduled airliner will
fly tomorrow.
What would you do? Myself, I'd call the airline to
find out. And
if I could not get through, I'd try again. Hey, this
is important!
I'd keep trying until I got an answer!
What if your paycheck
were delayed? What if your mortgage company
screwed up your mortgage
account? What if your local supermarket's
cash register treated
your credit card as if it had expired? What if
the truck that was
supposed to deliver your heating oil had not arrived?
What if you wanted
to find out which day of the week your bank would
reopen? Or whether
the store had bread? Myself, I'd call. And keep
calling until I got
through.
Yet, according to
the Gartner Group, up to 90% of the private switches
and automatic call
distributor systems could be down. The very
equipment that airlines
and banks and mortgage companies and
government agencies
use to handle customer calls might not be working.
For sure, they would
try to handle incoming calls manually, as best they
could. But we
could expect a marked decrease in the number of calls
that could be handled.
Even as the number of calls would be skyrocketing.
EMERGENT EMERGENCIES
We're assuming that
the public phone network is fully functional. But
the phone network is
engineered based on scarcity. We have already seen
single events (like
the beginning of ticket sales for a Rolling Stones tour)
cause major network
congestion. The fact that the phone network is
working does not mean
that it would be problem free!
Your local telephone
office is engineered for maybe one line in ten to be
busy during the Busy
Hour. What if this assumption is violated? Maybe
a single bank emergency
or spot shortage would generate assumption-
busting call volumes
and maybe not. Two such events, with the same
distal cause (Y2K),
occurring at the same time in the same
neighborhood, would
be more likely to. Maybe you try to call and
can't get dial tone.
Or maybe you call and get network-busy from
the other end.
In either case, the network would work, but calls
might not go through.
So here's one way
that "external" events might cause a working network
to become non-functional.
Its an emergent problem. There are many other
such emergent problems
that could occur when a single trivial, but
pervasive factor, like
the Year 2000 Problem, leans hard on the entire
infrastructure.
REAL WORLD EVIDENCE
Reports of tests,
in which the clock is experimentally advanced to the
last minutes of 1999,
are beginning to emerge. An off-line power plant
failed at one minute
past experimental midnight - a sensor that
integrated over time
suddenly detected an out-of-range condition as the
denominator went from
99-something to 00-something. A car factory
near Detroit that set
its clocks ahead not only lost its time clocks,
but its security system
failed - nobody could get in or out of the plant.
Another type of
real-world evidence comes from a venerable, established,
high-tech corporation
that spent $100 million and three years on a
software that was to
make the company Y2K compliant -- and then abandoned
it in late 1997, because
the fix was not matched to the corporate culture.
There are not very
many such stories. One reason is that the line
managers responsible
for Year 2000 fixes come from a system where a
key goal is to make
"your people" look good to your boss, where
showing positive results
is more important than emphasizing the
challenge ahead.
Another is that corporate lawyers are advising their
clients to remain silent
about the problem. A third is that there simply
has not been very much
"advance-the-clock" testing.
PLANNING FOR THE UNKNOWABLE
It is very unlikely
that we will know which systems will fail, or what the
second-order consequences
of those failures will be, or how people will
react, until the failures
begin to occur. When? They are beginning to
occur - slowly - now.
We can expect a big pulse of failures around
January 1, 1999, and
additional emergencies throughout the next year
or two.
We can surmise that
telecommunications systems based on Stupid
Network principles
will fail less frequently, and less severely,
than those based on
Telecom Classic. There are perhaps three
reasons for this.
First, these systems are newer, thus less likely to be
developed in the era
of scarce memory. Second, they are based on fewer
assumptions, and are
easier to design by over provisioning. Third, the
Internet Protocol was
designed to be so that pieces of the network could
work even as other
pieces fail.
But there is no
call for complacency. The global Internet is tied
at many points to older,
more failure prone systems.
Our thought experiment,
above, assumes that the public switched
telephone network survives
with full functionality.
But there is reason
to believe the opposite.
Extrapolating Capers
Jones' data on on-time
software projects to
AT&T's 500,000,000 lines gives us a minus 20-
something percent chance
of project completion. Whatever that means.
The five RBOCs and
three other major US interexchange carriers have
software problems like
AT&T's. Then there's integration testing - all
telephone companies
interconnect with each other, and their Y2K fixes
must interoperate.
AT&T interconnects with at least 280 other phone
companies worldwide.
As the critical
date nears, we'll need to expect the unexpected. And plan
for the unexpected,
insofar as possible. FCC Chairman Kennard recently
reported to Congress
(April 28, 1998) that Y2K, "has the potential of
disrupting communications
services worldwide." Here's hoping that such
disruptions, if they
occur, are of limited duration and severity!
THE HUMAN SPIRIT
On the other side
of the coming crisis, perhaps (given good preparation,
enlightened leadership,
and an otherwise peaceful world) we will be able
to look back and say,
"We survived, we learned, we never abandoned our
humanity no matter
how bad it got. And our software infrastructure -
indeed our society
- is better for it!"
(The best thinking
on emergent Year 2000 issues and actions
that I'm aware of is
on Doug Carmichael's website,
http://www.tmn.com/~doug/y2kproblem.htm
. . .)
--------------
NEW! NEW! NEW!
The Dawn of the Stupid
Network was the cover story of the Feb/Mar 98
issue of ACM Networker
(just out). It is a major post-AT&T rewrite of
the Stupid Network
idea. It'll be on http://www.isen.com/ soon. Better
yet, AT&T Executive
Vice President and all-around good guy Dado Vraslovic,
is writing a rebuttal,
defending intelligence in the network, for the
April/May issue of
ACM Networker, due out RSN.
--------------
SMART REMARK OF THE
MONTH: "If I taught a class, on my final exam
I would take an Internet
company and ask [my students], 'How much is
this company worth?'
Anyone who would answer, I would flunk."
Warren Buffett, quoted
in the Industry Standard Media Grok, May 5, 1998.
--------------
CONFERENCES ON MY CALENDAR
On May 18, I will
be lead-off speaker for a Washington DC
conference called "The
Bandwidth Explosion: Understanding New
Technologies That Are
Driving Business Opportunities." The website
is http://www.cambridgecom.com/index_conf1.html/
And on May 19, also
in Washington DC, I will address the OIDA
Communications Roadmap
Workshop. OIDA stands for Optoelectronics
Industry Development
Association. The title of my talk will be
"Stupid Optical
Networks: A Bright Idea."
Find OIDA contact information
on http://www.oida.org/
On June 8-11, I
will be at Jeff Pulver's Voice-on-the-Net Europe
Conference. I
don't know what I will talk about.
http://www.pulver.com/
On the evening of
June 11, in London, I will speak at a World
Technology Network
roundtable. A cozy dinner discussion with
technology leaders
from the UK. SMART people are welcome.
Contact JPClark@aol.com
for more info.
On Thursday, July
9, I have been engaged as Agent Provocateur at
a Washington DC Telestrategies
conference entitled "Next Generation
IP Networks."
http://www.telestrategies.com/
DON'T MISS George
Gilder's TELECOSM Meeting, September 15-17, Lake
Tahoe NV. Last
year AT&T would not let me speak at Telecosm. This
year, not only will
I be speaking, I'll be hosting a panel of
other AT&T refugees!
Tom Evslin and Joe Nacchio have accepted slots
on my panel, so far.
Watch this space for additional surprise guests
(as they leave AT&T).
Info at http://www.gildertech.com/
. . .
Regards,
David I
-------
<<to unsubscribe
to the SMART List, send a brief unsubscribe message
to isen@isen.com>>
<<for past
SMART Letters, see http://www.isen.com/archives/index.html>>
*--------------------isen.com----------------------*
David S. Isenberg
isen@isen.com
d/b/a isen.com
http://www.isen.com/
18 South Wickom Drive
888-isen-com (anytime)
Westfield NJ 07090
USA 908-875-0772 (direct line)
908-654-0772 (home)
*--------------------isen.com----------------------*
-- Technology Analysis and Strategy --
Rethinking the value of networks
in an era of abundant infrastructure.
*--------------------isen.com----------------------*
Date last modified: 13 May 98