On my first day as CIO at a company I worked for a few years ago, my first meeting was with the chief financial...
officer and CEO. The purpose of that meeting was for them to lay out for me the vision they had for the company's information systems. At the time, the company's suite of business applications was about 25 years old and lacked the capabilities that could help it compete effectively.
As the architect of those legacy applications, the CFO expounded on their rich set of business rules and the outstanding way they handled complex transactions. As he waxed poetic about their wonders, the CEO interrupted to admit that the systems had done an admirable job supporting the organization for a long time, but now served only as a barrier to moving the business forward.
"Use what you can," the CEO advised, "but don't make saving the system a primary objective. We must have better information about our customers, channels and products; and I don't think the current system will ever be able to do that, or do it well."
With those marching orders in hand, I set off to determine what the company needed and what it could afford for the short term and the long term. First, I decided that I needed answers to a series of questions: What would it take to replace the legacy functions? Was doing that worth it? What could we rationally modernize and reuse? What legacy features did we need as the foundation for our future?
In searching for the answers, I discovered a great deal about modernizing legacy applications. Here are some of the lessons I learned:
Get someone else to do the work. My approach to modernizing legacy applications begins with seeing what the vendors can do to update them. A couple of years ago, I inherited an application that was unable to access the Internet or work with mobile devices. I talked with the vendor and laid out some compelling reasons why the Internet was here to stay and why wireless soon would be ubiquitous. Chief among those reasons was that adding Internet and mobile capabilities to the application could extend the life of the company. I even threw in an offer to be the pilot customer for the newly refurbished application. The vendor finally agreed, and I got an application that aligned with my current and future business needs.
Standardize away the wackiness before you modernize an application. Fortunately for me, in this case we had not customized the application, which made the application modernization process easier. If it had been a customized or acquired application, I would have had to move to my next decision point by asking another series of questions: How much of the customization can I standardize? Are there compelling business reasons why we need to do standard things in a customized way? Do our customizations handle exceptions that we now rarely experience?
No matter what modernizing of applications needs to be done, it should always begin with simplifying and standardizing transactions, business rules, processes, features and functions. If I am going to invest the time and resources to update legacy systems, I should invest only enough to cover the basics for my ongoing success. As a bonus, I might consider standardizing a homegrown application to where I could replace it with an off-the-shelf system.
Standardizing and simplifying legacy applications before modernizing them is not for the faint of heart. But there is usually a reason for doing so, sometimes just to accommodate some wacky business rules. I like to start with credit to collections, procure to pay, financial close to reporting, and other horizontal processes, and ask why we need to do these things differently from the way the rest of the world does. Do we use our procure-to-pay process to gain market share? Do our sales presentations tout our superiority in sending out invoices? If not, there really isn't a compelling reason to customize the associated business rules or applications.
Decide the best way to deploy an application. Today we thankfully have a much broader set of options to consider for deploying an application. For instance, depending on how successfully you have simplified a legacy application, you can replace it with something newer; create a homegrown application; or, employing a type of Web service architecture, pick and choose the legacy modules and components that can be reused and connected to what is available from others.
Modernizing legacy apps
For example, one CIO told me he modernized his applications by segregating the code base into two categories. One category consisted of an application's unique features, which he then architected to match his service-oriented architecture (SOA) standards. In the other category were an application's features that he could get elsewhere. His modernized applications then linked his internal, SOA-compliant modules with a set of Web-based services. The result was a complete application refresh that did not require him to redo everything.
Be innovative while learning from others' experiences. Because application modernization is fraught with risk, I like to balance my own creativity while learning from others' successes. This requires me to network with others and ask them how they approached modernization. Learning from others has helped me avoid dead ends, death-march projects and outright failure.
Modernizing legacy applications is no fun, and almost always involves some level of pain. By first simplifying, then exploring the various implementation options, however, we can survive the experience.
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at firstname.lastname@example.org.