Truth About Legacy Software

The Global Problem of Old Software

(transcript of video)
Whether it’s COBOL, RPG, .Net or Java, or something far worse like Mumps or Fortran, aging software is less and less viable in today’s technology-driven world.

Custom enterprise applications that were coded in these languages followed an architecture that has rather suddenly, become outmoded. But before we look at why they are outmoded let’s just take a second to consider what happens to software over time.

Anyone who has maintained software has seen that the more it is changed the more complex it becomes. This is a universal truth and was described well by a Professor Lehman in his Laws of Software Evolution. For a given amount of incremental function, the cost of changing software to add that function continuously goes up over time, as does the schedule required to do it, and the risk associated with deploying it. It’s not a good formula.

This formula, unfortunately, does not sync up well with the pace of change in business today. With globalization, digitization of business, disruptions of markets by new technologies,  – and –  the consumerization of IT, an onslaught of new tools for IT, and making use of IT as a competitive weapon, trying to make legacy software meet all these challenges is simply not doable.

I’ve been involved with attempts to migrate legacy software to newer languages for nearly ten years now. The industry success stories are few. Here’s why I think that is: if you migrate one language to another, say RPG or COBOL to Java or .Net., even if you could cleanup the logic, which isn’t gonna happen, but even if you could clean it up, what you are left with is not that far from where you already were. You still have what I will call an old school architecture, and a pile of very complicated code. The value is not there.

So what is a new school architecture? This is a big discussion, but you can see the answer all over our website – it’s BPM. To understand why, let’s start from the top down, with a question that has been bouncing around IT for many years, build or buy?

Well, for most companies, the answer is now clear, it’s build and buy. Build custom software to differentiate your business processes that are strategically competitive for you, and buy software, cloud, site licensed, outsourced services, etc, where it is not strategic and you are best off following standardized best practices as economically as possible.

So the right answer is, build AND buy.

New Goals of Custom Software

Let’s talk about building custom software for a minute. What are important goals you should be thinking about? Here are seven really crucial goals for modern custom software:

Goal: Rapid time to market for applications: you must be able to get new software out the door quickly with a high degree of deployment success.

Goal: Quick to change: It must be easily and quickly changeable – the ability to change the software is actually more important than the ability to create it in the first place. Let me state the obvious, you will invest far more time and money over the years changing your software than you did to initially create it – typically by a factor of roughly five.

Goal: transparency of what the software does: the business processes and the business rules in the software must be visible and understandable throughout the organization; not just for programmers, but for all people with basic business skills

Goal: facilitate collaboration: IT and business users must work together throughout the process of creating or improving the software; by providing system transparency to the business users, they can now combine their business knowledge with systems knowledge and process improvement and innovation is greatly accelerated

Goal: be a platform for continuous business process improvement and innovation; this goal is largely built upon the goals of transparency and collaboration augmented with the universal capture of process metrics, analytics, and the ability to make rapid changes, combined with process improvement programs

Goal: rapid, fluid, transparent integration with other internal and external systems, cloud services, APIs and outsourced business processes

Goal: effortless, responsive UI deployment across all user platforms

These are key goals for custom software. Legacy software obviously meets few of these goals, and in fact most new applications created with traditional techniques do not meet most of these goals either.

When To Buy Software Instead of Building

So let’s talk for a minute about how buying software functionality fits into this picture. While it’s important to build excellent custom software, it’s equally important to not build it if you can buy it. When should you buy it? So let’s be clear what we’re talking about buying – we’re talking about buying software functionality that supports or executes business processes.

To answer a complex question in a simple way, you should buy functionality if that functionality is not key to your corporate strategy of differentiation from your competitors. If you are trying to stand out from your competitors, why would you buy off-the shelf functionality when software is such a crucial component in execution of business processes today?

By the same token, if a given business process is not strategic for you, you are much better off buying it off-the-shelf where it has been standardized into best practices with its cost spread over many users.

So here’s a question, inside the boundaries of your existing software, where do the strategic pieces lie and where do the standard pieces lie? That is a key question for how you approach replacing it. Ideally you would custom code the strategic pieces and purchase the standard pieces. Software never breaks apart or fits together quite so neatly, so this is where the hard work comes in.

BPM: Build and Buy

BPM is the obvious platform for new architectures that combine many pieces of both custom and purchased software. BPM historically evolved as a means of transparently integrating and orchestrating work across multiple systems. More recently BPM has gained state-of-the-art custom development capabilities that meet the goals I outlined a few moments ago and indeed, has significantly raised the bar and set a new standard.

Let me say it plainly, you will build much better custom software with properly configured BPM tools than you ever will with Visual Studio and .Net, or Eclipse and Java frameworks.

vLegaci has a long history of transformation of legacy software and is excited to be a leader in delivering on this vision.