IBM Unleashes the z15 Mainframe

In New York City, on September 12, 2019, IBM announced the latest and greatest iteration of its Z systems mainframe computing platform, the IBM z15. And I was lucky enough to be there for the unveiling.

The official IBM announcement letter can be found here if you want to dive into the details. But before you go there, consier first reading what I have to say about it below.

Before going any further, here I am with the new z15 in New York… don’t we make a handsome couple? 

The event was held at 3 World Trade Center in lower Manhattan. Ross Mauri, General Manager of IBM Z, kicked off the event extolling the unprecedented security delivered by the z15 with encryption everywhere and the data privacy passports. He claims that the IBM z15 is the most secure platform you can get, and the new capabilities back that up. Mauri also acknowledged that "there's always the next big thing in technology" but stated that "IBM is innovating and leading by anticipating customer needs to ensure the on-going relevance of the mainframe."

And there is a lot to like about the new IBM z15 platform, both for long-time users and those embracing the platform for new development. IBM is embracing the multicloud approach and reminding everybody that the mainframe is a vital component of multicloud for many organizations.

But modern infrastructure with the latest application development techniques is not as simple as throw out the old and bring in the new. I mean, let’s face it, if you have a mainframe with possibly hundreds or thousands of man years of work invested in it, are you really going to take the time to re-code all of that mission-critical work just to have it on a “new” platform? Rewriting applications that work today cannot be the priority for serious businesses! Especially when the modern mainframe is as new as it gets, runs all of that legacy code that runs your business, and also supports new cloud apps and development, too.

The IBM Z works perfectly as a part of your multicloud development strategy. The cloud promises an open, flexible world. But your most critical workloads also need to run securely and without interruption. To accomplish both objectives you must support cloud with an underlying IT infrastructure. And for Fortune 500 companies and other large organizations, the multicloud includes the mainframe as part of the enabling infrastructure.

What’s New

The new IBM z15 is housed in a convenient 19 inch rack, and that means it can be integrated into a standard rack. So you get all the benefit and strengths of the mainframe while fitting into the size expected by a standard data center.

Did you know that there are more transistors in the new IBM z15 chip than there are people in the world! Inside the IBM z15 processor chip, there are 15.6 miles of wires, 9.2 billion transistors and 26.2 billion wiring connections — all of which allow a single z15 server to process 1 trillion web transactions per day.

The mainframe is the ideal platform for many organizations. It provides the resiliency, security, and agility needed to power, secure, and integrate your hybrid cloud. And it capably, securely, and efficiently runs your transactions and the batch workload required to keep your business humming. IBM used to talk about five 9s of availability (that is 99.999%) but with the new IBM z15, IBM can deliver seven 9s (that is 99.99999%)! That is 3.16 seconds of downtime per year, or only 60.48 milliseconds of downtime per week. Now that is impressive!

The primary new features that are worth your time to investigate further, and that were highlighted by IBM at the kickoff event are:

• Encryption everywhere which protects your data anywhere, even after it leaves your system, with new IBM Data Privacy Passports, which delivers privacy by policy.
• Cloud native development that simplifies life for developers as they build and modernize applications using standard tools, including new support for Red Hat OpenShift. This enables you to both modernize the apps you have and to deploy new ones using the tools of your choice.
• IBM Z Instant Recovery can reduce the impact of planned and unplanned downtime. Instant Recovery can speed the return to your pre-shutdown SLAs by up to 2x.

The flexibility of the z15 is noteworthy, too. The new IBM z15 provides the flexibility to implement 1 frame...

or up to 4 frames, as your capacity needs dictate.

And did you know it can run multiple operating systems, not just z/OS? The IBM Z platform can run z/OS, Linux on Z, z/VM, z/VSE, and z/TPF. This enables organizations to run legacy applications and modern, specialist ones using the operating system of their choice. Indeed, convenience and flexibility are hallmarks of the IBM Z platform.

The IBM z15 is a modern platform for all of your processing needs. And that is backed up not just by IBM, but also a brand new survery from BMC Software, in their 14th annual mainframe survey for 2019. The survey shows that 93% are confident in the combined long-term and new workload strength of the IBM Z platform, the strongest showing since 2013! Other highlights inlcude a majority thinking that mainframe growth will continue, along with increasing MIPS/MSU consumption... not to mention that the mainframe is handling increases in data volume, number of databases, and transaction volume. If you are working with mainframes in any way, be sure to check out the new BMC Mainframe Survey.

Indeed, with the new IBM z15 things are looking great for the mainframe and those that rely upon it to power their digital business.

The Power of Data Masking for Data Protection

Data privacy regulations and the desire to protect sensitive data requires methods to mask production data for test purposes. Data masking tools create structurally similar data that is not the same as the actual data, but can be used by application systems the same way as the actual data. The capability to mask data is important to be in compliance with regulations like GDPR and PCI-DSS, which place restrictions on how personally identifiable information (PII) can be used.

