Page 1

From Legacy to Live

How to avoid throwing out the baby with the bathwater Mitigating risk while modernizing IT systems in the Utilities industry


Summary

The Utility sector remains in the midst of a major transition. The pressures of this transition are putting many utilities into seriously competitive, market-driven situations where the customer experience becomes a primary differentiator. This is occuring at a time when capital projects are in limbo due to credit markets and rate relief requests are beging reduced significantly. Utilities are addressing these and other challenges by implementing new business models that are supported by new technologies. New technologies do not necessarily mean completely new hardware/software investments, however. With capital at a premium current thinking is to modernize existing legacy IT systems to handle the new demands. Legacy applications often contain decades of business process refinement and value. Installing a completely new system would be the modern equivalent of “throwing out the baby with the bathwater.” Modernization (keeping the baby) retains value and can actually increase the ROI of core applications by supporting business process improvements offered by new technologies on open system platforms. However, failure to plan effectively for modernization can be devastating to an organization’s viability. This paper reviews the current applications modernization solutions available as well as 10 tips for legacy rejuvenation.

An industry in transition The North American public utility sector remains in the midst of a major transition. In many markets, the traditional cost-based, fully bundled service model is being replaced by unbundled, market-based or performance-based pricing. Regulated distribution utilities are focusing more on mechanisms and procedures for purchasing services from wholesale suppliers, rather than constructing capacity. Mergers, acquisitions and divestitures are commonplace. In the past, utility companies had very limited interactions with customers. Apart from opening new accounts and billing for services, the relationship was remote. The utility of the future can expect a much more intense level of customer involvement – conducting business 24 hours a day, seven days a week, 365 days a year, with internet--savvy customers who will be able to receive pricing signals and control their utility usage, as well as shop among utilities for the best prices. As younger customers begin their relationships with utilities, they bring expectations of a digital, mobile, and collaborative customer service experience.


These pressures are putting many utility providers into seriously competitive, market-driven situations where the customer experience becomes a primary differentiator – at a time when the economic crisis is throwing capital projects into limbo and fuel price fluctuations are leading everyone to question the fundamentals. In addition, many utilities saw their rate relief requests reduced significantly – a sobering trend for the industry. Utilities are addressing these and other challenges by implementing new business models that are supported by new technologies. As a result, expectations have never been higher for the role of information technology (IT) in improving the customer relationship and increasing internal efficiencies. While advances are being made on many fronts (automated metering, energy efficiency, customer cooperation, market deregulation, asset management, and enterprise management), some rather formidable challenges remain. The transition is not without risk. Tremendous amounts of data will be acquired in real-time, stored, and maintained. Privacy laws and regulations will emerge just as they did in the telecommunications industry. Organizations must create strategic plans on how to share information with customers and other stakeholders. In a world of unlimited capital and unlimited time, the assumed best solution might be to start over – creating a new IT architecture with new hardware and software. But, this is the modern equivalent to “throwing out the baby with the bathwater.” With capital at a premium current thinking is to modernize existing legacy IT systems to handle the new demands. This way, the “baby” is retained and enhanced by new technologies on open system platforms.

From Legacy to Live Utility legacy IT platforms can be either a safe haven – or a beacon of inefficiency – in today’s environment. As a safe haven, legacy systems support important applications, services, and data. As a drain on organizational efficiency and profitability, they can consume more time, money, human resources, and physical space than their modern counterparts.


With capital expenditures limited, many utilities are asking how to retain the value and perhaps even improve the ROI of core applications. The Aberdeen Group summarizes it this way: “Today’s pressure on IT departments to use existing resources cost-effectively continues to increase… the answer is to leverage existing business-critical applications and information more effectively.” Areas under investigation include providing better access to data, re-using tried and tested business logic to deploy services within a Service Oriented Architecture (SOA), and/or moving these applications to more cost-effective hardware. The goal is to reduce legacy costs, mitigate the risk of system failure, and transform the legacy platform to become part of a modern infrastructure. The options can be categorized as: Replace, Re-develop, or Modernize. Replace. Replacing the legacy applications with a new “packaged solution” may initially seem the most attractive route. However, the experience of many utilities has been that significant modifications have to be made to a so-called “packaged” solution, which frequently extends the time and cost of the project. Add to this the learning curves for technicians and users, and the Utility is presented with project that will impact its daily operations and its cost structure for a period of time. Re-develop. Re-development has the compelling promise to deliver a solution that will meet the new requirements and still leave the organization in control of its IT direction. However, re-development is without question the most risky, and probably the most expensive, option to take. There are many horror stories of re-development projects lagging well behind the published schedule or costing significantly more than planned. With resources committed to the re-development, existing systems are left with little or no maintenance resource. This forces the IT team to either cut corners to speed up delivery, or escalate costs by throwing more resources at the project in the hopes of finishing it more quickly. Modernize. Application modernization is rapidly being seen as the most viable alternative to the slash-and-burn approach of replacing existing applications with packages, or through grandiose re-development projects.


