Why Do Legacy Modernization Initiatives Fail?
“Modernization,” or “Legacy Transformation/Modernization” is one of those catchy business propositions that everyone agrees with. Who does not want to modernize? The term “legacy” connotes rigid, difficult to maintain, and almost impossible to change without a long highly costly engagement. Legacy pertains to systems and applications that are either home-grown or point solutions that were acquired and extended. Legacy also deals with the increasingly aging baby boomers that are approaching retirement age. Maintaining legacy systems will become increasingly expensive as the knowledge to upkeep legacy solutions is also retired with the workforce. Costs, as well as agility for change, are the main driving forces for legacy modernization and transformation.
Yet, many modernization efforts in the private and public sectors fail. For example, a recent memorandum by Peter R. Orszag - Director with Office of Management and Budget (OMB) - indicated “Federal Information Technology (IT) projects too often cost more than they should, take longer than necessary to deploy, and deliver solutions that do not meet our business needs.” He was speaking about IT projects in general. However, modernization and legacy transformation is a substantive percentage of IT budgets these days.
This is a two part blog. In this first installment we identify some of the main reasons why legacy modernization or transformation efforts fail. In the next blog, we will show how BPM Suites - both in platform and methodology - prove the best approach for successful legacy modernization / transformation.
So why do modernization initiatives fail?
The reasons are basic and go to the core of what it means to modernize. Here I would like to cover some of the more basic and core reasons why modernization efforts fail. These reasons are not orthogonal or mutually exclusive. Often failure is the result of the combined effect from two or more of these reasons.
Big Bang Modernization Initiatives: Often with the best intentions huge and expensive initiatives are launched with modern architecture paradigms - especially with Service Oriented Architectures (SOA). These big bang SOA projects typically deploy an Enterprise Service Bus (ESB) and attempt for instance to expose as services large numbers of legacy interfaces - with no clear business objectives. Long duration, complex, ESB can be overkill - a solution looking for a problem. A lot of effort is spent on architectural integrity - mostly paper-ware, model-ware, with little or no immediate benefits. In other words a bottom-up approach focused almost entirely on modern SOA plumbing. SOA architecture patterns have their place and are often essential. But overhauling large collections of applications with a SOA stack from the bottom up, layer-by-layer, with no top down justification or rationale is the wrong approach. A modernization initiative needs to think big but start small introducing incremental business value. Large rip-and-replace monolithic initiatives cannot keep up with the iteratively changing business drivers, federal mandates, and compliance requirements. There needs to be a clear roadmap of inexpensive incremental modernization steps: balancing business visibility and ease of implementation. (More on this in the next blog.)
Equating Modernization to Modern Languages, IDEs, Components, and Platforms: Large organizations often have millions of lines of legacy code. The code is written in older languages such as PL/1, COBOL or C. There are also many examples of code written in proprietary languages such as SAP’s ABAP. Some modernization initiatives have attempted to replace, or extend/expand legacy (e.g. COBOL code) with more modern language coding: with languages such as Java and C#. These languages and companion component frameworks are hip. The problem is that object-oriented or component coding is still coding! The business logic is still embedded in the code and its cryptic for the business. There are little or no business transparencies. There are definitely productivity improvements in going from structured languages to object-oriented languages, tools, components or frameworks, for IT. IT resources often love these languages and platforms. Paradigm shifts - such as modernization through BPM (and more on this in the subsequent blog) are often rejected at inception. These “modern” programming languages do have advantages and provide a lot of flexibility. The problem is that they provide value for IT - not business-centric modernization, aligning business with IT. When is the last time you saw a business stakeholder go through Java code or use Eclipse?
Ignoring the “Human” Participants in Modernization Initiatives: As the previous point illustrated, usually modernization has been equated with IT modernization in the overall enterprise architecture stack. An end-to-end business solution also involves human participants. Actually, often legacy systems, ERP systems, home-grown systems or even modernized versions of these elevate exceptions to humans. Managing exceptions can be the majority of the effort in an end-to-end process and these are thrown to humans with no governance, automation, or enablement. In other words, if you take the total effort involved in, say, resolving a customer or citizen request, just focusing on the operational or system areas without looking at the automation or enablement of the human participants who handle exceptions, results in partial and incomplete modernization - focusing only on the systems. How about the usual processing of tasks (vs. the exceptions)? Well, here you have the flip side of this “human” dimension: the resistance to change. Since employees are trained on familiar (“legacy”) systems, replacing them without understanding how the modern solution will make their lives easier, results in an inherent resistance to change. Also, approaching “modernization” with the same data-centric mindset that still requires business users having to be dependent on desktop procedures, knowledge management, and having to use and learn multiple siloed systems will not bring the most business value out of the initiative. This could jeopardize the success of the project. So ignoring the human participant will put the modernization initiative at great risk.
Ignoring Governance and Center Of Excellence for Modernization: At the end of the day no initiative can succeed without oversight and governance. This is an obvious statement - but often a core cause of failed modernization initiatives. As the previous three reasons suggest, modernization initiatives are complex. They involve many legacy systems, home-grown solutions, legacy extensions, undocumented code, and a maintenance nightmare. That is the ‘fait accompli’ side. Then you have the stakeholders: IT who wants to have modern architectures and languages; a diverse user community some of whom are dissatisfied with the current status of solutions yet others who are wary of “new” solutions and change in general; and perhaps most importantly you have the business frustrated with cost overruns, delayed projects, and systems that cannot keep up with business objectives. The larger the initiative (aforementioned Point #1), the more difficult its governance. If a modernization project takes too long, by the time the project is finished it no longer meets the needs of the business stakeholder. Modernization needs a center of excellence (COE) with specific governance involving best practices, prioritization, and project monitoring. The COE provides overall oversight, prioritization of modernization projects, and continued enablement for best practices. Modernization projects will have much less of a chance for success without an established COE that oversees the people enablement, the processes for best practices, and the prioritized modernization solutions.
These are some of the main reasons why modernization efforts fail - often with devastating results. Modernization has an important organizational dimension. In a modernization initiative business needs to be empowered to directly capture their objectives and make changes. IT and business need to speak the same language and need to come together to build as well as deploy solutions with tangible business value. That cannot happen with big bang IT projects; or just with modern languages; or lack of support for cases and human empowerment; and definitely it cannot happen without governance. It can happen with a modern, complete BPM Suite and the accompanying methodologies to incrementally transform the organization: thinking big and starting small with business and IT together for tangible high business value results. More on this in Part 2.
History is replete with such inventions which never saw the light of the day until a market-savy individual understands its potential. Hindered by the slow spread of information and uncertain financing, a stereotypical eighteenth century inventor toiling for months in his underlit laboratory might achieve too little or too late.
