Please feel free to forward this newsletter to as many friends as possible. I have a personal goal of reaching one million readers. I can achieve it with your help.

  the Software View: What, me worrY2K? or How I stopped worrying and learned to love the Year-2000 problem. (Part IV)

Welcome back, gentle readers. For those of you with Web access and a Netscape Navigator browser, please click here:
http://www.softwareview.com/
Scroll down the page and you will notice a link entitled, "Daily view weblog". The daily news page is also known as a "web log". It is en vogue and the fashion of these days to call it that. Click on the link, click "reload" on your browser or clear your browser cache to ensure that you always receive the freshest, hottest daily news concerning Java^TM, Linux, XML, and the software industry! The link never changes, but I will be updating the HTML file page behind it every day. Please, do take a gander at it every day.

Also, gentle readers, the Software View is an Associate Internet World Wide Web site of Amazon.com. I'd like to extend my sincere, heartfelt gratitude and thanks for your patronage. I'm offering links to books, et cetera that you can purchase from my web site. I'd greatly appreciate it if you would purchase software industry books from my web site. Help support my newsletter and web site by purchasing items from Amazon.com from my web site. Here is the URL (Uniform Resource Locator):
Click here

Now, dear readers, on with this week's episode of the Software View!

The Internet and World Wide Web are special cases. Applications might fail. Operating systems might fail. Servers and switches might fail In fact, there might be minor service blackouts all over the Internet, seriously affecting Internet-based businesses. Yet the Internet as a whole might stay functioning. After all, the idea behind the original Internet was to provide a highly redundant system of communication for military purposes. It still has that redundancy. Whether an Internet with ten percent of its infrastructure out to lunch can support the current levels of traffic is an open question, however.

BIG PRINCIPLES

Some forty percent of American companies are dragging their feet concerning the Year-2000 problem. But don't panic; even though you probably can't accomplish everything in time, there are still some definite steps you can take to help your enterprise survive the big odometer roll-over. In fact, there's a school of thought that says you're lucky you're late: You haven't had to put up with buggy remediation software, green inexperienced consultants, and immature strategies.

Indeed, Year-2000 fixing is now a seasoned field. Software is tested and effective; consultants have a proven track record and clients you can investigate; and there are standard methods for handling each situation. So stop drifting and stalling and get working.

The first principle of getting through the Year-2000 problem successfully is that your enterprise must survive. This might seem obvious, but it's the set of implications of this that're disturbing. For example, it's not important that your information technology department or computer systems survive the Year-2000 problem. (Yes, you are reading this in the Software View!) It's more important that your enterprise survives. Ideally, of course, you want both to come through unscathed. This might involve outsourcing some or all of the processing you do. It might even mean using manual and paper-based systems.

Another implication of this is that you might have to spend a pile of money. But you might "not" have to. Many clever enterprises have found ways to simplify their Year-2000 projects and get them done more inexpensively than experts have thought possible. For instance, just by using a customized version of Micro Focus's Revolve, Kemper Insurance slashed a $40 million estimate to about $700,000 for its forty-million-line-of-code databases running on an Apollo mainframe.

The second principle that you must accustom yourself to is reality. This isn't one of those Hey-when-can-I-get-that-new-feature?-Oh-I-will-get-to-it-next-week-type development projects. You need to do real planning with real numbers and real information this time. It might turn out that you can't be ready in time, even after spending a reasonable amount of money and devoting a reasonable amount of effort to the project. If so, you need to know that and start looking to Plan B from the start. The one thing you don't want is to have a warm, rosy glow about the project, toss Plan B, and find out in November 1999 that there's no way you can finish in time.

Your enterprise's fate is in your hands. You must have the highest amount of confidence possible in anyone in whose hands you place your enterprise. And put more faith in your own Plan B than in anything that you're trusting any outsider to do.

