“I always say that modernization is not an abstract thing; it's a very specific task.” —Dmitry Medvedev, prime minister of Russia
It’s Monday morning and you’re feeling pretty good after your first cup of coffee. No SEV1s, no fires. Then your boss, Joe, emerges from his cave waving the latest issue of a business magazine.
“Modernization!” he calls out. “We need to get on the modernization bandwagon ASAP or we’re going to get trounced by our competitors.” Joe throws the magazine on your desk.
Management by magazine. You remember the last time he got this excited. He knew that virtualization would save them from any downsizing. Everyone rushed and scrambled to do ‘something’ without really knowing what he meant. “This time would be different. This time I’m going to get some clarity,” you think to yourself.
You pick up the magazine and, as expected, the writer never actually defines the term. But that’s what the Internet is for. As you read, you discover it can mean a variety of different things, some of which seem really challenging and others more feasible (see Figure 1).
Figure 1: Examples of Modernization
Decide What to Modernize
Your company tried rehosting a while back, during the bad old years of ‘the mainframe is dead.’ You cross that one off your list. Where should you start? Remembering that your boss doesn’t have a clear idea of what he means by modernization, you realize it’s up to you. The most intriguing items—the ones you think are worthy of more consideration—are smart development and technical debt remediation. You’d love to consider Web and mobile, but that seems really out of reach. So many devices and OSs, and the skills required to code for this just aren’t the skills your team has.
Time for more research. You might be able to get away with only one modernization effort, if it really made a difference. Smart development: that sounds like a clever phrase but the search engine pulls up some really clear thoughts.
The key results that catch your eye refer to Architected Rapid Application Development (ARAD). You learn that these solutions are a technical model developed from object-oriented analysis and design tools, which incorporate analysis and design patterns and frameworks. Typically, organizations can generate 50 to 70 percent of source artifacts from the patterns, frameworks and (optional) models. Increasingly, organizations are blending traditional iterative methods used with ARAD with agile principles and practices to create a hybrid approach. Tools that help with this promise faster development, meaning you can deliver faster on customer demands. They help with continuous process improvement and centralize controls, making it easier to collaborate. That all sounds good. And it turns out that an ARAD platform makes it easier for existing developers to create mobile apps with the knowledge they already have.
Another top result is Business Process Management (BPM), the business side of speeding development by analyzing and improving business processes. You can create new business processes with BPM by wrapping together a variety of processes into new workloads often using APIs. That sounds a lot better than starting from scratch to build what the business wants.
Technical debt remediation turns out to be a fancy phrase describing how to fix bad code. You know there’s a lot of that in your portfolio. With a little bit of guilt, you remember when you first started coding; you’re pretty sure you wouldn’t be as proud of that work as you are of your most recent efforts. “Everyone has to start somewhere,” you think. But wouldn’t it be nice to get some of the wins you could get by recovering resources and improving performance with streamlined code. But there was never time to go back and fix anything, no time to do it right the first time and no time to fix it later—the developer’s dilemma.
You read more about the concept and learn that there are tools that will automatically review all your code and find problems, unnecessary complexity and areas of duplicate code, making it far easier to fix the big-hitter problems. That would be great.
Time to think about a project plan. From years of working projects, you know you need to select a project, assess software tools, run a small-scale test and analyze results before proceeding. Rather than start from scratch—no one does that anymore—you look for examples/proof points you can use for your own project. “Just like JCL; no one has written a PROC from scratch in years. You always copy and edit,” you say to yourself.
Reading about the modernization of the Social Security Administration, you learn that their systems ran legacy code older than anything your company has, you learn that they found a tool that helped them analyze their existing code, reviewing 250 million lines. You found it surprising to learn that the biggest challenge in modernization might be figuring out what are the most critical projects and systems. “Maybe I need to do both of the projects I was thinking about,” you consider.
You begin to look for vendors who can help you in both areas, so you can create an integrated project plan that will help you meet your manager’s goal of ‘modernization.’ You can’t help feeling a rush of excitement; this could be the most fun you’ve had at work since the Y2K excitement. Putting together your short list of vendors and a draft project plan, you stop in to see your manager.
“Joe, about that modernization effort you asked me about,” you begin. “Check out what I’ve got here.”
It’s time to get started.
John Rhodes is CTO of CM First Group.
Denise P. Kalm is chief innovator of Kalm Kreative, Inc.