Category: DevOps at IBM

  • 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

  • IBM: DevOps Begins and Ends with Culture

    IBM: DevOps Begins and Ends with Culture

    Making the transition to DevOps requires as much a shift in cultural mindset as it does new platforms for building, deploying and managing applications. Between the two, however, it’s often the extent of the cultural challenges needed to be overcome that gets most underestimated.

    Michael Elder, a IBM Distinguished Engineer, said one of the most important DevOps philosophies that organizations must embrace is that No Code is Sacred (NCIS). NCIS fosters an experiment-driven culture that encourages self-editing and promotes a “don’t be afraid to fail” mentality. This approach allows teams to form questions, quickly implement means to gather data, try alternatives and incorporate real user behavior and feedback, he said.

    Manage the Scrum (Meeting)

    Other cultural issues that need to be addressed include leadership and how daily scrum meetings are managed.

    An overzealous build champion can wind up adding technologies to the continuous integration/continuous deployment (CI/CD) platform that don’t get adopted simply because the team as a group did not agree to their inclusion, said Elder.

    Daily scrum meetings don’t necessarily need to take a full hour. Non-critical, time-consuming status updates should be eliminated from the agenda. Daily scrum is more about problem-solving and looping the wider team in on critical decisions than talking about updates most team members can already read about for themselves, Elder noted. The goal of the meeting is not necessarily to inform team members of events. They should be expected to know what’s occurred. The real goal of the meeting is to decide what to do next.

    Mindsets Matter

    Elder said DevOps teams be cognizant of Conway’s Law, which says that organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations. If the goal is to develop a more agile application environment by employing microservices, Elder said, then the organization should create smaller, more independent teams to construct and manage them. However, that doesn’t mean every monolithic application needs to turned into a set of discrete microservices.

    Elder also advised organizations to embrace Design Thinking principles that encourage DevOps teams to focus on what needs to be achieved instead of enabling processes. The focus ultimately needs to be on the experience of the users who are being asked to employ an application, he said.

    The Tools Issue

    The biggest cultural challenge, however, still may be to tooling. Organizations trying to embrace DevOps clearly need new tools. But acquiring new tools won’t drive meaningful change. Too many organizations buy tools in the hopes that processes will eventually be transformed. The decision to acquire new tools needs to be closely connected with the transformation of processes, said Elder. That said some tools, such as an enterprise instance of Github, are core to encouraging the sharing and reviewing of code within a DevOps process, he added.

    Of course, Elder noted the most critical cultural change as far as tooling is concerned is keeping an open mind. Developers and IT operations teams tend to get overly attached to specific programming languages and platforms. A true DevOps culture, above all else, encourages experimentation.

    — 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’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    DevOps Chat: IBM’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    In this DevOps Chat we discuss IBM’s Cloud Private. Cloud Private is the new offering from IBM that encompasses much of the different cloud offerings the company has developed over the years. Our guest on this DevOps Chat is Michael Kaczmarksi, an IBM Fellow and CTO of DevOps and Service Management. In his distinguished career at IBM, he has obviously seen technologies come and go. Michael gives us an inside look at IBM’s Cloud Private offering and how it relates to DevOps, service management, hybrid cloud and so many other contemporary technologies in the market today.

    As usual the streaming audio of our discussion follows immediately below. Below that is the transcript of our conversation to follow along.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got a very interesting chat lined up for today, with a great guest. Let me introduce him. We have today Mr. Mike Kaczmarski of IBM. Mike, welcome to DevOps Chat.

    Mike Kaczmarski: Thank you, Alan. Glad to be here.

    Shimel: So, Mike, you have a CV résumé full of accomplishments, and I don’t mean to embarrass you, but why don’t you just share with our audience kinda what you’re doing now with IBM and a little bit of your background?

    Kaczmarski: Alright, I’d be glad to. Well, my title is IBM Fellow, CTO of DevOps and Service Management, in a unit inside IBM called Hybrid Management—Hybrid Cloud Management. I’ve been with IBM—well, in February, it’ll be 35 years.

    Did a lot of work in the storage portfolio—a lot of the Spectrum products, Spectrum Protects, Spectrum Control. I came into a business unit that was called Tivoli at the time, became very familiar with all of the service and systems management products, and then into products like Maximo and others that we acquired or built out organically. And then became involved in a lot of the cloud technology—IBM Cloud and now I’m working very hard on DevOps technology and service management technology in a new offering that we have out called IBM Cloud Private.

    Shimel: Excellent. Excellent, excellent, excellent. And we’re gonna try to get to as many of these as we can, Mike. But in order to do that, I think we need to lay down a little sort of baseline, if you will. And how I wanted to do it was, you know, let’s talk about really what I think is one of the primary drivers behind the whole hybrid cloud transition that we see, and that is that traditional applications—you know, everyone would just like to move everything to the cloud, perhaps, make it easy, and be done. But that’s not the way the world works, right?

    Kaczmarski: [Laughter] Right.

    Shimel: You know, customers are beginning that migration, but that migration will probably take—Mike, you said you were with IBM 35 years. I’ve been around awhile myself. We’ll be long gone by the time that migration is over, I suspect. [Laughter]

    You know, so in the meantime, customers are faced with sort of this hybrid period where, you know, some of the applications and some of the application infrastructure may still be on-prem, may still be maybe a private cloud on-prem, maybe on a public cloud, maybe on a private cloud in a data center. You know, truly, a multi-cloud and hybrid environment. Is that what you’re seeing at IBM?

    Kaczmarski: Certainly what I’m seeing. If you consider things like the importance of customer data, data sovereignty, customers’ concerns over security, proper connectivity—all those need to be addressed, and customers’ businesses are running on their IT, and they’re comfortable at different stages with different aspects of those things being on the cloud, whether public or dedicated, and you often find something, like private cloud is a wonderful way to get started on understanding what operational architecture programming changes and even organizational changes they need to make to best start to utilize the cloud. Whether they take all those capabilities to public or dedicated cloud or not, the private cloud helps them.

    Shimel: No doubt about it. And so, Mike, when we talk about—you know, they may be IBM customers. But when we talk about organizations transforming their traditional—and by traditional, I mean non-cloud, they’re not cloud native apps—and trying to migrate them to the cloud. You know, I think you highlighted some of the things that we run into, but anything else that I think listeners may be interested in or at least gotchas that they should be looking for in transforming these apps and trying to move them to the cloud?

    Kaczmarski: Yeah. Well, I think there’s three patterns that we see pervasively. The ones you hear a lot about are those customers who are building out new cloud services, new cloud native programming models, and extending their business into the cloud using some of these new microservice-oriented programming models—polyglot technologies—and perhaps connecting them to their enterprise from the cloud; hence, the hybrid sense through APIs and API management so they can take advantage of their back office systems and the data and expose other application pieces on the cloud.

    There’s a few other patterns. We see customers who have applications that would fairly easily be optimized by cloud technology, such as container technologies for rapid deployment, rapid scale out, resiliency. There are applications that can be, we call it, lifted and shifted fairly easily. And then there’s a whole area of applications that are built out in monolithic fashion that have very tight interdependencies that have been around for years and years, and customers are making decisions on what they do with those applications, and it kinda depends on how much those applications are changing, how critical they are to the business—I don’t wanna touch it, it’s not changed in years, it’s doing its job. That might be some of their criteria. In other hands, parts of those applications might be changing fairly rapidly. And if that’s the case, then they start looking at refactoring or factoring out the portion of application code that is changing fairly rapidly into, say, microservices and placing those in the cloud.

    So, I think there’s a number of approaches that they’re taking, and obviously, it’s a business issue. What makes sense for me to refactor? What am I gonna gain by the refactoring of these applications and putting them in the cloud? How am I gonna lower operational costs? How is DevOps gonna help me, and what kind of return am I gonna get from that versus continuing to do what I do or even leaving some of my monolithic applications alone?

    So, I think, you know, there’s a broad range of considerations that customers have when they look at moving their applications to the cloud, and hopefully I’ve kind of listed a few, there.

    Shimel: Absolutely. So, Mike, you know, this is all—it’s all happening, and I think we’ve kinda described it well. But now, so IBM has recently come out with this Cloud Private, as they’re calling it, and you know, frankly, I think there might be a little misunderstanding in the market where, hey, you’re talking about hybrid cloud, but now, why are you doing Cloud Private? Right? Is it private cloud, is it hybrid cloud? Cloud Private—where does that fit in? Can you help clear it up for our listeners?

    Kaczmarski: Yeah, sure. IBM Cloud Private is an on premise cloud offering based on Kubernetes technology, optimized by some of our systems group. It does run and allow you to deploy private clouds, what I’ll call on premise clouds, on Intel, on Power, on zLinux, so you can take advantage of the systems you might already have deployed, but it has full connectivity to any services in—cloud services that are running in the cloud public or dedicated cloud. It’s a way for customers to start to either write new microservices or write new capabilities or refactor, as I mentioned, some of their applications into a cloud that is running on premise, allow them to experiment without concerns of data privacy, data governance, data sovereignty, and allow them to figure out what’s the best approach that they want to take for refactoring their applications or moving them to the cloud.

    It is Kubernetes-based. It’s based on the same technology that runs on our public cloud and what we call the container services. So, much of the workloads that can run in the private cloud if the customer chooses can be transparently moved to the public cloud or a dedicated cloud for them. The Kubernetes technology overall, the Docker containerization—everything’s running in Docker. They’re fairly pervasive in the industry, so it does give the customer a choice. I think it gives them a foundation that they can start with. They can move workloads at their most comfortable, keeping them on-prem, and then they can start to extend those workloads to the public or dedicated clouds as well.

    You know, another big difference with IBM Cloud Private is, we’re moving our middleware, our traditional offerings like the WebSphere and message queue and IIB and DB2 and the data science experience—traditional middleware that customers have running on-prem that they’re writing their applications against are now available in IBM Cloud Private in containerized versions, the same service, the same APIs, a lot of the same capabilities. And so, they can actually take advantage of the same middleware that they’ve been running with, now containerized in clouds so that they can take advantage of simpler deployment, AB deployment, a simpler upgrade, resiliency, scale out, and so on.

    So, that’s what I think we bring to the Cloud Private arena is the ability for customers to leverage the investment they have in our middleware and middleware services now in a cloud deliverable. And that also makes it easier for them to move their applications into a cloud architecture, whether it’s on-prem in Cloud Private or in public in IBM cloud or a dedicated cloud, an IBM cloud.

    Shimel: You know what, Mike, that was fantastic, and it kinda made a lightbulb go off for me, here. What really, what Cloud Private is offering customers, or anyone—you know, eventually, I guess, their customers—but it’s portability. It is giving you a cloud ready infrastructure, whether that cloud be on prem, at an IBM data center, maybe in a public private type of situation, hybrid situation or not. And not only is it allowing that infrastructure through containers and Kubernetes to be portable like that, you’re now portable-izing, if that’s a word, [Laughter] that whole layer of middleware that so many have been using for so long—

    Kaczmarski: Yeah.

    Shimel: – and making that also portable to whatever or however and in what combination you want to post your applications going forward.

    Kaczmarski: Yes, that’s sort of a—

    Shimel: And that’s really powerful.

    Kaczmarski: – yeah, that’s a good description, yes.

    Shimel: Yep. And, you know, I think, you know, Mike, it really goes to the heart of what we’re seeing in technology today, which is the—and a lot of it is via Kubernetes; well, microservices and containerization, let’s call it that.

    Kaczmarski: Yes.

    Shimel: It’s fundamentally shifting the IT infrastructure or the preferred IT infrastructure in a way that we haven’t seen maybe since when we moved from client server, or maybe when virtualization and hypervisors first became sort of dominant or started really asserting influence in the market. This is really a shift of that magnitude. Do you agree?

    Kaczmarski: Yes, I do, and actually, those are two perfect storms that kinda come together, the virtualization and the client server. I think containerization is an interesting supporting feature of microservices. It really allows a full stack deployment, and actually changes some of the roles and responsibilities of what developers have traditionally done.

    Shimel: Absolutely on that. So, this is DevOps Chat, though. Let’s talk a little bit about DevOps. I always like to tell people that—hey, DevOps is an umbrella term today. It’s more than just the breaking down of the silos between dev and ops, and there’s obviously a cultural aspect to it. But, you know, the thing about DevOps is, it’s about how things get done today. And so, when we talk about things like microservices and containerization and cloud, right, I don’t know if DevOps is a byproduct of those things or if DevOps is a precursor or an accelerator to those things, but they seem intrinsically linked.

    Kaczmarski: Yes.

    Shimel: What’s your view on that?

    Kaczmarski: Yeah, I think they are tightly linked. I think DevOps enables the kind of automation you really want to be able to understand how your applications are being developed, are integrated, how they’re performing, whether or not you’re ready to go into production with what you currently have, whether or not you’re really ready to support, operationally, the applications you already have—all of those things, as early in the life cycle as possible.

    And, you know, when you talk about containerization and microservices, as compared to monolithic applications, there’s a lot more moving parts. There’s many more moving parts in a microservice container organization of your code. You know, you have business function decomposed into various different microservices. It’s actually an organizational construct as well as an architectural construct. You have teams around those microservices building them. They all have API contracts with each other on their behavior, and now they’re deploying at different times into what should be a running system that’s providing a service. At every point along that line, you wanna understand. You wanna be able to herd all of these microservice teams that are together building out the application in a consistent way and always know where you stand in terms of the application being built.

    By the way, the same applies to monolithic apps, because they undergo change if they’re interacting with these cloud native apps and microservices. So, you need to be able to automate and make sure nobody breaks the builds, you need to be able to do continuous deployment of the microservices in, say, a test cluster or a cloud where they interact with each other. You want to vary the versions that are out there to understand if the API contracts have been violated. You want to have a real good idea of the performance and scale of the microservices that are out there—and there are so many of them in a traditional application now, manual tasks would never be able to keep up. So, automation through DevOps in terms of build, deploy, the manageability, the testing of the microservices is paramount in being able to scale a true microservice architecture to a product that has reliability and can be easily updated and can actually iterate very quickly to meet customers’ needs.

    Shimel: Absolutely. Mike, let me introduce another term into our term goulash today, and that’s service management, alright? So, service management is something that has certainly been on the IT agenda, right, on the IT menu for longer than the word DevOps has been used, right?

    Kaczmarski: Yes.

    Shimel: Service management is an important piece of it, right? And there’s been somewhat, frankly, of a disconnect on the nexus or connection of DevOps and service management. Are they compatible? Do they work together? Is there a continuum with them?

    What’s your view? I mean, you have both under your portfolio, here. What’s your view on that?

    Kaczmarski: Well, I think that integration of DevOps into Ops, if you will, relative to DevOps I just talked about in terms of automating, you know, build, deployment, test—integration into Ops is more about making sure you can monitor the application, making sure that if there are outages, you have procedures, run books that can quickly bring things back, supporting things like site reliability engineers, understanding who’s going to be notified if there’s a problem with a particular service—all of those kinds of things push back operational characteristics on the DevOps and even the development team.

    You know, as our teams were building out IBM Cloud, a lot of the services in IBM Cloud are managed by, developed by individual squads, so a logging service or a particular database service or whatever we make available in that cloud, there’s a squad behind it. Obviously, they develop it, they go through regular DevOps deployment and testing, they determine when it goes into production a lot of times based on analytics from a lot of the automation that they have.

    When it goes into production, they’re immediately also responsible for the ongoing operation of those services. This is the development team. They’re now responsible for the ongoing operation of those services. Now, they have site reliability engineers as well, but if you take some development teams and make them responsible for the operational characteristics of their services, a lot of interesting things start to happen. You start seeing development not around the application itself, but also around, “Oh, hey, I have some Selenium scripts that I’m gonna use to automatically monitor response time of the application. This needs to get deployed with the code.” “Oh, I have some run books for the SREs or automated scripts that, should certain events show up, will automatically restart or scale out services appropriately.”

    You start seeing operational artifacts as part of the development of the particular microservices or applications that are being built. And of course, as that starts to occur, you start seeing standards for handoff of these kind of artifacts between DevOps and Operations teams so that not only are they deploying application, they’re deploying the management around that application and they’re ready to go when that application goes to production.

    So, I think that’s the biggest cultural change I’m seeing with DevOps going into Ops is really integrating the management capabilities and intelligence into the application and the awareness that now the developer and the DevOps team have in providing what is needed to properly manage the application and operations.

    Shimel: Mike, that was one of the best answers to that particular subject that I’ve heard. Thank you very much for that.

    Unfortunately, Mike, as I told you before we started, the time here goes really, really fast. I promised you we’d be done in 15 minutes and we’re on 20 minutes already, so I know we had a lot of other topics we wanted to cover. Maybe we’ll have you back on at another time and we can do a part two on this, but we’re about out of time right now.

    Thank you so much for being our guest on DevOps Chat today, Mike.

    Kaczmarski: Oh, thank you, Alan, I really enjoyed it.

    Shimel: Not a problem at all, and as I said, I’d love to have you back on here soon, and we can continue the discussion. But before we go, for anyone who wants to get more information on IBM Cloud Private, where can they go?

    Kaczmarski: Well, actually, the easiest thing you can do is Google IBM Cloud Private, and there’s a number of references out there, and tools. There’s cloud reference architectures, developers, communities. If you want to engage with some teaming with IBM on what’s the best way to move some of your applications to the cloud, there’s IBM Cloud Garage, and there’s some wonderful blogs out there where developers will take you through how they actually move some of the applications to the cloud. So, I would just Google IBM Cloud Private, and you should see, in the first two things that come up, some really good references.

    Shimel: Fantastic. Mike Kaczmarski, IBM Fellow and CTO for IBM Private Cloud, DevOps Service Management—thanks so much for being our guest on this episode of DevOps Chat. To everyone listening, hope you enjoyed it, and we’ll see you soon on another DevOps Chat. Have a great day.

    — Alan Shimel

  • IBM Z: An Architecture That Scales for Modern Computing

    IBM Z: An Architecture That Scales for Modern Computing

    The architectures I like best are the ones that are built to scale. I can’t tell you how many time I’ve run across applications that have hit the wall when the request count goes up from hundreds to thousands of simultaneous users. The next thing you know the CPUs start to peg, memory get maxed or overall availability just magically goes away. All that’s left is the dreaded status code: 500 Internal Server Error.

    Those of us who have made distributed computing a way of life spend a lot of time making sure that our applications scale up. We’ve found the pursuit to be costly. As result, some of us have turned the entire problem over to managed service providers. Paying a bill at the end of the month to ensure 24/7 availability is a whole lot better than taking a call at 3 a.m. demanding to know why the inventory system in Toledo has gone down. Whether we choose to take care of our own metal or use an MSP, we understand that an architecture that cannot scale has little value.

    Surprisingly, one of the best architectures around is one that is used by 90 percent of the world’s largest airlines, 70 percent of big retailers, most of the banks worldwide and all of the largest insurance companies. Where is this architecture to be found? In mainframe computing. Yep, you got it: Big Iron.

    Big Iron: The Gift that Keeps on Giving

    Mainframe computing in general and IBM Z in particular have a computing architecture that is built to support usage by thousands, if not millions, of clients. Since their inception, these systems have been designed to provide high-availability, large-scale, multi-processor computing in a cost-effective manner. Whereas a typical data center filled with racks of commodity hardware will suck thousands of dollars a month in electricity, a single IBM z System that processes 2.5 billion transactions a day uses about as much electricity as the clothes dryer down in your laundry room. (2.5 billion daily transaction is the equivalent of 100 cyber Mondays every day of the year!)

    In terms of high availability, mainframe uptime is measured in years. There are systems out there that have been running continuously for 10 years and are still up today. This is no small accomplishment. Think about it: Imagine what it takes to have enough redundancy built into an architecture to never have to reboot, no matter how weird any of the applications get. Memory and application isolation have been built into the technology since the start. In a way, we’re talking cloud before the cloud.

    Memory isolation and application redundancy have been key features of mainframe technology since inception

    It’s an amazing technology, one that more developers, particularly those of us working on the forefront of application development should leverage. The question becomes how to benefit from its capabilities and drive business value from this asset with its treasure trove of data. The first step is to understand the difference between a system of interaction and a business critical system.

    Understanding Systems of Interaction and Business Critical Systems

    In the world of modern, distributed computing, application logic can be represented in a variety of ways. For example, it’s quite possible to check on the status of flight information by using a mobile app, going to an airline’s website or by calling the carrier’s toll-free number. The logic needed to find and deliver flight information is in a central location; the means to access that information is distributed. There are two systems in play—one is called the system of interaction and the other is the business critical system. The system of interaction is the system that interacts with the end user, collecting data to send as output. The business critical system is the system that serves as the repository of common application intelligence. The concept is akin to the thinking behind client-server architecture, but it’s a bit more in that it’s system based. Think of a phone system, cable TV system or online games as a system of interaction. Think of a rack of servers, the cloud or a mainframe as a business critical system. The overall digital experience is the aggregation of its components.

    This may seem like an obvious separation, but there’s a bit more to it, particularly when considering large hardware such as IBM Z and the like. Being a business critical system is more than being a simple data store. A business critical system can contain all the data necessary to perform complex machine learning activity upon a particular dataset submitted to it, weather prediction or medical diagnosis, for example. Of course, the business critical system has data, but the system also has algorithmic and parallel processing capability far beyond a standalone PC or cell phone, the components that are typical in a system of interaction.

    Business critical systems, particularly those that have been in service for decades, become very powerful when they support common standards of digital interaction—APIs based on REST, for example. Back when distributed computing was limited to a small part of the population, a proprietary approach to system interaction was acceptable. But, the rise of the internet changed it all. Today we have billions of people online, on some part of a global network. Thus, common standards such as HTTP and REST have emerged to make interacting with software systems worldwide easier. Companies such as IBM understand the importance of supporting the ways of the internet. Thus, a product such as  z/OS Connect EE allows developers to connect to a Z System installation and design an API around the code in that installation. Using z/OS a developer can wrap a REST API around some COBOL code. Having this type of capability opens up a world of possibilities.

    Going to the Next Level

    As the world of mainframes gets more attention from those making mobile apps and aggregating services into the cloud, a whole new level of software development emerges. Using a product such as z/OS Connect EE to create REST APIs combines the world of Big Metal with the world of big data. Those of us in DevOps understand that breaking down silos and fostering collaboration is what our work is about. Bringing together the skills and experience of all those who are dedicated to making quality software, from COBOL programmer to engineers who embrace infrastructure as code, is essential in the world of modern computing. The more people and systems we have working together effectively, the better will be both our software and the world we make.

    — 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

  • DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    We sit down with Sarah Plantenberg of IBM to talk design thinking. Sarah has been featured on several DevOpsTV videos around the Bluemix Garage. But she recently took on a new role at IBM around bringing design thinking to cloud customers. Sarah gives some great background on design thinking and why it can help you. Have a listen for yourself and we think you will find it informative.

    As usual, the streaming audio of our conversation is below with a transcript of our conversation below that. Enjoy!

    Alan Shimel: Hey, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Sarah Plantenberg of IBM. Sarah, welcome to DevOps Chat.

    Sarah Plantenberg: Thank you. It’s great to be with you again.

    Shimel: Great to have you on again, Sarah. As we spent, oh, a good half-hour chatting before we went on air today, just catching up, and it’s always great to hear what’s going on in your world, and, obviously, one of the big things is you now have a new title at IBM. I’m not even gonna attempt to repeat it because I know I’d mess it up. I’ll leave it to you to tell our audience what exactly is your new title, Sarah?

    Plantenberg: My new title is I’m a design lead, the designer for the offering management section of our cloud technical engagement organization, so I’m a senior consultant specializing in applying design thinking to our business and helping our clients apply design thinking to their businesses.

    Shimel: Absolutely. And, though that may not roll off the tongue, it’s actually a mouthful, in terms of how important and how much value IBM puts on this whole concept of design thinking. But, Sarah, some people in our audience may not be familiar with design thinking. Design thinking 101 for people who don’t know what it is, how would you describe it to them?

    Plantenberg: Design thinking is about understanding and then innovating in a really human-centered way. We understand the person that we’re building something for. We understand their current situation. We understand the greatest pain points they have or if you’re bringing something new to the market, what’s the greatest opportunity for your business. And then we innovate around that by really—we have some really great techniques and tools to help people come to ideas that they would not have come to if they were just sitting down, doing what they call a typical “brainstorming session.”

    Shimel: Mm-hmm.

    Plantenberg: Once you have those ideas, you have to take those and put them back in a context of that human being’s world. How many great ideas have we all come across? The example I give is that I have 150 applications on my phone and I use, honestly, probably 15 of them.

    Shimel: Yeah.

    Plantenberg: There’s a bunch of great ideas. [Laughs] But they don’t reach me in the right way at the right time. So design thinking is really a set of—a framework and a set of tools around helping bring all of those things together, and, in IBM, we use it to bring the right technology to the right person, at the right time.

    Shimel: Excellent. And, of course, Sarah, design thinking, while IBM is probably one of the leading advocates in the world for the concept of design thinking, it’s not—this is not a new concept, per se. design thinking has been around for a while. Again, design thinking 101 for our audience—give me a little, if you can, a little of the history that you know of there

    Plantenberg: So, yes, design thinking’s been around for many years. What IBM has done with design thinking is said, “You know, we really need to apply this … ” We’ve done three things. The first one is to say, “We really need to apply this to the way that we work . We need to understand how we’re positioning ourself, how our clients understand us, what they need, and really target IBM’s capabilities towards those.” And, in some cases, even a couple steps ahead of the game, what we see coming in the market, which is really where the cognitive capabilities and the way that Ginni Rometty is steering our company—that’s where that comes from, is understanding that’s really the heart of design thinking.

    The second thing that IBM has done with design thinking is help us use it at scale and teach our enterprises to use it at scale. It’s easy to do design thinking in the small, but to do it when you have a development team of 250 or when you have a development team that’s in India, China and New York? That’s a different ballgame. So IBM design thinking, IBM’s part of that is at speed and at scale.

    And then the third thing that we’ve done with it is what we’ve done in Garage, which is really to take an incredibly lean and integrated approach—you don’t have to integrate design thinking into your development, but we do. And we do that in the Garage and it’s been amazing because it’s helped people use design thinking and kind of allow it to permeate everything that they do, so we put it at the beginning to understand the users and come up with innovative ideas and then design those and develop them for users towards business outcomes, but we also use it to say, “Okay, now you’ve adopted that cloud, Client A.” Let’s pretend. You know, just talk about a client without using their name. “You’ve adopted the cloud; you’ve brought in the IBM Bluemix Garage Method. You’re iterating really quickly. Your agility now means something to the user.” Before that, without including the user, agility more often has strong IT economic benefit, but it doesn’t always follow the business, and so design thinking really connects those two things together.

    And then, once you adopt the cloud, it ripples. The impact of that ripples, so you can’t run your operations organization in exactly the same way that you did before because you have different tools and you’re running at different speeds or maybe you’re running at just one speed that’s a lot faster, and you have somebody else managing your cloud, so what does it mean to do DevOps? So we created a design—we applied design thinking to how people reorganize their operations organization, and that’s been a great tool for us, both to learn, as IMBers, about how our clients need to shift and also to help our clients really take an outside-in approach, a human-centered approach, to how they’re gonna run an operations organization.

    And I think the last thing I would say about that is you can also use design thinking at the business process level as well, so it’s—I could go on and on with this answer [laughs], but I would say it’s—

    Shimel: Oh, it’s okay.

    Plantenberg: —it’s really stepping back and looking at the big picture and understanding, rather than following the thread. You know, it’s taking a holistic approach, rather than a linear one, to operations.

    Shimel: Yep. And, you know, Sarah, one of the things about the Garage and the Garage Method is really kind of taking this design thinking kind of way, if you will, and applying it, in real world, to scaling at enterprise levels and in a agile fashion, right? And by “agile,” we don’t necessarily mean Agile manifesto, Scrum, but agile in a larger sense. And, Sarah, that’s actually something that you and I spoke about off-mic earlier, and that is what I call, or Gartner actually calls, this concept of “agile IT,” but it’s also something, as you pointed out, that has been preached from the highest levels at IBM now for at least the last couple years, which is kind of agile everywhere or, you know, going agile, if you will. Why don’t you, if you can, share with our audience a little bit about what that means to you and what is IBM’s kinda vision on that?

    Plantenberg: You know, what that means to me, I can’t separate my life at IBM from my life as a designer, when I answer that question, ’cause I’m a designer because I think like one—I didn’t choose to be one; it kinda chose me.

    Shimel: Yeah.

    Plantenberg: And, from that standpoint, I think that the only reason to be agile is to be responsive. There’s no other reason you would need to be able to shift quickly, unless you’re in response to something. In my world, that’s a user, and a user can be my manager; the user can be my team, when I was managing a design team; they’re my client. They’re the people I interface with because I’m doing something for them. Whenever I’m doing something for someone that’s my user, I need to be agile. But, as we talked before, where agile meets non-agile, you end up with kind of a mess. It’s a little bit of a—there’s cognitive dissonance. People can’t work together because they’re working in two different ways—it’s a square peg in a round hole.

    And so the concept of agile in the large, “Let’s all operate in the same way and let’s all have that way be inclusive,” meaning we integrate together, we know how to pass information together. We are all aligned around the same priority, so, when you ask me for something and I say I can’t get it done because X, Y, Z, say, “Yeah, I understand that, actually. Let me make sure—let me put this in the right priority.” And are all responsive to changing business needs—I think that’s the most important thing. When the tides shift, we all see it together because we’re aligned together. We can then respond together. And it’s an incredible way of working.

    Jeff Smith had brought this into the CIO’s office, and it’s been incredible, the results. I wish I had them in front of me. The reduction in the amount of time spent getting things done, streamlining the organization, and I literally mean streamline the organization. It got smaller. It’s tighter. It’s faster. It’s more responsive. We’re now rolling that out under Sean Reilley who’s the vice president. Moved over to GBS, our global business services, and that’s now an offering for our clients.

    And it’s very, very interesting to our enterprise clients who are having to do more with less—I hate that phrase, but it’s true [chuckles]—and they’re having to be more responsive because business is changing so fast, the conversations people have now about the cloud are vastly different than they were only two years ago, so enterprises can’t be responsive not only to emerging technologies but to what their users need and how the markets are shifting. They’re struggling, you know? And so this is really a fantastic answer ’cause it’s not a thing that you buy; it’s a way of being and a way of thinking and a belief system.

    And I think the last thing I’ll say about it is it really allows the people on the ground to use their capabilities to help change the business. Instead of being told what to do, they’re leading with what they know, within a framework that gives them a voice and gives them a method of working together. It’s just—it’s fantastic work.

    Shimel: Excellent. Excellent. So, Sarah, as you mentioned at the top of the podcast, you recently moved into a new role, where, before, you kind of really weren’t in the Garage and around design thinking with the Garage and Garage Method. You’re now helping IBM’s sales, marketing team, customer engagement teams both understand design thinking internally there, as well as taking those lessons and bringing it to market, to IBM’s clients. Is that correct, fair to say?

    Plantenberg: Yes, it is.

    Shimel: And, in that role, Sarah—and I’m sure you’re very excited; it sounds like an exciting new role and we all like to embark on new opportunity—what does success look like for you there?

    Plantenberg: Oh, what a great question [laughs]. Success … I often success for myself as having created something that doesn’t need me ’cause if it needs me, than it’s more about me than it is about an outcome, so I will say that that’s the preface ’cause my answer might, without that, sound a little weird. Success to me is that I can stand back and watch our clients move from the beginning of their cloud journey to the point at which they have a hybrid cloud and they’re running in the cloud method and getting tremendous value out of it and hopefully even having spread agile methods throughout their business and adopt design thinking and that human-centered approach, and they’re doing beautifully with IBM’s tools integrated with anything else that they may have. I want it to be easy for our clients to find what they need on the cloud – about the cloud, on the cloud methods, tools, understanding the capabilities on Bluemix and growing their businesses with those and being independent and thriving on Bluemix.

    Shimel: Great. That is great. And so, I mean, the Bluemix and all of that is still there. One—I think we have time for maybe one more question we can go into, Sarah, and that is I wanted to talk to you about the concept of multi-clouds, right? We become more nuanced in our understanding of what it means to move to the cloud. We’re not all moving all of our infrastructure up to Amazon or Azure or one of these public infrastructures, the service providers. Cloud exists in many forms, right? We have public cloud; we have private cloud; we have hybrid cloud; we have lots of flavors, almost as many flavors of computer clouds as there are different types of clouds in the sky. What does this mean to you and in terms of your role?

    Plantenberg: It means understanding the people who are having to make the decisions. I think that your analogy of clouds in the sky is really—it’s a great one because you don’t—we can’t expect people to only want cirrus clouds, and here comes a cumulonimbus cloud. “No, I’m sorry. I can’t have that. It’s not gonna work for me; I only do cirrus.” That’s not how the world is. We have to be comfortable and understand people are making different decisions and connecting these different clouds togethers, and, often, I actually meet clients who have one area of their business using one cloud and then another area, using another cloud because the business folks had a small, little consultant group who’s working on Amazon and the IT organization decided to go with Bluemix, and now they have to figure out how to integrate these two.

    That’s the world we live in, and people make choices for reasons. If we understand, from a design standpoint, “Why do you have these multiple clouds? How are they working together? Where do you wanna take your business?” then we know how to fit these things together and knit them together and do automations. In fact, we have some automating tools that say, “Okay, we can run a dashboard that helps you see all of your clouds,” so IBM no longer believes in backing up the IBM truck and saying, “Us or the highway.” That doesn’t work; it’s not the kind of world we live in. And everything is integrated—it’s really the name of the game—and so, for me, it’s understanding how people got to where they are and understanding where they wanna go and being able to bring them there with what they have.

    Shimel: Got it. Got it. Well, Sarah, we’re about out of time, so we need to end things in a little bit, but I wanted to, first of all, thank you for appearing on this episode of DevOps Chat and, secondly, really wish you nothing but the best of luck with this new role and responsibilities. We’ll be checking in to see how things are. And then, of course, we’ll see you next year, hopefully, at IBM InterConnect, and that’ll give us maybe six months or eight months of retrospective to take a look at and we can see what it’s about.

    Plantenberg: Oh, I count on seeing you there, Alan. [Chuckles]

    Shimel: Okay. That’s—I guess we’ll call it a wrap on this episode of DevOps Chat. Sarah Plantenberg, IBM, design thinking. Thank you so much for being our guest on this episode of DevOps Chat. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel