Distributed Systems challenge: are you ready? - includes related article on mitigating Y2K risk in distributed systems - Industry Trend or Event

If your business users rule their PCs, and if documentation barely exists, you'll be far from ready. Here's how to change that situation.

Countless organizations, large and small, have one thing in common: They have tended to put year 2000 problems in distributed computing environments on the back burner and deal with them as late-stage, low-priority tasks. Also, in many centrally controlled client/server environments, PCs and networks that reside outside of the IT organization's control have largely been treated as stepchildren by year 2000 project offices. Numerous smaller organizations that use PCs exclusively and lack a formal IT function have been guilty of ignoring the year 2000 problem all together. But if year 2000 problems in distributed environments are not addressed, organizations will experience major business disruptions that will be like "death by a thousand tiny cuts."

Companies and government organizations have tens of thousands of desktop and client/server systems running business functions around the globe; the U.S. Internal Revenue Service alone has 130,000 personal computers. Distributed systems are used for research, financial management, customer-related functions, order processing, marketing, point-of-sale management, hotline support, Internet site management, and a wide variety of other tasks. If these systems are not identified, upgraded, and certified for year 2000 compliance, they will cause unanticipated problems.

The biggest risk associated with addressing the year 2000 distributed systems challenge is that it is largely undefined. End-user departments, frustrated with attempts to get IT to meet rapidly changing business requirements, have created poorly documented islands of technology that have grown out of control. Finding and fixing year 2000 problems in a mainframe environment, where configuration control is commonplace, is a much more quantifiable task than performing this same work in a distributed environment, where it could take months of research across disparate business units to uncover the existence of distributed technology.

In many industries, business units have created mini-IT organizations that capture mainframe data and distribute it to a multitude of end users. In the financial services industry, for example, spreadsheets spring up like wildfire. Extensive system-to-system data interfaces further complicate these environments. Considering these complexities and the difficulties required in addressing them, it is important to temper distributed system remediation efforts based on the business criticality of the particular application. This requires close coordination between the central project office and business units that rely on these systems. Anything less could result in a poorly controlled initiative, where non-compliant systems pose a threat to business continuity.

Y2K Myths

Many myths surround the year 2000 problem in distributed systems. In order for problems to be solved, we must first dispel the myths.

Myth 1: Year 2000 is a mainframe-only problem.

PCs, and distributed applications in general, were built based on the same legacy, two-digit year field data used on mainframes. The erroneous concept of the year 2000 problem being isolated to older mainframe applications was spawned by the popular press two or three years ago. In regions where year 2000 awareness is high, such as the U.S. or U.K., this myth expired long ago. In other parts of the globe, however, managers have held onto this outdated belief.

Myth 2: PCs are year 2000 compliant.

Year 2000 problems can be found in a variety of PC hardware, operating system software, and application packages. The chart on this page highlights Y2K reliability for the Basic Input/ Output System (BIOS) that controls low-level PC computing functions. A BIOS made prior to 1997 is likely to fail a Y2K test 97% of the time. Additional testing concluded that almost half of the BIOSes made in 1997 failed a Y2K test. Failure, in this case, means that a PC set to a date that goes beyond 1999 will reset itself to 1980, 1900, or some other incorrect date. PCs may also not recognize 2000 as a leap year. These failures can destabilize software, network, and business functions relying on a valid system date.

Operating systems and application software are at the same level of risk as their mainframe counterparts. For example, Windows 95, in its native format, requires a year 2000 patch. PC users must upgrade to newer versions of a variety of popular software products to ensure that these products function properly once the century date rolls over. The good news is that most larger, mainstream software providers have posted compliance information on their Web sites. The bad news is that many users of these software products are just beginning to review the situation and may not have the time or resources to ensure that these upgrades take place.

One additional consideration is that compliant software products that utilize date windowing routines may still lead to user-related problems. Microsoft Excel and Access, for example, use a fixed-date window for determining if a two-digit year field is in the twentieth or twenty-first century. A two-digit date greater than "28" is considered to be in the twentieth century, which could be problematic for 30-year mortgage routines. Lotus 1-2-3, on the other hand, assumes two-digit dates to be in the twentieth century according to a report in Computer Reseller News. Data exchanged between these programs could readily be misinterpreted unless users specify the full four-digit year something rarely done today.

Myth 3: Client/server systems are year 2000 compliant.

