|
It seems pretty sure that planes will not fall out of
the sky although the toaster might burn your toast on the first morning of new millennium.
But even if its worst effects are likely to have been neutralised, when it comes to the
workplace, most organisations are still taking no chances with the millennium bug.
Bug-busters have been hunting their prey down for several months, if not years, but few
could be confident that they have converted every last line of code. And so as the last
few months of the century unfold, IT departments are entering a period of contingency
planning. That is only to be expected. But one of the most common elements of contingency
plans is turning out to be the imposition of moratoria on new systems and applications.
And as an antidote to non-compliance, they are viewed as ineffectual gestures by some, and
by others as lulling businesses into a dangerous sense of false security.
Warning
PA Consulting Group, for one, has been issuing warnings. Organisations that believe their
systems will be ready in time for the millennium should not be complacent, but should
switch to the final phase of business continuity planning now to counter the real threats
to their business, so says a recent report, ‘Defusing the Millennium Bomb’. In
practical terms, this means recognising that the threats posed by the date change present
major risks to the functioning of the business before, during and after the changeover
itself. The report is based on the progress of several UK organisations over the last
three years. "Organisations must ensure that they know exactly what is critical to
the success of their business and then prioritise their effort on that basis," says
Fons Kuijpers, a member of PA’s management group. "They must focus on the real
risks to their businesses, most of which will be outside of their direct control, such as
utilities or their supply chain."
Kuijpers continues explaining that organisations originally thought that at this stage
they would be on the home stretch of their conversion programmes, but now they realise
this is not so. "Existing disaster recovery plans may not help unless there is
confidence that the alternative arrangements do not have millennium-related
problems." And hence they resort to moratoria.
Enterprises declaring moratoria are attempting to deal with a fundamental risk. They have
worked hard at remediating, upgrading, replacing and testing their IT assets to deliver
year 2000 compliance. They are concerned that changes introduced after final testing has
been completed will tend to destabilise their systems and will risk introducing new
non-compliances. In order to avoid such risk, they declare a moratorium. The logic seems
clear enough, making obvious sense, so it seems. Apart from ensuring that no bugs break in
unawares before there is time to find them, moratoria are a way of imposing a Y2K
discipline on employees who might otherwise believe the problem is overhyped.
Alternatively, the cut off will free up internal resource should Y2K problems start to
appear. But some of the most respected voices in the IT industry have been arguing
otherwise. GartnerGroup is one. At heart, the consultancy believes that moratoria are not
only impractical but dangerous. "Through 2000, 90 percent of enterprises which
declare a year 2000 moratorium on changes to their IT assets will be obliged to implement
changes despite the existence of the moratorium," explains Andy Kyte, a GartnerGroup
analyst. "Such declarations are unnecessary and dangerous: rather than reducing risk,
these lengthy moratoria will tend to increase it."
Blanket moratoria
GartnerGroup analysts have been receiving inquiry calls from clients who are considering
imposing a blanket moratorium on changes to their IT asset base for periods of up to nine
months, typically, from June 1999 to April 2000. This is hardly ‘temporary’, the
time frame usually implied by the word moratorium. But apart from the commercial
implications of such a long freeze, Kyte argues that declaring a moratorium creates a
mindset that says, ‘We will avoid new year 2000 problems by refusing change.’
However, it is impossible to eliminate change occurring to IT assets over a lengthy
period.
GarterGroup list a number of difficulties it believes will arise while organisations try
to maintain the integrity of moratoria. Operational problems, that by their very nature
cannot be anticipated in advance, is a first. For example, if a data centre, unable to
deliver the required transaction-processing response service level to end users,
determines that it could solve the end users’ problem by acquiring additional disk
storage, will managers then have to say that the end users’ problem cannot be
resolved before April 2000 because a moratorium prevents the configuration of additional
storage devices?
Kyte suggests a second – underground programming. "With a moratorium in place,
there is a risk that changes will simply be driven underground, thereby subverting any
change management program," he says. Another is how companies will cope with the
post-moratorium backlog. Further, a lengthy moratorium will create internal problems for
the IT department. "There are entire teams whose raison d’être is modifying
operational systems who would need retraining for some other roles and whose skills in
operational systems would atrophy during an enforced absence," he says.
Methodological fallacy
Other voices agree, if for different reasons. The consulting group ImagoQA suggests that
moratoria are based upon a methodological fallacy. Most organisations will use the
moratorium period for development work with the lack of imminent deadlines for roll-outs
meaning that they focus more than usual on testing, especially given the profile on
testing that Y2K has created. However, given that many organisations plan to use moratoria
in this way, Imago argues that testing software should not come to be regarded as a kind
of added extra, as this approach suggests, but should be a integral part of any IT
project.
Compounding the mistake, Imago believes that many organisations will waste thousands of
pounds in this way. They will spend vast sums on testing procedures that are not
re-usable. Rather, because testing should be seen as an investment like any piece of
hardware or software, the moratorium period should be an ideal time to build solid testing
procedures that do not just get the organisation over this issue but act as a basis for
future projects.
Freezing production
Others still believe that moratoria are simply a waste of time. "Of the companies I
have spoken with, some are freezing the production environment from July, some in December
and the rest appear spread between the two," says Steve Clark, managing director of
AMI Software. "Personally, I can see no point in a long moratorium period so long as
the changes being implemented have been thoroughly date and process tested. Frankly, all a
long ban on production changes does is make sure that the current environment works now.
It does not guarantee any kind of successful transition to the next century." Having
made all the arguments against moratoria, the evidence shows that IT departments will be
imposing them. The received wisdom is that they are a valuable part of contingency
planning no less. But for all the potential dangers they represent, one thing is for sure.
There will be plenty of work for IT employees to be doing in the meantime. Ian Barrett of
Bull Information Systems’ millennium and euro practice department suggests two main
areas: "If companies are planning a moratorium this only need be on going-live.
Development work can and should continue. Additionally there are two further topics that
should be addressed at this time."
Code inspection
The first is Y2K code inspection. "There have been significant advances in automated
toolsets since the first ‘scanners’ were used to find date-related code. Finding
a reputable third party with current inspection technology can enable an IT manager to
dramatically increase his confidence, and that of his Board, that his code is
‘safe’," Barrett explains. This can be done either before full testing, to
improve the effectiveness of testing or after the test and fix phase to ensure that fixes
have been properly applied.
"In fact planned and repeated code inspections could be used in any situation where
strategic compliant systems have to be further modified between now and 2000.
Additionally, code inspection can be used to demonstrate due diligence, that is to show to
shareholders, suppliers and customers that an organisation has taken all possible steps to
ensure compliance," he adds.
The second area is in preparation for the euro. Many Boards in the UK are now turning to
their IT managers for an understanding of the cost of euro compliance. "Although euro
compliance has to be addressed top-down as a business-issue, rather than an IT issue, some
decisions will be made on the basis of how currency-intensive the existing applications,
packages and systems are. Organisations should be able to make use of the in-depth
knowledge their Y2K project teams have gained," Barrett says. Alternatively if code
inspection has been performed using a tool that builds a repository holding information
about the source code then the same repository can be re-used in aid of euro compliance.
Anyone reading moratoria as holiday, has been warned! |
|
