Businesses today must continually innovate or face shrinking market share by competitors who are ahead of the curve.

Innovation can take many forms, depending on your business, but agility in Information Technology is often critical to delivering new services and products and to connecting via new channels or markets. At the same time, many businesses are reliant on legacy systems that cannot easily meet these emerging needs.

And yet the legacy systems that many organizations depend on are not easily replaced, not without risk to the business. They may have grown with the organization and have information structures and embedded processing logic that is crucial to the unique products, services, and delivery mechanisms employed by the business. Highly skilled, long-time technical staff may be needed to maintain the system and keep the business operational.

So, how do you move forward? How do you maintain smooth operations and innovate to meet your business' demands? There are many options, but identifying the best approach involves an assessment of your current enterprise applications portfolio, agreement within your organization on where you want to go, and many other factors. One size does not fit all when it comes to legacy asset management and transformation, but you can craft a plan that will take your systems and business forward on a safe and continuous path.

So What Is a Legacy System?

Traditionally, we've used the term ERP (Enterprise Resource Planning) to identify enterprise software packages with integrated modules in key areas such as financials, distribution, and manufacturing that perform operational and transactional functions of the business. In most cases, ERP systems have originated from a software vendor and may be on maintenance with upgrades and support. Some organizations have enterprise applications designed and developed in-house that handle some or all of the functionality of an ERP package. Still other organizations may have started with an old ERP package from a software vendor but have completely taken over maintenance themselves to the point that their business application suite has become "home grown." In this situation, even if the vendor is still offering newer versions of software, your application may have diverged so far from the base package that an upgrade is not feasible.

Any of these scenarios might describe the origins of your legacy systems. An application suite that is uniquely designed and customized for your business, possibly built using older languages and tools, and that has evolved and morphed over many years can be very difficult to replace with commercial off-the-shelf (COTS) software.

Consider the lighthearted "might just be a legacy system if" list in the spirit of Foxworthy's redneck jokes. Does any of this sound familiar?

You might just have a legacy system if some of the following are true:

• The original application was implemented before Al Gore invented the Internet.
• Your users can have any user interface they want as long as it's text-based, 24X80, green on black, and navigation is handled via menus and function keys.
• Special program code has been written to handle unique customer requests over the years.
• Occasional operational issues must be addressed by using DFU to fix the data.
• Simple maintenance tasks require a long-tenured programmer with deep knowledge of the system.
• You have to study a full area of the application for three weeks before changing a field value and still use a subroutine to do it.
• The maintenance backlog is growing, but programmers are too busy troubleshooting operational issues to ever get the business requirements handled, 
• Your team is fairly sure that some subroutines or programs or files are no longer used, but not certain enough to delete them

