Just as the three little pigs chose three very different approaches for building a house, IT managers pick diverse paths when they tackle application modernization. Whether they desire a simple cosmetic user-interface change or a complete application and architecture redesign, there's room for seizing opportunities as well as smashing into obstacles. The challenge is to keep the big, bad, outdated wolf at bay.

Many articles have been written about the technological options available to help modernize a legacy application. Here, I take a step back and focus on the kinds of agreements between IT divisions and businesses that can help establish a solid foundation and provide the necessary direction for the development and implementation of an application modernization project. Sometimes it takes a combination of huffing and puffing to face the issues awaiting both sides.

The Business Perspective

What return on investment (ROI) can a company modernizing its IT architecture and application environment expect? At one end of the scale is the underlying program with an added modern interface that is supposed to make the user community happy. Actually getting there, however, often means a greater investment in training and support. At the other end of the balance rests a new application architecture to manage and new technology to support, the usefulness and lifetime of which have yet to be proven in an ever-evolving marketplace.

Left in the middle, the business should be concerned about the real value that an application modernization project provides. What is the impact on the bottom line, and when will that jolt occur? The demand for IT resources and technology is always bigger than the supply. As one job is being accomplished, other projects must wait. So, exercising careful evaluation and organizing your priorities are mandatory to ensure that your business gets first what it needs most.

To that end, it is valuable for companies to establish a business case and identify the actual drivers behind their program modernization efforts:

• Business needs: Legacy applications dictate current business processes, leaving no room for improvements or further development, in turn negatively affecting the company's bottom line.
• Technical needs: Application technology is no longer supported nor scalable to the extent needed to meet current and future business requirements.
• Operational costs: Running the old program has a measurable negative impact on IT resource spending.

One or preferably more of these factors must exist to justify an application modernization project. At this point, it is critical to carefully evaluate the possible alternatives. For example, should you acquire a standard application or start new development from scratch? Which option would actually provide the most value to the business compared with the effort and resources involved and the estimated payback? Also, what criteria and parameters should be involved in reaching the eventual decision?

Strategy or Hitchhiking?

Identifying these factors and streamlining the decision process can at times be daunting. Not all businesses have a well-devised, updated, and communicated strategy. Although there are many good reasons for managers to invest in developing, maintaining, and communicating a formal business approach, in reality you may have a more informal agreement describing perhaps the three to five most important goals. Regardless of the format, this information is crucial to IT managers as they plan and make decisions about the modernization project. An IT strategy provides the necessary foundation to ensure that the IT plans and investments are aligned with those of your business and that everyone knows your target and priorities. As the saying goes: If you don't know where you are heading, any direction will take you there.

If the business leaders decide to pinpoint their three most important goals, you can create a document describing the three IT initiatives that will reinforce these objectives. It is important to secure ownership and support for any modernization plan in case a conflict or problem emerges in the future.

Modernization Only?

The legacy application you are about to modernize was developed many years ago to meet the demands of your company at that time. Those needs have likely changed dramatically, and the efforts you have taken to adapt the application may have added a significant amount of complexity and perhaps introduced barriers to future maintainability.

The existence of complicated business rules that no longer provide any value, of handheld procedures evolved beyond system support, and of changes in your organization and its skill levels all contribute to the obsolescence and depreciation of a legacy application. That's why optimizing the business processes is a very useful and recommended approach early on in a modernization project.

Keeping the Lights On

As a first step, you must justify your current application environment and then move forward to revitalize the aspect that promises the best return.

Your company can

• re-create a current application
• move a legacy application from a mainframe to a more tractable, standard-based framework
• exchange custom-designed code for packaged code
• integrate aspects of the current environment with newer programs
• remove applications that are no longer beneficial

Depending on the scale and extent of your modernization effort, your enterprise will also need to focus on your IT staff's ability to support other ongoing business and IT activities as well as the current daily operations and maintenance. The latter is known as the lights-on requirement, which is a measure of the resources necessary to keep your operation running while new and mission-critical applications are being devised, developed, and implemented.

