Year 2000 update - It's about time

The Year 2000 problem is a ticking timebomb, urgently demanding contingency planning from the boardroom down - but reports indicate that UK IT companies are dragging their feet

Within the IT industry at present, there are two topics in particularngency planning from the boardroom down - but reports indicate that UK IT companies are dragging their feet. that are creating a considerable amount of hype: the Year 2000 'problem' (Y2000) and the Network Computer (NC). We will be covering the latter topic in a few months' time.

The former, however, has created much contention from across all manner of industries, not just IT. Some would say it's just an excuse for consultants and Cobol programmers to charge unearthly sums of money to fix a few bugs here and there, while others are prophesising Armageddon as we enter the next millennium.

With all the hype surrounding the Y2000 problem, it is often difficult to understand just exactly what the problem is. Essentially, part of the Y2000 problem can be summarised as the inability by many software applications to cope with life after 1999. The reason for this goes back to the 1960s, 1970s and even the early 1980s, when applications were written to hold the century as a two-digit number: 1997 simply becomes 97.

The problem arises when these applications perform calculations based on date information; for example, when subtracting 1997 from 2002, you should expect to get back a result of five. When working with two-digit century fields, however, you would get back a result of -95, because 02 - 97 = -95.

What the impact of this incorrect result will have on your system is difficult to quantify as it all depends upon what the results are being used for, but certainly within the financial sector, errors like this could cause immense problems.

In a report conducted by Aspect International Consulting for ECsoft entitled IT and Beyond, 90 per cent of the companies surveyed felt that at least 50 per cent or more of their company's future success relied on the quality of their IT functions. Fixing the problem therefore must be seen as a priority. However, in the same report, only 11 per cent of companies surveyed were placing the Y2000 problem as their top priority.

According to Cedardata's recent report, Defusing the Timebomb, one in ten of the UK's Top 1,000 companies still have no plan for, or do not know how they are going to address the Y2000 issue as it relates to their financial management and accounting systems.

In the same report, of the 90 per cent of companies who have a plan, only 22 per cent have completed it, while 10 per cent have not even started implementation.

Considering that 80 per cent of all IT projects implemented in the UK, not including Y2000 projects, run over-schedule, the urgency of implementing some form of Y2000 contingency to fix the problem increases dramatically as we draw closer and closer. However, unlike ordinary IT projects where deadlines can be shifted back and forth almost at will, December 31st 1999 is simply non-negotiable.

In finding out who should be responsible for overseeing a Y2000 contingency, Aspect International Consulting's report concluded that 37 per cent of companies surveyed thought that the IT department should be responsible for the operational problems posed by the Y2000 problem.

While most directors agree that it is the IT department's responsibility, 38 per cent of all financial directors felt it should be the responsibility of the operations director, while nearly as many personnel directors (35 per cent) felt responsibility should fall with the entire board. While everyone is passing the buck to someone else, December the 31st, 1999 draws inexorably closer, and still these companies have no plans to fix their Y2000 problems.

The rising cost of fixing the problem

Within the same report, costs to fix the Y2000 problem range between #200,000 and #45m over the next two years. While 45 per cent of companies surveyed felt reasonably confident that they had budgeted enough for all eventualities, 19 per cent had some doubts. Some opportunistic law firms have speculated that the Y2000 problem could become a trillion-dollar opportunity.

Attitudes to fixing the Y2000 problem are split roughly in half: 49 per cent of companies surveyed in Aspect International Consulting's report say that it's a maintenance issue that the IT department will have to fix, just like any other problem. The remaining 51 per cent see the Y2000 problem as a catalyst for replacing old legacy systems with client/server environments.

Mixed feelings reside within the industry as to whether two and a half years are sufficient to solve the problem; some industry people have even gone so far as to recommend that companies have their systems fixed by the end of 1998.

Conventional methodologies can be painful and long-winded, often requiring a lengthy process of assessment, analysis, modification, and testing.

