The four major options open to business
There are four main options open to business to counter theeffects of date change errors. In most cases a mix of the options will be needed toachieve the desired business goals:

  • Repair Logic
  • Repair Data
  • Rewrite Applications
  • Replace with Packages

Of the above, the first and second add no extra value tothe enterprise - all they do is protect the status quo - or prevent a mighty slidebackwards. The last two options offer the opportunity to add substantial incremental valueto business processes - possibly even leading to enhanced functionality and businessprofile as a result. However, the clock is running and there may be only one "valueadd" option realistically left open as we shall now explore.

Repair Logic

This is not a full fix to the problem, but helps when thereis a considerable amount of archived data to deal with.

In many cases, it will be impractical to recover the fullset of archives and apply the Repair Data option. This could be because of an enormousnumber of acquired transactions or because of the legacy of differing data formats overtime.

If analysis shows that Repair of Logic is a valid option,the process entails amending all program logic code in the affected areas to apply acontext-sensitive interpretation to dates. Much like the way the reader has to do whenresearching the Great Fire of '66 in the Library analogy discussed earlier. Thisapproach could be construed as a relatively "quick and dirty" solution becausethere is no cast-iron guarantee that the interpretation will always be correct. But it isfast to implement because the data structures have not changed. Altered programs can thenbe re-distributed around the organisation, that do not require changes to the database tooperate.

This is a medium risk option - assuming of course youcontrol the source of the software. If you do not, it should not be undertaken lightlybecause your software suppliers/writers will be under similar pressure from manydirections and you must be sure that deadlines will be met. There are software tools thatcan be used to automate some of the process and they would probably pay for themselves intime saved.

Repair Data

Repairing of the data is by far the most preferable of the"stand still" options. It entails the re-mapping of all databases or files thatcontain date information, to reflect a four digit year. It should be little comfortincidentally to reflect that technically we will be building a potential problem for theyear 10,000 by this practice!

However, changing the data requires that all program logicreferring to dates is altered to deal with the extended format. The systems must then beextensively re-tested to ensure correct operation and a very carefully planned strategyfor conversion of live data and archives must be implemented. The very large estimates forthe global bill for fixing the millennium bug come from this activity. The undertaking isa medium to high risk option because of the impact of missing deadlines, not testingthoroughly enough, or running out of implementation manpower. In any event, tools can beused that will automate some of the process and probably pay for themselves in time saved.As for the Repair Logic option, the risk may be medium to high or even unacceptable -depending very much upon your choice of software suppliers/writers and their availability.

Rewrite Applications

This is the first tactic reviewed that offers a chance tomake capital out of the forced investment we must make. It will not have escaped yournotice that with the previous two solutions, any planned enhancements or additions to thecorporate IT strategy to benefit business operations, will have been put on hold while thedate fix is implemented. Some computer industry analysts point to this and say that thisis why for once, industry hype is not there to try and sell more hardware. So as the needto rewrite key parts of our IT infrastructure is forced upon us, there is a tendancy toactually relegate the date change issue to a non-cost item - because it will come freewith the cost of developing new applications. This is all very well, but every frustratedChief Executive who has experienced long delays and miscalculation of delivery dates ofnew IT systems, could not possibly contemplate "betting the farm" on thedelivery of a new corporate infrastructure, on time and within budget. Those thatidentified the millennium bug and acted upon it back in 1993 have every reason tocongratulate themselves. The other 95 per cent that have yet to begin, will not undertakethis tactic lightly.

Replace with Packages

The fourth of the options also adds value to thecorporation, and is the implementation of standard packages. If, and it is a big if, yourcorporation can adapt its trading style and business practices sufficiently to be able tointegrate an off the shelf product, or the package has a high enough degree of initialconfigurability and change flexibility, then this solution should prove the mostattractive of the four in terms of business value-add payback and risk management.

The major benefit of adopting the package solution approachis that reputable software vendors should already be protecting their customers from thecentury date change issue, with software that has already been designed and tested toensure full 2000 compliance. Those that cannot show this capability now will have exactlythe same problems as business users. One of the key factors to take into considerationwith the package solution, is the time taken to implement some systems; if it is more thantwo years, which can be the case, then the system is unviable as a year 2000 solution. Thepackage approach therefore offers the opportunity to convert a cost only project into aninvestment that will add value in updating your information systems to a more efficient,easier to maintain and better to use structure. It also enables the addition of processesthat your current systems are incapable of - such as European Monetary Union and theimpending Grüner Punkt EC legislation which will affect all manufacturing and logisticsbusinesses.


European Monetary Union
The topic of European Monetary Union has also caught themedia's attention. This issue is of course of primary importance in Europe but shouldalso be considered throughout the world, as there will be an impact on trading partnerswithin the European community for businesses on other continents. While the timetable isvery likely to change, some form of monetary union will inevitably take place. Whether theUK is in or out of the EC, all companies will be affected and planning for thisevent's impact on IT systems should be under serious consideration today. The move toEMU as defined in the Maastricht Treaty timetable, is in three phases:

Phase 1: 1st Quarter 1998. This is when the formal decision to go ahead with the qualifying countries is expected.

Phase 2: 1st Jan 1999. Currently scheduled to happen on this date is the locking of the exchange rates and the introduction of the new "Euro" being used in all European Central Bank activities - as well as other wholesale market operations.

Phase 3: The final phase is when the conversion of all monetary transactions take place and the national currencies would be withdrawn.