(Continue the banter on Twitter with #mightbelegacyif.)

On a more serious note, MC Press ran a survey of RPG development shops a couple of years ago. Some of the findings of Thomas Stockwell's report are telling in terms of the challenges of legacy asset management in the IBM i world. For example:

• "Sixty-five percent of those surveyed said that maintenance deadlines were missed on a yearly basis, with 19 percent saying they missed deadlines two or three times a month."
• "Thirty-eight percent said that upper management considered the cost of maintaining code to be too high."
• "The results of the survey indicate that—as frustrated as management may feel—the maintenance programming staff is even more acutely frustrated."
• "22.4 percent of programmers said the modules they were maintaining were unstable."
• "Managing the code of our information systems currently appears to be consuming the majority of our time as programmers and managers."

So, for many IT shops consumed with managing their legacy systems and day-to-day operations, there's very little time for innovation and improvements, which may lead to the business falling behind.

Technology and Business Drivers for Transformation

Why do you need to transform your legacy application? It's important to identify the driving force for taking these important steps forward from both an IT and a business standpoint.

From the perspective of IT, the primary drivers or considerations for transforming legacy systems typically involve…

• The ability to deliver applications to users via current interfaces, such as Web, Windows, mobile with social media integration, and whatever comes next.
• A modern application architecture—ensuring componentization, reuse of logic and centralized business rules, and service-oriented access to key business functions.

Commercial drivers for application portfolio transformation can vary, depending on the nature of your specific business, but they generally include product and service strategy improvements and some assessment of future markets/opportunities. For example, business priorities may require some variation of the following:

• Online interfaces for customers and partners to transact business directly with in-house systems
• Mobility access to some subset of functionality for the roaming workforce
• Productivity increases via improved processing, workflow, and access to information
• Electronic interchange solutions, often conforming to industry standards or mandates
• Improved quality of customer and supply chain interactions through advanced technology
• Executive information and analysis

The challenge for IT in formulating the plan is that the business may provide budget or requests only when specific needs arise, whereas a CIO must anticipate what those needs might be and proactively navigate the system's landscape in order to have the architecture and tools in place to deliver.

Approach

Your unique technology and business drivers for transformation will be important to identify so that you can ensure commitment and alignment within your organization for the challenging, and sometimes costly, road ahead. As a leader in technology within your company, you will be better able to both assess and sell your plan for transformation if you develop a cost/benefit analysis for your options.

Consider the following approaches for transformation. In some cases, your best plan may actually incorporate elements from more than one of the options below.

If you have both the mandate and the budget to replace your legacy systems, then you may be evaluating some large-scale, higher-risk options such as the "rip and replace" or "Big Bang" approach to transformation. Alternatively, if you have limited budget or are more risk-averse and prefer "evolution" over "revolution," you should consider approaches to transform or modernize your legacy system in stages toward a brave new world, using some combination of the above options.

Coexistence

Regardless of your specific transformation plan, there is typically a need to manage your legacy system (in full or in part) for a period of time while you are implementing new functionality. To ensure that your mission-critical legacy applications continue to operate in a stable fashion and that appropriate integration points are established while you implement the new system functionality, you must ensure that you have planned for coexistence.

Some considerations for planning your coexistence strategy:

• Logic Reuse—"Wrap" business functions to create a callable service layer. We used to call these APIs; now, if you can wrap them as a Web service, we can call it the beginning of a service-oriented architecture (SOA). Regardless of what terms you use, the idea is to isolate areas of logic that can be reused in multiple areas and interfaces (such as Create Order, Calculate Price, Create Policy, etc.) Ideally, the callable routines will be separated from the legacy interface so that the old programs also use the centralized service and they are maintained in one place. (This is not going to be necessary for full-scale replacement obviously.) Of course, if this functionality undergoes changes, you will have more regression testing to do when a shared component is used in many areas of your system.  
• Maintenance—Can maintenance be frozen in the affected modules? If you are embarking on a project that will convert or integrate heavily with an existing module, the project will be a moving target if the dependant legacy application is changing at the same time.
• Database—Analysis of the existing database (whether it can be reused or will need an overhaul or a new design) will need to be assessed and planned up front. Changing an underlying database that a stable legacy system relies upon can increase the risk of the project, especially if it is done in a haphazard manner. In some cases, a new database will be implemented, but a synchronization engine will be built to keep the business in sync during the coexistence phase.
• Navigation—If partial areas of a system are being replaced or refaced, some planning for how users will navigate between different areas will be required. Ideally, they should be able to move seamlessly between their working areas, if possible. Otherwise, prepare for your users' training (and frustration).
• Testing, Pilots, and Running in Parallel—Testing and Implementation are critical components for any project plan, but when coexistence between an existing legacy application and new module are interwoven, more care must be taken beyond just the base functionality of your new area. Plus, regression testing may be required at every stage if shared modules are established between existing and new modules.

Building Your Plan

Your enterprise applications should be under constant evolution beyond the ongoing maintenance activity to consider the strategic direction of both business and IT. If you have fallen behind but now have a clear mandate to transform your legacy environment so that you are in a position to better meet business needs, then you must build your plan and take action.

Assessing your current enterprise application portfolio is an important first step in formulating your plan for transformation. Many legacy applications do not have good documentation, and the knowledge of how the systems have evolved is primarily in the heads of the IT experts who manage the systems.

Building your transformation plan should involve the following analysis:

• Assess and inventory your current enterprise application portfolio. There are good analysis and documentation tools on the market today that can help with this effort if required.
• Analyze your Information Technology (current tools, platforms, and skills). Do you have the infrastructure and tools needed to deliver the required solutions today and in the future?
• Consider your business and IT drivers. Where do you need to go? Establish your goals for the next year, two years, five years.
• Categorize modules by priority, complexity, suggested approach(es).
• Assess resources. Do you have sufficient resources to both manage your legacy application and work on transformation activities? How will IT staff keep up with the skills and tools—old and new—required to deliver the level of application innovation and agility required today? Will training or outsourcing be part of your plan?
• Determine risks and inefficiencies with the existing system. Is manual intervention required by skilled IT staff to keep the system operational? Are you losing customers to competitors due to anything lacking in the system? Can you save money, or make money, by effective use of technology?
• Analyze your Return on Investment (ROI). Perform some analysis based on your desired transformational improvements to identify how the company will benefit financially over time.

With a clear understanding of where you are and where you want to go, you will be in a better position to make decisions on your best approach for moving forward. Talking to the business' users and management to understand their priorities will be critical to crafting your plan and determining what must be tackled first.

The level of organizational commitment, the state of your current systems, the available resources and budget will be key factors in determining how you move forward.

Risk assessment should be undertaken, both in terms of the risks you face today by doing nothing and the level of risk that your organization is comfortable facing with regards to your legacy transformation initiatives. Of course, a well-honed plan with an exceptional project leader, capable team members, and a supportive corporate culture will go a long way to mitigate risks.

Recap

The challenge faced by IT organizations to keep up with the maintenance demand can become a risk to business. At the same time, executives expect IT not only to maintain a stable business environment while reacting to frequent changes, but also to ensure the company stays competitive in the industry with e-commerce, Web Services/EDI, and operational/business process improvements such as workflow, mobile solutions, social media integration, and whatever comes next.

To move forward, a plan for legacy management and transformation should be established based on an understanding of both your business and technology drivers. Determining your strategy will require an assessment and inventory of current applications and to some extent, a re-discovery of your business requirements for your application portfolio. In this way, you will be armed with a solid base to build your plans and the system you need for the future.

Transforming a legacy application into a modern, services-oriented, flexible application architecture takes commitment, focus, budget, and effort. It doesn't happen overnight. There are no silver bullets. But gains can be made during the transformation to meet tactical business needs, which will get easier as you move forward. In some cases, a well-designed legacy system may live on for a very long time in the back-end with appropriate transformation and modernization plans. In other situations, full-scale replacement might be the ultimate goal. Regardless, you can get started today. The result will be well worth it and can position your organization as a leader within your industry.