Tag: mainframe

  • Compuware Adds Testing Tools to DevOps for Mainframe Portfolio

    Compuware Adds Testing Tools to DevOps for Mainframe Portfolio

    Compuware is extending its ongoing campaign to bring DevOps processes to the mainframe by acquiring XaTester, a provider of tools for creating unit tests for both batch and CICS-based programs written in COBOL, PL/I and Assembler.

    In addition, Compuware announced it has formed an alliance with Parasoft, a provider of tools for testing application programming interface (API) calls between mainframe and non-mainframe systems.

    Finally, Compuware revealed it has added support for automated unit testing for the IBM Management System (IMS), a hierarchical database that is used to run both transaction and batch-oriented applications.

    Those latest editions  come on the heels of an update to the Topaz for Total Test platform that, among other things, make it easier to extract data from mainframe applications.

    Compuware CEO Chris O’Malley said all these new capabilities will expand the reach and scope of Topaz for Total Test platform that makes it possible to apply DevOps practices to both new and legacy applications being developed and deployed on IBM mainframe platforms.

    Despite being more than five decades old, O’Malley noted that mainframes are still widely employed to process both transaction and batch-oriented applications at a level of scale other platforms still can’t match. The challenge now is to integrate the wealth of applications running on IBM mainframes within the context of a modern application development process, he said. That requires putting new application development and deployment tools in place that are optimized for DevOps versus traditional waterfall approaches still widely used in mainframe environments.

    CICS and IMS applications are at the heart of some of the fastest transaction processing applications running in the enterprise. Rather than rewrite those applications, O’Malley said organizations that have invested in mainframes want to be able to expose those applications as a service using APIs. Testing those integrations requires mainframe teams to adopt frameworks that enable them to become more agile, he noted—for example, organizations integrating applications need to be able to easily engage in A/B testing to be able optimize performance.

    As the lines between mainframes and distributed computing systems continues to blur, most organizations are working toward having one team support both platforms. As part of that effort organizations are introducing DevOps practices that have proven themselves on distributed computing platforms to mainframes. That approach helps mitigate a mainframe skills shortage that is occurring as more IT professionals with mainframe skills leave the workforce.

    It may take a little extra effort to get IT staffs managing mainframes to part ways with legacy approaches to building and deploying applications that have clearly stood the test of time. But as more organizations embrace digital process transformation the rate of change in mainframe environments clearly need to accelerate, O’Malley said.

    In fact, IT professionals with mainframe skills that are also literate when it comes to DevOps just might find themselves among the most sought-after people in enterprise IT. After all, the number of IT professionals that can play both side of the mainframe and distributed systems ball are very few indeed.

    — Mike Vizard

  • Speed and Security Can Coexist in Mainframe DevOps

    Speed and Security Can Coexist in Mainframe DevOps

    DevOps teams face a constant tug-of-war in their daily work, balancing the need for speedy rollouts of high-performing (fast, reliable) applications that are secure also. If the team moves too quickly, an overlooked security vulnerability may make its way into production. If the team is not nimble enough to identify those security gaps, it can slow down the entire development process, hampering organizational agility.

    The need to strike this critical balance has led to the rise of DevSecOps, or the integration of security into DevOps best practices through automated techniques. Much has been written about the importance of bringing the mainframe fully into the DevOps fold, evolving the platform to keep pace with the speed of modern software development. But what about the security of mainframe code and mainframe data specifically—incorporating the mainframe into the third leg of the DevSecOps stool?

    A recent survey found that 72 percent of customer-facing applications are completely or very dependent on mainframe processing, which means there’s a lot of personal, sensitive information flowing through mainframe code and into mainframe data repositories. The mainframe platform itself is the most secure system on the planet, due in large part to its unique function and design. IBM’s new pervasive encryption is a groundbreaking development for enhancing data security on the mainframe even further, enabling data at rest (in traditional VSAM files and databases) as well as in transit to be encrypted at a pace of 12 billion transactions per day, all with no impact on system throughput speeds.

    Bulletproof Mainframe Security

    Still, highly personal and sensitive data can be compromised if steps aren’t implemented to ensure mainframe code and data are as inherently bulletproof as the supporting platform. What steps can help mainframe users achieve the conflicting goals of fast mainframe development combined with superior security?

    Privatized Test Data

    Speed is critical in all aspects of DevOps, including application testing. Mainframe transactions are the heartbeat of modern applications, making testing critical to ensure these components are working properly. Many organizations prefer using live, mainframe-based production data in testing, as this provides the most realistic view of how an application will work “in the wild.” However, in the rush to pull testing data, many organizations have fallen into sloppy practices including failing to disguise this data, which puts sensitive, personal data at risk of exposure. Companies needing to comply with the EU’s Global Data Protection Regulation (GDPR) face another risk—non-compliance—since they may be using customer data for a purpose (application testing) beyond that for which it was originally procured.

    Mainframe users can continue to use real production data in application testing, but they need to take special steps such as using pseudonism, which entails randomly scrambling certain values in a database (for instance, names) so that real customer names are disassociated with other personally identifiable information such as addresses or credit card information. Making it reasonably difficult to associate individual customers with their personally identifiable information is one way to achieve a higher level of information security for production data used in testing. Creating privatized application testing data sets must be a repeatable, automated process that allows testers to quickly get access to the test data they need to expedite testing processes.

    Credentialed User Auditing, User Role Management

    The DevOps concept entails greater frequency of code changes, which naturally leads to more testing and more developers and testers accessing data and applications. Unfortunately, the involvement of more team members, all working at a faster pace, can sometimes lead to carelessness and inadvertent and unintended security risks. There are techniques available now that allow organizations to see exactly what credentialed users did and what data was accessed. Some may view this as bordering on “Big Brother” type of behavior, but the fact is, with so much sensitive data continuing to reside on the mainframe and growing compliance requirements (GDPR, for example), such surveillance is vital to protecting both the enterprise as well as workers, the majority of whom have no ill intention.

    However, user auditing comes with an important prerequisite, and that is better management of user roles. “Least privilege” is a long-held security best practice of restricting access for users only to those resources absolutely required for them to do their jobs. The challenge is when workers change roles, they often are not removed from their previous role definitions and privileged access points, and simply given new ones. Since they may no longer need their old credential sets, this violates the least privilege concept and represents a significant security threat that auditing may not be able to fix. The benefits of auditing—in terms of fostering faster testing and overall development without compromising security—depend on strong user role management.

    Automated Rollouts/Rollback

    Automated rollouts make the process of releasing code into production faster and more efficient. A dwindling pool of mainframe specialists means that in many cases, workloads spend significantly more time being queued up waiting for available resources, than they do actually being implemented. Removing the need for a developer to manually push new updates into production can be a major benefit in speeding up the mainframe cog. However, approval layer and audit capabilities must be built-in to ensure code security has been tested and verified and the source of any potential problems can be traced back quickly and accurately. Automated rollback functionality is also critical in the event that a security flaw does make its way into production, by enabling developers to immediately roll back to a previous version of the software until the flaw is fixed.

    Much progress has been made in recent years when it comes to evolving the mainframe for DevOps, as several examples can attest. But given the sensitive personal data that is often running through, and residing in, mainframe code and data, the scope must expand to DevSecOps, and the steps described here represent a solid initial plan for getting there. Organizations that do this will enjoy the maximum benefits derived from a highly agile, secure mainframe environment delivering unparalleled scalability and reliability for its digital transformation initiatives.

    — John Crossno

  • CA, IBM Partner to Drive DevOps on the Mainframe

    CA, IBM Partner to Drive DevOps on the Mainframe

    CA Technologies and IBM announced today at the Built to Change Summit they are combining their tools and platforms to bring DevOps process to mainframe environments.

    The two companies are extending their existing relationship to include a partnership to jointly develop and sell new services for IBM’s Cloud Managed Services on z Systems (zCloud). Included in that effort is CA Brightside, a platform for bringing DevOps processes to mainframes using existing open source tools and frameworks such as Jenkins, Gradle and IntelliJ via a command line interface and CA Mainframe Resource Intelligence, a software-as-a-service (SaaS) application for monitoring consumption of mainframe resources.

    Other managed services will be based on CA Service Virtualization software for rapidly testing and modifying applications in place; CA Mainframe Operational Intelligence to monitor applications; and CA Data Content Discovery to find, classify and protect data.

    The services are available today to all IBM Managed Cloud Services for z Systems clients in North America and will then be rolled out globally throughout the rest of 2018.

    Greg Lotko, general manager for mainframe at CA Technologies, said that although CA Technologies competes with IBM when it comes mainframe software, it has a vested interest in making sure mainframes stay relevant at a time when organizations are looking to replace less agile forms of application development that use waterfall and ITIL processes with DevOps methodologies that speed application development. From a practical perspective, end customers are demanding that CA Technologies and IBM work more closely together, he said.

    Barry Becker, vice president of hybrid cloud services for IBM, added that as the line between mainframes and distributed applications continues to blur, it’s clear organizations want to be able to treat mainframes as back-end platforms that make a wide variety of enterprise data available to those applications. That need is driving many those organizations to extend DevOps processes to mainframes.

    Historically, competition for control over application workloads within internal IT organizations between mainframe advocates and proponents of distributed computing  has tended to be fierce. But Becker said that as digital business transformation gains traction, there’s now a greater appreciation for the need to leverage transaction processing and big data applications that are widely deployed on mainframes. Not only is it not practical to rewrite all those applications, he noted, applications running on mainframes are more secure. The creates the need to extend out to the mainframe the DevOps processes that are being used to build distributed applications, he said.

    Zealotry that tends to focus on the merits of one platform above all others is usually counterproductive. The rise of DevOps presents organizations with an opportunity to bridge a divide within their organizations that, in some cases, is decades old. Of course, mainframe proponents are not likely to abandon waterfall and IT methodologies overnight. But DevOps processes can mainframe environments a lot more agile at a time when senior business and IT leaders are now judging the merits of one platform versus another increasingly on how flexible it allows the business to become.

    — Mike Vizard

  • ADDI Addresses the Problem of Dependency Management

    ADDI Addresses the Problem of Dependency Management

    Want to know what a bad day looks like? Imagine you’re a developer working your way up the career ladder. One day your manager comes by your cube to tell you that you’ve been assigned to implement a critical, new feature in the company’s premiere application. You’re elated. At last you get to show off your coding mettle.

    You spend the next two weeks working day and night to get the feature out. Finally, it’s time for release. You send out a pull request to merge your code into the codebase. Everything should be peachy. You can taste the stardom at hand. The next thing you know, your inbox starts to fill with emails complaining that your new code has broken the build. Turns out that the third-party libraries your code uses are older versions that have long since been deprecated. The code that works fine on your local system is causing havoc in the general codebase. Everything is going haywire. What should have been your hour of glory has turned into an episode of embarrassment and shame.

    You Have Entered Dependency Hell

    Anybody who has been coding for any amount of time has been in dependency hell. Those of us who programmed in early versions of Windows called it DLL Hell. Java developers have been burned by third-party .jar files that just don’t jibe as code moves down the release cycle. To this day, there is a legion of Python developers out there who are still struggling with the challenges of getting Python 2.7 code to work in newer Python 3 environments. Node developers face ongoing issues transitioning legacy code from ECMA 5 to ECMA 6. Dependency mismatch issues have been a problem throughout the history of software development. Mainframe developers have been blindsided by unknown dependencies since early batch jobs were run under JCL. Dependency mismatches are real and they hurt, sometimes too much.

    So, What’s to Be Done?

    The software industry has not been asleep at the wheel when it comes to solving the problem of dependency management. In fact, making dependency management easier—degrading it from likes of extreme dental pain to an addressable issue akin to an annoying muscle ache—has been a mostly successful undertaking.

    One of the early goals of the .NET framework was to do away with DLL Hell. (DLL Hell is a corruption condition in DLL dependency referencing caused when COM objects declared in the Windows Registry are out of sync with the calling code.) .NET avoids the Registry altogether and references DLLs directly using the file system or the more easy-to-manage Global Assembly Cache (GAC).

    Maven, a very popular Apache Project, brings a significant degree of order to dependency management for Java developers. Maven’s Project Object Model (POM) allows developers to declare exactly which version of .jar files their code needs to use. (See Figure 1.)

    maven-pom-01

    Figure 1: The Maven Framework for Java development allows projects to declare dependency versions

    Babel allows Node developers to move between ECMA 6 and ECMA 5. 2to3 is a program that will convert code written in Python 2 to version 3.

    Clearly, most programmers have confronted the issue of dependency management when developing new code. And, the industry has been active trying to lessen the burden of dependency management when introducing new code into an existing codebase. But addressing ways to management code dependency is not confined to PC-based computing; the mainframe community is actively addressing the issue, too.

    Which Brings Us to Mainframes

    The fact that code quality degrades of over time is not so much due to incompetent programming but rather the demands of continuous revision and the fast fixes put in place to meet the requirements of the moment. Sometimes down-and-dirty code that works today is preferable to more elegant approaches that will take months to implement.

    In the mainframe world, there can be decades’ worth of these type of fast fixes in play. Trying to improve code can be a roll of the dice. Usually what gets broken is a dependency well beyond the immediate scope of programming activity. As mentioned earlier, dependency management has always been difficult. That’s the bad news. The good news is that the mainframe community is keenly aware of the problem dependency management and has done something about it. IBM’s solution, System Z’s Application Discovery and Delivery Intelligence (ADDI), is particularly adept at addressing the issue.

    ADDI is a big product with a lot of features. One of the more interesting features is the Analysis Browser, which allows a mainframe developer to get a detailed understanding of all the dependencies in a particular application.

    Analysis Browser

    Figure 2: IBM Z ADDI Analysis Browser allows developers to visually understand code dependencies and program accordingly.

    Having a clear, visual picture of all the dependencies in mainframe application is a very big deal. Mainframe code is by nature onerous. There are a lot of parts that are hidden due to the immensity of the technology. Using human intelligence to try to figure out all the dependencies in force takes too much time. Hence, a tool such as Analysis Browser is indispensable when it comes to addressing the age-old problem of dependency management.

    We’re All in This Together

    In the past, identifying dependency problems usually resulted in someone getting woken at 3 a.m. to fix a mission-critical problem. Using a proactive tool such as ADDI’s Analysis Browser allows more people to get a lot more sleep. Comprehensive dependency management does not need to be the result of ongoing catastrophes in production; rather, quite the opposite.

    The first step to reducing the risks and calamities caused by dependency misalignments in code is to make a commitment to address the problem. The world of software development is littered with teams who just want to get through the current release and are more than happy to repeat the insanity dependency hell all over again in the next one. The excuses vary from, “We don’t have the time to do a solution,” to, “It may not be the best way to do it, but I’ll always have a job.”

    Once a commitment is made, then it’s a matter for tools and process. You use the tools to determine risky dependencies. You follow process to improve the release.

    Whether you’re in a distributed shop that embraces ephemeral, on-demand provisioning or a more mature mainframe shop working with Big Iron, the fact is that reliable dependency management is critical for the well-being of the enterprise. Yes, while it’s true that the details of coding and code management will vary from an IBM Z to an AWS cloud instance, the underlying thinking that brings good dependency management together is strikingly similar. As just mentioned, it’s a matter of tools and processes.

    In terms of implementing ways of dependency management that work, we might be speaking different languages. But, when you take a close look at the basic concepts behind effective dependency management, you’ll find we’re all saying the same thing.

    — Bob Reselman

  • CA Technologies Advances DevOps Automation Agenda

    CA Technologies Advances DevOps Automation Agenda

    CA Technologies further advanced its staged goal of unifying its disparate portfolio of DevOps automation tools by announcing today a new release of CA Workload Automation AE (AutoSys) software now directly integrated with the CA Automic One Automation platform the company acquired early last year.

    CA AutoSys is the older of two offerings and is positioned by CA Technologies as being able to support more complex workloads running on a larger number of platforms, including mainframes. CA Automic One Automation was acquired to bolster the automation capabilities CA can offer optimized for distributed computing environments.

    Gwyn Clay, vice president of product management for CA Automic, said it’s no secret CA Technologies has multiple automation engines. The long-term goal is to enable organizations to employ any mix of automation engines and associated DevOps tools as they see fit to create what the company describes a software factory.

    Other new capabilities being added to CA AutoSys include the ability to centrally manage all the various agents the company provides, support for connecting to Amazon Web Services (AWS) and Azure Database Services, improved load balancing and the ability to set up more custom email notifications.

    Clay noted the rate at which IT organizations are embracing DevOps varies widely. Just about every organization has at least one DevOps project or pilot in place, but most of them are still relatively nascent compared to the level of sophistication being applied by web-scale companies, he said.

    CA Technologies is betting that, rather than stitching together components themselves, enterprise IT organizations will prefer a more modular platform that requires less effort to set up without locking them into a specific tool.

    DevOps is coming to the enterprise in one form or another. But unlike web-scale companies, where developers and engineers have tended to work closely together from the inception of the company, enterprise IT organizations will navigate myriad culture issues. There has been a historic predisposition in enterprise IT organizations for developers to “throw code over the wall” to IT operations, with little regard for how that code might run in the actual production environment. IT operations teams, meanwhile, have not always been as forthcoming about the state of that production environment as they might be. That lack of trust and visibility means both sides often make decisions that are not always in the best interest of the overall organization. For example, an application workload might wind up being deployed on a public cloud, even though that platform may be both more expensive and less secure.

    At the same time, it’s still not clear to what degree warring cultures inside the enterprise will be able to put aside their historic animosities to create a coordinated approach to automation and DevOps. Mainframe and distributed computing teams to this day still battle for control over workloads inside the enterprise. Whatever the outcome, there’s no doubt various teams will eventually be forced to work more closely together to achieve DevOps goals regardless of whether they like it.

    — Mike Vizard

  • Mainframe Computing and the API Economy

    Mainframe Computing and the API Economy

    The API economy has come a long way since the days when I worked at a very well-known automotive website back in 2007. Back then, APIs were the thing that application programmers used at a very low level. Programming using web-based APIs was a rarity. In those days, we downloaded libraries into our local codebase and programmed against those binaries. I was programming in Java at the time, so the general practice was to use an application management framework such as Maven to get .jar files from the internet and incorporate those .jars into my code.

    Yes, there were technologies such as RPC that allowed us to access functions running on other machines directly and there were shops that used the technique extensively, but in my little corner of the world we accessed services directly through in-memory binaries. Also, we—the automotive website—published our data as HTML in web pages.

    Then something happened around 2010. It turns out that other developers outside the company wanted to use our automotive data. In fact, a lot of developers wanted that data. My employer saw the writing on the wall. Within a year, we were publishing an API that provided all the information we had on just about every car sold in the United States. We were in the API Economy big time!

    It was a transformational undertaking. It was also incredibly taxing. The company had to alter a lot of its development processes to meet the demands API publishing. Not only did we need to support publishing the data under XML and JSON, we also had to put in a security layer to make sure only those developers who were entitled to use the API had access. And, we had to provide comprehensive documentation that provided the support necessary so that a developer could use the API to full efficiency. The work beneath the surface of the API to keep data flowing and current was even more daunting. And, this was only for V1. We had yet to develop any sort of road map that described future versions.

    Was it hard work? Yes. Was it worth it? Yes. We were at the forefront of the API Economy. Moving our data out of HTML and into machine-readable formats such as XML and JSON provided a lot of commercial value, to the company and to other developers. It was a game-changer then. It’s game-changing now.

    The good news is that technologies have emerged that make API publishing easy compared to those early days. Today, most of the major players in the technology landscape realize that to stay commercially viable, they need to represent their services as robust APIs in a way that is easy to publish and easy to consume at web-scale. This is particularly true in the realm of mainframe computing.

    IBM Z Systems: A Significant Player in the API Economy

    There’s a lot of mainframe technology in force in the world today. A very large number of banks, financial services, governments and large-scale transportation entities have major mainframe installations. Many of these installations are IBM Z Systems. IBM is major force in this landscape—always was, always will be. With a workforce of more than 300,000 people, how can it be otherwise?

    One of the things that IBM has been very good at doing is devising technologies that allow services that reside in their Z System installations to be exposed as APIs. The way they do this is using a technology called z/OS Connect EE. z/OS Connect allows developers to expose Z System applications as APIs accessed via HTTP (See Figure 1.)

    Figure 1: z/OS Connect EE serves as the intermediary between an HTTP based API and a IBM Z mainframe

    Developers create an API using the z/OS Connect EE API Editor. The API Editor is an Eclipse-based IDE that allows developers to define the endpoint URLs for an API. (See Figure 2, below.)

    Figure 2: The z/Connect EE API Editor allows developer to define the HTTP methods and associated endpoints to that make up an API

    Then, once the endpoints are defined and HTTP methods (e.g., GET, PUT, POST and DELETE) are bound to services that reside in the Z System installation. (See Figure 3.). Each service maps to an application, such as a transaction in CICS, IMS, DB2, etc.

    Figure 3: z/OS Connect EE provides a way to directly bind an HTTP request to mainframe resources

    Not only does the z/Connect allow developers to represent services in a Z System as fully functional APIs, but it also has a feature that exports API definition as fully compliant Open API specifications.

    This is a big deal.

    Open API is one of the three most prominent API specification formats in use today. (The other two are RAML and API Blueprint.) A developer can use the Swagger specification that z/OS Connect generates to create interactive documentation for use by third-party developers. (See, Figure 4.)

    Figure 4: z/OS Connect EE has the ability to generate an API specification in Open API format that can be used to create interactive, online documentation automatically

    Again, this is a very big deal. One of the key factors for publishing a successful API is to provide comprehensive documentation. An API that is poorly documented rarely becomes a hit in the API Economy. The more comprehensive an API’s documentation is, the more widely used it will be.

    z/OS Connector EE + Eclipse = A marriage made in heaven

    I am a big supporter of using tools to reduce the labor of working with complex technologies, particularly with something as broad and multi-faceted as mainframe computing. The z/OS Connect EE API Editor fits the bill. It’s embedded within the Eclipse IDE. If you know how to use Eclipse to make a Java program, you’ll find using z/OS Connect EE API Editor to create Z System API to be an inviting experience. Yes, you might have to spend some time get up to speed on mainframe technologies such as CICS and COBOL. But, the good news is you won’t have to learn a new programming environment to do it. Just think of the API Editor as Eclipse wrapped around z/OS Connect EE and the IBM Z System computing environment.

    This 10 minute video does a really good job demonstrating how to use the Eclipse based z/OS Connect EE API Editor to create a full blown REST API using services provided by a IBM Z System mainframe. It’s pretty amazing.

    Once an API is published from a z/OS system, it can be used internally or exposed for public consumption. Representing Z System services as an API – is a significant step toward making mainframe technology a first-class contributor to the API Economy. In the API Economy, consumers care little for the underlying technology. What matters is the service. It’s striking in a way: What may look like a cloud-based API on the outside is really an IBM Z System underneath the covers.

    The API Economy Moving Forward

    The API Economy has come a long way since those first days almost 10 years ago when we wrote our first GET /make/mode/year request at the automotive website. The days of hard-coding routes and manually creating documentation have come to an end. Good riddance. To be honest, that type of development was not only a waste of labor, it also was questionable programming.

    Today, modern tools such as z/OS Connect EE API Editor allow developers to focus on the challenges of designing APIs that make a difference. The focus on design is critical, particularly as we move into the era of the internet of things (IoT). In the not too distant future, most API activity will be conducted between machines—small devices, many pushing the boundaries of miniaturization, talking among themselves and to other larger systems. The volume of data these devices will create will be well beyond today’s norms. Interestingly enough, mainframe technology is geared to handle this extreme volume of data.

    Mainframe technology will play a major role in the IoT ecosystem and the API Economy. If I were a gambling man and I wanted to position myself to be in the right place at the right time as the API Economy evolves, I would place a significant bet on getting involved in Z System development now. Technologies such as z/OS Connect EE and its API Editor open the doors to many lucrative opportunities. It’s up to us to make the decision to walk through them.

    — Bob Reselman

  • Application Discovery and the Value Proposition of IBM Z ADDI

    Application Discovery and the Value Proposition of IBM Z ADDI

    Discovering how an application works can be a difficult, expensive undertaking. That’s why architectures based on REST are so popular. The architectural style provides an easy-to-implement interface that allows consumers to use an application productively without having to understand anything at all about its internals. All a developer needs to know to work an application is how to interact with the resource represented by the given endpoint. What’s going on behind that endpoint is another matter.

    That’s the good news.

    The bad news is that when it’s time to make changes to the application’s internals, things can get difficult. Many times a well-defined interface is hiding a pile of spaghetti code. Sometimes a developer might be able to find an analysis tool that will help make sense of things. Or, maybe there’s documentation that explains it all. But, it’s not unusual for developers to have to bite the bullet and go through the source code and deployment scripts line by line to figure out how the application works. Such work incurs significant expense.

    Discovery: Understanding Dependencies in an Application

    Mainframe developers have been solving the problems of application discovery for years. IBM has been at the forefront of addressing application discovery with a comprehensive solution called Application Discovery and Delivery Intelligence (ADDI). ADDI allows a developer to inspect a IBM Z mainframe application and analyze its performance.

    Application discovery is accomplished using Application Discovery Intelligence (ADI), which is part of the ADDI toolset. Developers and system analysts use ADI, which integrates seamlessly into the Eclipse integrated development environment (IDE), to discover the assets used in an application and also to determine the dependencies between them once discovered.

    Figure 1 below shows an example of the ADI graphical interface. The IDE provides a high level overview of the application (1) as well as a listing of its components (2). Developers can drill down to look at details in a central viewing pane (3). The IDE provides a detailed listing of  a component’s connections and associations, such as subscriptions to message queues or SQL calls (4). Also, developers can view details about a particular assets, such as a SQL query (5).

    Figure 1: Application discovery intelligence describes components in an application and describes interactions between them

    Having immediate insight into the structure and operation of an application reduces the expense required to improve it. Developers save a lot of time not having to peruse code on a line-by-line basis. Yet, this is only part of the cost-saving. Understanding the composition of an application is an important first step. Understanding how an application performs is essential for implementing improvements. This is where delivery analysis comes in.

    Delivery: Providing Quality Service 24/7

    Ensuring quality service on a 24/7 requires that availability of up-to-date runtime information. A good performance monitoring tool provides the ability to to drill down to determine the cause of an issue. IBM Z provides such as array of tools. Remember, meeting service agreements to specification is and has been a critical activity in the mainframe computing culture. It’s part of a mature business process.

    IBM Z Application Delivery Intelligence provides mission-critical insights on a drill down basis. As shown below in Figure 2, IBM Z Application Delivery Intelligence Analysis reports a dangerous condition (1). Then, engineers can drill down to view associated metrics (2) and then even deeper, to view a timeline that shows environmental conditions such as response time from the database and CPU time consumption (3).

    Figure 2: IBM Z Application Delivery Intelligence provides drill-down reporting that allows engineers to identify root causes

    One of the drawbacks of architectures that aggregate heterogeneous systems is that relationships between components become opaque. For example, an application that uses a database service to store and retrieve data has no direct insight into the underlying query behavior of the database service. All that can be accurately reported is the request and response time to and from the service. However, when both application logic and data storage reside inside the same location, reporting details becomes easier. But still, drill-down correlation between systems is still difficult when components are in a common location, such as a virtual machine, yet isolated from one another due to strict encapsulation. Mainframe systems, however, do not have the problem because all components reside in a single location in which access to components is transparent. Thus, cross-component drill-down is easier to accomplish.

    Built to Scale in the Modern Cloud

    When it comes to computing at scale, mainframes were always meant to handle multiple users in a high-volume, transactional environment. Mainframe computing does not lend itself to the type of latency bottlenecks that come about when there are racks of commodity PCs operating with with varying degrees of reliability. The hurdle that mainframe computing had to overcome was making it so it could be accessed using standard web-based standards, most notably REST. IBM addresses the problem with z/OS Connect, a technology that allows IBM Z application functionality to be represented by a REST API. Once a REST layer is added onto an IBM Z system, it becomes just like another resource in the cloud computing ecosystem. And, an IBM Z mainframe computer is designed to be fault-tolerant and highly available. There are IBM Z systems in production that have run without interruption or downtime for decades.

    Making Discovery and Delivery Less Expensive

    Discovering how an application works and ensuring that applications in production meet performance expectations are two of the most important activities in today’s modern enterprise. Application Discovery and Delivery Intelligence provides the tools to meet these needs in the IBM Z cloud computing ecosystem. Using ADDI provides the insights necessary to ensure that service level agreements are met cost-effectively to the satisfaction of all. When it to making applications that matter in a world of web-based computing, ADDI provides an essential value that is difficult to match.

    — Bob Reselman

  • DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    In this DevOps Chat we sit down with a frequent guest on DevOps Chat, Rosalind Radcliffe, distinguished engineer and mainframe expert from IBM. Rosalind talks to us about the latest generation of Big Iron from IBM, the z14 systems. Also, we discuss some of the new API and functionality that allows you to do just about anything with your mainframe that you do with your other computing platforms.

    Rosalind is always an interesting interview with lots of great information.

    Note: There are references to a video chat throughout the conversation. We tried to record this chat as a video, but unfortunately, the technology just didn’t work out well for us. But, as usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud, and you’re listening to perhaps the first video chat or video DevOps Chat from devopsy.kinsta.cloud. And I’m happy to have as my first video chat guest none other than Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe: Happy to be here, as always.

    Rosalind Radcliffe

    Shimel: Well, you’re not going to be able to sit and make faces while you’re talking because we can see you. But thanks for joining us. Let’s jump right into things. First of all for our audience who may not know Rosalind, Rosalind is a distinguished engineer with IBM and works within the IBM Enterprise Systems division, mainframes, e-systems, author, engineer, well-known speaker and just a great resource for anyone who is interested in DevOps, mainframe, systems of engagement, systems of records kind of stuff, and a frequent guest here of ours on devopsy.kinsta.cloud.

    So, Rosalind, the last time I saw you was over at Gene Kim’s DevOps Enterprise Summit in San Francisco. And I thought it was a great show this year. Had a chance to do a bunch of interviews. I did a panel on DevSecOps. But more than that, I really enjoyed speaking to a lot of the people in attendance there, a lot of the attendees. Any key takeaways from you on it?

    Radcliffe: Well, I think it was another really good conference, but it was one year next. So there was a lot of people who really have done the DevOps transformation or are a good long way on the DevOps transformation. And so there were a lot more stories about the value that they’re getting and how they’ve transformed, and more about the organizational transformation that happens after you start a DevOps transformation. So I thought that was very good.

    We also had more mainframe customers talking about their transformations, and it was really good to hear the stories about mainframe is really just part of the DevOps pipeline, and more and more customers are starting to see that.

    Shimel: I think so. And Rosalind, if you don’t mind, I actually wrote an article coming home from Gene’s event called “The DevOps Cha-Cha.” And it’s about this sort of undercurrent. I didn’t necessarily see it in the presentations, but I got it in speaking to people there. And that is this sort of whispered thing that hey, this DevOps thing isn’t that easy. Right? We thought it was going to be easy.

    And you know, my DevOps transformation is not going as planned, and it’s not going as fast as we wanted. And it’s not—there’s a lot of work involved here. And I don’t know what gave people the impression that it’s a hockey stick. You know, it was straight up. Things seldom are. I think DevOps can be lumpy, or DevOps transformations can be lumpy. And it’s a little bit of three steps forward, two steps back, cha cha cha, and so forth. Your opinion?

    Radcliffe: Well, I would absolutely agree. I don’t think people understand the cultural challenge to this transformation. Because it really is all about culture. And it’s not just bringing in tools, and a lot of people think, “I’m going to bring this toolchain in and it’ll all be fine.”

    And maybe some of the teams that works for. But there are a lot of teams that that’s really just not going to work for. And there’s just no way that we can just have this continue in the environment. We really have to make sure we are understanding that this is culture, and that the culture is really, has to change. And it’s across the entire organization.

    I think the other thing people didn’t realize is that it is a … what’s the best way to put it? It’s not just culture and you’re done, or it’s not just do it and you’re done. It really is a continuous improvement process. And we like to talk about the kicks team because they’ve been doing this for 15 years or something, and they know they’re not done.

    Shimel: Mm-hmm.

    Radcliffe: So it’s not something that ends. You learn your lessons. You get better. And you learn a new lesson, and maybe you didn’t get better. And so you learn the lessons. And it really is this continual improvement. And so it’s not easy. It’s not a piece of cake. But it delivers real value if you move down this pipeline.

    Shimel: Yep. I mean, takeaways. Dev ops is never done, right? You’re never done with DevOps. And it’s only a failure if you stop trying, right? Anything else is just feedback loops. [Laughter] Everything else is feedback loops. So I think those are great takeaways from that.

    So I went from Gene’s to another event to another event. And we’re rapidly, you know, Rosalind, approaching event season. And, of course, IBM’s big event this year is a little different than years past. It’s called IBM Think, right?

    Radcliffe: Yes.

    Shimel: It’s in March in Vegas. Can you –

    Radcliffe: Yeah. It’s going to be an interesting event. We’re bringing everything together in one. So we used to have in our connect, and Watson’s event, and internet of things. You take your choice of names. Now it’s all one. So we’re going to have one big IBM event for all of our technology, all of our parts of the product. And they’re really trying to bring it in a focused way to make sure it’s a set of customer stories on what they’re doing and how they’re doing things.

    Shimel: Do you know the exact dates, perhaps, off your head? Or if not we’ll –

    Radcliffe: Yeah. See, it’s March 19th. It’s March 19th. The first day is an inner-circle day. And the next Tuesday, Wednesday and Thursday are the main days for the conference. And so it’s a shorter week this time, not making people come in on a weekend and giving you a chance to get home, which I think is a very good thing. But it’ll be a fully packed set of days.

    Shimel: Fantastic. Hopefully we’ll see you out there. I’m not sure about devopsy.kinsta.cloud’s plans yet around it, but we will be making plans, for sure. So Rosalind, you spoke a little bit about Gene Kim’s event. We spoke a little bit about the upcoming IBM Think event. Let’s focus in now on Z systems, enterprise systems. I know you guys are, you released a new generation. What was it, around September or August?

    Radcliffe: It announced in July, July 16th or 17th, and became available in September. And yes, the Z14 with the latest announce.

    Shimel: Yep. And it’s brought a whole bunch of stuff to the forefront, probably some of the biggest might be around security and encryption from my point—humble point of view—anyway. But you’re excited about some new stuff coming up with the Z systems we were talking. Why don’t you share it with our audience?

    Radcliffe: Yeah. I’m really happy. We’ve been doing a lot of work to make the dev ops pipeline work for z/OS software. And a lot of customers are turning to open source. And so they want to use Git. And so I got Rocket to port Git to z/OS, so that’s the first step. And that’s great. That’s been available this year. But we have to have a build system. And so we have made available something called dependency-based build, and it’s in beta, and it will be GA by Think. The idea is you can use Groovy Scripts to write your build definitions for z/OS.

    So think about that. It’s not, you know, JCL. It’s not different. I can use Git just like any other language. I can use Groovy just like any other language. I could write my build scripts. And it’s not different. It can make our COBAL and PL/1 in assembler look just like all those other modern, fun languages.

    And really they—okay, assembler might be a little hard. But, okay, other than that, COBOL is just English and PL/1 is a pretty good language. So why not? The fact that you have to do things so differently, we want to get rid of all that. And so this new capability, it’s in beta. Anybody’s well—it’s an open beta. Think about this. IBM open beta? Yep. There it is.

    Shimel: IBM –

    [Crosstalk]

    Radcliffe: Go play with –

    Shimel: That would be neat. [Laughter] Where can people go play with it? Did you have a URL or section?

    Radcliffe: We have a URL. I’ll get it to you so you can post it. It’s not a friendly URL.

    Shimel: You know, I can’t help but smile, Rosalind, and think about some of my friends and family who aren’t in the tech industry listening to this, or watching this, and hearing that we’re going to be playing with some Groovy scripts, what’s going through their head. But that is great news. And it’s part of this bigger movement.

    You touched on it a little bit. We started at Gene’s event, and it does show. And that is initially with DevOps we’ve been through the binary IT mode, the multi mode, multi speed, binary speed, all this nonsense where let’s treat the mainframe folks as special, and all of that.

    But I’m glad to see that—and Rosalind, I think I ran into you at CA World, perhaps, right, where IBM was a major sponsor. And that seems to be the message coming out of the enterprise world now, the mainframe world, which is that’s nonsense, that we’re not going to stand for being labeled special or anything like that. We move as fast as the next guy does, or as fast as the other systems do. We use the same languages in a lot of instances. And we’re even updating the languages that we do use to make them more relevant in today’s world.

    So to me that’s a huge message, right? That we need to continue hitting home, though. Because I still hear people talking about multispeed and all of that stuff.

    Radcliffe: Yeah. But bimodal is something that needs to go away.

    Shimel: Uh –

    Radcliffe: It just needs to go away. We’re done with it.

    Shimel: Okay.

    Radcliffe: The idea that things are going to go at different speeds is true, but it’s not based on platforms. If I build an API, I really hope I do a good job of that API. And it doesn’t matter if it’s running on a system of record or a system of engagement, it’s running in Java, or it’s running in Cobalt. If I write good code, I’m not going to be changing it 1,000 times a day. So the point is if you’re building APIs, you’re going to build them. But you need to be able to change them as fast as possible.

    So it doesn’t matter the platform. I should be able to deliver that code today. I need to make a change, let me deliver it. And I really—I guess I want Z to be considered special for its qualities of service, i.e. its reliability, its scalability. Not because it’s different in the way you do work for it. So if it’s just another node in your pipeline, it’s just another node. It just happens to have a different set of qualities of service. And if you build your node, or your Java, whatever, and you end up needing the qualities of service of Z, run it on Z. Why not?

    Shimel: Agree.

    Radcliffe: And let’s get the differences because you think a system of record has to be slow, or the differences because you think Z has to be slow. I mean, it’s funny to me. We call the mainframe an old system, but really with the Z14 and the LinuxONE announcement, it’s the most modern platform that exists out there. It’s the most modern chip. So how is it old?

    Shimel: Yeah. Yeah. I hear ya. A hundred percent agree. Rosalind, you know, we’re almost at the end of our time on this experiment and I do hope the video comes out. But if not, the audio will. And if you’re listening to this without video out there, it’s because the video didn’t work out so good. But at least we’ve got the conversation imparting the references to the video.

    Rosalind, we hope to see you soon. Maybe between now and Think we can do something a little more in-depth, a webinar or something about what we’ll see from Enterprise Systems at Think and what else we have coming down the pike as we move closer to Think. And until then, though, have a merry Christmas, happy new year, happy holidays, and thank you for always being available to us here at devopsy.kinsta.cloud.

    Radcliffe: Well, thank you. Thank you for your time. And you enjoy the holidays, as well as everyone who is listening if they hear this before the holidays. Merry Christmas.

    Shimel: Yes, yes, yes. All right. Rosalind Radcliffe, IBM Enterprise Systems, distinguished engineer, and our guest on our very first video DevOps Chat. I guess they’re not DevOps Chats. All right, Rosalind. Thank you. Have a great day, everyone.

    — Alan Shimel

  • IBM Z: It’s Not the Dog. It’s the Trick

    IBM Z: It’s Not the Dog. It’s the Trick

    There’s a piece of conventional wisdom that runs rampant in the tech-o-sphere: You can’t teach an old dog new tricks. Supposedly, once people become enamored with a technology and use it for a long period, they are loathe to adopt new ones. We’ve all heard it, and some believe it. Me? I not buying it any more than I believe that you can’t teach a new dog old tricks. From where I stand, a good trick is a good trick, period!

    So let’s talk about a really good trick: mainframe computing. It’s technology that is used by many business sectors—airlines, insurance companies and banks. And, it’s been designed from inception to support interaction from hundreds—if not thousands—of users. Yet, many perceive the trick to be old dog, that’s it’s not applicable to modern computing.

    Actually, the opposite is true. It’s an important trick that should be used by any dog, new or old. It’s a question of adaptability: how to make the trick useful in any circumstance.

    Let’s put the trick-and-dog analogy aside and talk directly. Companies are sitting on a boatload of mainframe assets that can and should be leveraged for use in this world of mobile devices, APIs, microservices and speed-of-light DevOps deployment practices. The question is, how?

    To make mainframe technology viable in modern cloud-based paradigms, it must satisfy four conditions. The technology must:

    • Support information exchange using modern API standards;
    • Support coding in modern programming environments;
    • Support automated testing throughout the deployment pipeline; and
    • Be deployable according DevOps best practices.

    IBM Z, a mainframe-based technology, has done a great job of meeting these conditions. The various products and  toolsets that IBM provides for IBM Z technology make working with IBM Z in today’s cloud computing environment surprisingly easy. Let’s take a look at the details.

    Supporting REST APIs for Information Exchange

    REST is fasting becoming the standard by which information is exchanged between systems over the internet. As mobile devices and the internet of things grow as the means by which users interact with applications, the data these applications require is accessed in real time using REST. Today, REST is a first-class citizen in IBM Z technology. A key feature of IBM Z Application Discovery and Delivery Intelligence (ADDI) is the capability to discover  applications running on IBM Z hardware and identify them as potential  REST API candidates. Support for REST makes IBM Z applications consumable to a wide variety of computing devices. Also , supporting REST means that IBM Z applications integrate easily with standard DevOps testing and deployment practices.

    ADDI provides the support for REST that allows IBM Z to be an agnostic resource on the internet

    In the world of modern, cloud-based computing REST is the lingua franca of information exchange. Supporting REST makes IBM Z data and transactions available to the modern digital ecosystem.

    Support for COBOL and PL/1 Programming Using the Eclipse IDE

    The IBM Explorer for z/OS, which is part of the Application Delivery Foundation for z Systems (ADFz) tool suite, allows COBOL and PL/1 developers to code in the Eclipse Integrated Development Environment (IDE). Eclipse is well-known to a broad range of developers working in languages such as Java, PHP, Node and Python. Using Eclipse to do IBM Z programming under COBOL and PL/1 allows developers to have a shared programming experience and increase their productivity by an average of 15 percent.

    Although the actual lines of code the developer creates will be particular to the developer’s programming language of choice, the unit testing and debugging experience Eclipse provides is similar regardless of language. A developer uses Eclipse to unit test code as it’s being developed. If the test fails, the developer sets breakpoints and starts the debugging session to inspect the code at runtime. The way code-test-code-debug is conducted in Eclipse is consistent. Thus, the skills acquired using the Eclipse IDE are easily transferable between languages.

    Having all developers work in a common development environment creates a shared experience—an important step toward breaking down organizational silos. Reducing the silos that isolate knowledge workers from each other so they can collaborate better and faster across teams and geographies, combined with deploying code in an automated CI/CD pipeline, significantly speeds a company’s ability to get code to market while also making collaboration easier across teams and across geographies.

    Support for a Wide Range of Testing Techniques

    For a software development framework to be viable in a CI/CD infrastructure, it must support a wide variety of testing capabilities. In addition, testing needs to be verified via automation. As mentioned above, IBM Explorer for z/OS allows developers to create unit tests on COBOL and PL/1 code. Once unit tests are created, they can be automated for use throughout the development pipeline. Test reuse via automation speeds up the deployment process significantly.

    However, testing at the code level is not enough. As code moves through the modern deployment pipeline, it must be subjected to load and performance testing. Test engineers accustomed to using mainstream tools such as Apache JMeter or Rational Performance Tester will have little problem using IBM Z Workload Simulator for z/OS to do load and performance testing. The concepts behind load and performance testing are similar, regardless of the language and environment driving the development process. For example, Workload Simulator for z/OS allows test engineers to emulate hundreds, if not thousands, of users to exercise the software under test. Being able to create stress on a system in a controlled, reportable manner is critical for getting good performance testing metrics.

    Supporting the DevOps Deployment Practices

    Basic to DevOps best practices is the notion of releasing quality software quickly and incrementally. Instead of waiting months to do a release that has many features, the DevOps practice is to release one feature at a time, as quickly as possible. In the DevOps world, release cycles are no longer a matter of weeks and months, but rather days, if not hours. To achieve the fast release cycles emblematic of DevOps, management of the deployment pipeline must be automated.

    However, when it comes to mainframe assets there is a hitch in terms of deployment units. In the microcomputing software environment, deployment units typically take the form of an executable file, supporting dependency file or script file such as .exe, .jar, .js or .py. Also, given the rise of container technology, the deployment unit can be the container itself. In terms of IBM Z, the deployment units are the file and the job.

    Engineers at IBM Z have taken the clever approach to managing asset deployment. File and jobs have become abstracted deployment units accessible via the IBM Explorer for z/OS Atlas APIs. Thus, IBM Z components can be treated as any other artifact in the deployment pipeline. DevOps engineers use the APIs exposed by Atlas to cancel a job or delete an associated file. Standardizing direct access to the IBM Z deployment pipeline using REST APIs gives DevOps engineers the flexibility required to get working code released quickly.

    DevOps engineers not only can automate the pipeline, but should ad hoc intervention be required, they also can use the Atlas APIs to make the changes required at a moment’s notice. Combining the Atlas APIs with ADDI’s ability to collect, correlate, calculate and produce mission-critical application and testing health metrics, as well as trend analytics, makes IBM Z a first-order participant in the world of cognitive DevOps.

    Putting It All Together

    One of the great things that the internet has done is to create a standardized way by which any computing system can interact with another. As long the system supports REST, regardless of whether it’s a smartwatch, a cellphone or a large-scale computing environment such as IBM Z, it’s a leveragable asset on the internet. And, if the system meets the conditions that define DevOps best practices, it can be managed with the degree of control and predictability required to participate in the breakneck release cycles that are part of modern software development. It really doesn’t matter whether the system is new or old, as long as it can adapt to present demands. Adaptability is key to longevity, no matter the age of the dog or the trick.

    — Bob Reselman

  • DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    IBM recently GA’ed perhaps its biggest zSystems mainframe release in the last decade or longer. The z14 mainframe from IBM has also been designed from the ground up to be DevOps-empowered. From APIs and other integrations to language support, the z14 is IBM’s most advanced mainframe ever. I had a chance to speak with Hayden Lindsey, VP of DevOps Enterprise Systems for IBM, about the z14.

    Hayden gives us the low-down on how the z14 has been designed to work in hybrid environments. It also works well with modern CI/CD tools such as Urban Code and others. Additionally, APIs give it the ability to integrate with many different environments, tools and apps. It is truly a mainframe for today and beyond. Hayden does a great job of describing all of this.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Enjoy!

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 117632″ width=”130″ height=”130″] Hayden Lindsey

    Hayden Lindsey, Vice President & Distinguished Engineer – DevOps for Enterprise Systems. Hayden is responsible for the development, product management, sales enablement, and services of this portfolio. He has worked at IBM for 28 years and has held a variety of positions, including software developer, product architect, product manager, co-leader of the Eclipse tools platform, and director of the WebSphere Studio/Rational modeling and construction tools. He has a bachelor’s degree in Mathematical Sciences from the University of North Carolina at Chapel Hill.[/su_pullquote]

    Alan Shimel: Hi, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Our guest on this episode of the chat is a good friend of ours, Hayden Lindsey, VP, Enterprise DevOps at IBM. Hi, Hayden, welcome to DevOps Chat.

    Hayden Lindsey: Hi, Alan. Good to be with you again.

    Shimel: Good to have you here. Hayden, it’s a big day—big day for the folks over at the IBM Enterprise team. It’s the general availability of z14 today, isn’t it?

    Lindsey: It sure is. Yes, we announced this back in the middle of July and we’ve now been making our products available. A lot of mine were available the latter part of last week, and now the box itself, GA, today. So—a big day.

    Shimel: Fantastic. And Hayden, just—you know, our audience being so focused on DevOps, they may not realize the full scale of what the z14 release is about. What it is, it’s a combination of hardware—as you mentioned, a new box. There’s a ton of software, there’s a tone of integration—it’s just chockfull of all kinds of goodies. Can you give us kind of a—at a high level, the scope of z14?

    Lindsey: Sure. And I think what you see is the result of pulling software, both middleware and tools, from the various divisions that we used to have like Rational and WebSphere and moving those into a single z or mainframe focused brand.

    And so, in contrast to most prior hardware releases where you’d be hearing about the speeds and feeds and, you know, the z13 had the fastest processor of any box on the planet—this time, the focus is more on the entire solution that involves both hardware as well as software and tools. And so I think—we worked on that, we did design thinking, we had sponsor users, we did the whole nine yards form the hardware up through the operating system, middleware, and tools, and I think that made a big difference.

    And so this time, for example, we have something called pervasive encryption. We all know how important security is, we all hear about these breaches that are happening—Experion being the most, or Equifax being the latest one. And, of all of the records that have been stolen, and I think it’s something like 9,000,000,000 since 2013—only 4 percent are encrypted. And this new mainframe lets you encrypt 100 percent of the data with no impact to performance. So, that’s just—that’s one example. Clearly, there’s hardware stuff there, but there’s also middleware that had to be involved in making this solution. So, that’s an example—it’s really cool.

    Shimel: That’s actually a big example, Hayden, because you know what? Encryption has been around—I mean, I spent 20 years in the security space and encryption has been around for most of that. The problem was the hit you took on performance when you encrypted and then had to decrypt and re-encrypt just the latency and—

    Lindsey: And the programmer had to do it. [Laughter] Or the database administrator had to set it up for the database, but then what about when it was being used in the application? And so that was—this is what is being solved, where you don’t have the time inhibitor of people doing it, and then you also don’t have the performance impact where it makes a system unusable.

    So, I think this could be really groundbreaking for the companies and the government agencies around the world that deal with sensitive data.

    Shimel: Sure—and we all do now. Hayden, you said something else, though, that I wanted to key in on, and that is sort of moving away from the speeds and feeds, if you will, metrics of—you know, to measure the value of anything. And I worked with a woman once, and she used to call that bag diving. Right? You know, when you gotta start getting into the speeds and feeds to show the value of your product, you’re diving into your bag instead of talking the true value.

    Lindsey: Right.

    Shimel: So, I’m happy to see that that’s kind of the path that IBM is taking, talking about the value, but I also think it’s a result, as you said, of so much being added into here, right, from the design thinking around the entire release, if you will, to the integration with things like cloud, with the DevOps entire tool set and methodologies that IBM and others have developed.

    This is so much more than just, “Oh, we put—this is the next iPhone with the faster processor.” This isn’t the next z with the faster processor, it’s much more than that. As I think I—maybe you said it earlier or maybe we talked about it off-mic. This is probably the most substantive release for z in at least a decade.

    Lindsey: I think it is, and of course, the market will tell us if our aspirations come to bear or not, but I certainly think the encryption element is just—well, I think it’s phenomenal, and it could be very, very, very significant for virtually any company out there.

    And then we’ve got more on machine learning and analytics so that you can do in transaction analytics rather than doing it after the fact and having to try to back out or just write off fraudulent transactions. And, of course, we’ve done a lot with our DevOps portfolio compilers. But I really do think, maybe, since we put Linux on the platform, it’s that significant.

    Shimel: Wow. Huge. So, Hayden, we are about DevOps here, so let’s focus in a little bit. I mean, one of the nice things is, I’ve seen some briefings around how you can use the new z14s with the IBM Enterprise DevOps solution and really sort of leverage—I don’t wanna use the term bimodal multi-speed nonsense. Leverage integrating your z system with cloud systems into one coherent business strategy. How’s that sound? [Laughter] So, talk about it.

    Lindsey: Yeah, so one of the three themes for the release is open and connected, and that obviously ties into a hybrid cloud strategy. It ties into, you know, a digital economy or digital transformation. It ties into API economy—whichever angle you want to take, you have to be able to make the data that resides on the mainframe, which is estimated that roughly 80 percent of the Enterprise data in the world resides on and is managed by the mainframe, and about 70 percent of the business transactions.

    And so, if you want to, though, make that available to your new iPhone X app, as we saw introduced yesterday—you know, or 10 or whatever they’re gonna call it.

    Shimel: Mm-hmm. Yeah, they’re calling it 10.

    Lindsey: They’re calling it 10 using a Roman numeral.

    Shimel: Yeah.

    Lindsey: But, you know, if you’re gonna do that, you have to make it easy to access the data and transactions, find those transactions, understand them, because very likely, they were written by somebody who’s not around any more or had moved on to other jobs. And so, you need to have tools that make API enabling and opening up and connecting to the mainframe easy and efficient, and just as easy, just as efficient as you would if you were opening up something on the Linux platform—although, of course, you have Linux on z—or a Windows box or anything else. So, that’s—it’s essential that we allow z to participate in the broader digital economy, API economy, and that’s what my team has been focusing on, along with other teams in IBM.

    Shimel: Sure. So, now, Hayden, in that same vein, you know, there’s still that mainframe attitude where, you know, we don’t open our mainframe up to all of these APIs, and maybe we don’t want to hook into our systems of engagement, you know, up in the cloud or what have you.

    For clients listening out there—and a lot of our listeners are Enterprise class, they work in Enterprise class organizations—how important is it that they really consider opening up, you know, their mainframes to this API economy, as you called it?

    Lindsey: Well, I think increasingly, certainly, the IT and line of business executives, the clients with whom I work, are realizing they have tremendous assets that they could leverage if they were to make them available. Nobody—at least no companies I know of, or government agencies, have the resources to just recreate everything from scratch. And, I think if you look back at what the analysts were saying back in the SOA era, they said, you know, it was five times faster to create a service leveraging something that exists that already does the same thing or something very similar than it is to create it from scratch—not to mention the fact that, if it already works, you’re likely to have higher quality as well. And I think the exact same analysis would prove to be true now that we’re talking more about RESTful APIs.

    So, I think more and more clients realize they need to expose that value. The key is, just, it’s sometimes daunting when you’ve got—you know, the estimate is like 250,000,000,000 lines of COBOL, not to mention PL/I and Assembler and 4GLs and so forth. It’s getting your arms around applications that were probably created in a more monolithic, less well-structured fashion. You need to do refactoring. You need to discover what is there, and then put together a plan for doing that API enablement.

    But I think people know they need to do it, it’s just, sometimes it’s viewed as a daunting task and they have to figure out how to get started, and we have something called the digital transformation model that we’re rolling out to help our clients put a plan in place.

    Shimel: Got it, and I agree. So, you’re just setting me up for my next things here, but—so, that’s the biggest question we hear at devopsy.kinsta.cloud, Hayden, which is—hey, this is all great. How do we get going? How do we roll this? How do I get executive buy-in? How do we—is there a one, two, three? Is there a blueprint I can follow.

    So, z14, let me throw it right back to you—where do we start? How do they get moving with this? How do they—and specifically, how do they start incorporating the DevOps and API stuff into this?

    Lindsey: Yeah, it’s the question that I hear from virtually every customer I talk to, and I’m getting ready to do a tour in Europe next week, and I’m sure it will come up in every single meeting. And the fact is, every customer is different, so there’s no single answer. And, within any given client, they have applications that span the gamut from nearing end of life to ones that are under active or brand new development. And so, what we’ve—but, of course, there are patterns and similarities across clients and application types, and there are best practices that we have gleaned by working with clients through the years, and that’s where I mentioned this thing called the digital transformation model.

    We’ve shifted to this way of working with our clients to focus on applications rather than one answer for the Enterprise—hey, you should start with deployment automation, or you should start with test automation. That answer should not be an Enterprise answer, it should be for this suite of applications because of what their current state is, the as-is state, and what you desire the to-be state to be. If you just need something to run efficiently and you’re gonna replace it in a few years or retire it, all you want it to do is run efficiently.

    So, use our latest compilers, but you know, the fact of the matter is, putting in a fully automated pipeline is likely a wasteful effort. Whereas, on the other end of the spectrum, for the things under very active development, that’s where you want to do DevOps in its fullest, and really, it’s just a matter of what steps do you take to get there.

    And so, this model that we’ve come up with has four levels—the first one I described about, just do your compiling, is run—just run it. Just run it efficiently. The next is maintain, the next is expose, the next is evolve. So—I mean, and I don’t know if we’ve got the best names in the world, but the fact is, you really need to think about, for the business, what degree of DevOps adoption do you need for a given application or application suite. So, that’s the more, I think, realistic answer that we’ve been using with clients this year and a tool that we’re using that’s different from what we’ve done in prior years.

    Shimel: Excellent. So, Hayden, I mean, just to illustrate this, I remember back at Interconnect last year, you know, we had the whole little DevOps TV booth set up, and I was interviewing some IBM clients. And one of them, it was a bank, and I forget if they were from Poland or the Netherlands now, or maybe even Australia. They were IBM’s z System customer and they had just updated, I wanna say, from COBOL 4 to 5—maybe it was 5 to 6, I don’t remember now.

    But they had just updated their version of COBOL, and it made a huge, huge difference for them in terms of performance and—

    Lindsey: Yeah. Yeah, exactly. You know, we’ve—one of the things that our compiler team does every single release, and this starts from the very earliest days of, we were just imagining what the new mainframe or new power platform is going to be. We were working hand in hand with the hardware folks.

    And, you know, with COBOL specifically, where something like 70 percent of the world’s business transactions are running COBOL, obviously, performance does matter, and so this is where you can get into a little bit of feeds and speeds. Mainly because, not because—some of the numbers aren’t eye popping, but it’s because you can be more responsive for your clients. But with some compute intensive apps, they run 16 times—not percent, times—faster on the latest compiler, which is 6.2, versus 4.2, which may be where that client was coming from. So, that’s skipping the version 5 things, but we still have the majority of our clients on the 4.2 version.

    So, it’s tremendously faster, but this is by doing this joint development. You know, if you put new instructions or new vector support in the hardware and the compiler doesn’t generate these new instructions, well, then, obviously, no client is gonna be able to take advantage of it unless they want to write their own assembler. So, you know, our compilers are delivering tremendous value, and I gave you a COBOL example, but you get similar results with PL/I and with our automatic binary optimizer that basically just does the, tries to do the work that the compilers do, but just working on binaries rather than having you go back to the source.

    So, it’s a big deal. You know, and the less—it’s maybe a bit more mundane. Yeah, the stuff runs faster and, as you said, diving into the bag. [Laughter] But, you know, when you’ve got numbers like 16X or 5X or what have you, that’s huge.

    Shimel: It sure is, it sure is. So, Hayden, you know, I mentioned Interconnect, too, and as we’re running low here on time, I just wanted to quickly prompt you on that and let our listeners now.

    So, this year, Interconnect is part of an even bigger kind of unified conference that IBM has put together called Think—Think 2018, I believe it’s called, and if I’m not mistaken, it’s March.

    Lindsey: Yes.

    Shimel: Go ahead.

    Lindsey: Well, you might see a trend here. [Laughter] Because, you know, Interconnect was the combination of Impact and Innovate. Innovate—I think that’s the name it was. I’ve kinda forgotten, but anyway, we had a Rational conference, we had a WebSphere conference, we had IoT stuff and all that. And now we combine those into Interconnect—at least the WebSphere and Rational stuff. And it got bigger, and now we’re doing something that is more or less IBM-wide and it’s called Think. It’s gonna be the week of March the 19th at the Mandalay Bay in Vegas, so still in Vegas like most of our other conferences have been of late.

    And so, I think there’s pros and cons to having a more broad, where we can tell the full IBM story, and that’s the focus, and you’ve got SMEs from all the different areas of the country, be it cloud, cognitive, Zpower, what have you. But I think that’s great, but because you do have those experts, and we will have the breakout sessions or keynote sessions on specific areas, be it DevOps or z or compilers or deployment automation like UrbanCode.

    So, there will be still those specialty sessions, and yet you get the big picture. And the one thing that I would like to ask your listeners is, the call for papers is open, and you know, we are shooting for having 100 percent of the talks in the various tracks either be a customer or partner only, or being customer and/or partner jointly with an IBM-er, but we’re just really trying to get away from IBM-er talking head telling a story without a partner or a customer there saying what they’ve done in real life with a given solution in a given area.

    So, we’d really love to have as many partner and client nominations as possible.

    Shimel: I love that idea. You know, I shared a panel the last two years, Hayden, on Dev—I think they were on, well, it was on DevOps and then SecOps. But, you know, I tried really hard to balance it with—yeah, we had one person from IBM, but we also had an analyst and then we’d have a partner and then a practitioner. And I think that sort of balance gives it, it makes it—

    Lindsey: It adds some legitimacy to the whole thing and different perspectives.

    Shimel: Yep. Just real quick, for anyone listening, if you go to IBM.com/events/Think, you can get all the scoop there and follow the links to submit. And as Hayden said, if you’ve got something to say and share with people, it—having been to three or four of these, or more, it’s a great platform. So, I’d encourage everyone who would like to participate to do so. And even if you don’t want to speak, but if you want to go really understand what’s happening, whether it be with Watson or z Systems or hybrid cloud or Bluemix or any of those things. You know, if any of those are important to you, I think it’s a great show to attend.

    Hayden, we’re about out of time—we’re actually over time, but that’s okay. Thanks so much for taking the time on what is a busy day with the general GA of z14. Best of luck with it. Let’s check in, I don’t know, maybe before the end of the year, and see how—you know, what kind of market reception a lot of these features and capabilities are receiving and we’ll see where the rubber is meeting the road.

    Lindsey: Sounds good, Alan, and thanks, again, for your time.

    Shimel: Thank you for your time. Hayden Lindsey, VP, Enterprise DevOps with IBM on GA Day for z Systems z14. Thanks, Hayden, have a great.

    Lindsey: Okay. Bye for now.

    Shimel: This is Alan—thank you. This is Alan Shimel for devopsy.kinsta.cloud. We’ll see you soon on another DevOps Chat.

    — Alan Shimel