Every organization has a unique experience navigating their modernization journey. However, some common best practices are available that can help any organization.

In this chapter, we discuss best practices for infrastructure, application, and process modernization with IBM Z.

This chapter includes the following topics:

If one suggestion sits at the heart of application modernization, it is to use a full-featured Source Code Manager (SCM) to organize all of your source code. As development processes transform to support multiple developers simultaneously working in the same area of code, it becomes critical to use a tool to manage everything. It also airs the possibility that the existing tool that sufficed for single-stream development is no longer sufficient.

This issue becomes clear with teams who use library managers to promote their applications across environments. Library managers work well for writing applications in a single stream because their stages are tied to each environment between development and production. However, they do not handle multi-stream development well.

Instead of having a code “branch” representing a particular environment, modern SCMs use each branch for a specific feature or deliverable. Therefore, you can merge the branches together in different ways according to which features you need in a specific environment. Meanwhile, each branch in the SCM can be updated independently of the others.

Figure 5-1 shows these differences and emphasizes the increase in productivity that can be achieved by using a modern SCM-enabling, multi-stream development.

One important detail to remember is that source code is not limited to application code only. Benefits can be realized by storing your test cases in an SCM, and especially in colocating those tests alongside the application code that they test.

This process also can be extended to include automation scripts and any other text files that are part of coding, building, or deploying an application. Having everything that you need in the same SCM enables CI/CD pipelines to include automated building, deploying, and testing for application changes.

The use of the same tools across platforms might include cost benefits if you can reuse something that you licensed. However, other reasons exist that might outweigh cost considerations.

Consistent tools across environments means that your teams can use shared skills and expand the number of people who might work in an environment. Historically, teams that work in one environment are unfamiliar with the tools that used in other environments and vice versa.

By using universal tools regardless of hardware platform, all teams become familiar with the same tools and might work in any environment. If the tools you use are common and used in a school curriculum, you are positioned for an even better advantage because of the immediate increase in productivity from new hires that join your ranks. All of these factors are beneficial to your team’s velocity.

Common tools also allow for sharing digital artifacts across environments. For example, a common DevOps toolchain allows for the definition of one pipeline that performs some operations on IBM Z to deploy the back end, and some operations on public cloud to deploy the front end, with a centralized dashboard for reporting. In a general sense, scripts or common routines might be shared across environments, which increases shared skills and knowledge among teams and in effect boost productivity.

Numerous examples exist of how technology changed our lives; for example, the use of GPS instead of reading a paper map or finding directions online, or searching for a phone number online instead of the use of a phone book. Similar stories also exist regarding code writing or performing system operations.

It is common for developers to use a GUI-based editor when working on their code. Thus, it makes sense that we want to enable their use for application code that runs on IBM Z. This enablement might be a change for experienced programmers, and some tasks might be easier to complete without the GUI. However, the focus must be on enabling as many people as possible to increase productivity.

A similar story is true of operations. Experienced system programmers likely have their own customized sets of jobs, scripts, and so on, to perform daily tasks. Because they understand the details of what they are doing, they can quickly respond to requests. Those programmers with less experience and smaller libraries of scripts might be more productive if they can use a standard workflow to accomplish their task requests.

Modernization means doing things differently. The emphasis must be on doing things that enable future productivity, which means offering IDEs for coding and cloud provisioning and management for system programmer actions.

For more information, see 4.8, “Provision, deploy, and release” on page 48.

Because environments that are hosted on IBM Z are expected to always be available, changes to these production systems are tightly managed to control the risk of breaking production. That expectation is something that is not likely to change with modernization. In fact, modernization might increase the importance of these already-crucial systems because they extend across an organization’s hybrid cloud.

Multiple phases of testing are one of the components that contributes to this stability because nothing is promoted into production before it is thoroughly vetted for quality. The test environments that are used for this vetting must still be controlled by skilled system programmers, but an opportunity might exist to allow greater flexibility because the effect of downtime is not as critical as it is in production. Empowering developers by allowing them to self-provision temporary resources for their application testing can greatly speed up development.

For example, one of Company A’s COBOL developers is changing an application that is hosted in CICS on IBM Z. In past configurations, one shared CICS environment was used for multiple testers, which meant that testers had to coordinate who can use it at a specific time so that no one affected anyone else’s testing.

Through modernization with CP&M, Company A enabled developers who are not skilled as system programmers to easily provision a private, temporary CICS region to use for their testing and then deprovision it when they are done.

A great way to scale and extend the scope of the self-provisioned model is to emulate the entire environment. Whereas allowing self-provisioned testing enables self-provisioning resources within a shared system, such as a z/OS LPAR, emulated environments allow developers to have a private system. These environments are emulated because they run on x86 hardware (on-premises or in-cloud).

Because developers get their own emulated z/OS environment, they have much more flexibility for customization as needed for their testing. Better yet, each developer can have their own environment, which means that developers do affect each other with their customizations or if their testing causes failures. This model gives the benefits of each developer having their own z/OS system without affecting IBM Z hardware usage.

At first, Company A relied on a shared z/OS LPAR for their developers to unit test their application changes. Eventually, they outgrew this model and had many developers working on changes that must be tested independently of one another.

At the time, commodity Linux servers were sitting unused in their data center, so they installed IBM Z Development and Test (ZD&T) and turned their developers loose to work in parallel, which increased productivity. Company A recently chosen Red Hat OpenShift as their container platform, and they are considering moving these emulated environments to IBM Wazi for CodeReady Workspaces.

For more information about ZD&T and Wazi, see 4.7, “Test” on page 47.

