Tag: ibm

  • BMC to Infuse AI Across Software Portfolio

    BMC to Infuse AI Across Software Portfolio

    At its recent BMC Exchange event, BMC Software announced it will be infusing machine learning algorithms and other artificial intelligence (AI) technologies across its entire portfolio of IT operations software.

    The first instance of BMC software to make use of machine learning algorithms is the latest version of TrueSight AIOps platform, which ingests data from multiple data sources to automate processes across BMC service desk, IT operations and tools for managing DevOps processes. BMC also is working with IBM to employ the cognitive computing services known as the IBM Watson cloud service across its portfolio.

    In addition, the company launched TrueSight Cloud Cost Control, a tool for managing and tracking usage of cloud services across multiple providers, and BMC SecOps Policy Service, which easier to embed compliance and testing via an external service that gets included in their software development processes.

    Finally, BMC announced it has signed an alliance with Amazon Web Services (AWS) under which the two companies will work to accelerate the migration of application workloads to the AWS public cloud.

    Dan Streetman, a senior vice president for worldwide sales and marketing at BMC, says his company is developing a product strategy around three major themes:

    • IT organizations will require management tools that will work across multiple clouds;
    • As part of general “shift left” developers now expect to be able to programmatically invoke IT operations and security services; and
    • IT professionals now expect the tools they use to manage IT to have the same types of advanced capabilities that consumer applications provide via speech interfaces such as Apple Siri or Microsoft Cortana. Various IT and customer service desks also soon will use speech interfaces to provide a highly automated self-service experience to end users.

    In fact, given the complexity of the IT tasks that now need to be managed, Streetman says a race is now on between IT vendors to live up to those expectations. Much less of a concern, he says, is any notion that AI technologies might one day replace IT professionals that by and large are already overtaxed; rather, it is apparent that IT vendors are now being evaluated on their ability to maximize existing investments in IT professionals that are already in short supply. The real opportunity is to free IT professionals to enable them to concentrate on higher-value tasks.

    Naturally, it remains to be seen how various AI technologies will impact the management of IT. It certainly will take a while for IT administrators to put their faith in AI. But as those technologies continue to mature, there may soon come a day when IT professionals look back with wonder at all the things they used to have to accomplish one manual task at a time.

    — Mike Vizard

  • DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    In this DevOps Chat we speak with Steve Boone, product owner and development manager for Urban Code Deploy. Now that DevOps is in practice at more organizations, measuring DevOps success is a question many are asking. Steve has helped hundreds of companies adopt, implement and scale their agile and DevOps practices as part of their digital transformation. Steve gives us some insights into how can you measure your DevOps success.

    As usual the streaming audio of our chat is below. Following that is a transcript of our conversation to follow along.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 117787″ width=”100″ height=”100″] Steve Boone
    Steve Boone is a DevOps SME at IBM. He has helped hundreds of companies adopt, implement, and scale their agile best practices including CI, CD, Environment Provisioning, and Application Release Automation. Steve is currently the Product Owner & Development Manager for IBM UrbanCode Deploy.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to be joined today by Steve Boone. Steve is the Product Owner and Development Manager for IBM UrbanCode Deploy, one of the leading CI/CD solutions in the market. Steve, welcome to DevOps Chat—how are you?

    Steve Boone: Doing great, Alan. Thank you so much for having me today.

    Shimel: Great. Steve, I wanted to talk to you—well, about a couple of things today. But let’s focus in first on, I’m just back from another major conference, and once again I’m—not amazed, because by this point, it’s expected. But still, you know, going strong, the biggest thing we get, or the biggest feedback that I hear from organizations looking to do DevOps transformation is—hey, this all sounds great, it sounds really good, but how do we know, you know, first of all, how do we get started with our DevOps transformation, and then once we’re doing it, how do we know it’s working? Right? How do we measure the ROI, or even if we can’t get to a real ROI, how do we measure progress? What does success look like?

    And I would imagine, you know, the guys at UrbanCode, the team at UrbanCode has been dealing with this for some time. What do you tell people?

    Boone: Yeah, that’s a great question, and it’s—you know, I think it’s a little different for everyone. And when we start looking at measuring success and first finding out, you know, where do we start, a lot of times we’ll work with customers to identify, you know, what are your problematic areas? There’s a lot of aspects to DevOps, it’s not all CI/CD, there could be aspects of agile planning, there could be release management. There’s a number of different things that come into play.

    So, we usually sit down and try to focus on, you know, where do you think your bottlenecks exist today, and then start to address those. But when we went to measure—and you know, you’re right, the allure of DevOps comes with all of this ROI promise, right, where if we do these things and we change our people and our process and our tools, we’re gonna be better off for it, the business is gonna be better off for it.

    So, how do we then make sure that’s actually happening, right? That the time and energy that I’m putting into changing my processes are actually showing me that ROI.

    So, what we’ve seen a shift in the industry towards is really starting to gather the different sets of metrics that are coming from, really, the end to end products that we’re dealing with in DevOps whether it’s your build tools, your testing tools to understand what I’ll all our key metrics. So, you know, if in fact we are capable of speeding up our delivery to our pipeline, we should be getting to market faster, right? So, we look at statistics like cycle time—how long does it take for an application or a release of application to go from dev to prod? And then we look at that data over time. Is it, in fact, improving? And if not, we want to identify other bottlenecks that are kinda holding that progress up.

    So, if I look at a set of components that make up an application and I see that the majority of those components have a really good cycle time, you know, we’re only as fast as our weakest link. So, if the database component, for example, is routinely slower to get through QA than the rest of the component, that’s going to slow down our time to market and therefore gonna slow down our release.

    And the beauty is, in turning on the flashlight, so to speak, so that you can see that data and actually do something with it, a lot of times we look at it and say, “Well, we know we have automation and therefore we know we’re going faster.” But that just might mean we’re going to QA faster or we’re going to dev faster. We want to make sure that we’re actually getting that ROI, so if we can set baselines with teams and say, “Hey, prior to doing this automation, it took you four months to get from dev to production out the door, right? This past release cycle we did it in three and a half months—great. What is that time savings? What does that time savings mean in cost?”

    And, we’re starting to see a big trend within the industry of many different companies starting to put together products to start to track these. So, I think it’s a whole new area for us to focus on, and in hopes—what we’re trying to share with customers is that, look, not only are the changes in people and process that you’re making working, but the tooling is working, and hey, here are some areas where you can improve those processes.

    Shimel: Yeah. So, Steve, obviously, I want to—you said a mouthful, there. [Laughter] But let me focus in on one thing you said that I want to re-emphasize to our audience, and that is, you know, DevOps is so much more than CI and CD, right? There’s config management, there’s APM—there’s a lot that goes into this umbrella term that we call DevOps, and it seems to be growing every day.

    That being said, though—you know, I once heard someone describe DevOps is the symptom and CD is the cure. So, you know, I don’t want to minimize the importance of CI/CD, but you know, automation—there’s so much that goes into this equation or this term that we call DevOps. And I think that’s—you know, Steve, it’s almost like it’s its greatest asset but it’s also its greatest liability, you know what I’m saying?

    Boone: Yeah, there absolutely is. I think that a lot of times, we definitely see, when people are talking DevOps, their focus tends to be on CI/CD. And I think that’s because, you know, out of the gate, especially if you’re just starting off, it’s kind of your biggest bang for your buck, right? You can get a lot of fast return on investment just by improving your processes and automating them and making them consistent.

    As we see teams mature, and as they transition into a more Enterprise wide DevOps solution, then we start to see—well, where are the real boundaries in my organization, right? Is it, we see a growing trend where app dev teams are focusing on automation, but there’s a whole different silo in infrastructure, you know? So, an app dev team wants to request an environment to do some testing in—they have automation, and the tools that they have for automation could easily provision that environment. But the business dictates that that’s the infrastructure’s just, and they have a completely different set of tools that they use for that, right?

    And so now we get into this challenge of really continuing to try to break down these barriers to make sure that these assets and tools that are out there can work together, and that there’s clear cut guidelines on that.

    So, yeah, I think it is a blessing and a curse, right? Because when we start thinking about DevOps, everybody wants that—you know, we’re a culture of having that instant gratification. So, it’s nice that we can get that with deployment automation and build automation and test automation. But we need to be looking ahead to the future, which is gonna be—hey, I’m gonna provision these things on demand and make these environments available to my teams, and today we use Amazon for that. What happens if, six months from now, we have to change and we need to support Azure or Google or SoftLayer or Bluemix, right? We need portability, we need full stack provisioning and config management on that.

    And that’s—I think that’s something that, a lot of times, people just starting out, they don’t look too far ahead. And my suggestion to folks is—hey, it’s okay to take that first step. You should be cautious about the first step, but keep in mind where you wanna be two years from now, three years from now, five years from now. What’s your DevOps end goal?

    Shimel: Yeah. You know what? So, Steve, I think that might be the first question we need to—especially for consultants out there who may be listening to this. You know, whether you work for an IBM or a small consultancy, I think that has to be the first question. You know, people come and say, “I want to do DevOps.” You gotta ask them, what’s the end goal, here? What’s the end game? Why? And that’s a huge piece of it.

    Steve, if I can, I’d like to turn to a little bit more about UrbanCode and, you know, UrbanCode’s kind of a unique animal, if you will, in that, you know, it was one of the earliest, earliest kinda startups playing in the CICD space, right? And so it had that whole startup culture, if you will, the startup thing going on. And then, of course, you know, acquired by IBM and really become a linchpin of, you know, IBM’s DevOps, and not only DevOps, but you know, in IBM, as you know, DevOps is tied into cloud and hybrid and Bluemix and SoftLayer and all the things you mentioned. You know, it’s such a critical piece of that puzzle.

    What is happening lately with UrbanCode? I saw Gartner give you guys some accolades recently.

    Boone: Gartner gave us some accolades. We scored very well, as well, on the Forrester Wave that just came out.

    Shimel: The Forrester—yes.

    Boone: We were named as a leader in the—yep, in the Forrester Wave. So, that was exciting. It was a great score for us. We’re about as far right in that quadrant as you can be.

    And there’s a lot of really good things coming out. I think the reason we scored so well is that they’re looking at the strategy within UrbanCode and seeing that, you know—as you mentioned, this isn’t our first trip around the block. We’ve been helping customers do this for over 10 years. And for us, you know, we work with companies that are small startups to everything that are enterprise financial institutions and healthcare and government agencies.

    So, there are, at any given time, different, I’ll say, business focuses that are in a different spot of transition. So, I can go to an enterprise and talk to 30 different groups and organizations in that enterprise—they’re all in a different maturity, they’re all in a different level and area of that DevOps transformation. But what we’re able to do is, we have a solution that can help everybody regardless of where they’re at, and as they mature together over time, ultimately help them reach the goal where the company wants them to be.

    You know, some of the new things that we’re focusing on—you know, last year, part of our vision, we had announced at Interconnect our DevOps Insights product as well as our continuous release product that are focused on helping customers one, transition into DevOps, do a lot of that deeper reporting and ROI analysis on where they are in their transformation, but as well as help companies manage to the cloud and for the cloud.

    What I mean by that is, you know, today, we talk about cloud like it’s ours, but for large enterprises, it’s still very much a challenge. You know, it’s hard for a team to just go request access and say, “Hey, I’m gonna push my data to the private cloud.” There’s still a lot of—or even public cloud, whatever it might be. There’s still a lot of hurdles to that.

    So, what we’re trying to do is, as teams embrace this and they’ve got deployments going on-prem and off-prem, how do we organize that? How do we have visibility and traceability and understand as you’re taking large applications and breaking them down, let’s say, into microservices? You know, some of those applications are easy to re-architect, some are not. And sometimes you’re left with applications where you’ve only got maybe three quarters of that application re-architected, or you’ve got databases that are always gonna be on-prem, or you’re using mainframe services.

    And that’s really where the UrbanCode products excel, is allowing you to really deploy anything, anywhere, but also have a cohesive look at, what are the interrelated appendices of those parts? If something on my backend mainframe changes, how is that affecting the things that I’ve deployed into my mobile app? And if something needs to fall out of just release, you know, what’s the impact, even? How is that gonna affect business? And I think those are some of the main reasons why we scored well within the Forrester Wave and why they marked our strategy so high.

    Shimel: Absolutely. You know, Steve, we’re coming up on the end of our allotted time, unfortunately, but I wanted to mention one thing if we can talk about it, and that is that you spoke about Interconnect, which has been the big IBM DevOps related show, as well as other technologies for the last couple years. This year, IBM is kinda consolidating a lot of the shows they do into a pretty big mega-event called Think 2018, and of course, that is gonna be once again at the Mandalay Bay in Vegas, and it’s happening March 19th to the 22nd. I believe the call for speakers has just opened, and I’ll put some links in the show notes so that people can, if they wanna speak or if they want to attend the event would be great.

    But in any event, what’s UrbanCode’s plans around Think 2018?

    Boone: Yeah, thanks. I hope folks do and are able to register and come out. It’s going to be a fantastic show, and it is very much a mega show for us. So, we’ve taken—I believe there’s 11 different topics that really, I’ll call them focal points or even think of them as investments within IBM. Everything from cloud to Watson to mobile to security, internet of things—there’s a number of different topics going on at this.

    UrbanCode will be under the cloud focus, and we’ll—underneath the cloud topic, there’s a section specifically for DevOps. So, if that’s what you’re interested in, come out and check us out—we’ll be there. We’ll be talking about our latest release that we’ll have done at that time, and we’ve got a lot of really cool features that were actually in development and testing right now that we plan to announce at the Think conference, so without be demo-ing those, and we’ll have—as always, have a bunch of UrbanCode customers there sharing their ideas, sharing their experiences, and really helping educate how they’ve transformed their business.

    And I think what a lot of folks will find appealing is that it’s never a one tool solution, right? And that’s one thing I always encourage folks is, when you’re trying to be in a DevOps transformation, a single product, a single methodology—it’s not gonna do it. You really need to embrace the various tools that are in the market, you need to embrace existing tools that are already in your company, and these are gonna be working examples and explanations of how some of the top companies in the world are doing just that using UrbanCode and using a variety of tools that we support.

    Shimel: Absolutely, absolutely. Alright, Steve, we’re actually way over time, I apologize, but I think we got some good information here that people will be interested in. I want to thank you for being our guest this week on DevOps Chat and invite you back soon. We want to hear more about Think 2018 as we get closer as well, but good luck with UrbanCode, Steve, and we’ll speak to you soon.

    Boone: Hey, Alan, thank you. As always, appreciate you having me today.

    Shimel: Alright. Steve Boone, Product Manager, UrbanCode Deploy—or Product Owner, excuse me, UrbanCode Deploy. Thanks for being our guest on this DevOps Chat. This is Alan Shimel, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • 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

  • IBM: DevOps Challenges Require Managed Services

    IBM: DevOps Challenges Require Managed Services

    The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.

    Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:

    • Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
    • Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
    • Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
    • Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
    • Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.

    IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.

    Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.

    — Mike Vizard

  • DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    CJ Paul and Cliff UIn this DevOps Chat we sit down with Cliff Utstein, director of Offering Management, IBM Cloud DevOps and CJ Paul, distinguished engineer and chief architect, IBM Cloud DevOps. Cliff and CJ give us some insight into how some of the biggest trends in technology today—DevOps, cognitive, IoT  and blockchain—are connected. It is a great discussion with some of the people at IBM who are dealing with these subjects day in and day out.

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

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud and we’re here for another DevOps Chat. We have a really interesting DevOps Chat today and it’s regarding how DevOps kinda interacts and can help you get started with some of the leading sort of technology trends out there today and talking about things like cognitive and blockchain and IoT, etc. So a lot to cover in our 15-minute show, but we’re gonna do the best we can. I’m joined today by two friends from IBM. First of all, a returning guest to DevOps Chat, our friend CJ Paul, distinguished engineer and chief architect, IBM cloud. CJ, welcome to DevOps Chat.

    CJ Paul: Thank you, Alan. Glad to be here.

    Shimel: Thank you and welcome – glad to have you here. And, secondly, we have Cliff Utstein, and, Cliff, if I mispronounced your last name, I apologize, but Cliff joins us from Boston and he is the director of DevOps product development for IBM Bluemix and cloud. Cliff, welcome.

    Cliff Utstein: Thanks, Alan.

    Shimel: Did I mess up the title or the name?

    Utstein: I actually lead product management for IBM’s Bluemix – IBM’s cloud DevOps.

    Shimel: I apologize. So much for me for following the show notes. That’s what you get. [Chuckles] But, okay, fantastic. So, guys, you know, three big, kind of meaty topics out there—cognitive, blockchain, and IoT—and then how does DevOps help you get started with all of them. Let’s start with cognitive because, certainly, IBM is a market leader in cognitive and it seems like they’re building cognitive into everything. So let’s talk a little bit about that. CJ, I’ve probably spoken about this with you in the past, so, if you don’t mind, let’s start with you. How can DevOps help you get started with cognitive?

    Paul: Well, we find many customers evaluating several of these cognitive services that Watson provides. They are available as APIs in Bluemix, so this is – such as natural language understanding, natural language classifiers, the Watson conversation service, and many others like that. And many companies are looking at how to take advantage of those combination services to build interesting applications, like chatbots, that they can deploy for various use cases. So, as they look to build these applications, clearly, the way you build these applications is important.

    What DevOps proposes now is an iterative model where you rapidly take ideas and get them into code and deliver them out to market and see how effective they are. And then, you know, measure the usage and iterate rapidly from there, so using the DevOps practices and toolchains that we provide, it can greatly speed up a company’s ability, the developer’s ability, to build and deliver these leading-edge cognitive applications.


    — 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

  • IBM: DevOps, AI to Drive Digital Business Transformation

    IBM: DevOps, AI to Drive Digital Business Transformation

    Conventional wisdom holds that one of the biggest challenges organizations face today is a chronic shortage of application developers. But as artificial intelligence (AI) advances, the process of writing code will become more automated. But rather than there being not enough developers to write all the code necessary, the shortage will be in software engineers who can develop innovative systems.

    Bob Lord, chief digital officer for the Digital Business Group at IBM, says a glimpse of the future of application development is already being provided today. Instead of writing low-level code, most developers today simply combine modules to create new applications. Anytime new functionality is required, another module gets dropped into the application. The number of developers writing the low-level code needed to create those reusable modules is relatively few, says Lord.

    Over time, however, AI models will learn how to write that code. People will add value by providing the engineering expertise needed to combine modules to create an innovative application, Lord says. Naturally, most of the processes employed to deploy that software also will be automated. But IT operations teams will be needed to continuously train the AI systems being used to deploy that software. This is in much the same way that we need human pilots to fly a plane whenever something new or different occurs, despite the existence of autopilot technology.

    In general, Lord says, IT organizations would be well-advised to focus on three things:

    • They need to decide what architecture strategy is going to be employed to accelerate DevOps integration.
    • They need to develop a data strategy that drives digital business transformation.
    • They need to layer a cognitive computing strategy that employs advanced algorithms to maximize the business value of the data they’ve accumulated.

    While some organizations approach these issues in isolation, Lord says the reality is they’re all closely connected. Organizations are investing in DevOps not just to reduce costs—DevOps is about attaining a level of IT agility capable of driving digital business transformations. In fact, Lord believes the way IT organizations are measured will change: Rather than being rated on traditional IT metrics, they will be measured on how effective they were in attaining business goals—especially when to comes to velocity at which applications are rolled out and updated.

    In the meantime, Lord says, developers are starting to exercise more influence over the technologies organizations are employing to achieve those goals. Because of that issue, IBM is making an effort to get closer to the developer community. But as application development advances, many of those developers will be software engineers rather than people who write code, while IT operations teams will become teachers who train intelligent systems how to respond to the needs of deployed code.

    — Mike Vizard

  • DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    Before the recent IBM InterConnect conference I had a chance to sit down and chat with Sanjeev Sharma, CTO of DevOps Adoption at IBM. I have spoken to Sanjeev many times and he is a contributor to devopsy.kinsta.cloud, as well as the author of “DevOps for Dummies.” Sanjeev has a new book out called “The DevOps Adoption Playbook.”

    With no disrespect toward the “DevOps for Dummies” book, the playbook is on a whole different level. This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, as well as some of the leading names in DevOps that he learned from during this time.

    “The DevOps Adoption Playbook” lays out a clear “how to” for DevOps including topics such as value-stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a power point of best practices that he had started that tried to take in everything he had learned.

    Sanjeev also stays true to the “playbook” paradigm. He makes references to cricket, soccer and other sports throughout. It is a good read and well-organized. As I told Sanjeev, in a field full of “what is,” “The DevOps Adoption Playbook” is a “how to.” I highly recommend it.

    As usual, the streaming audio of our conversation is below, with the transcript of our conversation below it.

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on DevOps Chat is Sanjeev Sharma, a DevOps author and IBM CTO DevOps. Sanjeev, welcome.

    Sharma: Thanks, Alan. Good to talk to you again and I’m glad to be on this DevOps Chat

    Shimel: Absolutely. Sanjeev, you are of course CTO DevOps Solutions at IBM, correct?

    Sharma: The exact title, not that it matters as much—it’s just nomenclature—is CTO DevOps Adoption. I am client-facing and work with customers around the world, helping them adopt DevOps, primarily focused of course on IBM solutions.

    Shimel: In addition to that, Sanjeev, of course you are the author of both editions of the “DevOps for Dummies” books, which were very successful in introducing DevOps concepts to the world at a time when DevOps wasn’t quite as well-known as it is now. Correct?

    Sharma: Right, yes. It’s hard to believe that that book has been around for multiple years now. We’ve had tremendous success. Bernie Coyne coauthored the second edition with me. We updated it and it’s been very successful. The book came out at a time when people were mostly asking the question, “What is DevOps and what does it mean to me?” That’s what that book is targeted towards. It’s a very short book. You can read it in an hour, an hour and a half. It’s like a dummified version, so pretty short and to the point.

    Shimel: Yes. But really, Sanjeev, I wanted to talk to you about the new book that you just came out with through Wiley and IBM Press and its called “The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise.” Sanjeev, I’ve read the book and to me this sort of represents the culmination of all of the lessons and the knowledge that you have accumulated over these last few years, in helping organizations around the world with their DevOps. Is that fair to say?

    Sharma: Absolutely, but I would go one step further and say it’s just not my knowledge and my experiences, which are fairly extensive. I’m sure I worked with dozens of customers around the world. I haven’t counted, but some of them very intimately through their multi-year DevOps adoption journey.

    But as you will see in the acknowledgement section of the book, it was also knowledge I gained talking to my colleagues here at IBM, talking to people like you and other business partners, our followers and colleagues in the DevOps industry, and also of course from our customers, because I wasn’t with them 24/7 carrying the tools of the trade and implementing DevOps and fighting the technology and the political and the business battles. They were doing it, and I was learning by observing them succeed or, in some cases, stumble and then figuring out with them how to go around the hurdles they were facing. So I owe a lot to all the people I worked with over these years, including our customers, in putting together what has come in this book.

    Shimel: Absolutely. Sanjeev, you’re being humble. You have worked with dozens of DevOps people. But in that role, as you say, you’ve interacted with many of the thought leaders, if we can call them that, within the DevOps movement.

    More than that though, when you look at the book, what I’ve said about the book and I’m writing a review of it, is that in a world full of books that are “what is” your book is a “how-to.” I think that’s an important reminder. We read too many books around DevOps that are trying to define what DevOps is, trying to put your finger on that slippery fish of, “This is DevOps,” where you spend some time on that right in Chapter 1. We give a little review of DevOps, but you spend a lot more time on good practical how-to DevOps advice.

    Was that your idea with this book? What drove you to write this book?

    Sharma: Absolutely, Alan. If you read this as a “how-to” book and not a “what” book, then I have succeeded in getting my message across. Quite frankly, it’s how this book came together. As I was working with our clients maybe two years, 18 months ago, the questions started changing. People no longer were asking us, “What is DevOps?” They were asking us, “How do I adopt DevOps? What are you seeing other people do? What can I learn from your experiences when you go with that bank over there or that health care company or that telco, that retailer? What are you observing when you’re out there in the trenches?”

    I started actually putting together a PowerPoint deck. This is where this book started, as a PowerPoint deck of best practices as part of the success. In fact, last year at InterConnect, myself and my colleague, Lee Reid, who is actually the technical editor of the book, we did that presentation and we called it “The DevOps Adoption Playbook,” and that’s what I intended this to be, this book to be a playbook which somebody reading it can have or they can learn all about it and then, based on the situation they are facing, pick a play, just like a coach or a captain does or a quarterback does in American football. He can do a read and get an idea of, “Okay. We need to run this play because that’s what’s needed here.”

    So it’s definitely a how-to book. There are certain, of course, strategic areas in the book on how to convince the business that the DevOps is in order to make a business case. Like its name suggests, it’s a playbook on how to go and get in the trenches and adopt DevOps in a large organization.

    Shimel: Sanjeev, first of all, the book is available on Amazon and other sort of traditional bookseller sites. Correct?

    Sharma: Absolutely. This is my first retail book. The first book that you mentioned, “DevOps for Dummies,” was a free book we were giving away, sponsored by IBM. So to me as an author, when the book came out and I knew it would be available, the first thing I did was drive to the nearest Barnes & Noble, which actually is 15 miles from my house, just to go see the book on the shelf. So yes, it is available at all major booksellers, both as a physical book and as an e-book.

    Shimel: Let me ask, and I think I probably know the answer. Did you take a picture, a selfie of yourself with the book on the shelf behind you?

    Sharma: I wanted to do that, but the book was placed at a very awkward angle, so I couldn’t get myself into it. So I just took a picture of the book sitting there with the other books. And, you know, it’s not a selfie if you give the camera to somebody else. This was in the middle of the day. They were letting nobody in the bookstore. It was pretty hilarious. I wish I had videoed the whole thing.

    Shimel: Very cool. Sanjeev, people can get the book. They can see you for themselves. Also, I will mention that it’s the kind of book where if there’s something specific you’re looking to hone in on, a particular issue, problem, topic you’d like to delve into, the table of contents and the way it’s laid out makes it very easy to do so. So you could use it to kind of pinpoint in the kind of thing you’re looking for, or you can take it as an overview around the whole book. Either way it’s pretty good.

    Sharma: Thank you.

    Shimel: But, Sanjeev, there are a couple of terms in the book that I’d like to – one of the things is you talk about this concept of fast waterfall. It was mentioned in there a few times and I’ve seen others mention it.

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

    Shimel: Sanjeev, you talk about this concept of fast waterfall. Did you hear that?

    Sharma: Yes, I did. Thank you for repeating that. We were seeing a very broad spectrum of maturity levels and a spectrum of business needs, and we go with clients and see how they adopt DevOps. So when I go into an organization, no organization is monolithic. No organization is homogenous. You see one part of the organization where nothing is broken, things are going fine, but they’re using a very old-school waterfall approach to delivering systems.                           

    So the question that arises is: What do you do there? Do you disrupt something that is working during maintenance, more to try to introduce agile principles or try to introduce continuous delivery? Or do you just make what they are delivering more efficient?

    My thesis in the book is that you focus on optimization. You look at the delivery pipeline. You do what we call a value-stream mapping, and look at where the waste is, where the bottlenecks are, and look towards eliminating or mitigating those, without necessarily needing an end-to-end sea change to say, “No, you have to stop what’s working for you. Your business doesn’t need you to go any faster. Your business doesn’t need you to be more innovative because this is an application in

    – but you have to disrupt it.”

    That all or nothing approach does not work. It is also very expensive. So how do we make it more efficient? I don’t like the term “fast waterfall.” I would like to call it “optimized waterfall”. You focus on optimization. Yes, eventually your goal should be to move to full Agile. You goal should be to move to continuous delivery, but you cannot do that day one. You cannot do it across every project, every system and every application at the same time, but you can do some things to start everybody on that optimization journey.

    That is to me what I am referring to in the book. Get started. Get started where you are. Understand your end goal. But you don’t have to get there at light speed. You don’t have to get there yesterday and you don’t have to get there all together. You have to make that business decision of how much change to introduce, how much change you can consume, and how much change you can afford at this time. Maybe not today, maybe you can only do it next year. So that’s summarizing some of the thinking behind what you’re really getting ready to do.

    Shimel: Understood. Sanjeev, you mentioned value-stream mapping. That’s a workshop that I’ve seen you perform over the years and it’s great. If anyone ever gets a chance to sit in on one of your value-stream workshops they absolutely should. Can you give us just a little bit of an idea of what’s involved with that?

    Sharma: Sure. Value-stream mapping, I would add, as an exercise is nothing new. It’s been in there in the Lean movement since the last century, probably since the 1950s. It’s a technique by which you look at processes and you try to figure out where there might be some waste, and then do a root cause analysis to determine why the waste is there and make a plan to mitigate it.

    So in DevOps, if you look at your delivery pipeline as a value stream, that requirements are coming in at one end and code running and production being used by a user, getting business value at the other end, we do a value-stream mapping to look at where the waste is. So we look at artifacts going through that delivery pipeline.

    What are those artifacts? Who are the stakeholders who touch those artifacts and perform actions on them, who do processes on them? How does the transition happen from one stakeholder to the other? How does the artifact get transformed as it goes from one stakeholder to the next? What environment or tool or repository does the artifact live in and is it consumable?

    There’s a concept in Lean called percent complete and usable, which tells me: when I get an artifact, can I use it as _____ to consume it? Are the requirements coming from the business usable by developers? Is the code coming from developers usable by the testers or whatever? Are there manual tasks which are causing waste? Are there tasks people are doing which add no value to the product? They don’t add any business value, like status reports. They have some value, but are the status reports really being used to progress the product or are they really being used because some needs a view, and they have to spend time creating those reports rather than having a real-time dashboard somebody can just look at?

    So a value-stream mapping exercise and what you’ve seen is a half-day version of a workshop we do with clients, where we go in and take one project of theirs and do a value-stream mapping to get an idea of where the waste is. Many times, actually more often than not, we do it at a division or a program or a line of business level and look at for that line of business: What does the value stream look like and where are the bottlenecks? Where is the waste?

    Then we spend some time doing root cause analysis on each bottleneck we identify. Then we go away and come back with a recommended adoption plan of what DevOps practices and capabilities and tooling, and organization change also, would we recommend to help mitigate those bottlenecks. So it’s a very powerful exercise we do.

    I have an entire section dedicated to it in my book. And on YouTube, if you Google, search for DevOps Whiteboard, you will find me doing a mock value-stream mapping also. There’s a 30-minute video of me doing it with one of my colleagues. So it’s something we’ve had a lot of success with and I think it’s something every organization should do.

    Shimel: I agree with you and I have seen the video. Sanjeev, we’re almost out of time. I wanted to just pivot from the book for a moment and talk a little bit about InterConnect. IBM’s InterConnect this year is coming up in about two weeks. I know you’ll be appearing there and I would imagine the book is involved in what you’re talking about. Yes?

    Sharma: Absolutely. IBM Press was the publisher of the book along with Wiley. On Wednesday afternoon we will do a book signing. They’ll set one up. So if you have a book, if one of your listeners has the book, they can bring it there. I’ll be more than happy to sign it and have a chat with them. They will also be selling the books there at the IBM Press store.

    And I am told—I don’t know if I’m even supposed to tell this, but if you come to a DevOps session, a track in the DevOps session, in some of the sessions we’ll be doing some surprise giveaways of books also. But don’t tell anybody that.

    Shimel: No, of course I wouldn’t.

    Sharma: It’s one big secret. No, no, no. Personally, I am doing three sessions, one of which is a panel with customers, and there are two other sessions related. Both of them are topics I picked out of the books, individual chapters from the books. One is on building a business case for DevOps, and the other one is a risk-based model to adopting DevOps.

    Then the third is a panel, and the fourth is a workshop I’m doing on driving innovation. So it’s kind of broader than DevOps. That’s going to be an hour-and-a-half workshop. So it’s going to be a fun few days and I look forward to meeting your listeners there.

    Shimel: Absolutely. You know what? We’ll try to get some links to these in the transcript and notes on this podcast.

    But for now, I think we’ll call it a wrap on this DevOps Chat. Sanjeev, congratulations on a great book here. I mean “DevOps for Dummies” was certainly a great read, but this is a book. Kudos to you and the team. You put together a really nice how-to here. I’m looking forward to hearing and seeing you at InterConnect. Of course we run into each other quite a bit during the year and I’m sure we’ll continue to do so.

    Sanjeev Sharma –

    Sharma: Absolutely, Alan. Thanks a lot for having me and I looking forward to chatting again soon.

    Shimel: Absolutely. Sanjeev Sharma, “The DevOps Adoption Playbook,” a new book out, definitely pick it up, by Wiley Press and IBM Press. Sanjeev, thanks for being on DevOps Chat today and we’ll speak to you soon.

    Sharma: Thank you for having me, Alan. I’ll speak to you soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • Scaled Agile: Faster Feature Cycle Time, Improved Time to Value

    Scaled Agile: Faster Feature Cycle Time, Improved Time to Value

    Do you remember when the business imperative was improving feature cycle time? As if we just needed to deliver more stuff faster to win in the marketplace. I wouldn’t say that times have changed, but I would say we were just scratching the surface, and rightfully so. After all, we have to start somewhere. The adoption of agile methodologies have proven successful in helping redefine the characteristics and behavior of development teams and, in the process, have certainly helped speed feature delivery cycle time. Great! Is your business more successful now?

    Our goal then, and now, should have been to improve time to value. What good is it to deliver more stuff faster if it’s not the right stuff? How do you know whether it’s the right stuff? How do you make smarter decisions so that you know?

    Agile & Lean at Scale

    The Agile Manifesto explains the key tenets of agile transformations that lead us to this thought: It’s all about value, vision and quality—and rethinking what quality means—in terms of customer value. I didn’t make this up … a team of really smart people from different organizations and industries collaborated and the result is a truly inspiring set of guidance to help teams focus to deliver faster, smarter and better. The thing is, without adopting this guidance at scale, without thinking about what value means and how to prioritize investments into the delivery of value from the top down, we’re back to the same old decision-making process that often takes us off track.

    Business owners, portfolio managers, analysts, solution architects, product managers … all of these roles that operate largely on the “business” side need to think lean and agile and collaborate with engineering continuously to drive the organization as a whole to work faster, smarter, better. Aristotle said: “The whole is greater than the sum of its parts.” Think about that in terms of creating a unified, collaborative organization that marches to the same drum beat, uses the same language, follows the same process to make decisions and drive change. Regardless of whether you are operating at the portfolio or team level, or somewhere in between, you are essentially planning and executing, planning and executing. Your deliverables may be different but the goal is the same: deliver value faster, get feedback, rinse and repeat.

    Addressing the Whole Transformation

    Convinced? Maybe just intrigued? Fair enough. Let’s talk about how to do this, starting with my warning: Change is hard, especially when you’re trying to transform the mindset of an organization and do real work at the same time, so it’s not for the weak or meek. I’m not trying to scare you, just making sure you enter this with eyes wide open.

    With that out of the way, let me enforce the need to consider the whole transformation to be successful; this is not just about the process and it’s even less about the tools that support that process. It’s about the cultural change, first and foremost. There is no tool or magic pill for that. A well-defined, cohesive process is key, however, in uniting the tribes, so in this way it helps with the culture issue. Finally, embedding a well-defined process in tooling just makes things easier because you knock off the requirements related to collaboration, traceability and reporting with the tooling. Remember: people, process, tools.

    SAFe is the Recipe

    So what scaled agile process should you use? Well, I can tell you that you do not need to develop your own process, there are several out there. I favor the Scaled Agile Framework (SAFe) for a number of reasons: it is extremely well-defined, it covers nearly any size and complexity, and it is flexible despite what some may think. At the same time, it’s just a framework—there is no one size fits all and you do not have to adopt every aspect. But you don’t need to start from scratch, either. Be smart about this and take advantage of the invaluable insight that went into the development of SAFe 4.0. My team has done that and I’ve worked with several large enterprise organizations that have as well.

    I love analogies to illustrate a point and simplify what might otherwise be complex, so let me leave you with this one: scaled agile transformations are like cooking. Start with a simple recipe (especially if you’re an inexperienced cook), learn the art and how to adjust seasoning as you go, and fine-tune the dish after feedback from your family. Then try it again. Do you get it? Same with scaled agile: Start with a good framework (SAFe), learn about it, take what is valuable from it for your organizational needs and try it out for an iteration, get feedback from your team and make adjustments to the process for the next iteration. Simple.

    Please visit our SAFe landing page on jazz.net for all things “SAFe”! We are here to help you with your scaled agile transformation (SAFe or not), so don’t hesitate to reach out.

    The IBM SAFe Team (safeinfo@bg.vnet.ibm.com)

    About the Author/ Amy Silberbauer

    Amy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Watson IoT line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 29 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework) transformations.

    Connect with Amy on LinkedIn.

  • DevOps in Legacy Systems: A Mission Impossible?

    DevOps in Legacy Systems: A Mission Impossible?

    The word “legacy” evokes mixed reactions from the IT and business crowds alike. For those who depend on legacy systems such as the zSeries and iSeries platforms, it is a way to deliver stable and reliable applications into production. Business stakeholders who may not know the intricacies of the technology often take a view of, “Why fix it when it ain’t broken?”

    mainframe

    On the other hand, for those who haven’t experienced the joys and pains of legacy systems , legacy world will continue to defy their logic and assumptions because their view of the world is shaped by the open system world which has completely different characteristics: being more malleable to change and easy to maintain etc. Hence there is this great divide between the legacy and new worlds. Add Agile and DevOps to the equation with the lofty goals of increased release frequency and reduced lead times, we end up with a divide that is too far to bridge.

    cobol code

    The likes of Gartner have come up with constructs such as two-speed delivery to help deal with this legacy challenge. In my view, there is a problem with the idea of dual-speed because it is based on a wrong analogy to start with — that of allowing vehicles to move at different speeds depending on whether you are on the motorway or a city road. That analogy works well for traffic management scenarios but not for complex IT architectures we see in the enterprise. The dependencies across the systems in the enterprise landscape are just too intricate and too tightly coupled to be defined using such a binary logic. In my experience, I find that many Agile and DevOps transformations hit the roadblock and never achieve the desired levels of productivity and effectiveness because of an oversimplified view of these complex dependencies across legacy and open systems.

    The three biggest challenges that prevent a legacy DevOps transformation are mindset problems, architectural constraints and tooling limitations.

    The Mindset Problem

    “There are no legacy systems, just legacy thinking.” That’s a great quote I heard recently from an engineer in a large organization trying to adopt DevOps at enterprise scale. The initial resistance from teams to move into DevOps ways is due to reluctance to change, emerging from an inertia of doing things a certain way for years if not decades. The mindset problem is as much a problem for those outside the legacy world as those inside. The “outsiders”—typically leadership, management team and consultants—tend to oversimplify the problem and, too often, rely on examples from the open systems world. This just alienates the incumbent legacy teams and makes them even more skeptical of DevOps driven change. The outsiders need to have a genuine appreciation of the challenges with legacy architecture and need to work in collaboration with the legacy teams if they really want to transform their organization.

    Architectural Constraints

    Legacy systems have certain characteristics such as being static, tightly coupled and monolithic blocks of procedural code. These systems were not built for the modern Agile workflows that focus on incremental and iterative deliveries. A significant majority of these systems are written to operate in batch mode.Testing the systems requires cycling through multiple business days, which simply limits the level of agility you want to introduce in the organization. I am currently working with a legacy engineering team in the financial services space where you have to cycle through a minimum of 20 business days to simulate even 70 percent of the test scenarios. However, there are a number of solution options to overcome the architectural challenges; they range from killing applications to migrating to modern platforms or re-engineering legacy code. Not surprisingly, the right approach depends very much on your context.

    Tooling

    Tooling in the legacy world to support a DevOps ways of delivery has always been a challenge. But it is fast changing now, thanks to a number of startups and even old-school IT product companies investing in this space. If you consider zSeries as an example, there are better IDEs (integrated development environments) such as RDz that can replace traditional code editors typically based on “green screens.” These IDEs provide great features such as better navigation, debugging, split views and searches on the legacy code. One of the CIOs I worked with made it clear to his team that he wanted to get rid of “green” screens from the IT floor. There are tools such as SmartBear Collaborator that support a great peer review experience and help bring one of the original XP practice of pair programming to the legacy world. There are tools such as endeavor from CA that promise automated build and deployments in the z-series world. Similarly, there are tools that support test automation of mainframe applications and tools for code coverage and code quality checks on legacy programming languages like COBOL. XATester looks like a promising tool for unit test automation from a Danish startup called Xact.

    While this write-up is not intended to be a compendium of all DevOps and engineering tools, the central message is that there are a number of DevOps tools emerging on the legacy landscape which can help your legacy delivery teams get on to the DevOps and Agile journey.

    What is more important is for organizations to realize that many of these legacy systems will remain part of their IT landscape for the next foreseeable future and it is time to invest in these core systems. They may not look as appealing as the digital platforms, but they are fundamental for businesses and you cannot ignore them on your DevOps journey. DevOps in the legacy world is not going to be smooth, but it is certainly not a mission impossible!

    — Aditya Vadaganadam