The principles behind modernization are based on the optimum retention of existing business logic and data combined with the marriage of new capabilities. These new capabilities might include: • • •

Enabling for e-Business Transforming the user interface, including Web enablement Changing the database technology

• •

Integrating with other enterprise systems Flexibility to meet changing business functions or models

Regardless of the option chosen, unless business processes have changed significantly, the minimum requirement of the new solution is that it does all the things the existing application does. Otherwise, the legacy application can never be turned off.

Process-oriented planning, tool-based implementation The decisions involved in modernization not only include the obvious (which applications, which platform, budget, timeline, etc.), but also need to consider all the other facets -- not simply the code conversion. These decisions are best supported by using a process-oriented approach for the planning. Some of the most experienced modernization vendors have developed and refined the process steps and offer specialist services to assist the Utility organization. In general, the steps include:

1. Determine business fit and cost of ownership It is important to understand the value of existing application assets to the business, the need for strategic investment, and the current total cost of ownership of each system before a clear modernization strategy can be determined. Many legacy applications, although rich in functionality, are difficult to modify, are less integrated with other systems and cost disproportionately more to operate. Additionally, if the application operates on a proprietary hardware platform this may be considered as an operational risk. There are a number of ways applications can be modernized to become more agile while continuing to maximize the ROI of the legacy application: •

Incrementally exposing core business functionality from the legacy applications as Services within a Service Oriented Architecture (SOA). These SOA Services can be integrated into new clientfacing applications such as .NET and Java/J2EE.


Consolidating legacy data sources into relational databases to enable easier data access, better reporting, and simpler integration.

Moving legacy applications from older proprietary platforms to more cost-effective and better performing platforms.

Moving to a modern development environment. Many development shops still use development tools based on “green screen” sessions (e.g. COBOL or RPG development). Modern development tools provide support for COBOL and other older languages.

2. Assess the current platform The long-term issues regarding the current platform should be addressed upfront. This entails looking at the current hardware and anticipating its future. Is it proprietary? If it is time to upgrade, might this be the time to move to an open systems environment? How many years of life remain in the hardware, operating system, and database? Does the organization have sufficient skills and resources to continue to support the hardware?

3. Detail the existing application The next step is application assessment. This usually starts with the completion of an assessment document that articulates the key details: current platform, numbers of programs, database used, integration points, third-party products used, etc. The assessment should also detail the business changes required and the preferred target technology landscape. The best modernization vendors have developed and refined these assessment documents and offer specialist services to help evaluate the best alternatives -- leading to a Modernization Roadmap to guide the project development.