Several vendors have warned that certain Unix operating systems, once thought immune to the Y2K problem, must be upgraded to compliant versions. Client/server and Internet-based environments depend on these operating systems, along with numerous other off-the-shelf utility packages. The hardware itself, including routers, workstations, and communication technology, may also need to be upgraded or replaced.

Off-the-shelf upgrades may only be the tip of the client/server problem. Custom code, written in C, C++, Visual Basic, or other proprietary languages is likely to contain date logic that does not properly interrupt dates across the century boundary. One application team found that a new C++ system, fully designed to be century-date compliant, took two-to-three months of debugging to get the leap-year logic working properly. Complicating this issue is the fact that there are fewer tools available to facilitate year 2000 compliance upgrades in client/server environments.

Myth 4: Distributed system failures have little business impact.

The C++ system referred to above happened to be the-front end of a mission-critical reservations system for a major airline. Had the system not been identified and debugged before the year 2000 arrived, it would have shut down reservation services for a period of weeks; at the cost of millions of dollars.

The financial services industry processes massive amounts of currency data using spreadsheets. Senior executives make key decisions using desktop systems. Salespeople manage customer databases using PCs. Marketing departments recycle mainframe data to drive market research. And the Internet has spawned countless new ways to deploy PCs in business-critical situations.

Myth 5: Fixing distributed systems is easy.

For the standalone computer user, finding, testing, and upgrading PC hardware and software may be just an annoyance. The situation for a firm running dozens of networks and thousands of PCs and operating in numerous physical locations is more problematic. One major insurance company committed 15%, over $40 million, of its year 2000 budget to ensuring that distributed systems function beyond 1999. The process of finding, assessing, and upgrading these environments could take years and require large, dedicated SWAT teams.

Myth 6: Microsoft has things under control.

When asked about the year 2000 problem at the Seattle-based Microsoft CEO Summit held in May 1997, Bill Gates told attendees that "PCs are in good shape in this respect." His statement helped stall executive awareness-building efforts and caused year 2000 managers to throw up their hands in frustration. It is also curious in light of the fact that Microsoft did not post product compliance data on its Web site until April 1998. When challenged about the delay, Microsoft year 2000 strategy manager Jason Matusow told VNU Business Publications, "It would have been more damaging to have released information that is not correct-it would have set people off in the wrong direction." It seems, however, that Mr. Gates did just that over a year ago. Microsoft has classified its software into five, year 2000 compliance categories:

1. Compliant (though a free patch may still be required)

2. Compliant with issues (includes Windows 3.x)

3. Not compliant at all

4. Products still require testing

5. Products that will not be tested

A review of Microsoft's product compliance status, which is posted on its Web site, should convince anyone that PCs are not immune to the year 2000 problem. It should also convince anyone waiting for Microsoft to deliver a quick, year 2000 fix that this will not happen.

Establishing a Plan

Building a plan to address distributed system Y2K risks is necessary for all companies. The plan incorporates many tasks that apply to large Y2K projects, but must be adjusted to meet the nuances of the distributed environment. The main goal is to build a plan that enables the central project office to work with business units to incorporate a standard approach, personnel, skills, and tools on the project. The plan includes an awareness strategy, a process for completing the inventory, analysis, remediation and testing effort, vendor management, staffing, and deployment of tool-equipped SWAT teams.

Building Awareness

Communicating awareness of the distributed systems challenge across disparate business units is essential because a high degree of cooperation is required to complete the distributed systems analysis, upgrade, and testing. The task falls on the in-house Y2K communications coordinator with support from executive sponsors to ensure that the project is taken seriously. Awareness building includes:

* Posting information about distributed and desktop risks on internal Web sites.

* Publishing a list of potential risks in internal newsletters.

* Notifying and meeting with senior business-unit executives.

* Ensuringthatayear2000 business-unit coordinator is assigned to own the year 2000 problem for each business unit.

Staffing and Budget Requirements

Points of contention in organizations arise when deciding who is going to fix the distributed systems year 2000 problem and who is going to pay for it. The business unit owns the problem and is part of the solution. Fixing the problem should be assigned to joint teams of business-unit coordinators and SWAT team analysts working with end users to ensure year 2000 compliance (see sidebar, "Mitigating Y2K Risk in Distributed Systems," pg. 24). The project plan should reflect the time and effort required from those SWAT teams as well the end-user involvement that will be needed.

