Developing an Effective IBM Z Technology Planning Strategy

It’s important to account for all that the IBM Z platform can do for your organization as you build your corporate technology plan. Whether your goals are modernization, cost reduction or something else entirely, planning must be comprehensive and account for all of the technology you have and the opportunity it provides.

Defining Mainframe Modernization

To some organizations, modernization means moving off the IBM Z platform. Often, other options are not even investigated. It’s assumed that to modernize you must discard the platform entirely. Those of us who work with IBM Z daily know that mainframe modernization means something entirely different. Of course, this is just perspective, but if you’re the one tasked with planning your corporation’s technology future, you should arm yourself with enough information about the platform to make good decisions.
The reasons to modernize can vary. The underlying issue is that other problems that need solving are lumped into the word “modernize.” You really need to delve into the details of what you want to accomplish when you modernize. For example, do you need to:

• Remove the potential disaster of your support staff all retiring on the same day?
• Take advantage of containerization?
• Increase your system uptime to create a better user experience?
• Provide your developers with the latest tooling and move toward an agile, DevOps environment across the enterprise?

3 Factors to Consider When Developing Your Modernization Strategy

You want to modernize? Great! If you can tell me exactly what that means, then you’re on the right road to building a comprehensive plan. Consider these three factors as you develop your big-picture modernization strategy:

1. Workforce Planning

The aging mainframe workforce is certainly an issue but even if your solution is to move off the platform to solve it, you will still have many other issues to consider while moving. Applications may or may not need to be rewritten so you will likely still end up with COBOL programs running somewhere. The time required to prepare and migrate will have a cost in time and money and in potential latency once you start moving applications away from the system of record. Moving becomes a complex series of architectural decisions that must be examined in total, comprehensively. You should be looking at all possible options, not just one.

2. Containers, APIs and DevOps

Containers, APIs and DevOps often cause executives to want to move away from IBM Z because these constructs exist in the cloud and on the distributed platform. However, all of these can be done on IBM Z right now. If you can take advantage of microservices, APIs that require zero mainframe knowledge, and build a comprehensive DevOps pipeline within IBM Z, why incur the expense and outages associated with moving off the platform? Again, get all of the facts and look at this comprehensively.

3. Cost

The answer often comes down to the cost of the platform. The perception is often that IBM Z is too expensive. While this is possible, it’s not likely. You’re usually able to see all of your Z costs easily because they’re all contained in easy-to-understand metrics. The cloud, not so much. Movement from Capex to Opex can make tremendous sense in many cases, but not all. Analyzing the true cost of what your cloud spend will be is difficult. Some factors are certain though: Those subscription costs will rise, the number of servers will increase, and monitoring and measuring it all will be complex at best.

Making a Technology Plan

In short, it’s important to solve your technology planning systematically and comprehensively. Examine each problem in its lowest terms and all of the options you have available. Some modernization options may not be what they seem at face value—and when you consider the big picture, you’ll find that the IBM Z platform is often a key component of an effective modernization plan.

---