Even then, you may not have a fully compliant system come Year 2000. The Gartner Group estimates that 45 per cent of the total effort required to solve Y2000 problems will be spent in testing.

With a growing number of automated test tools now available you can then start testing as soon as you begin the assessment phase of your Year 2000 contingency. Not only do these types of tools minimise already over-stretched resources, but also it does mean that you can perform ongoing testing throughout the entire project. This has a knock-on effect with developers in that bugs will get reported quicker and can therefore be fixed almost straight away.

The majority of applications suffering from the Y2000 bug were developed in-house and written in Cobol, and so were popular during the 1970s and 1980s. These applications contained few comments; the structure of the code may not have been particularly efficient and there was little or no documentation. The bulk of all test tools available are targeted at this market.

Applications developed for IBM mainframes were generally developed with PL/1, favoured by many large sites over Cobol. However, the Y2000 problem is probably more difficult to address with the PL/1 code than it is with the Cobol equivalent and therefore there are far fewer tools available to this portion of the market.

Some organisations even chose to develop their applications in Assembler.

Often chosen for performance reasons, even after the development of Cobol, PL/1, and other development tools, Assembler is a low-level language able to address fields by many methods. It is for this reason then, that the Y2000 problem is especially difficult to detect and fix automatically.

Unfortunately, a great deal of mainframe sites will have at least some Assembler code that will need to be checked, with the sole option of performing the task manually. Tools for fixing the Y2000 problem within Assembler are scarce, almost mythical.

On the bright side though, applications developed with RPG, a fourth-generation language that is still popular today, should be simple to fix. The structure and formatting rules of RPG make it extremely easy to detect any Y2000 problems, even though there is only a limited number of test applications available.

Of the multitude of other, platform-specific, development tools, we can only speculate as to the availability of suitable test tools. Even with Visual Basic, the most popular development tool worldwide, there are few test suites available. For many IT specialists then, fixing the Y2000 problem will be a long haul indeed.

The list of tools available to fix the Y2000 problem will continue to show a healthy growth as we move closer and closer towards the new millennium.

It is unfortunate, therefore, to find that a large proportion of these 'Y2000 tools' are merely tweaked or rebadged versions of existing software test tools.

How the EMU could affect Y2K

To add further confusion to this potential hot-bed of chaos, many industry analysts have begun talking about the European Monetary Union (EMU). While killing two birds with one stone may seem a perfectly logical suggestion, isn't the industry trying to be just a little too ambitious? For a start, no-one really knows yet whether the EMU will become a reality or not, and if it does, when it will be introduced; it is unlikely to come into effect until after 2000, but no-one can really say for definite.

Even then, no-one really has a clear idea of what an EMU-compliant application should be. Tinkering with your code to conform to a set of guidelines that haven't even been solidified yet is just asking for even more trouble.

The wide variety of tools available to fix an even greater abundance of legacy applications makes it impossible to recommend any particular Y2000 test solution or family of products.

With a maximum of just two and a half years to go, our one recommendation would be to fix just enough of your systems to ensure correct operation after 2000, and then, once these are completed satisfactorily, you can return to the rest of the applications functionality.

From all at Network Solutions, good luck - you'll need it.

Top 10 Year 2000 Do's and don't's

DO ...

1 Take the Y2000 problem seriously. Solving it is not necessarily an enormous problem in every computer installation - but the problem does need to be properly scoped and managed.

2 Take a complete inventory of all computer systems (hardware, OSs, networks and apps), security systems, telephone systems, vault door locks and anything else that may be controlled electronically using date information.

3 Think about electronic data exchanges with clients and consider how file format changes may need to be synchronised.

4 Address the Y2000 problem in manageable, prioritised chunks; accept the need for bridging technology at interfaces with other systems.

5 Consider the longer term when selecting Y2000 software tools: many will have broader uses beyond this project.