IBM Z processors are continually advancing to include new instructions that are designed to perform specific operations at a faster rate. Unfortunately, compiled applications cannot use these new instructions until they are updated by something or someone that is aware of the new instructions.

Traditionally, this update meant recompiling application source code with an updated compiler; the newer compiler knows about the new instructions, so it uses them when it translates source code to machine instructions. For COBOL applications, another alternative is available: IBM Automatic Binary Optimizer for z/OS (ABO).

IBM ABO takes the executables that you use and optimizes them with the latest machine instructions. Even if you lack the source code for some of your applications, you can still optimize them with ABO. Although it is still necessary to test the optimized executables before deploying to production, you can be assured that no source code was changed and less required testing is needed than you typically associate with application source changes.

COBOL applications that are changed often are recompiled with each change, so they are more likely to benefit from compiler improvements. ABO is a great approach for those applications that are not changed frequently or cannot be changed frequently because of lost source code. These applications are no longer relegated to old machine instructions.

For more information about IBM Automatic Binary Optimizer for z/OS, see this web page.

Hardware and software updates typically are planned with the cadence of IT budgets, so chances are good that your organization stays within supported releases. Although staying within supported releases is helpful to ensure that vendors act if something fails, it does not mean you use everything that is accompanied by your updates.

A best practice is to add an assessment step to each update that focuses on new capabilities. These capabilities can be features of new IBM Z hardware, such as compression cards, or it can be functions that come with upgrading a middleware subsystem, such as a new REST-enablement capability.

It is important for the assessment to identify any new capabilities and which teams must be contacted for awareness. One all-to-common scenario occurs when system programmers are aware of new hardware features, but database administrators are not aware. If the database administrators knew about the new hardware, they update their subsystems to use it.

Consider the following questions for an update assessment:

The following questions assume that the benefits warrant implementation:

Developers might write code without worrying about hardware dependencies and some low level of integration, and architects might ignore topography concerns by using the cloud computing model. One pitfall of embracing cloud is to fall into the trap of thinking that you do not need to consider how things fit together because everything works “in the cloud.”

When running production across hybrid platforms, the latency between the platforms must be a point of concern and planning. Even for (or perhaps especially for) batch transactions that occur after the close of business hours, adding a fraction of a second can mean that work is not completed before the start of the next business day. This issue is seen even for on-premises computing that starts on IBM Z, involves calculations on a server rack in the same data center, and then ultimately finishes back on Z. The latency is increased by cloud because of network paths between systems.

For more information about the benefits of colocating work, see 3.1.4, “Colocation with IBM Z” on page 30. Consider the latency introduced between platforms as you plan modernization.

Modern environments that are supported by agile processes and tools provide a great foundation for IT that enables organizations to grow, although it is the people behind these environments who are its greatest assets. One way to future-proof your teams is to recruit talent that has enterprise computing skills.

The IBM Academic Initiative schools foster and progress education that is related to enterprise computing. Across the high school and university levels, schools with course curricula that include IBM Z also feature computer science societies and other clubs, and everything in between. IBM often partners with clients to create an event with students from their geographic area. This endeavor is a worthwhile event for all who participate because students need jobs, clients need new hires, and IBM wants both to succeed.

Another opportunity to find enterprise computing talent is through a program that is called Master the Mainframe. It is a coding competition that teaches enterprise computing concepts with the look and feel with which students are familiar.

The competition consists of three levels, with a digital badge that is awarded to participants who completed several hands-on exercises. Master the Mainframe is creating generations of skilled developers and system programmers; all you need to look for is their digital badge.

For more information about Master the Mainframe, see this website.

You also can contact the IBM Z Ecosystem team at: [email protected].

Many software vendors offer one or more collaborative methods for designing a modernization journey. Even better, some of these offerings are available at no cost. Regardless of the cost, it is worth bringing in subject matter experts to get a sense of what solutions other organizations used for their modernization journeys to be successful.

IBM uses the garage method for collaborating with clients to examine a challenge, design a solution, and foster it into production. The process starts with a Design Thinking session to disassemble the problem, brainstorm ideas, and test concepts.

Afterward, IBM Garage™ experts work to create a minimum viable product (MVP) with their counterparts on the client’s team. The process can help accelerate value and reduce risk, in addition to providing guidance to deliver immediate business value.

The IBM Garage™ experience blends business strategy, design, and technology into a single end-to-end journey. The IBM Garage methodology is built around co-creating, co-executing, and cooperating a solution by applying technology to a business problem.

For more information about IBM Garage, see this web page.

If you want to hear technical information about a technology from experienced technical users, IBM Developer advocate teams might be what you are looking for.

Developer Advocates present on technical topics that are based on personal experience, without any sales pressure. If technically feasible, Developer Advocates can even hold hands-on workshops so you can get practical experience without affecting your own systems.

For more information about offerings from the IBM Developer Advocacy teams for IBM Z or IBM Cloud, contact your IBM account team.

IBM Developer is a community where you can find a plethora of technical learning materials and engage with other professionals through blogs and events. Great technical content is available on IBM Developer, including step-by-step tutorials and code patterns that include some sample code that is published under open source guidelines to get you started. Podcasts where SMEs discuss technical topics in detail and videos that include demos also are available.

IBM Developer is a great resource for technical topics about application modernization and modern tools for operations. For more information about IBM Developer, see this web page.

By now, the picture is a bit clearer about how your IBM Z environments can play a role in your hybrid cloud.

In this chapter, we explored some of the ways to get started and discussed some of the technologies and products that can help you modernize.