Possibly the most vital part of reality is enterprise-wide support. Everyone in the enterprise must know that the Year-2000 Problem survival is a priority. This is especially true for members of upper management, who would often just as soon ignore the problem and concentrate on "business as usual." By funding necessary Year-2000 Problem projects, they might get to keep their enterprise. By stalling or ignoring the situation, however, they risk losing it all.

THE COST

While at first it may seem almost preposterous that two missing digits can wreak so much havoc, it becomes clear just how large the problem might be when you think about the many places that dates are used and referenced within computer programs. Obviously, the problem is real, and something must be done - but what? And how much will it cost?

Luckily, we do know how to prevent Year-2000 fiascoes, although it isn't easy. First, you have to find all the hardware and software that might be affected. Then you have to decide whether to replace it or fix it. Then you have to make sure your fixes work by testing and integrating new software with code that may have been written before many of your existing staff were hired.

The actual cost of achieving Year-2000 compliance will go far beyond analysis and conversion costs, however. Production delays, reduced market share due to poor public relations and media reports, and the loss of profitability or important data will all affect companies. Once the dust has settled and everyone is compliant, another ugly chapter will unfold: the search for culprits within companies, and the search for corporate accountability by shareholders and victims of accidents or other losses.

Reports indicate that the United States government is budgeting $30 billion for conversion, and Fortune 500 corporations have ear-marked between $20 million and $200 million each for Year-2000 conversion projects. The vast majority of these budgets exclude the cost of litigation, which could exceed that of conversion unless there is government intervention.

In small- to medium-sized companies (those with between five to one hundred information technology staff), minicomputers and desktop personal computers form the bulk of hardware inventory. However, the impact of Year-2000 will be as great at these companies as in mainframe environments, although the problems will often be more difficult to address. Apart from the widespread, decentralized nature of desktop personal computer computing, many small- to medium-sized companies run older software and hardware.

It is estimated that only thirty percent of these companies will be even close to fully compliant by the big day. Among those that have a head start, the chain reaction of upgrading software, then the operating system, and then the hardware as well, is occurring much more often than originally anticipated because of overlooked desktop personal computer programs.

Even well-informed information technology managers at large corporations are struggling to justify Year-2000 conversion expenditures, especially when only fifteen percent or so of the costs will provide visible performance increases or advantages. Many decision-makers are hoping that they will retire or be promoted before the crunch comes; others are minimizing estimates in a desperate attempt to get financial approval now - with the intention of revising their budgets later. It's likely that many companies will experience serious financial difficulties due to delayed or partial solutions to a very real problem.

Experts continue to be amazed that the financial directors of many companies are still looking at the individual cost to their organizations, assuming that they can wait now and absorb the expense in existing maintenance budgets later on. However, at that late stage the industry's ability to supply staff people may be outstripped. Truthfully, 1997 was probably the last year when larger companies, especially those in the financial industry, could or should have commenced work on their Year-2000 compliance projects and emerge unscathed. For the rest, triage management will come into play, often calling for some very tough decisions. In fact, many problems will still occur at such office sites due to lack of testing and/or poor integration.

Even mature information technology departments often lack the necessary short-term project-management infrastructure to coordinate such a tight, yet wide-ranging, project. New initiatives are unsettling to legacy infrastructures with established methods, and it takes time to implement new lines of communication, set and agree on priorities, establish standards and procedures, allocate or redeploy staff, and synchronize schedules.

Without positive leadership from senior management, a surge of denial and redelegation of responsibility will be a common reaction. Solving your Year-2000 problem involves making tough choices, improving procedures, meeting deadlines, and automating routine tasks. It's an opportunity for staff to take a constructive look at all aspects of operations, and an opportunity to implement up-to-date techniques. As a result of Year-2000 projects, new design approaches, such as automated modeling and business-rule repositories, are being introduced to established information technology departments that have not seen change since COBOL was invented. Legacy staff suddenly have to lead small teams of new programmers with fresh methodologies and ideas. Although the overall effect of the Year-2000 issue is likely to be negative, there are positive aspects as well.