4. Define the target environment If the recommendation is to move a legacy application off its current platform to a modern environment, more than hardware is involved. An assessment of operating system, languages, user interface, database required, third party products required, and how the application interfaces with other systems must be made. Taking a proprietary language to another environment is not all that difficult. There are tools on the market to do this (e.g. proprietary COBOL to .NET COBOL on Windows). However, if the wish is to convert the existing application code to another language (e.g. converting COBOL to Java or C#), the work becomes significantly more complex.


There are many issues to be defined: What will the architectural framework be? How readable and maintainable will the resultant converted code be? Does the organization possess the required skills? etc. Code conversion, particularly from a procedural language to an object-oriented language, is unlikely to be a fully automated process.

5. Scope the project and prioritize actions There is often the temptation to attempt to do everything at once during a modernization: change platforms, change user interfaces, change databases, improve integration with other applications, etc. The most successful projects are those that prioritize these activities and break them up into sub-projects in a way that each sub-projects can be delivered separately. The project scope must be documented in detail beforehand. This ensures that the strategy, tactics, and resources have been agreed upon and “scope creep� is eliminated, or at least minimized. The activation of a formal change request procedure, where implications are signed off by all project owners, reinforces this discipline.

6. Investigate modernization products and services With a Roadmap and detailed project scope in hand, the next step is to investigate the technologies and services available to best implement the project. Has a project similar to the one in your scope been done before, or is this project unique? What experience do vendors have in this area? Are there automated tools to assist? Modernization projects typically start off with very simple ideals, such as replacing a flat file system with a relational database. However, the choice of tools to achieve this can vary from replacing all of the existing I/O statements with embedded SQL (which is a time-consuming, laborintensive approach) to a middleware solution that is virtually risk-free, faster, and less expensive. Middleware tools differ in their architecture and it is vital to investigate them fully to ensure that the chosen solution will provide the performance and scalability required. For example, Legacy Liberator, a wellestablished and proven technology, automates the process of converting not only application code, but also the database, user interface, Job Control Language (JCL), and the data to a platform of choice. Component Adapters make the existing business rules and data in a critical legacy application available via a seamless, scalable, and nonintrusive interface layer (the Component Broker). This layer lies between


the existing application and new application modules, and the services can be exposed as J2EE compliant JavaBeans/JCA, COM/C# objects for use with Visual Basic/Windows .NET or XML-based Web services, for integration with new or other enterprise applications. An e-Toolbox framework provides a Web server and platform-independent template application. It uses the Component Adapters and Component Broker middleware to ensure that existing core business application services are integrated into a Web application with real-time, straightthrough processing.

7. Allocate resources People, money, time. Those are the resources required. Most projects will require a mixture of internal and external vendor resources. Internally, the key position is that of Project Manager (PM), who has overall responsibility for project success. Success is measured in terms of meeting all the project targets for effectiveness, budget, and schedule. In addition to coordinating and communicating with the equivalent PMs from the vendor side, it is the responsibility of the PM to ensure that the relevant application assets, the test plans, testers, and other resources are available when required.

8. Create a project plan The project plan is typically a team effort: drawn up in close cooperating with the vendor(s) and key internal personnel. Most project plans consist of at least four parts: • • •

Desired outcome (end-state objectives) Budget requirements Timeline showing project tasks and required resources to complete the task. Ensure that sufficient time is allocated to both vendor and user testing and at the end of each major milestone build in a small contingency. Detailed commentary on the tasks and responsibilities for the organization and the vendor(s). It should include the scope of the project, the success criteria, detailed steps of each project phase; the number of test cases the vendor is to carry out for each work package; the extent of final acceptance testing, and the acceptance criteria. In addition, the commentary should articulate how the project will be monitored and the project change procedures should the scope need to change during the project. Lastly, it is important to document what is not included in the project scope.


9. Execute the project Project execution not only requires technical skills, but also interpersonal skills to coordinate, communicate, and motivate the project team. It is essential that project managers keep on top of the tasks, particularly at the beginning. Quite often, internal staff continue to give priority to their “day jobs,” rather than focusing on project tasks. “Schedule creep” at the beginning too often leads to missing the deployment date at the end, unless considerable contingencies are built-in. Throughout the project, project managers should have formal progress meetings, bringing in technical team members as appropriate. It should be expected that each vendor PM will provide regular status reports for each meeting. Within the team, someone should be appointed to take meeting minutes, documenting decisions made, actions required, problems and the plan to solve them, etc. After each deliverable, it is all important to monitor any issues that arise from acceptance testing and ensure they are resolved in a timely manner.

10. Evaluate, learn, adjust Since the project scope and plan contains a definition of the success criteria, the performance against these criteria should be carefully evaluated. Typically, this is done in a “post mortem” where “what went well” and “what did not go well” are discussed and documented in order to learn from the experience. While the primary outcome of a successful project is usually economic (demonstrated by a tangible return on the investment), success if not always defined in financial terms. Other targets may be equally important: improved performance, ease of use (e.g. through a new graphical interface), improved data access, streamlined business processes, reduced errors, better support for sales or customer service, etc. Modernization of legacy applications can positively impact revenues and costs – allowing the Utility to extract additional economic return from existing investments while meeting the new requirements being placed on Utility IT.


Project Phase

General Tasks

Planning

Requirements Definition: Roadmap; High Level Architecture; Scope, Budget

Inception

Establish Project Team & Set-Up; Evaluation of third-party tools and services

Design

Architecture; Database; Prototypes; Test Plans

Technical Set-Up

Product Installation & Configuration; Tool Set-Up; Construction Procedures

Construction

Language Conversion; System Services; Database Build; DCL; Interfaces

Testing

Unit; System Testing; User Acceptance

Deployment

Documentation & Implementation


About Transoft Transoft, a leading provider of innovative and pioneering modernization solutions, helps clients maximize the potential of existing applications by safely moving these core applications to modern, open platforms while improving their functionality in the process. Transoft is part of IRIS, which has an exceptional reputation for delivering award winning, market leading solutions to more than 60,000 organizations worldwide. The technology and services from Transoft deliver rapid return on investment, reduced costs, improved productivity, and the ability to manage operational risk. Major organizations such as The Gap, L’Oreal, Boeing, Balfour Beatty and Christie’s, and thousands of other customers enjoy the business benefits of a Transoft application modernization strategy. We work with a large network of VARs, System Integrators, ISVs and technical partners.

Transoft Contact Information Here

White Paper: Throwing out the baby with the bathwater  

Client: Transoft Location: UK

Read more
Read more
Similar to
Popular now
Just for you