The phasing of this is such that it is intended for thetransition period to be short i.e. weeks or months, rather than years. There is a highdegree of uncertainty whether there will be dual currency arrangements necessary to copewith the new Euro in use by the European Central Bank. Also, whether a corporation decidesto use the Euro or not will very much depend on the credibility and liquidity of the newcurrency.

Accounting and other systems will need to be changed anddual systems will in all probability be needed. Pricing and invoicing systems will need toadapt because of the need to price in Euros when exporting to a participating country,whether or not the UK chooses to opt out.

It is not all bad news, however. Interest rate volatilityshould decline and the differential in rates should reflect only credit risk andliquidity. Central cash management will be easier to achieve for multinationals becausethere will be more pooling, sweeping and netting of funds. Payments should become fasterand the costs should fall with the elimination of foreign exchange transfers.

So there is at least one other major reason apart from thenegative millennium bug issues to consider the strategic overhaul of your businesssystems, rather than just make a tactical adjustment to fix today's problem.


Assessing the impact
The options discussed above will in most cases form only partof the solution. Most businesses will require a mix of the various tactics. It may be thatcertain strategic choices of hardware to support mission-critical activities dictate theplatform that other solutions have to operate on. It may be that sufficient budget is notavailable to achieve a complete change of core software, and it is certain that largesections of existing IT infrastructure will be discarded as inappropriate for 21st centuryuse.

The way forward is ascertained by a complete and systematicanalysis of the enterprise. The real issue with the year 2000 is the lack of knowledgethat organisations have regarding the applications, the business functions and therelationship between a business function and the enabling applications. This lack ofknowledge increases the risk associated with the millennium crisis. Generating a systemsplan where one previously did not exist, will also certainly help in the area of futureapplications deployment and business process change engineering.

There are many ways of approaching the problem, but therectification work for the millennium bug can best be handled using a parallel methodologyi.e. more than one simultaneous investigation stream. IT systems need to be categorisedinto complete business units. Each business unit is then considered strategically by theBoard of Directors for business function and profit/revenue contribution, such thatnon-core business activities can be either sold off or discontinued. There is little pointin investing time and effort on a business activity which is destined for closure,replacement or substantial re-engineering. A current trend in management thinking is toreverse the diversification that was popular during the seventies and eighties so thisapproach will help with that process, and there will be a clear list of businesspriorities that will drive the rectification process.

Having isolated the strategic business units, aninvestigation of the IT systems supporting each unit can be performed. This initiallyshould deliver database structure diagrams which would highlight those files/databasesthat will require date restructuring. Leading on from that, program/table cross-referencescan be drawn up (if not already available as part of the normal site documentation) toshow those programs that are definitely affected through association. Lastly, all programsnot identified already must be investigated for date references and rectificationundertaken. Finally after all amendments have been applied and unit testing has takenplace, full system testing must be performed and all appropriate documentation updatedbefore the task of redeployment is undertaken. The task is people-intensive, so whereappropriate, tools can be used to reduce the manual effort required. A factor in thesuccess of the project will also be the calibre of project manager deployed. It isexpected that good project managers will become very hard to find as the deadlineapproaches.

The more focused the approach to the millennium crisis, themore timely the solution will be. The Gartner Group for example, have defined a 6 stageframework within which organisations can select the appropriate solutions and evaluatevendors and products that will help achieve the highest rate of success in addressing thecentury date change issue.

Inventory Legacy applications, business relationship and environmental considerations
Scope Driven by business goals and issues
Parse Identify detail of applications
Examine Perform gap and quality analysis
Consider options Reconcile requirements and capabilities
Tactical solutions Think strategically, act tactically

The INSPECT methodology reproduced by kindpermission of the Gartner Group

INSPECT and other such methodologies provide a frameworkfor evaluating existing systems, prioritising tasks and planning detailed technicalsolutions. Their emphasis, as it is with INSPECT, should be on the business value of suchactions so that major investment is not wasted on updating (sic) systems that will in factbe redundant in five years time.


In summary
The millennium need not be a business and computing disaster,although it will be if ignored. One concern is that even if we get our own houses inorder, will all of our business partners? Certainly, due diligence must include an itemabout year 2000 system compliance when contemplating acquisitions over the next fouryears. Closer attention to the potential litigation and possible bankruptcies arising fromthe date change may provide gaps for exploitation or low cost acquisition opportunities.The major opportunity however is inherent to the process needed to evaluate the changesrequired for the 21st century - the opportunity to implement newer, better businesssolutions to compete more effectively on the world stage.

This briefing has given an executive insight into theproblem, the exposure to organisations if ignored and has discussed the four options opento address them, namely:

  • Repair Logic
  • Repair Data
  • Rewrite Applications
  • Replace with Packages

It has described how the first and second options addlittle or no extra value to the enterprise - all they do is preserve the status quo - orprevent a slide backwards. The last two options are to be preferred because they offer theopportunity to add substantial incremental value to the business processes - possiblyleading to enhanced functionality and business profile as a result. We have also seen howthe European Community with Monetary Union will be placing demands on the applicationsoftware over the next few years. Coupled with initiatives such as the Grün Punktlegislation which will affect all manufacturing and logistics companies, the impendingdisaster could well be a blessing in disguise. So while the option to rewrite large scaleapplication software is fast receding, there is still enough time to embark on areplacement of core, mission critical business functions with highly configurable, year2000 compliance software from reputable software suppliers.