Continue in 2 seconds

The Year 2001 Problem

  • April 01 1998, 1:00am EST

We've all heard many times about the calamity that is expected to occur when we reach the Year 2000. If our information systems aren't fixed, doomsayers seem to predict that it will be the end of the (information technology) world as we know it. Accounts payable and accounts receivable systems will miscalculate the age of the payables and receivables. Credit cards won't work properly. Interest calculations will be incorrect. Airline reservations systems will have wrong dates. And so on. In reality, if this problem isn't fixed, the actual impact it will have on the world at large is anyone's guess. But, since the potential problems loom large, it's far better to fix the problem now than to wait until the Year 2000.

No one would argue the point that the problem needs to be fixed. However, I would argue against the way most organizations are approaching the solution. From the discussions I've had with a fairly large number of organizations, and from what I've read about how other organizations are handling the Year 2000 crisis, one thing seems clear--the focus is on the operational systems. Granted, these operational systems are generally the mission-critical applications. By definition, the organization could not function at all without them working properly, so the sense of urgency to fix these applications is totally understandable.

The Other Half of the Problem: DSS

But, the operational systems are only half the problem. The other half of the problem involves the myriad decision support systems that give end users the information they need to make strategic decisions about nearly every facet of the organization. Without these DSS systems, the organization might not collapse immediately, but it would simply be a matter of time before it began falling apart.

Think about it this way. As organizations follow their current path toward fixing the Year 2000 problem, they are spending large amounts of time, money and human resources to either modify existing operational systems or replace them with entirely new applications. But, every time you change one of these systems, you almost always also change the data file formats. You either change the format of a particular field (such as a date field), or you add new fields. Changing these formats has a ripple effect on all the other systems that are fed by the operational systems, most notably the decision support applications. It's your DSS applications that read and analyze these data files; and if you change the format of these files, your DSS applications will either break outright or they will give you spurious, meaningless results. All of your DSS applications will be looking for data in the old format and will be confused by the new formats. Everything from your oldest COBOL reports to your newest, interactive, GUI-enabled end-user analysis tools will be affected. The result? As you fix your operational systems, you will break your DSS systems.

The Year 2001 Problem

To you as an individual, the Year 2000 might mean that you'll be a little hungover on January 1, 2000. (Or, possibly January 2 as well, if the party was really good.) But, for your DSS systems, it might mean a hangover that will last far, far longer. If the problem isn't addressed beforehand, the main issue we'll be facing immediately after the Year 2000 crisis will be broken DSS applications. Hence, I call this the Year 2001 problem. And, unlike a hangover, it's not the kind of problem that can be fixed with a large pot of strong coffee. Instead, it will require an effort equivalent in scope and scale to the current efforts focused on the OLTP half of the problem.

Data Warehouses Can Help

Obviously, in reality, the Year 2001 problem should be considered an integral component of the Year 2000 problem. As such, it is clearly better to solve the problem before it occurs than to react in crisis mode in the early months of the year 2000. How can we effectively address the problem? Fortunately, one of the best solutions involves building something we're already familiar with--a data warehouse.

First, we can leverage the consolidation aspect of a data warehouse. Currently, most organizations have a completely unintegrated decision support environment. Typically, a large organization will have dozens of disparate systems (including statistical tools, spreadsheets, report writers, graphing packages, etc.), each of which was designed without regard to the overall IT environment. Many were just "quick and dirty" applications that never seemed to die. Others are stovepipe applications that are inflexible and expensive to maintain. Many of them are now out of date, and nearly all of them are undocumented. These applications will all require updating and consolidation.

Rather than modifying (or replacing) each of these DSS applications individually, it is far more efficient to build an integrated environment. Doesn't this sound like a great use for a data warehouse? In fact, it is. Not only does a data warehouse allow you to consolidate data from many operational systems, but it also allows you to consolidate your disparate decision support applications. And, while building this new consolidated environment, you can make all the changes necessary to solve the Year 2001 problem.

A second way that data warehouses help solve the Year 2001 problem is that they isolate your decision support systems from changes made to your operational systems. The isolation occurs via a well-defined interface between the two environments; namely, the extract/cleanse/transform/load processes that link the environments. Once you are aware that your data warehouse will be affected by the Year 2001 problem (because the operational systems that feed it will be changing), you can take precautions to ensure that your extract/cleanse/transform/load routines will be flexible enough to handle the changes in data formats within your operational systems. This means that you can build your warehouse now and be assured that it won't need major modifications when the operational systems are modified for Year 2000 compliance.

Solve Both Parts of the Problem

If you really want to solve the Year 2000 problem, then there is no way to do it other than to fix both the operational and the decision support systems. You cannot close your eyes to the decision support component, for that will lead you into the Year 2001 problem. As I discussed, a data warehouse is a great way to address these issues in a proactive fashion. Fortunately, many of you already have a data warehouse in place, so you are already well on your way to solving the problem. If your warehouse is scalable, then it should be flexible enough to handle the changes required for Year 2000 compliance. For those of you who do not yet have a warehouse project in place, the Year 2001 problem may be the impetus that management needs to fund the data warehouse project you've always wanted.

Many people fear that the Year 2000 problem will negatively impact data warehouse initiatives as more resources get channeled into modifying the operational systems. But, almost counterintuitively, most recent studies show that this is not happening. Realizing the magnitude of the problem, management is expanding the IS budget to include placing resources on the operational system modifications without impacting the warehouse initiatives. This is good, solid, long-term thinking that will pay off in the end. I'd have to assume that many of these companies already implicitly recognized the Year 2001 problem. Now all that's left to do is find a good party on December 31, 1999.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access