At this point in the process, you might wonder about outsourcing. Projects involving new technologies, new skills, and the demand for a large number of resources rightfully deserve consideration in the area of outside support. In fact, every external contribution providing insight, comprehension, and knowledge — be it in the shape of experience, references, education, or the like — provides an invaluable foundation to help plan and prepare for any project covering new ground. The question remains at what cost and to what extent.

Although outsourcing all or part of a mission-critical application modernization project might help, it also means that the skills and knowledge for a great deal of the project would remain with your outsourcers and perhaps establish a future dependency. Failing to stay on top of the project could lead to cost increases, a poor-quality solution, the missing of critical deadlines, and ultimately the failure of the project itself. Trying to manage outsourced and in-house activities with the same key staff members could create a bottleneck that's challenging to overcome.

The in-house team members capable of providing background knowledge and performing necessary tests as a project develops are often the same people who are also deeply involved in running the daily business. It may be difficult for them to find the time to control an external development project while up against a calendar already fully devoted to regular duties and activities. It is therefore critical to plan carefully and communicate timely information early on to prepare the organization. Doing so will help ensure a smooth migration and modernization effort while minimizing the possibility of business disruption.

Gain or Pain

The application modernization procedure is also a learning process. Factoring in the achievements and the knowledge that emerge along the way can be an important contributor to a successful outcome. But you must allow the time necessary to do the iterations required to integrate them.

So, regardless of the execution model you choose, the careful planning, monitoring, and reporting you complete will help you make well-founded and documented decisions up front. If anything goes wrong, the solid foundation you have developed will ensure that you are well prepared to adjust and adapt to the new situation and stay in control as well as maintain credibility with your management team.

Assess the risks involved in the project and what could happen if something goes awry or if delivery is delayed. Be sure to take into account the impact on both cost and sales budgets if your planned activities are not completed on time, as well as the effect this would have on marketing campaigns that rely on the facilities and functions being delivered punctually. If you prepare for critical situations well ahead of their possible occurrence, you will have spent your time well.

Deal or No Deal

Once you have settled the issues just described and are ready to launch the deal, you can create a Project Initiation Document (PID) to ensure that the agreement and its consequences are clear to the business in particular and to the people involved in the project in general. A PID should record the following considerations:

• Project background and objectives: Why are you initiating this project, and what are its specific purposes? This includes a detailed description of the benefits that the business will gain from the outcome.
• Project scope: What will be delivered, and even more important, what will not? This should reflect the agreement achieved with the business. Part of the scope is also a specification of the IT systems or interfaces involved in the process.
• Project resources: Who is involved, and what are their roles in the project? Who is expected to either participate or make resources available, and when are those efforts due?
• Project deliverables: What stages are on the list, and when is each stage expected to be finished? You should plan for many smaller deliverables, ensuring an ongoing flow of completion. Doing so will give you advanced warning if it appears that you will exceed your time schedule.
• Project plan: What are the detailed tasks necessary to tackle each stage of the project? This should outline the time each step is expected to take, how dependent one job is on another, and who is responsible for completing each duty.
• Project details: What critical constraints, assumptions, conditions, risk assessments, and evaluations are crucial to the project? What are the software license and hardware acquisition requirements?

Taking Off

Once the managers of your company have signed the PID, the deal is settled, and you're ready to begin your application modernization project. To ensure a good start, the business and the user community must become fully involved right away to take ownership and ensure commitment. Close collaboration and focused communication are key factors in motivating the participants to invest the time and efforts necessary for success once the mission is completed and the ROI is due.

Carsten Flensburg is a System iNEWS technical editor and has been a System i programmer since 1992. His focus areas are modular system design, API programming, system integration, and communication. Carsten currently works as a System i application development manager for a European vacation rental company called Novasol, which is a part of the U.S.–based Wyndham Worldwide Corporation. You can reach him at Flensburg@novasol.dk.