The biggest problem that most modernization projects face is the simplest. Where do you start? Do you even start? These are real questions because application modernization isn’t something simply or easily done. It takes determination, commitment, time, and most importantly, funding. The Internet is littered with stories of modernization projects that began, seemingly well, and then failed, either quietly with a whimper or sometimes spectacularly, with a bang. In order to find out why this is true, we have to begin with understanding what we are talking about.

What does “Application Modernization” actually mean?

One problem in all this is that the industry still doesn’t have a good definition of what is meant by an application. Making sure everyone understands what you’re talking about is key to gaining the alignment on goals. It’s odd that something so prevalent in the industry has been defined so variously, but part of that is due to the fact that the nature of applications have changed so much over the past fifty or so years of commercial application development.

Let’s start by saying I don’t mean that an application is “just a program”. That may have been true of some systems thirty years ago, but it’s certainly not true of most enterprise systems today. As developers we like to think of “the application” as being our Java EAR files or WAR files, but that’s only a small part of what the entire application actually consists of.

Instead, an application, as I define it, consists of one (but usually more) custom-written program components together with the supporting infrastructure, application middleware, middleware services (such as databases, queuing software, integration software and other aspects), and other components that make up a complete solution. It probably is deployed over several computers, either for scalability horizontally (the same component deployed multiple times) or vertically (the solution is split into multiple coordinating components). It may split itself across multiple geographical regions, or across multiple operating systems or computing architectures.

When you draw out all of these components, their dependencies, and the different systems that those all depend on and communicate with, what you end up is rarely the nice, neat, tree-like structure you see pictured in software engineering textbooks. Instead, it more often resembles a tangled hairball that may be extracted from a poorly maintained bathroom sink.

And it’s that distributed, multi-element nature that leads us to the second important definition:

Application Modernization is the process of updating an application so that it can be maintained, extended, deployed and managed in a way that allows the application to meet the business’ current and future needs.

This is the key to the problem. We don’t write applications in isolation — we write them as part of a surrounding ecosystem. Doing anything with an application like this requires you to not only understand all of these dependencies, but to plan for how to deal with each of the supporting components, in the right order. As a result, any change almost never happens all at once — this is an effort that takes not only planning, but time to execute.

Now that we understand what we’re doing — we can return to our previous question — Why do so many (I would go so far as to say most, in my experience) modernization projects die before they even get going? It all comes down to three major problem areas:

• Differing and Competing Goals

• Lack of clarity and agreement on approach

• Lack of the long-term commitment (for funding and priorities) it takes to complete the job

Let’s look at each of these different problem areas in turn and see why they are so difficult to resolve.

Differing and competing goals

This is first and foremost a question of alignment. Gaining alignment among all of the key stakeholders is probably the single most important aspect of application modernization. By alignment I simply mean bringing everyone together to move in the same direction. The problem we have is that application modernization means different things to different people, and they often have different and competing goals. Unless you can bring everyone together behind establishing a shared vision and set of goals, any project will end up being pulled apart before it really has a chance to begin.

Lack of Clarity on Approach

What I’ve seen in every client I have worked is that they end up having people split into two different camps.

The first camp — “Don’t do modernization — Get rid of it instead!”

The first group is the people that say you shouldn’t even do modernization. This is common among those that believe that the only way to get to the cloud is to throw everything away. There are certain vendors that have made quite a lot of money promoting this view — that has as it’s corollary that only their product and their method can get you to the cloud successfully. They look upon all of the work and all of the lessons learned in your existing environment with something approaching disdain, and often want you to hire all new developers who “get” the cloud. The problem is that those same developers may not “get” your business… We’ve seen lots of failed transformations that start this way — a team will make enormous progress on one or two — or even ten — new apps, but then the huge hurdle to the existing apps can’t be overcome. This is how you end up with multi-million dollar cloud infrastructure projects with less than 10% adoption rates.

However, there’s something compelling about this viewpoint. As developers, all of us have been frustrated by legacy code in one form or another. Poorly documented code, code with byzantine business logic, or code that simply was implemented using sub-optimal technologies or frameworks all grate on the nerves of developers tasked with maintaining or extending it. But the problem is we often don’t understand the problem, or the recommended solution, nearly as well as we think we do. And that leads us to the second camp.

The second camp — “Don’t do anything! We’re fine!”

There are a couple of different variations of this. One is that the system is too old, too fragile, too undocumented to possibly modernize. That is often a half-truth spread by those who are in favor of the “throw it all away” approach. However, the most troubling variation of why you shouldn’t change anything is that you shouldn’t change anything because things are fine the way they are. After all, things are getting done, and the system is working, so why mess with it?