Budgetary considerations should not delay a distributed systems year 2000 project. If business units typically cover these expenditures, then distributed system upgrades should be included in annual technology budgets for that business unit. Other organizations may wish to pay for distributed system upgrades out of a central budget. One key consideration is that companies can gain a tax advantage by positioning PC hardware and software upgrades as capital investments that can be depreciated over time. The bottom line is to not let money become a hindrance when addressing this problem.

Distributed Systems Assessment and Correction Process

Management and business-unit executives should agree to the process required to mitigate year 2000 risks in distributed systems prior to deploying that process. This is an important consideration because the process will be deployed in multiple locations by a multitude of business and IT professionals. It should include the following:

* Guidelines for inventorying and assessing distributed systems compliance in desktop systems.

* Guidelines for network administrators responsible for managing client/server compliance.

* Guidelines for centrally compiling hardware and software compliance data using a database or repository.

* A definition of standard assessment and correction tools required for this project.

Tool & Technology Support

Once responsibilities and guidelines are in place, analysis and remediation work can begin. The PC tools chart shown on page 26 lists software tool categories and vendor support available for addressing year 2000 problems in distributed systems. Most of these tools can be distributed via Internet or intranet facilities to facilitate distributed tool utilization in remote business units. A brief definition of each tool category is provided below:

* Inventory tools scan PC hardware devices and related networks and produce complete lists of the commercial software running in that environment.

* Configuration management tools, or control and monitoring software, typically run on a network and track versions of products and application files being used by a given user and hardware device. Monitoring tools determine if a non-compliant software product has been added to a PC or server environment.

* BI0S test and fix. A number of tools can scan BIOS technology for year 2000 date problems and indicate if they can and should be patched or if the machine must be replaced, as would be the case for most 286, 386, and some 486 PCs. A subset of these tools can correct the BIOS problem.

* Commercial software analysis tools can scan desktop or client/server environments, identify commercial software running on that environment, compare version numbers to a product database and produce a report, highlighting non-compliant software requiring an upgrade.

* Client/server applications analysis tools provide impact analysis on C, C++, Visual Basic, Oracle Forms, PowerBuilder, and a host of other client/ server languages. Some also support the code remediation process.

* Data analysis (for spreadsheets and databases). Select tools can review, and in some cases correct, spreadsheet data and distributed database environments and provide compliant usage information to the users of those environments. That includes the identification of two-digit year fields that may default to an unexpected fixed window.

* Application testing. Testing tools support the interactive analysis of client/server environments in much the same way as do mainframe testing tools. Functions include interactive analysis, debugging, and data aging.

Desktop 2000 Projections

Desktop systems will take a big hit in 1999 and 2000 if end users and business-unit executives are not cognizant of the year 2000 problem or willing to spend time resolving it. If this occurs, organizations could suffer major productivity or monetary losses linked to widespread failure of distributed systems. Management must aggressively pursue these activities now, since vendors will encounter backlog problems in 1999. For example, if tens of thousands of companies all try to replace outdated PCs in the latter part of 1999, there could be a shortage of PCs running well into the year 2000. Software vendor distribution channels could experience similar delays.

Ideally, the business units should be the ones driving the distributed systems year 2000 project. Regardless of who drives the project, there is no time to lose in addressing this piece of the year 2000 puzzle.

                                      FUNCTION

                                       Change          BIOS/
                                      Control         Realtime
                      Software       & Package         Clock
COMPANY              Inventory       Monitoring      Test & Fix

Greenwich
Mean Time            Check 2000                      Check 2000
gmt-2000.com

Intersolv               PVCS
intersolv.com

IST
Development
Inc.
iscinfo.com

Mercury
Interactive
mere-int.com

NeoMedia
neom.com

PinPoint            ClickNet Y2k                    ClickNet Y2k
Software
pinpt.com

Platinum            TransCentury                    TransCentury
Technology            Office &                         Office
platinum.com          AutoXfer

Ravel
Software
unravel.com

StarBase                           StarTeam 2000
starbase.com

Viasoft
viasoft.com         OnMark 2000                     OnMark 2000

WRQ                 Express 2000                    Express 2000
wrq.com

                                      FUNCTION

                                   Client/Server        Data
                     Commercial     Applications      Analysis
                      Software        (e.g. C,      (databases,
COMPANY               Analysis        C++, VB)     spreadsheets)