UBS Hainer’s Masking Tool for BCV5 (their test data management solution) offers robust masking of Db2 for z/OS data. I wrote about this capability previously on the blog last year (see Data Masking: An Imperative for Compliance and Governance, November 12, 2018), and if you are looking for a concise, yet thorough overview of the product’s data masking capabilities I point you to that blog post.

So why am I talking about data masking again? Well, it is a thorny problem that many organizations are still struggling with. As much as 80% of sensitive data resides in environments used for development, testing, and reporting. That is a lot of data that is ripe for exposure.

But I also wanted to share a new video produced by UBS Hainer that explains how data masking can help you to stay compliant and protect your sensitive data. It is well worth your time to watch this 2 minute video if you need to better address the protection of sensitive data at your shop.

Click to watch the video

Data masking is not a simple task, and as the video helps to explain, there is much to consider. To effectively mask your data requires a well-thought-out process and method for implementation to achieve success. As such, a tool like BCV5 Masking Tool can simplify how you address your Db2 data protection requirements. It provides dozens of easy to use masking algorithms implemented using Db2 user-defined functions. It ensures that the same actual value is translated to the same masked value every time. And the value will be a plausible value that works the same as the data it is masking. The tool understands thing like referential integrity, unique constraints, related data, and so on.

A reliable method of automating the process of data masking that understands all of the complicated issues and solves them is clearly needed. And this where UBS Hainer’s BCV5 Masking Tool excels.

BMC AMI for DevOps Intelligently Integrates Db2 for z/OS Schema Changes

Organizations of all types and sizes have adopted a DevOps approach to building applications because it effectively implements small and frequent code changes using agile development techniques. This approach can significantly improve the time to value for application development. The DevOps approach is quite mature on distributed platforms, but it is also gaining traction on the mainframe.

As mainframe development teams begin to rely on DevOps practices more extensively, the need arises to incorporate Db2 for z/OS database changes. This capacity has been lacking until recently, requiring manual intervention by the DBA team to analyze and approve schema changes. This, of course, slows things down, the exact opposite of the desired impact of DevOps. But now BMC has introduced a new solution that brings automated Db2 schema changes to DevOps, namely BMC AMI for DevOps.

BMC AMI for DevOps is designed to integrate into the DevOps tooling that your developers are already using. It integrates with the Jenkins Pipeline tool suite to provide an automated method of receiving, analyzing, and implementing Db2 schema changes as part of an application update.

By integrating with your application orchestration tools AMI for DevOps can capture the necessary database changes required to move from test to production. But it does not just apply these changes; it enforces and ensures best practices using built-in intelligence and automated communication between development and database administration.

The ability to enforce best practices is driven by BMC’s Automated Mainframe Intelligence (AMI), which is policy driven. The AMI capability builds much of the DBA oversight for schema changes into the DevOps pipeline, enforcing database design best practices as you go instead of requiring in-depth manual DBA oversight.

Incorporating a database design advisory capability into the process offloads manual, error-prone tasks to the computer. This integrated automation enables automatic evaluation of Db2 database schema change requests to streamline the DBA approval process and remove the manual processes that inhibit continuous delivery of application functionality.

Furthermore, consider that intelligent database administration functionality can be used to help alleviate the loss of expertise resulting from an aging, retiring workforce. This is a significant challenge for many organizations in the mainframe world.

But let’s not forget the developers. The goal of adopting a DevOps approach on the mainframe is to speed up application development, but at the same time it is important that we do not forgo the safeguards built into mainframe development and operations. So you need a streamlined DevOps process—powered by intelligent automation—in which application developers do not have to wait around for DBA reviews and responses. A self-service model with built-in communication and intelligence such as provided by AMI for DevOps delivers this capability.

The Bottom Line

BMC AMI for DevOps helps you to bring DevOps to the mainframe by integrating Db2 for z/OS schema changes into established and existing DevOps orchestration processes. This means you can use BMC AMI for DevOps to deliver the speed of development required by agile techniques used for modern application delivery without abandoning the safeguards required by DBAs to assure the accuracy of the database changes for assuring availability and reliability of the production system. And developers gain more self-service capability for Db2 schema changes using a well-defined pipeline process.

DevOps is Coming to Db2 for z/OS

Mainframe development teams are relying on DevOps practices more extensively, bringing the need to incorporate Db2 for z/OS database changes into the toolset that is supporting their software development lifecycle (SDLC).

But most mainframe professionals have only heard a little about DevOps and are not really savvy as to what it entails. DevOps is an amalgamation of Development and Operations. The goal of DevOps is to increase collaboration between developers and operational support and management professionals, with the desired outcome of faster, more accurate software delivery.

DevOps typically relies on agile development, coupled with a collaborative approach between development and operations personnel during all stages of the application development lifecycle. The DevOps approach results in small and frequent code changes and it can significantly reduce the lead time for changes, lower the rate of failure, and reduce the mean time to recovery when errors are encountered. These are all desirable qualities, especially as organizations are embracing digital transformation driven by the 24/7 expectations of users and customers to access data and apps at any time from any device.

