11 dark secrets of application modernization

More than 95% of Fortune 1000 companies still use IMS, IBM’s ancient hierarchical DBMS. At least, that’s the number according to TwoBitHistory.org.

My own informal survey, in contrast, reveals that approximately zero percent of the best IT developers have any interest in working in that environment.

The ability to attract top talent is one reason — not the only one but among the most important — for CIOs to modernize their applications portfolio. Others include reduced license and support fees, and improved flexibility and adaptability.

Except that “modernization” isn’t as straightforward a proposition as it might seem. It has dark secrets that smart CIOs must take into account in their decision-making.

1. Application modernization is a compound issue

Application modernization (“app mod” if you’re a member of the Cool Kids Club) covers a bunch of very different solutions to a bunch of very different problems.

Depending on the application and who you talk to, app mod might mean version updating, replatforming, platform replacement, language modernization, refactoring, or COTS conversion. While they’re all called “modernization” they have little or nothing in common. Each has pitfalls to be aware of. Some are well-known; others are more covert.

Plus, the fact that modernization means so many different things is in itself particularly vexing: Before you can modernize a given application you first have to decide, not only whether to modernize it, but which type of modernization it needs.

Then multiply by the number of applications in your portfolio.

2. Version updating is its own form of debt

Some IT leadership teams think they’re being business savvy by “not buying technology for technology’s sake,” and, to pile one cliché on top of another, taking an “if it ain’t broke, don’t fix it” approach to managing applications and the stacks they run on.

They apply this logic to commercial applications, and to every platform every application runs on — the server OS, DBMS, CMS, development environment, desktop OS, browser, and on and on — updating only when specific new features deliver a specific new ROI.

Unfortunately, the Law of Pay-It-Now or Pay-It-Later still holds sway: Pay-It-Later invariably costs more and is more disruptive than staying current.

3. Replatforming solves for only one variable

Moving legacy applications to an open environment that has corresponding platforms all the way down the stack is another popular modernization approach — with a not-so-secret gotcha. Replatforming means migrating from mainframe-hosted z/OS + COBOL + CICS + DB2 to x85-hosted Linux + COBOL + CICS + DB2, for example. In cloud migrations, this is called “lift-and-shift.”

Here’s what you get: reduced license and vendor support fees. The dark secret? That’s all you get.

4. Platform replacement costs more

Platform replacement is a modernization method that changes out just one platform an application runs on, on the grounds that it’s obsolete or losing market share and mindshare. You might, for example, switch an application’s DBMS from Sybase to SQL Server. While this is also sometimes called “replatforming,” it has nothing in common with replatforming as described above.

What you get: fewer of the risks and vulnerabilities that come from using obsolete technology; also, access to a better pool of talent. What you don’t get: Reduced costs or any improved capabilities. Costs will, in fact, increase because you’ll have to license the replacement platform.

5. Language modernization often makes a bad situation worse

The seductive sales pitch says automated tools will extract your business logic from your legacy COBOL code and rewrite it in a modern language. This is often accomplished by replacing, say, a 100,000-line-of-code COBOL application with a 100,000-line-of-code Java application.

That’s the darkest secret of language modernization: Languages aren’t just vocabulary and syntax. Languages bring with them application design philosophies.

The second-darkest secret: Languages generally bring with them whole libraries of pre-developed logic as well. A development team writing a new application takes advantage of these libraries. Few if any code converters can do that, which means the converted code they generate is even harder to maintain.

6. Refactoring truly modernizes. So of course it’s costly and time-consuming

Refactoring is a modernization technique that converts an obsolete application’s structure to conform to proven practices — normalizing data, for example, or restructuring monolithic code to a microservices architecture.

Some tools purport to automate much of this restructuring. By all means, try them … on the vendor’s nickel until a few well-chosen proofs of concept convince you the tools work as advertised.