Greenwich
Mean Time            Check 2000
gmt-2000.com

Intersolv
intersolv.com

IST                                                IST Year 2000
Development                                            Packs
Inc.
iscinfo.com

Mercury
Interactive
mere-int.com

NeoMedia                                           ADAPT/PC-2000
neom.com

PinPoint            ClickNet Y2k
Software
pinpt.com

Platinum                            TransCentury    TransCentury
Technology                             Office          Office
platinum.com

Ravel
Software                            Unravel 2000
unravel.com

StarBase
starbase.com

Viasoft
viasoft.com                         OnMark 2000     OnMark 2000

WRQ                 Express 2000
wrq.com
                        FUNCTION
                      Applications
COMPANY                 Testing

Greenwich
Mean Time
gmt-2000.com

Intersolv
intersolv.com

IST
Development
Inc.
iscinfo.com

Mercury              WinRunner 2000
Interactive
mere-int.com

NeoMedia
neom.com

PinPoint
Software
pinpt.com

Platinum              TransCentury
Technology               Office
platinum.com

Ravel
Software
unravel.com

StarBase
starbase.com

Viasoft
viasoft.com           VIA/AutoTest

WRQ
wrq.com

RELATED ARTICLE: PC Labeling Strategy

RED

PC that must be replaced

ORANGE

PC that requires BIOS upgrade

YELLOW

PC that requires commercial software upgrade

GREEN

Compliant hardware/ software that requires user application testing

Physical labeling of PCs is the quickest way to ensure that Year 2000 risks are highlighted and mitigated.

Source: Tactical Strategy Group Inc.

RELATED ARTICLE: Mitigating Y2K Risk in Distributed Systems

Here's how SWAT teams may be deployed to work with business units to assess and correct year 2000-related problems in distributed environments.

1. Perform pre-project setup.

* Assemble SWAT-team analysts and train them in assessment process and tool utilization.

* Identify business-u nit executives and outline requirements for the desktop assessment.

* Assign business-unit coordinators to manage year 2000 tasks within each business unit.

* Business units should identify distributed technologies, by location, under their control.

* Establish a central database that can cross-reference platform, commercial software, and location data.

* Finalize budget responsibility for the desktop assessment and upgrade project.

2. Inventory and assess year 2000 impact on distributed systems.

* Deploy SWAT teams regionally to work with business-unit coordinators to inventory and assess desktop systems.

* For each PC found in a business unit, run inventory/scanning software, collect compliance status on the system, and upload this information to a central database.

* In the absence of scanning software, SWAT teams can reset PCs (once data is backed up) to a post- 1999 date to determine if date settings function properly.

* Software compliance status can be obtained by accessing vendor databases provided with various inventory tools (see chart, pg. 26) or through vendor research cam piled by t he project office.

* Label each physical PC red, orange, yellow, or green (see chart, this page) indicating hardware upgrade status, BIOS status, and software compliance status.

* Provide a summary of the distributed systems compliance results to senior business-unit management.

* Outline timeframes for upgrading hardware, BIOS technology, operating systems, and commercial software.

3. Assess and upgrade distributed client/server environments.

* SWAT teams should work with distributed client/server network coordinators to ensure that operating environments are year 2000 compliant.

* SWAT teams should train network coordinators in the use of client/server language assessment and upgrade tools.

* Project office should help coordinate outsourcing of remediation work for custom-built client]server applications as needed.

4. Upgrade hardware and software.

* Project office should coordinate major vendor upgrades centrally to get the best upgrade price and verify if the vendor must provide free year 2000 upgrades.

* Non-compliant PCs should be scheduled for replacement as soon as possible.

* Business-unit coordinators should order compliant software upgrades for that business unit and should oversee the upgrade process.

5. Test applications and integrated environments for compliance,

* Project office should post guidelines for ensuring that spreadsheet and database data is utilized in a compliant manner focusing on two-digit date-field utilization.

* End users should test spreadsheets and databases to ensure that they are being used in a compliant manner by entering post-1999 data and reviewing results.

6. Implement compliance-monitoring process.

* Project office should ensure that the distributed systems inventory provided by SWAT teams is kept current via ongoing procurement procedures.

* Business units should deploy monitoring software (see chart, pg. 26) to track noncompliant software upgrades occurring between now and 2000.

COPYRIGHT 1998 Wiesner Publications, Inc.
COPYRIGHT 2000 Gale Group