The need to be able to survive and thrive in the new digital economy has caused organizations to adopt new and faster methods of developing, testing and delivering application software. Moving from a waterfall software development methodology to an agile methodology is one way that organizations are speeding the time-to-delivery of their software development. Incorporating a DevOps approach is another.

Instead of long software development projects that may not deliver value for months, or perhaps even years (common using the Waterfall development methodology) an agile DevOps approach delivers value quickly, and then incrementally over time. DevOps enables the continuous delivery of new functionality demanded by customers in the digital economy.

Succeeding with DevOps, however, requires a cultural shift in which all groups within IT work in collaboration with one another, and where management endorses and cultivates this cultural change. Because DevOps relies upon incremental development and rapid software delivery, your IT department can only thrive if there is a culture of accountability, collaboration, and team responsibility for desired business outcomes. Furthermore, it requires solid, integrated automated tooling to facilitate the SDLC from development, through testing, to delivery. Creating such an environment and culture can be challenging.

With DevOps the result will be a constantly repeating cycle of continuous development, continuous integration and continuous deployment. This is typically depicted graphically as the infinity symbol such as in Figure 1 (below).

Figure 1 - continuous development, integration and deployment

Note, however, that this particular iteration of the DevOps infinity graphic calls out the participation of both the application and the database. This is an important, though often lacking, detail that should be stressed when adopting DevOps practices.

The Mainframe and DevOps

The adoption of DevOps has, until now, been much slower within mainframe development teams than for distributed and cloud application development. The staid nature of mainframe development and support, coupled with a glass house mentality, and a rigid production turnover process contribute to the delayed adoption of DevOps on the mainframe. This is not surprising as mainframes mostly are used by large organizations running mission critical workloads with an aversion to any kind of change and risk-averse.

Additionally, the traditional waterfall development methodology has been used by most mainframe software developers for multiple decades, whereas DevOps is closely aligned with an agile approach, which differs significantly from waterfall.

Notwithstanding all of these barriers to acceptance of DevOps on the mainframe, mainframe developers can, and in some cases already do successfully utilize a DevOps approach. Technically speaking, the mainframe is just another platform and there is nothing inherent in its design or usage that obviates the ability to participate in a DevOps approach to application development and delivery.

What about Db2 for z/OS?

Integrating database change into the application delivery lifecycle can be a stumbling block on the road to DevOps success. Development teams focus on application code, as they should, and typically view database structure changes as ancillary to their coding efforts. In most application development projects, it is not the programmer’s responsibility to administer the database and modify database structures. But applications rely on the database being designed, implemented, and changed in accordance with the needs of the business and the code.

This means that many development projects have automated their SDLC tool chain to speed up the delivery of applications. This is the “Dev” portion of DevOps. But the requisite automation and tooling has not been as pervasively implemented to speed up the delivery of database changes. This is the “Ops” portion of DevOps. And this is changing.

A big consideration is that the manner in which change is applied to applications differs from how database changes are applied. That means each must be managed using different techniques and probably different tools. When an application program changes, the code is compiled, and the load module is migrated from test to production. The old load module is saved for posterity in case the change needs to be backed out, but the change is a wholesale replacement of the executable code.

Database changes are different. The database is an entire configuration in each environment and changes get migrated. There is no wholesale replacement of the database structures. DDL commands are issued to ALTER, DROP, and CREATE the changes to the database structures as needed.

From the perspective of database changes on Db2 for z/OS, DBAs need the ability to modify all the database objects supported by Db2 for z/OS. Supporting Db2 for z/OS using DevOps requires tooling that understands both Db2 for z/OS and the DevOps methodology and toolchain. And the tooling must understand how changes are made, as well as any underlying changes that may be required to effectively implement the database change. Some types of database changes are intrusive, requiring a complicated series of unloads, metadata captures, drops, creates, loads, and additional steps to implement. The tooling must be capable of making any of these changes in an automated way that the DBA trusts.

Fortunately, for organizations adopting DevOps on the mainframe with Db2, there is a solution for integrating Db2 database change into the DevOps toolchain: BMC AMI DevOps for Db2. BMC AMI DevOps for Db2 integrates with Jenkins, an application development orchestration tool, to automatically research and determine database schema change requirements, to streamline the review and approval process, and to safely implement the database schema changes making development and operations teams more efficient and agile.  

Webinar: DevOps and Database Change Management for Db2 for z/OS - August 13, 2019

DevOps practices are gaining popularity on all development platforms and the mainframe is no exception. DevOps relies heavily on agile development and automated software delivery. However, the ability to integrate and orchestrate database changes has lagged. To learn more about DevOps, change management, and Db2 for z/OS, I am delivering a webinar on this topic along with John Barry of BMC. We will discusses issues including an overview of DevOps, the requirements for database change management, and an introduction to BMC’s new AMI DevOps for Db2 that solves the change management dilemma for Db2 for z/OS development. You can register today to attend the webinar on August 13, 2019 (Noon Central) at https://event.webcasts.com/starthere.jsp?ei=1251892&tp_key=3ff9b7af72.