6 Look carefully at date interfacing as the way of providing the quickest lowest-cost solution wherever it is practical.

7 Take the opportunity to implement proper software configuration management, or adapt management procedures, as the changes will need to be properly controlled.

8 Take advantage of software tools to reduce resource requirements, particularly in the areas of code scanning and testing.

9 Use the opportunity to develop good testing procedures and test packs - these will stand you in good stead for the future, and the EMU may not be that far away.

10 Plan to complete the project by the end of 1998 so that the software can 'dummy'-run live for 12 months through weekly, monthly, quarterly and annual cycles: if you miss the deadline, at least you will have some degree of contingency.

DON'T ...

1 Underestimate the size of the problem which may exist outside of the environment controlled by IT, particularly on the PC.

2 Spend too much time examining the options, choosing partners, evaluating software: the clock is ticking.

3 Believe that solutions are going to get less expensive - demand is already outstripping supply, putting upward pressure on costs.

4 Think that you can outsource the whole problem - the technicians and users involved with your applications have a valuable contribution to make to your Y2000 project and may not believe that it is possible to outsource final testing.

5 Let the realisation of the many 'additional benefits' promoted by some vendors get in the way of meeting the underlying Y2000 objective.

6 Be talked into believing that it is as quick to rewrite some systems as it is to correct them - unless perhaps you have lost the source code.

7 Assume that all your IT suppliers are taking Y2000 as seriously as you are: check that your hardware, systems software, and application packages suppliers are going to be ready too.

8 Set the system dates of your 'live machine' forward in order to test post-2000 scenarios.

We have heard of many instances where tests such as setting the date back to the normal 20th century has confused the OS and caused many problems.

9 Let the time scales for the early project phases expand at the expense of testing time, as so often happens on time-sensitive projects.

10 Sit around waiting for the silver bullet - it's not coming.

Researched by Bloor Research

CONE MILLS AND SSA

System Software Associates (SSA) announced on June 5 that Cone Mills, headquartered in North Carolina, with 1996 sales of $745m, has selected business planning and control system (BPCS) client/server version 6.0 as its enterprise resource planning (ERP) solution.

Cone Mills is one of the world's largest textile manufacturers and producers of denim fabrics, and exclusive supplier of the fabric for Levi Strauss and Co's 501 jeans.

Previously running a 'homegrown' system on a Unisys mainframe, Cone Mills needed a new order fulfilment process system to gain a competitive edge through superior customer service.

"We wanted to steer away from the mainframe towards a client/server environment and were looking for a flexible system that would decrease response time and reduce costs," said Randy Autman, manager of application systems at Cone Mills. "We also needed a solution that was Y2000-compliant."

In addition to BPCS' order fulfilment capabilities, Cone Mills also selected it for its quick time to benefit.

"It is critical that our implementation runs as scheduled. We need to start taking orders to be delivered in Year 2000 by January 1999.

And SSA, with an average implementation time of six to nine months, was the only vendor with such a proven track record," said Auman. Cone Mills was scheduled to start the implementation process on the 1st June 1997.

The launch, in August 1997, of the BPCS Maintenance Management Century Date (MM/CD) 6.0, will complete SSA's Century Date Program and will cover the entire range of BPCS applications.

The maintenance management products in the offering will include automated data collection, calibration tracking, equipment tracking, component tracking, maintenance cost tracking, parts inventory/purchasing, tire tracking, warranty claims tracking, and work order planning and scheduling.

Headquartered in Chicago, Illinois, with European headquarters in Frimley, Surrey, SSA develops and provides cost-effective business enterprise/resource planning information systems and currently has over 8,000 industrial-sector customers worldwide.

CONTACTS

- Bloor Research (01908) 373311

- Mercury Interactive (01634) 262525

- System Software Associates (SSA) (01276) 692111

- Cedardata (0181) 949 7057

- Aspect International Consulting (01276) 675777