This contains a kernel of truth. After all, when the software industry came up with the term “legacy” software, it was meant to be a good thing! A legacy is something positive that you want to pass on to your descendants. However, the term no longer has those positive connotations in software engineering. But it should! After all, legacy software represents the distilled knowledge and wisdom of lots of different developers and business teams gained over a number of years. There is something valuable in that, and it’s something you don’t want to throw away lightly.

However, as we all know, cruft accumulates. Things can’t run in their exact same form forever. In every system, technical debt finally accumulates to the point that some of it has to be paid back and that means making some new, possibly radical, decisions.

The problem is that application modernization falls between the two camps. You have to keep things running, while still addressing the sometimes deep technical issues that make it difficult to keep up with the needs of the business. But first you have to align everyone to move together in the same direction — at neither of these two poles, but somewhere in the middle, with a strategy that balances the two objectives of doing things differently, while still keeping the lights on.

Lack of the long-term commitment (for funding and priorities) it takes to complete the job

Let’s face it, lots of proposed projects fail simply because they don’t have the necessary funding. Lots of vendors and consulting companies (IBM included!) will be happy to show you how they can take a small application and show you how to modernize it and move it to the cloud in a number of weeks. However, while this is a great thing, and a step in the right direction, that kind of short-term win is not typical for large application modernization projects.

You see, when you consider all of the applications in a typical enterprise, what you will generally see is something like the following when you plot out the overall size of the applications (measured in terms of whatever metric you like — function points, story points, person-years of effort, etc.) versus the number of applications of that size in the enterprise.

Essentially, you get something that from a distance looks like an exponential decay over the log of the number of applications. What that means in practice is that there are a few very large, very complex applications in each enterprise, followed by a somewhat larger number of applications that are less complex, but still somewhat large. However, the applications in the “long tail”, which could be tens or even hundreds of applications, are medium to small. This means two things:

#1 The experience of the amount of effort expended to modernize a “small” application may not represent the amount of work it takes to modernize a “large” application, which may be an order of magnitude or two larger and more complex.

#2 The experience with a “small” application must be multiplied by a very large number to reflect the total effort to modernize all of the applications of that size in an enterprise.

When you add both of these up, what you find out is that modernization of all of the application in an enterprise is a long, complex endeavor that will typically take years. This means that you have to have the corporate will to sustain the kind of investment this will require over the long term, and to make sure that it remains a priority for that entire period. That also means that this has to extend farther than many teams think; it has to go beyond just the IT operations or development team, even beyond the CIO — it has to be a priority for the CEO of the company over a long period of time.

We have worked with some of the biggest companies in the world on these projects, and we can give you some hints, techniques and tips that can help guide you to a successful modernization project. But before we get to that, we need to think about why you even want to modernize.

Why modernize? Some real reasons.

There are many bad reasons for pursuing application modernization. You may be interested in it for a purely mercenary reason — because there’s a new technology you want to put on your resume. You may do it because a vendor tells you it’s the right thing to do (or worse, that it’s fast and easy!) None of these are good reasons for going down the long modernization road. However, there are three things that we have seen that are good reasons for beginning the journey:

#1 You can’t develop features at the pace your business requires — and it’s the technology choices and architecture (and not your processes or team constraints) that is causing that.

#2 The architecture of your application is hindering you from being able to add functionality because of fragility (you can’t test it) or constraints arising from technology choices.

#3 Your application is expensive to maintain and extend because either the infrastructure is excessively costly (for instance, older versions of middleware that require special support contracts) or the skills required are too expensive to find and maintain.

If you are in any of these situations, then application modernization may be a good match for you. Once you’ve made the decision to start in the right direction, the next question is how you keep moving in that direction.

How do you succeed? Organizational secrets of success

So let’s say you are convinced that modernization is possible, and what’s more that your team either already has or can acquire the skills to succeed with a modernization effort. Will you succeed? Unfortunately, the odds are against you in most software development organizations.

The major reason most modernization projects fail is that the organization is not set up to begin, sustain, or complete the amount of work necessary to finish the job. What’s more, organizational headwinds often impede the way to making progress with the multitude of tasks that a successful modernization effort will require.

Yet despite all that, some organizations succeed. What is their secret? It really comes down to three things:

#1 The organizations that succeed are able to put in the required investment and sustain it over the period of time (usually measured in years) that a successful enterprise application modernization will take.

#2 The organizations that succeed are willing to make the organizational changes necessary to succeed in the cloud.

#3 The organizations that succeed are willing to change their architecture, development and operational processes to match the pace and type of effort that a modernization will take.

Modernization is neither fast nor easy. But it is accomplishable given sufficient effort, investment and willpower. But as we discussed above, you need an approach that everyone can align on that helps you keep the lights on while still moving forward. That’s what we’re going to look at in the next section.


READ PART II here: https://ibm.co/2ScbcMP