Year-2000 solution providers in the code-conversion component of the project will have a tremendous advantage after the crisis is resolved, when their roles and relationships to the company will be reviewed. These firms and individuals will have access to user code, design, and database schemes, and they will have the staff at hand to maintain these systems. Inventory and system knowledge will have been transferred to them because of the Year-2000 crisis, at least in part. This may shake up the hierarchy in some organizations, to the benefit or detriment of individuals involved.

STAFFING

The single largest factor affecting timely Year-2000 compliance is staffing. Good intentions, money, and time aside, the project will still fail without competent staff. Not only are programmers versed in older languages required, but expert project leaders and managers capable of coordinating the complexities of simultaneous multi-system conversion will be needed at all levels.

The later a Year-2000 conversion job starts, the smaller the pool of available resources will be. This situation is compounded by the fact that the later the job starts, the more staff will be required to do the same work. You'll need extra hands not only to meet the looming deadline, but also to overcome redundant, duplicated activity due to the late start. The law of diminishing returns definitely applies: Every new person on a project adds another group of communication links, and every new developer compounds version control and testing.

Resource requirements increase quickly once decisions are reached, peak at testing, and then gradually fall off. Unfortunately, in the case of Year-2000 projects, the completion date is as fixed as the earth's orbit around the sun. Moving the project completion date ahead will not be an option when staff shortages occur.

TIMING

It can take as long as a year for a large company that recognizes the need for a conversion project actually to begin work. The date manager who starts investigation today could easily find that he has less than a year to complete conversion, testing, and migration by the end of 1999.

To make timing even more difficult, some vendors are behind schedule on Year-2000-related changes, including revisions to systems software. If an enterprise is wholly focused on its own conversion project, it may have insufficient staff left over to test and implement new software from vendors, especially if revised versions are full of additional features and functions.

THE SOLUTION

The first step to solving Year-2000 compliance problems is identifying the programs, hardware, and storage components that will need revision.

The next step is determining the most cost-effective way to make each item on that list compliant. Often software upgrades will be dependent upon hardware upgrades, and some short-term solutions will be cost-effective only for a brief while.

When it comes to Year-2000, the general opinion of many system vendors is "upgrade or you're on your own." Upgrade-ripple, where a new version of software requires new operating system and hardware upgrades as well, is going to be a reality for most office sites.

APPROACHES TO THE YEAR-2000 PROBLEM

Most companies start their Year-2000 planning by looking at software conversion. They must first decide whether to expand data files or to leave them as they are and try to solve the problem by coding. These two methods are often referred to as the "data" or "logic" approaches.

The logic approach is sometimes called the "window" approach, because it tries to define logical windows within which the century must be either "19" or "20". This method attempts to minimize the amount of conversion in a system by working only with expanded dates in localized sections of the system.

LOGIC/WINDOWING VERSUS DATE-FIELD EXPANSION

In simple terms, when you use the logic or windowing technique, you leave the two-digits (stored) years alone and add software code that determines the century "on the fly" (while the data is being processed). There are several ways to do this.

One windowing method is based on parameters, either hard-wired or derived from input files. A base year, such as "50" for the year of 1950, is selected. Then every year between 50 and 99 is treated as a twentieth-century date (1950, 1951, etc.) and any year between "0" and "49" is treated as a twenty-first century date (2000, 2001, etc.)

CONSIDERATIONS FOR COMPARISON

The data approach starts with expanding any date-related data field, then modifying all code, screens, and reports that use the newly enlarged field. This solution is the most robust and durable, but it can also require more work.

As explained above, the windowing or logic approach seems so simple. Why would anybody want to take the much more difficult and time-consuming route of changing both the actual date data and the applications, when simple code tricks could suffice?

To be continued ...

Sincerely,
Mark Kuharich

Join my free e-mail newsletter called the Software View by clicking here or by sending an e-mail to thesoftwareview-owner@west-point.org