Also beware: Some versions of automated refactoring preserve the application’s behavior exactly. While this does minimize business disruption, it doesn’t convert an overnight-batch application to near-real-time processing — the architectural change most likely to drive competitive advantage.

Refactoring delivers serious business benefit in the form of improved adaptability and flexibility. But there’s no such thing as a free lunch. In the case of refactoring there isn’t even such a thing as a McDonald’s-budget lunch. Architecture modernization delivers the goods, but it’s expensive and effort-intensive.

7. COTS conversion might not sound like a modernization technique … but it is, and is often the best modernization alternative

Often, the best path to a modernized application portfolio is to replace a current-state application “ecosystem” with a modern suite of applications written by someone else. It’s far from a panacea — anyone who’s ever been involved in converting to a COTS/SaaS suite knows how difficult it can be — but it’s often the least risky and cleanest way to replace a collection of applications whose platforms and architecture are yesterday’s news to something that has a future and can help the business attain its planned future.

8. Knowing what you have takes more perspiration than automation

Now that we’ve run down the dark secrets of your various modernization methods of choice, there’s something more fundamental to beware of. Before you can modernize an application you need to know you have it and how it’s built so you know which of the modernization types just discussed might be applicable.

Sadly, despite all the brilliant promises made by all the brilliant purveyors of brilliant automated discovery tools, these tools are only useful for discovering servers, not what applications run on them.

What makes the lights grow even dimmer is that if your application inventory documentation is so incomplete that you need auto-discovery, it’s incomplete enough that you haven’t documented the platforms — the development environment, server OS, DBMS, content management system, and other tools — on which each application runs. Until you know this you can’t begin to choose which of the modernizations discussed above will provide the most benefit.

9. Software is an opinion — which makes application integration an argument

Each business application encodes a development team’s opinion as to how some aspect of the organization should run. Its opinion’s syntax is scribed in code. Its vocabulary is chiseled into the application’s data design.

Where the scope of two or more applications overlap — when, to take a simple example, the accounts receivable and CRM systems both maintain customer data — automation is needed to keep the two sets of records in sync. Add up all of the application overlaps in a portfolio and the result can be hundreds of custom point-to-point interface programs, all of which need to be modified and regression-tested every time a development team adds or alters an application.

An enterprise service bus (ESB) or similar technology can help reduce the sheer number of interfaces defining a single interface for each application.

But in addition to the sheer number of interfaces there’s the problem of semantic misalignments — that is, your accounts receivable and CRM systems’ customer data models differ. Reconciling these different definitions of the same entity is what makes integration tricky at the start and trickier to maintain.

An ESB can’t fix the problem of differing semantics because the problem isn’t technological in the first place. It’s that the developers disagree.

10. Modernizing the IT workforce is often harder than modernizing the applications they support

Your workforce is, presumably, highly competent at maintaining and enhancing the applications and underlying platforms that comprise your current applications architecture. They’re also a repository of deep knowledge about how their applications are used to make the business run as it’s supposed to run.

They aren’t highly competent in the replacement applications and platforms your modernization plan will implement.

You’ll need them to become just as competent in the replacements as they are right now if your modernization plan is going to work.

Beyond that, you’ll need them to become competent so they’re able to spot the opportunities for business improvement that can only come from smart people who are familiar with both the available tools and the current situation.

The dark secret: Showing them the door and hiring replacements instead just doesn’t work.

Sure, you can terminate them. But finding competent replacements will be neither cheap nor easy, and no matter how competent their replacements turn out to be, the rule of thumb is that replacing an employee costs the equivalent of a year’s salary — it would be prohibitively expensive.

Which is one more reason the last app mod dark secret is the worst dark secret …

11. Well-run IT organizations rarely need to modernize

Well-run IT organizations practice lifecycle management. They keep everything current all the time. This keeps the budget manageable — the app mod effort is steady with few “big bang” initiatives, and has the happy fringe benefit of keeping your workforce modernized along with your applications and platforms.