This guide sets out to explore the reality of whatthe media is describing as a ticking time bomb for business. The looming threat is theimpact that the year 2000 date change will have on all computer systems as we approach thenext millennium, a bomb which is threatening to stop business in its tracks with apotential disaster on a world-wide scale not seen since the Wall Street crash unlessaction is taken now. This document is designed to aid the senior business manager’sunderstanding of the key issues in the change of century, provide pointers in theassessment of their corporation’s exposure and highlight possible actions that willnot only contain the problem, but can potentially be leveraged as a competitive advantage.
Computer professionals are by nowthoroughly aware of the scale of the date change problems and are showing varying degreesof concern about their solution. They have not however been particularly adept atcommunicating them to the business management of the corporations which they serve. Someclues as to why this communication is not forthcoming are contained within the potentialreactions of some Chief Executives who, when appraised of the problem – and the problem isnot complex, it is the solution that is the challenge – may demand to know who they canfire or sue.
Governments across the globe are aware ofthe issue and are dealing with it with varying degrees of commitment. On the 2nd of August1996, The British Government’s Ian Taylor, Science and Technology Minister announcedthe creation of a task force. Headed by Robin Guenier, who was previously interim ChiefExecutive of the Governments Central Computer and Telecommunications Agency (CCTA), theirmission is to co-ordinate actions to alert UK businesses to the threat and help them copewith it.
Similar to the Wall Street crash where manymillionaires were created while other businesses floundered and died, within the allegedimpending doom lies opportunity for those corporations who recognise it. There are alsopotentially serious problems for those who ignore the warning signs in not only their owncompanies, but those of their business partners. Robin Guenier, when talking about thepossible solutions stated “I don’t believe there is a silver bullet, but thereis a silver lining.” He went on to say that the date problem can be solved, providingthat Chief Executives believe there is a problem to solve and set about doing so in goodtime.
Part of the current disinterested approachby many corporations lies in the wide range of interpretations put upon the date issue bythe media. It varies from being treated as an amusing article in a magazine, throughcriticism about the computer industry “hyping” the issue to generate more sales(which Guenier believes it will not) and on to the hysterical “we’re all goingto die” scenario propagated by the popular press. Surrealism sells copy, whilepragmatism is what is required to address this particular issue.
What is the Issue with the Year2000?
This briefing is not intended to scare. Curiously though, muchof the scare factor does emanate from within the computer industry itself – inGuenier’s opinion generally from those who have not had to run a business. “Oneof the reasons we are where we are” he asserts, “is the huge gulf betweengeneral business management and IT specialists and I think it is part of theproblem.” “Finger-pointing is pointless”, he went on to say. “At leastuntil the solution is being implemented…”
The computer industry press has been fullof scare-mongering stories about “the end of the world” being nigh – in computerterms anyway – since 1993 when the problem was first documented in detail by a Canadianconsultant named Peter de Jager. However the problem goes much further back than that. Itoriginates in the early 1960s when much of today’s software was first written. Sowhat exactly is the problem?
Simply put, poor design of software hasmeant that the majority of computer programs written in the last thirty years will notwork properly after the year 1999 – and in all probability will fail well prior to that.Let us be quite clear about this. There is nothing wrong with the computer hardwaretechnology your corporation has invested in: it will be performing perfectly well. Butyour application systems will not. There have been various estimates from a number ofconsultants about the eventual costs incurred by business across the globe in rectifyingthese faults, and they vary from zero to $600bn. Some estimates for the cost to the USGovernment amount to $30bn alone. Your company will be contributing its share of thispotentially colossal figure, if it hasn’t begun to already. The fact you are readingthis briefing is a clear indication you are taking it seriously. Whether you see it as abottom line cost or an investment opportunity is the key message behind this document.
The millennium crisis is not just acomputer department issue. It will affect the whole of the organisation and should betreated with that degree of importance. To be fair, considerable money has been saved inthe past because of the cause of today’s problem. This was the space saving of whatwas very expensive disk storage by the omission of just two characters on every dateditem. So perhaps one could argue that all that is happening now is that the day ofreckoning has arrived. We are now going to pay for all the costs saved in minimising tapeand disk storage over the last 30 years.
The cause of the problem
The root of the problem is that computer application systemshave in many cases, not been designed to cater for dates properly. Computer files anddatabases contain information about the business. Names, addresses, stock holdings, billsof materials, debtors, creditors, the list is endless. Computer files and databases alsocontain dates.
A common method of speech is to refer todates in this century by only quoting the last two figures. We talk about ‘96 for1996, ‘99 for 1999 and so on. This is fine for speech, because if we want to draw thedistinction between this century and the next (or last) we say the year in full – 1996,1896, 2096, in that way there is no confusion. With the computer systems of the sixties,seventies and eighties, we did not have the luxury of large amounts of storage space wehave today, so programmers tended to save space by ignoring the 19 of 1900 and assuming itinstead. Which means that no matter what century a piece of information relates to, theseolder legacy computer applications will almost always assume they refer to the 20thcentury. In the 1970s, computer programmers never suspected that programs created thenwould still be running at the end of the century.
But they are. IT Managers have a sayingthat a programmer only ever writes one program. Then they copy and amend it to suit theneeds of the new application. So it is quite possible for the core of a program createdtwenty years ago to still be an integral part of a computer system created for thenineties. Together with the ability to only store two digits of year information.
A fact that has not been given much publicairing is that this situation is not new. It last arose in 1970 when mainframe systemswritten during the early 1960s started failing because there was only one year digitstored. Programmers thought in 1962 that it was not likely that they would have to worryabout what happened in 1970 because either they wouldn’t be there (an attituderepeated in the seventies and eighties) or the systems would have been already replaced.The systems were replaced, but only when they started to fail when they assumed that 1970was 1960. The use of computers at this time was very much limited to large corporationswith huge computer information divisions with comparatively limited amounts of programs toamend. This meant that the problem was easily isolated and contained.
Examples of the effects on youroperations
Confusion with dates permeates just about every aspect ofbusiness life. The very nature of business is that it is a cause-effect relationshipseparated by time periods. For example, an order is placed, the item is scheduled formanufacture. The item goes through various stages of manufacturing cells, it is qualitychecked, packed, sent to distribution, shipped, invoiced and finally paid for. Everysingle event in the above list is date stamped because that is what controls the order ofevents. If we jumbled the order of events, the system would become unworkable.
Computer systems are complex items ofequipment, but they can handle the large volume of transactions that they do because theyare instructed to break down complex business tasks into small actions. And with dates,that means treating them as a number on which to perform calculations.
Example: problems with tenancyagreements
Consider this: 12th May 1996 can berepresented as 120596. Numerically, this doesn’t help much. But if we represent it as960512, then it has great significance in that the later the date, the higher the number.So August 5th 1996 is later than April 3rd 1956 is obvious when represented bythe numerical statement: 960805>560403.
But what happens when the date is in thenext century? 3rd April 2056 would still be represented as 560403 and the statement that960805>560403 would now be incorrect. Except that no one would tell the computer, andproperty lease expiry dates in the next century would be shown as having already expired.Eviction proceedings may well then be initiated by the computer system automatically.
Example: problems with birthdates
There are many other areas where the shortcut to the storing of twentieth century dates will cause major business headaches. Takebirth dates, for example. Everyone knows that the age of people can not be negative. Socomputers are generally programmed to only see the absolute value of any date orcalculated age. It is however possible for a computer to calculate that a person born in1956 is 43 years old in 1999 but 54 years old in 2000. How?
99-56 = 43 which iscorrect
00-56 = -56 whichcan’t be negative so the program assumes 56
This would have a dramatic impact oncalculation of insurance premiums, expiry of driving licences, entitlement to pensions, orincome support. In fact, anything that depended on a forward projection into the nextcentury. It will not have escaped your attention that this problem could already havestarted –we do not have to wait until 2000 to experience this effect.
Example: problems with interestcalculations
By now you will be beginning to appreciatethe enormity of the problem. The opportunities for errors are endless. What about onehundred years interest added to your bank balance? Great. What if it were deducted? Not sogreat. To both corporations and individuals, it could be calamitous.
What is the solution?
The problem could be envisaged as the largest public libraryyou have ever seen. Every book has to be removed. Every word on every page has to bechecked for a missing “19” which must then be inserted. All other dates must bemade explicit – no references by context are allowed. The Great Fire of London of ‘66during the 17th century is no longer allowed. The century information must be inserted -i.e. 1666. Finally, the books must be reprinted with the corrected dates, andredistributed to every library around the world that had a copy of them on theirbookshelves.
In fact, the problem in computer terms is worse. Whenreading books, the century is normally implicit in the context of the passage thatcontains it. Not so in a computer program. The computer program will have been written toassume that the century is 19 – and that is the essence of the millennium bug.
One incorrectly stored date can upset the calculations ofall the correctly stored dates around it, and the problem may not manifest itself untilmuch later. One estimate from a leading analyst states that the cost of addressing theproblem for a medium size business which they define as one with 8000 programs supportingbusiness functions, to be in the region of $1,650 per program – or $13.2 million. Thiscost includes awareness initiatives, the inventory and assessment of a program, theselection and application of a solution and the complete testing of the solution.Additionally, the cost of project management, implementation and documentation is includedin this figure.
The good news is that many industry observers – includingJBA – consider that discussing costs to fix a bug that may or may not be prevalent inyour enterprise is a largely sterile discussion. Metrics of your particular IT solutionare required on which to base final estimates which in all probability will not be as highas the worst case scenario described above. The bad news is that there will definitely bea cost. So what can you do?