reprint from: Y2K Opportunities [1]by Bob Fabian & Bob Hopkins The reality is that the year 2000 problem cannot be ignored by any organization that wants to stay in business. We depend on systems and equipment that are "sensitive" to dates, and may fail on or about January 1, 2000. Fixing the problem is the price of staying in business. Unfortunately, the required solutions may provide few other benefits. Stand Still Solutions The first choice for many organizations was to use enhanced replacement systems to address the year 2000 issue. This involves replacing "legacy" systems with packages or new custom systems which are Y2K compliant. The new systems will also provide improved functionality. This is an attractive strategy, but still leaves the problem of changing the technical infrastructure and testing the overall solution. These latter tasks are considerable in themselves. Many organizations have found that they have no option but to convert major applications. Either there are no viable replacements or there is not enough time to complete the installation. There are a large number of organizations in this position. Allied Signal decided that its $50 million SAP R/3 project would not be installed in time to fix the Y2K problem. They are forced to fix code that will eventually be replaced. The Toronto Stock Exchange made headlines when it was forced to adopt a similar strategy that involved renovating legacy systems. The cost of renovating legacy applications will be high and, in most cases, it will be a stand still strategy. No new functionality will be introduced, and resources will be drained from all other tasks. Testing alone will require sophisticated approaches and is likely to require more than half of the overall effort. All this, … to just stay in business! Spin Off Benefits Some of the effort involved in renovating and testing the major applications can be reused to provide a spin-off benefit. Web enable the applications and reuse the Y2k testing framework. The potential ROI can be very attractive. There are a number of reasons why providing web access to legacy applications can make excellent business sense. The IP network may already be in place - the incremental cost of a new network service will be low. Browsers and IP access may be in widespread use, so training and support costs will be low. Everyone knows how to use a browser and all the critical software is in one place (on the web server). People inside and outside the organization can have access to current information and can directly provide information required by central systems. The reported ROI for such projects has ranged up to several hundred percent per year. Reusing the Y2K testing effort could provide an even more dramatic ROI. The bitter Y2K pill gets a sugar coating that can make it much easier for the organization to swallow its millennium medicine. Providing broader and more friendly access to internal staff is no longer an issue. Many organizations have installed intranets and have resolved whatever technical problems they encountered. Access by third parties, through an extranet, may still be an issue. But here as well, the technical problems and business issues are being addressed. Important concerns are the security and reliability of IP networks, and the dangers of "further tampering" with legacy applications. Questions about security are basic. First, an internal IP network can be isolated from the external Internet. Firewalls protect internal services from prying external eyes. For internal use, a web browser is no more dangerous than any other device connected to the network. External access can be controlled. Issuing certificates to acceptable external users allows the organization to restrict access. The level of security is superior to that obtained by working with user ids and passwords, and providing access through dial-up telephone connections. The connection, even to external users, can easily be made secure. Reliability is a more complex issue, but with a careful choice of Internet Service Providers, the level of reliability can be very high. There is only a minimal need to tamper with legacy applications. In the Y2k project, input/output transactions may not be changed, but the testing infrastructure must accomodate all of the formats for input transactions, queries and reports. Transactions from the web can be reformatted so they appear to be identical to those from the legacy application. The same approaches can be appled to both queries and reports. The legacy application does not need to see any changes except a possible increase in transaction or query volume. The risks associated with providing web access to legacy applications are modest and controllable. The Right Solution? This approach is not right for all applications. Time-critical applications may not be able to accept the uncertain response times of the Internet. People are working on ways to provide a guaranteed level of service over the Internet, but today there will be occasional delays. Even if time-critical applications are excluded, there remain a large number of applications that might take advantage of this approach. If you have a candidate legacy application, there is a simple initial set of steps that should be followed:
Assuming it does make sense to proceed, the size of the resulting web access project will vary. It will depend on how many users are to have web access; on where those users are located; on the complexity of the required business logic; and on how much of the required infrastructure is already in place. In most cases, the cost of developing web access to a legacy application will be low and, as explained, most of the required testing is covered by reusing the Y2K work. This can be one of the more attractive system opportunities for organizations faced with the need for a major Y2K undertaking. With the right people, the risks can be held to a low level. The rewards can lead the way to a whole new approach to the use of corporate information. It's an opportunity that many organizations should carefully consider. Bob Fabian is an independent management and systems consultant. He brings to this opportunity an extensive knowledge of legacy applications and of the technology required to support web access to legacy applications. Bob Hopkins is Principal with Western Management Consultants. He brings to this opportunity his considerable project management experience and his experience with Y2K conversion projects for legacy applications. [1] Copyright by CIO Canada. This is a reprint from the July 1998 issue. Reproduced with the permission of CIO Canada. top |