devopsy.kinsta.cloud

Tag: ibm

  • DevOps Chat: CI/CD with Travelers and Urban Code

    DevOps Chat: CI/CD with Travelers and Urban Code

    In this DevOps Chat we speak with Laurel Dixon-Bull of Urban Code and Frank Canihuante of Travelers about CI/CD. Frank explains to us how he improved the CI pipeline at Travelers and some of the challenges he faced with the scale of a large enterprise like Travelers. Good case study.

    As usual, immediately below is the streaming audio of our conversation. Below that is the written record of our chat. Enjoy!

     

    Alan Shimel: Hey, everyone. Alan Shimel, Editor in Chief, devopsy.kinsta.cloud. Here for another DevOps chat. Today we have two guests on DevOps Chat. First of all we have Laurel Dickson-Bull of IBM’s UrbanCode. Laurel, welcome to DevOps Chat.

    Dickson-Bull: Hey, thanks Alan. I’ll just give you a quick introduction. I’m an offering manager for UrbanCode Deploy. And I started at IBM about 14 years ago, working on internationalization and localization. I spent a few years in release management and saw the agony of software delivery. And then now working very close with UrbanCode Deploy delivery team.

    Shimel: Excellent. And our second guest is Frank Canihuante. If I mispronounce it I apologize Frank. We’ll give you a chance to correct. And Frank, you’re with Travelers. Welcome to DevOps chat.

    Canihuante: Hi, Alan. That was close enough as far as pronunciation. Yes. So I’m a tech lead here at Travelers. I’ve been with the company for three years and was actually hired to lead the technical aspects of setting up a new pipeline actually. Been a developer for over two decades under various roles, different types of projects. And for the past 10 years or so, I’ve been very involved with things that relate to what we now call DevOps. And always thought of that as being just doing good software engineering.

    Shimel: Absolutely.

    Canihuante: So this is right up my alley.

    Shimel: So we spoke a little off camera or off mic before we started today. And Frank, you mentioned that you’ve been doing sort of very DevOps like things for the last 10 years, way before they started calling it DevOps. And you know you’ve been riding this wave for a while. But Frank, I wanted to take a quick moment and talk about sort of the legacy that you had at Travelers. You mentioned you joined three years ago and you were brought in to really kind of update the pipeline, the CI process if you will. Right, continuous integration. Can you give us an idea of what it was like when you first came on board?

    Canihuante: Sure. You know the interesting thing about this project that is now basically setting up a pipeline. That it wasn’t really stated as such. It was about replacing the old systems. And that right away told me that we weren’t quite sure of what the actual solution was. Now, these days we think of CI, CD, even three years ago, those two words weren’t all that popular as they are now. Of course now we understand that that is the way to go these days. You set up a continuous integration and a continuous delivery set of tools. So there was a lot of confusion. There was a lot of angst because everyone knew that if you were about to change, these tools are near and dear to your day to day activities as a developer, as a QA, as a DevOps professional. There’s some disruption that’s gonna happen. So lots, lots of expectations and a little bit of apprehension as well.

    Shimel: Yep. Got it. And so Frank, you came in and you know tasked with updating this. For someone who’s listening out there and says geez, that’s just where I was. Where Frank was three years ago, that’s where I am today. Can you give ’em a little advice? Where do you start?

    Canihuante: Sure. So I have put pipelines together before but at a smaller scale. So my biggest concern _____ at the same time what made it very exciting for me to take on the job was how am I gonna do this in a large enterprise. Travelers has 30,000 employees, 3,000 of which are in IT. So I knew this is directly or indirectly impacting hundreds of thousands of people. So there was a lot of responsibility to go with it. So one thing that I would recommend is you have to do your homework. You have to have a lot of experience in development to be familiar with the way developers think. Because at the end of the day they are your customers. And they’re very demanding. They have things that work now, however quirky they may be, it works. You’re about to change that. You have to be sure whatever you’re gonna replace the old tools with, it’s something that you as a developer feel comfortable with. This is where the Devs part of the DevOps part comes in. And the other part also is once you have the system put together, you have to run it like a product. And this is something that sometimes we in the rush of getting something out there, people don’t perhaps think of the operational aspects of a system. But it is something that we need to have.

    Canihuante: I was just saying that you know putting it together requires a set of skills that basically call on all your development experience. But you cannot forget about how are you gonna run these tools, how are you gonna operationalize them. So trying to keep your customers happy is yet another challenge.

    Shimel: Yeah. Absolutely. And so Frank, ultimately you and the Travelers team wound up partnering up with IBMs UrbanCode deploy on this project, correct?

    Canihuante: Yes. So we looked at several tools. We had all the main vendors of CI and CD tools.

    Shimel: I mean you don’t have to name names but —

    Canihuante: Okay. Sure. So we had a process in which we brought in several vendors of CI and CD tools. And we really put UrbanCode Deploy through its paces as far as the deployment tool. We had in our RFP, which we did have a formal RFP process, many, many questions that related to how it actually worked and how it was actually operated. So we had a pretty good idea before we even brought the tool in for actual POC. But having the POC is what really made a big difference in realizing what it can do. It was very different from the old tool that we replaced. And actually once we had our users in, it brought the level of angst and anxiety that they had about the new system down to the normal levels. You know one thing is to see a demo, another thing is to actually put your hands on it and actually get an application be deployed through this new tool.

    Shimel: Got it. So Laurel, let me turn to you a little bit. When did you become involved with Frank and the Travelers team?

    Dickson-Bull: Well, I’ve been aware of Frank and Travelers team probably for the last couple of years. I think I visited you down you in Connecticut Frank, probably a year or two ago. I have to say though most of what I know about Frank and his team are things that I’ve heard. Really strong team. They’ve actually adopted UrbanCode very quickly and have you know made really fast progress. You know to some people, two or three years may seem like a long time. But to standardize on a deployment tool and in a large organization with ten thousand developers, that’s actually really, really good progress.

    Shimel: I agree. So Frank, give us an idea you know first of all do you consider this project to be successful at this point?

    Canihuante: Absolutely. There are many ways to measure how a project is successful. Projects of this type. In our case, we had over 2,000 applications in the old system. And one way to measure success is to say how many do we still have in the old system after a years’ time. So out of the 2,000 plus, we got about a hundred or so that are still in the old system. And they’re on track to be actually migrated to UCD in the next few weeks or months. But in addition to that, there are these other things that actually make it successful. Just having built something in collaboration with hundreds of other people and get their heads together as to putting together a pipeline that’s gonna make their life easier down the road. That’s another way to measure success. It’s kind of hard to measure it, but you see it in the way people talk. For example, we’re no longer talking about the way we need this tool or that tool. We’re talking about two different ways to solve a particular problem. Before, we didn’t even know how to solve it. Now we have multiple ways. And even the conversations are different. It’s not about particular problems that a group may have. But it’s always thinking how can we solve this problem for everyone. How can we come up with that pattern that solves how to build and deploy applications? Not just for my group or my division, but for the entire company.

    Shimel: Got it. And Laurel, does that jive with you know I’m sure you’re speaking with other organizations using UrbanCode Deploy. Is that sort of measure of success the same you know across the board? The same type of thing?

    Dickson-Bull: Yeah. Well, I would say that what Frank described as you know the challenge of standardizing on a tool for the enterprise and then going through that and it really opens up the conversations. Because once you have the visibility into the deployment automation and you start having success operationalizing your software delivery. People get excited about that. And they want to you know solve problems of automation. Dev and Ops are talking to each other. And the conversations become more collaborative. So I have definitely seen that with other large companies. And you know Travelers does represent a very large segment of our customers in the financial services. You know banks and insurance make up a good chunk of our customer base.

    Shimel: And you know Frank, in talking again off mic a bit you know setting up your CI pipeline. UrbanCode Deploy’s obviously a tool that you use. But you guys are also using the integration with that and Jenkins. Correct?

    Canihuante: Right. Yes, that’s correct. And Jenkins is interesting too because it was already in-house so _____ reasons why people wanted it. But it comes in two flavors. We have Jenkins ______ with various versions ______ also standardizing on a enterprise version of it. And we provide solutions that now encompass not just UrbanCode Deploy but also Jenkins. And we’re also providing a standard way of solving particular types of deployments. For example, how to deploy to WAS or JBoss. How to do .Net deployments. How to do database deployments. And it gets everyone really excited about having a standard way but sometimes even with flexibility to even tweak that a bit. Because we have some groups that only do say .Net, others do only JAVA or some do a mix of both. And now we have a menu of solutions that will span more than one tool. In addition that, there are other things that we have done that we are picking up these oddball applications. Like for example, telephone applications, voice applications. Even things that _____ not thought that we were actually going to install for but we have the ability to do that such as mainframe components, desktop components. We’re all bringing it together as a family of solutions on these tools in addition to integrations with other systems outside of the tools themselves. Such as the ticketing system for example or the monitoring system.

    Shimel: Got it. And Laurel, you know I’ve known about UrbanCode having integration with Jenkins for some time. Actually at Interconnect I think it was last year or the year before, Eric Minick of UrbanCode actually did a joint session with Kohsuke Kawaguchi, the founder of Jenkins and CTO of CloudBees. And so I’m wondering have you run into a lot of UrbanCode customers who are also using Jenkins?

    Dickson-Bull: Oh, yeah. For sure. I would say about half of our customers are using Jenkins. And UrbanCode is you know a great extensibility platform for Jenkins, right. So we’ve got over 300 plugins that will integrate with multiple technologies. And then like Frank was saying, multiple platforms from COS and even .Net, right. We have a lot of Microsoft integrations. So, yeah. I mean Jenkins is a great partner actually in the customer environment.

    Shimel: Interesting. Guys, as I mentioned to you earlier, our time here goes so quick and we’re already coming up on 15 minutes. We’re gonna have to try to wrap up. But as I mentioned, I always like to ask our guests you know can you recommend a book to our audience that you know kind of a must read or should read. And Laurel, I’m gonna let you go first. Is there a particular book you’d recommend to our audience that they might find useful?

    Dickson-Bull: So in the vein of DevOps, collaboration and teamwork that’s really important. Especially in agile development. There was a tool that I came across (that helps you) figure out your strengths. And then when you work with your _____.

    Shimel: You know what Laurel —

    Dickson-Bull: What?

    Shimel: I think we missed you when you said the name of the book. Can you repeat it?

    Dickson-Bull: Okay. It’s not a book.

    Shimel: Oh, okay.

    Dickson-Bull: It’s actually a survey or it’s a tool that you can use with your agile teams to figure out your various strengths. And it’s called Strengths Finder and it’s published by Gallup.

    Shimel: Got it. Oh, very cool. We’ll see if we can get a link to that in the notes.

    Dickson-Bull: Okay.

    Shimel: Frank, how about you? Anything you could recommend to our audience?

    Canihuante: Yeah. There’s so many books out there. But there’s one that I really like. It’s more of an author than a particular book. His name is Steve McConnell and he’s written the famous “Code Complete.” And I believe there’s a “Code Complete 2.” But there’s one other I really like. Actually two more. It’s called Rapid Development and the other book is called “Software Project Survival Guide.” These are from late 1990s. But if you read them it’s kind of like “The Phoenix Project” but 20 years ago. The same problems. The psychology of the software development world and how all that works. Really exciting stuff.

    Shimel: Excellent. Well, Frank, before we close off and Laurel, I wanted to mention Frank, you are appearing at IBM Interconnect this year?

    Canihuante: Yes. I am. I’ll be talking about our Travelers story at Interconnect.

    Dickson-Bull: And we’ll be having you on a panel too, right Frank?

    Canihuante: Oh, that’s correct. That’s gonna be on Wednesday. I forget the date.

    Dickson-Bull: Yep. We have a few of our larger customers who have had success with DevOps joining us on a panel called, “DevOps-You’ve Got This.”

    Shimel: Great. Sounds Great. We look forward to seeing it. I’m actually doing a panel there too called DevOps-It Takes a Village. So we could share notes Frank, while we’re out there. And Laurel, will you be attending Interconnect as well?

    Canihuante: That’s awesome.

    Dickson-Bull: I will be. I’ll be leaving that panel, DevOps-You’ve Got This. And then right before the conference, we have a full day workshop with customers from UrbanCode. So I’m organizing that now and we’ll be leading that on Sunday.

    Shimel: Fantastic. All right. Well, Laurel Dickson-Bull of IBM UrbanCode. Frank Canihuante of Travelers, thank you for being our guests on this episode of DevOps Chat. Look forward to seeing you both out at IBM Interconnect the week of March 19th. And your panel Laurel that you’re organizing as well as Frank, you’re talking a little bit about your Travelers experience. And good luck as you continue to you know make the pipeline and DevOps happen at Travelers Frank. Thanks for telling us about it.

    Dickson-Bull: Thanks Alan.

    Canihuante: Thanks Alan.

    Shimel: Thanks guys. This is Alan Shimel for devopsy.kinsta.cloud. Thanks for being our guests today and we’ll see you on a DevOps Chat soon.

    — Alan Shimel

  • IBM Building First Universal Quantum Computers for Business and Science

    Yorktown Heights, N.Y. – 06 Mar 2017: IBM (NYSE: IBM) announced today an industry-first initiative to build commercially available universal quantum computing systems. “IBM Q” quantum systems and services will be delivered via the IBM Cloud platform. While technologies that currently run on classical computers, such as Watson, can help find patterns and insights buried in vast amounts of existing data, quantum computers will deliver solutions to important problems where patterns cannot be seen because the data doesn’t exist and the possibilities that you need to explore to get to the answer are too enormous to ever be processed by classical computers.

    IBM Quantum Computing Scientists Hanhee Paik (left) and Sarah Sheldon (right) examine the hardware inside an open dilution fridge at the IBM Q Lab at IBM’s T. J. Watson Research Center in Yorktown, NY. On Monday, March 6, IBM announced that it will build commercially available universal quantum computing systems. IBM Q quantum systems and services will be delivered via the IBM Cloud platform and will be designed to tackle problems that are too complex and exponential in nature for classical computing systems to handle. One of the first and most promising applications for quantum computing will be in the area of chemistry and could lead to the discovery of new medicines and materials. IBM aims at constructing commercial IBM Q systems with ~50 qubits in the next few years to demonstrate capabilities beyond today’s classical systems, and plans to collaborate with key industry partners to develop applications that exploit the quantum speedup of the systems. (Connie Zhou for IBM)

    IBM also announced today:

    • The release of a new API (Application Program Interface) for the IBM Quantum Experience that enables developers and programmers to begin building interfaces between its existing five quantum bit (qubit) cloud-based quantum computer and classical computers, without needing a deep background in quantum physics.
    • The release of an upgraded simulator on the IBM Quantum Experience that can model circuits with up to 20 qubits. In the first half of 2017, IBM plans to release a full SDK (Software Development Kit) on the IBM Quantum Experience for users to build simple quantum applications and software programs.

    The IBM Quantum Experience enables anyone to connect to IBM’s quantum processor via the IBM Cloud, to run algorithms and experiments, work with the individual quantum bits, and explore tutorials and simulations around what might be possible with quantum computing.

    “IBM has invested over decades to growing the field of quantum computing and we are committed to expanding access to quantum systems and their powerful capabilities for the science and business communities,” said Arvind Krishna, senior vice president of Hybrid Cloud and director for IBM Research. “Following Watson and blockchain, we believe that quantum computing will provide the next powerful set of services delivered via the IBM Cloud platform, and promises to be the next major technology that has the potential to drive a new era of innovation across industries.”

    IBM intends to build IBM Q systems to expand the application domain of quantum computing. A key metric will be the power of a quantum computer expressed by the “Quantum Volume”, which includes the number of qubits, quality of quantum operations, qubit connectivity and parallelism. As a first step to increase Quantum Volume, IBM aims at constructing commercial IBM Q systems with ~50 qubits in the next few years to demonstrate capabilities beyond today’s classical systems, and plans to collaborate with key industry partners to develop applications that exploit the quantum speedup of the systems.

    IBM Q systems will be designed to tackle problems that are currently seen as too complex and exponential in nature for classical computing systems to handle. One of the first and most promising applications for quantum computing will be in the area of chemistry. Even for simple molecules like caffeine, the number of quantum states in the molecule can be astoundingly large – so large that all the conventional computing memory and processing power scientists could ever build could not handle the problem.

    IBM’s scientists have developed techniques to efficiently explore the simulation of chemistry problems on quantum processors (https://arxiv.org/abs/1701.08213 and https://arxiv.org/abs/1612.02058) and experimental demonstrations of various molecules are in progress. In the future, the goal will be to scale to even more complex molecules and try to predict chemical properties with higher precision than possible with classical computers.

    Future applications of quantum computing may include:

    • Drug and Materials Discovery: Untangling the complexity of molecular and chemical interactions leading to the discovery of new medicines and materials;
    • Supply Chain & Logistics: Finding the optimal path across global systems of systems for ultra-efficient logistics and supply chains, such as optimizing fleet operations for deliveries during the holiday season;
    • Financial Services: Finding new ways to model financial data and isolating key global risk factors to make better investments;
    • Artificial Intelligence: Making facets of artificial intelligence such as machine learning much more powerful when data sets can be too big such as searching images or video; or
    • Cloud Security: Making cloud computing more secure by using the laws of quantum physics to enhance private data safety.

    “Classical computers are extraordinarily powerful and will continue to advance and underpin everything we do in business and society. But there are many problems that will never be penetrated by a classical computer. To create knowledge from much greater depths of complexity, we need a quantum computer,” said Tom Rosamilia, senior vice president of IBM Systems. “We envision IBM Q systems working in concert with our portfolio of classical high-performance systems to address problems that are currently unsolvable, but hold tremendous untapped value.”

    IBM’s roadmap to scale to practical quantum computers is based on a holistic approach to advancing all parts of the system. IBM will leverage its deep expertise in superconducting qubits, complex high performance system integration, and scalable nanofabrication processes from the semiconductor industry to help advance the quantum mechanical capabilities. Also, the developed software tools and environment will leverage IBM’s world-class mathematicians, computer scientists, and software and system engineers.

    “As Richard Feynman said in 1981, ‘…if you want to make a simulation of nature, you’d better make it quantum mechanical, and by golly it’s a wonderful problem, because it doesn’t look so easy.’ This breakthrough technology has the potential to achieve transformational advancements in basic science, materials development, environmental and energy research, which are central to the missions of the Department of Energy (DOE),” said Steve Binkley, deputy director of science, US Department of Energy. “The DOE National Labs have always been at the forefront of new innovation, and we look forward to working with IBM to explore applications of their new quantum systems.”

    Growing the IBM Q Ecosystem

    IBM believes that collaborating and engaging with developers, programmers and university partners will be essential to the development and evolution of IBM’s quantum computing systems.

    Since its launch less than a year ago, about 40,000 users have run over 275,000 experiments on the IBM Quantum Experience. It has become an enablement tool for scientists in over 100 countries and, to date, 15 third-party research papers have been posted to arXiv with five published in leading journals based on experiments run on the Quantum Experience.

    IBM has worked with academic institutions, such as MIT, the  Institute for Quantum Computing at the University of Waterloo, and École polytechnique fédérale de Lausanne (EPFL)

    to leverage the IBM Quantum Experience as an educational tool for students. In collaboration with the European Physical Society, IBM Research – Zurich recently hosted students for a full-day workshop to learn how to experiment with qubits using the IBM Quantum Experience.

    “Unlocking the usefulness of quantum computing will require hands-on experience with real quantum computers,” said Isaac Chuang, professor of physics and professor of electrical engineering and computer science at MIT. “For the Fall 2016 semester of the MITx Quantum Information Science II course, we featured IBM’s Quantum Experience as part of the online curriculum for over 1,800 participants from around the world. They were able to run experiments on IBM’s quantum processor and test out for themselves quantum computing principles and theories they were learning.”

    In addition to working with developers and universities, IBM has been engaging with industrial partners to explore the potential applications of quantum computers. Any organization interested in collaborating to explore quantum applications can apply for membership to the IBM Research Frontiers Institute, a consortium that develops and shares a portfolio of ground-breaking computing technologies and evaluates their business implications. Founding members of the Frontiers Institute include Samsung, JSR, Honda, Hitachi Metals, Canon, and Nagase.

    “We heavily invest in R&D and have a strong interest in how emerging technologies such as quantum computing will impact the future of manufacturing,” said Nobu Koshiba, President of JSR, a leading chemical and materials company in Japan. “Our pipelines of innovations range from synthetic rubbers for tires to semiconductor and display materials, along with products in the life sciences, energy and environmental sectors. By having exposure to how quantum computing can provide new computational capability to accelerate materials discovery, we believe this technology could have a lasting impact on our industry and specifically our ability to provide faster solutions to our customers.”

    — Jules Louis

  • IBM InterConnect – CrowdChat, Preview and Panel Discussion

    IBM InterConnect – CrowdChat, Preview and Panel Discussion

    We are just about 2 weeks out from IBM InterConnect, which is shaping up to once again be heavy  on DevOps and related technologies. Of course there are other things on the agenda besides DevOps (really?), like cognitive and Watson for instance. There will be plenty of cloud, IoT and more cutting edge technology subjects. But you could read about that on other sites. Lets stick to DevOps here.

    First things first is I want to invite you to participate in a CrowdChat we are holding on March 10th at 1pm EST. CrowdChats are one of my favorite social media activities. For the duration of the event it is controlled chaos, as multi-threaded discussions break out across Twitter, Facebook and Linkedin.  You just have to use the hashtag #ibminterconnect to join in the discussion.

    I will be one of the hosts of this event, but I will be joined by Gene Kim, IBM’s Angel Diaz and Erick Minick and some surprise hosts that I can’t mention right now. So join in the discussion and fun on the 10th.

    At InterConnect itself, there are some great keynotes lined up and many outstanding speakers from diverse backgrounds. I want to call your attention though to one session in particular.

    Enterprise DevOps: It Takes a Village

    Wednesday, 9:00 AM – 9:45 AM | Mandalay Bay Ballroom A | Session ID: 1346A

    When talking about enterprise DevOps transformation, many people look for a silver bullet—a magic wand that will convert an old, inefficient organization into a high-performing, DevOps-enabled IT team. But in truth there is no single silver bullet. DevOps takes a village. This DevOps village, like a real village, consists of physical infrastructure, as well as members. DevOps often needs a cultural transformation that builds a true community with the same aims and goals. No one vendor has all the tools and no one tool does it all. DevOps tools must work in unison. Finally,  a methodology that recognizes the communal nature of DevOps is essential to bringing it all together.

    I hear the moderator for this panel session is pretty good. Some guy named Shimel ;-). Seriously, we have a strong panel and it should be a great discussion.

    Other speakers to catch are Gene Kim, Sanjeev Sharma (on his new book), IBM CEO Ginni Rometty, Wayne Brady and Reshma Saujani, founder and CEO of Girls Who Code. Check out the InterConnect site for full details.

    We will be posting some more DevOps Chats and interviews of some of the scheduled speakers between now and March 20th as well. So stay tuned for those.

    Tomorrow, we have a webinar with Carmen DeArdo of Nationwide, Donovan Stevens, South African Revenue Service and Rachel Reinitz, IBM Distinguished Engineer, CTO IBM Bluemix Garage. The webinar is on “Lesson Learned in Scaling Enterprise DevOps”, you can register here.

    — Alan Shimel

  • Dispelling the Myths Around Continuous Testing

    Dispelling the Myths Around Continuous Testing

    You may have seen the term “continuous testing” and thought it was just the DevOps flavor of the month. Some might even think it isn’t part of DevOps or isn’t for cloud or hybrid cloud applications. Well, think again.

    As it turns out, there are a few more fallacies around the idea of continuous testing floating around the application development community. Ready to find out?

    Chapter five in the new, free eBook “Continuous Testing for Dummies, IBM Limited Edition,” lists 10 myths. Here are a few to ponder:

    Continuous testing is only about executing test scripts

    Limiting the term “testing” to only the execution of test scripts is a misnomer. As my co-author, @Al_Wagner and I point out, testing and checking application functionality are not equal. There’s a long list of testing items to check off one’s list, the least of which is collaborating.

    Continuous testing is merely a buzzword

    Guess what? It’s a core part of that essential DevOps practice, continuous delivery. And, with customers demanding higher quality software faster, it isn’t going anywhere soon. In short, invest in continuous testing.

    Only agile teams do continuous testing

    False! Some or all parts of continuous testing are critical for any type of team as well as all players. This includes test automation, production-like test environments and realistic test data. A related myth—only testers contribute to testing—is also not true at all. The idea of continuous testing includes all team members. The book describes the roles everybody has to play. For example, did you know that designers can improve testing? They can work with testers to help them understand where the fragile parts of the application are.

    Automating tests means we need fewer tests

    No, the machines are not taking over. Automating tests does not mean cutting back on testing jobs. To the contrary, automation is reducing testers’ needs to act like cyborgs and spend more time doing what they do best: learn and experiment.

    Continuous testing isn’t for large, complex systems

    Au contraire! The best thing you can do for large or complex systems is leverage continuous testing practices and tools such as service virtualization to conduct end-to-end testing earlier and more frequently, rather than having each subsystem do all its own testing in isolation until just before deployment to production.

    To read more myths about continuous testing, check out “Continuous Testing for Dummies, IBM Limited Edition,” here.

    About the Author / Marianne Hollier

    MarianneMarianne Hollier is an IBM and Open Group Master Certified IT Specialist in application development. She has strong, practical expertise in measurably improving the software development life cycle and driving the necessary cultural changes to make it work. She is instrumental in architecting, tailoring and deploying the IBM DevOps best practices as well as appropriate software development tools on many types of projects, from large to small, long to fast-track, agile to traditional. Marianne is especially passionate about all things testing—process, tools, culture and automation. Her experience is broad-based, spanning both custom projects as well as standard software packages that apply to many industries, including refining, pharmaceutical, telecommunications, health care, financial, automotive, government and retail. Connect with Marianne on LinkedIn or Twitter.

  • DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

    DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

    In this DevOps Chat, we catch up with Chris Lazzaro and Peter Klenk of IBM Bluemix and Bluemix Garage. With IBM InterConnect just a month or so away, it is a good time to hear what those innovative Bluemix folks are up to. Peter and Chris give us their take on new IBM Bluemix services, as well as the continuing evolution of IBM Bluemix Garage and the Bluemix Garage method.

    I will be chairing a panel at InterConnect too by the way called: DevOps, It Takes a Village. If you are going to InterConnect come say hi!

    As usual below is the streaming audio player, followed by the transcript.

    Alan Shimel:                Hey, everyone, Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to have two people as our guests on this edition of DevOps Chat. I’m joined by two friends of mine from IBM, Chris Lazzaro and Peter Klenk.

    Peter, Chris, welcome to DevOps Chat.

    Peter Klenk:                Thanks a lot, Alan, glad to be here.

    Alan Shimel:                Okay. Peter, why don’t we start off by just giving our audience a little bit of background on your position and who you are at IBM?

    Peter Klenk:                Sure. I’ve been at IBM a while doing a lot of various type things, but as we try to become a cloud company I’ve become the product manager for pretty much everything DevOps in the cloud, so how we promote working, the kinds of tools we’re offering in the cloud and so on.

    Alan Shimel:                And, Chris, how about you?

    Chris Lazzaro:           I’m Chris Lazzaro. I’m the lead architect for the Bluemix Garage Method. The Garage Method is where we try to teach customers how to be successful in the cloud, adopting best practices for DevOps and really act like a startup.

    Alan Shimel:                With scale like in enterprise.

    Chris Lazzaro:           Yep, and meet those enterprise demands.

    Alan Shimel:                Absolutely. Gentlemen, obviously the cloud is not new. It was funny. I spoke to someone the other day and they were with another large provider such as IBM, and they were transferred internally. They said, “Well, yeah, they wanted me to go to IOT and stuff because that’s where all the growth is.” I said, “What about cloud?” He said, “Oh, cloud is old news already. That’s not as strategic anymore.”

    I must admit I was somewhat blown away because everything I’ve seen says while most or the overwhelming majority of organizations have some infrastructure in the cloud, it’s a relatively small amount of their total infrastructure and the greater migration is certainly ahead of us.

    Peter, you are DevOps in the cloud. What are you seeing? Is that true, not true?

    Peter Klenk:                The reality is I think most enterprises have been experimenting in the cloud, doing pilots, doing some innovation projects, but the bulk of the workload in the world is still running in a more traditional infrastructure. We still talk to a lot of mainframe clients. We talk to certainly a lot of on-prem datacenter clients.

    There are kind of two things going on. Getting to the cloud is part of it, but I think the bigger question they ask is: how do we get more efficient, more developer productivity, more team productivity, more essentially rapid innovation, reduce the time to feedback from our clients, so that the systems we’re building stay relevant and don’t get disrupted by all these kind of born on the cloud enterprises, which we see popping up in every industry, like in entertainment, you name it?

    Alan Shimel:                Yeah. Chris, when we talk about Bluemix Garage Method and stuff, there is a certain element of that, right, taking what these startups, these, as Peter said, born in the cloud sort of startups, some of what’s in their DNA and trying to – I forgot the word of the program we use to edit DNA now, not Zipper, but whatever – trying to –

    Chris Lazzaro:           CRISPR.

    Alan Shimel:                CRISPR, you’ve got it – trying to transplant some of that DNA into these enterprises. That’s what you guys spend a lot of your time on.

    Chris Lazzaro:           We are trying to bring that rate of innovation that’s possible in the born on the cloud kind of startups, and then teach everyone how to utilize the cloud in order to get those innovative ideas that are out there as quick as possible, and reduce those barriers from going from idea to production.

    But like you said, there are a lot of enterprises out there where the backend systems of record are mainframes or just data that simply won’t ever be able to move to the cloud, and that’s why hybrid cloud is so important. Some of these new technologies like IOT and cognitive, you can start experimenting with those and still connect them back to your on-premise infrastructure.

    Alan Shimel:                Yeah. You know what? Certainly IBM is going to be the last company that tells you, “You should move off your mainframe.” But you’re right. People aren’t going to move off their mainframe, but that doesn’t mean there are some things that remain on your enterprise mainframe system and some things that are better off in the cloud, and you do have this sort of hybrid, not one-size-fits-all, and you do what’s best for that individual need. Sometimes it is staying back in the datacenter. Sometimes it’s moving up to the cloud.

    Peter, I think you hit it on the head in saying it’s all about improving productivity. If it feels good and if it’s better for the company, then do it – to paraphrase a 1960s thing.

    Of course, gentlemen, this is a big part of the whole Bluemix – not Bluemix Garage Method, but the Bluemix platform in general in the cloud. Correct, Peter? And that is to make developers or make developing more productive and more efficient. Fair enough?

    Peter Klenk:                Yeah, fair enough. I think what Bluemix is has changed since we launched it a couple years ago. I think maybe this is just indicative of what’s happening in the cloud in general, but we started talking about very specific runtime environments and you’re going to run workload on the cloud.

    It certainly is that and Bluemix has infrastructure. It has cloud foundry. It has containers. It has a serverless programming model called OpenWhisk. There are plenty of ways to run your workload in the cloud.

    But it’s also this catalog of services you can use in your application. How is that related to developer productivity? Well, no one is going to build a NoSQL database or a natural language processor or a cognitive sentiment analysis or any of these types of frameworks on their own anymore. You’re going to use services, and that’s a big part of what the platform is, is this rich catalog of services.

    It gives you a leg up in building the application for your domain, leveraging new direction models, cognitive models, IOT-type sensors and feedback systems.

    Alan Shimel:                I think it’s even more than that, Peter. You mentioned NoSQL. No one wants to stand their NoSQL up themselves, their NoSQL infrastructure up themselves. And certainly what we’ve seen with Mongo recently around security issues, it’s nice to know that you have an IBM, right, and everything they bring in the way of security, standing behind your Mongo service that IBM has stood up for you.

    I think that’s a big part of it. Who can afford to really do it right?

    Peter Klenk:                I think that’s something we bring to the table. If you look at our catalog, we’ve got open source-based things. We have third-party things. We have IBM homegrown things, like the whole Watson set of cognitive services. But with them all comes – you know, it’s a foundation of scale and security and global distribution with points of presence around the world, but you need an IBM-scale kind of partner to deliver.

    Alan Shimel:                Yeah. Chris –

    Chris Lazzaro:           So it’s that –

    Alan Shimel:                I’m sorry; go ahead.

    Chris Lazzaro:           It’s that ability to get a small application or a minimum viable product up and running very, very quickly using a platform as a service or a cloud, but then being able to scale it as required and to add those DevOps tools, the management and monitoring tools or deploy it across multiple datacenters with multiple instances. So the complexity can grow as you start gaining customers and being successful with your app.

    Alan Shimel:                You anticipated my question. That was exactly it. Really, that is sort of – because when you look at how most startups operate, they don’t create to scale immediately. It’s not build it and they come. They build it small and as they come they kind of build it bigger.

    I come from that world I should add. I spent 25 years in that world. It just seems to me to be a no-brainer to say, “Geez, if I can partner with someone who can bring me that instant scalability, and not just the cloud infrastructure as a service, but the whole kind of scalability that a Bluemix brings to me, just from a DevOps perspective that just has to make things much easier.” But it’s much more appealing and it’s probably much more economical.

    Peter, agreed?

    Peter Klenk:                Yeah, agreed, and you got to the DevOps point, which is to me is part of that whole cloud picture. It’s the platforms, the services, but it’s also the way of working, which is what the Bluemix Garage Method is all about. Chris can elaborate on that, but it’s meant to be a set of practices that teams will adopt, potentially incrementally. It’s not everything will apply to everyone out of the gate, but it’s kind of the foundation of how effective DevOps teams work. Then we back that up with a set of tools that represent the kinds of tools that support those practices.

    Similarly, everyone needs a place to store to their code, and a way to build it and push it onto a runtime on a platform like Bluemix. But, let’s face it; most of the world has on-prem stuff. They might be dabbling in other clouds. So it’s really deployed multiple places often.

    And for that little startup mentality maybe that’s all you have, but as you grow you’re going to want to add different kinds of testing. You’re going to want to move the code through more environments, to expose it to different kinds of scenarios around performance and scale and security and vulnerabilities. You’re going to want to probably have more rigorous change management policies about what gets allowed into production with what level of review.

    So when we build out the DevOps offering, we’re providing point tools. We’re partnering with point tools. But we’re really focused on how they integrate together and how they can be simple for the teams that really are just starting out, the kind of – I won’t even say two pizza teams. I’ll say the one pizza teams – but then grow up with those teams and then with those whole organizations, where now they’re deploying multiple apps across multiple runtime environments, multiple clouds, and manage the rigor and complexity that comes along with that.

    Alan Shimel:                Agree. Guys, as often happens here, our time starts getting ahead of us or behind us, but I wanted to come back to there is some new news around continuous delivery on Bluemix. I don’t know. Peter, are you the better person to share with our audience or is that a Chris thing?

    Chris Lazzaro:           Well let me set the context first and then I’ll hand it off to Peter.

    Alan Shimel:                Great.

    Chris Lazzaro:           There’s two really key points. One is as we look at DevOps methods and help people define that, IBM’s definition really starts with idea. It’s everything from going from idea to production and then managing and scaling that up.

    So we start off with design thinking, and that’s really important to really get that into your DevOps process. From there it’s all about reducing the barriers of bringing that idea into production, and you want to get rid of all the barriers and friction points. You need not just a platform that can support you, but also a set of tools that enable continuous delivery, so that your developers are curating and getting that right out into production.

    That’s where the continuous delivery service really helps. Peter, do you want to talk about that?

    Peter Klenk:                Sure. We just announced at the end of last year a new service in the Bluemix catalog called Continuous Delivery. It focuses on a few things. One is the continuous integration, continuous delivery pipeline. But another is managing the set of tools and the integrations that a team is going to need to do the whole job around software delivery.

    One thing we find in the enterprise is that it’s easy for a couple of folks to go off and start downloading a bunch of different tools, and getting them to run somewhere and use them like in their little project because maybe they’re motivated to try new stuff, but to then scale the successful patterns across the enterprise is really hard. Not everyone is as motivated. Not everyone wants to do the research to figure out what’s going to work in their environment.

    So in addition to that continuous integration, continuous delivery pipeline, we have this first-class concept called Toolchains that can be captured in templates, so that you can easily provision new teams onto, say, a source repository on an agile plan or an issue tracker and CI/CD patterns that have the right kinds of jobs and environments in them, to give you a way to just quickly bring new teams into this modern world of tools and practices.

    Alan Shimel:                CI pipelines, sure. Peter, if someone is interested in kind of toying, messing, experimenting with Bluemix continuous delivery, do you have to be on Bluemix to do it? Does it have to be on public cloud? Where could they get more information on that?

    Peter Klenk:                They can start reading about it at Bluemix.net/devops. If you have a Bluemix account, you have everything you need to get started. If you don’t, that’s something you can easily create, no monetary commitment. The service right now is free. I imagine it will remain free for small teams that just want to start trying it out. So it is running in the public cloud.

    We do have something called Bluemix Dedicated, which is a single tenant instance of Bluemix for certain enterprises that want that, and the service is also available there.

    Alan Shimel:                So private cloud, is that not in style anymore, Peter?

    Peter Klenk:                I think that’s fair. I think there are different ways to –

    Peter Klenk:                Yeah. The key point here is it’s a single tenant instance, but it’s the full Bluemix stack. So our service is available that way as well. But for tire kickers, go to the public cloud, Bluemix.net/devops.

    If you’re not quite ready for that, Chris, Garage Method. How do you get started over there?

    Alan Shimel:                We’re going to come back to that in a second, before I lose my train of thought, because it doesn’t take me much. Peter, you mentioned the toolchain aspect of Bluemix and the continuous delivery in the stuff you’re putting together. If someone is experimenting or testing the Bluemix continuous delivery, can they add other tools to the toolchain, sort of maybe do a custom integration?

    Peter Klenk:                They can. The pipeline is highly customizable through scripting. There is a set of integrations, the third-party tools available, kind of no box because it’s on the cloud, but virtually out-of-the-box. And certainly then in the applications they’re building, they certainly have access to all the other services in Bluemix as well. So there is some cool stuff.

    Alan Shimel:                Got it. Chris, let me come back to you. We mentioned Watson earlier. I remember last year at InterConnect I was kind of blown away when I realized Watson was going to be on Bluemix. With APIs anyone can hook into Watson. I met some lady who in no time created a custom dating site where Watson was picking your dates for you. I mean I’m married, it didn’t me any good, but it was still an interesting concept.

    But, Chris, when we talk about this Bluemix continuous delivery, does it work with Watson and some of the other services? And is that something we can do with the Garage Method and so forth or no?

    Chris Lazzaro:           The continuous delivery pipeline can definitely work and deploy cognitive or Watson applications. We’ve got a number of examples of those on the Garage Method site. So if you just Google Bluemix Garage Method you’ll get there.

    What’s really neat is that with these toolings and this platform, you can deploy an application that’s making use of the giant Watson cognitive capabilities and then easily tie in your logic to that. So you just plug into Watson as if it was a regular service.

    Alan Shimel:                Excellent.

    Chris Lazzaro:           So we’ve got those courses out there that walk you through it. The other place to get started would be at InterConnect this year. We’ll be having a lot of workshops and training and sessions at the InterConnect conference.

    Alan Shimel:                Let’s talk a little bit about InterConnect. Of course it’s coming up. It’s moved back a little bit this year. I believe it’s in – is it late March now or April?

    Peter Klenk:                March.

    Alan Shimel:                Peter or Chris, you don’t have the exact dates, do you?

    Peter Klenk:                I will in a second. I want to say March 20 –

    Alan Shimel:                Yeah, like March 20 to –

    Alan Shimel:                I know the 22nd is a Wednesday and that was a big thing. I’m speaking there as a matter of fact. I just got all my speaker kit stuff today.

    Peter Klenk:                The 19th through the 23rd at Mandalay Bay in Las Vegas.

    Alan Shimel:                Yes. Guys, we might as well end things off then with an InterConnect question. What are you most looking forward to this year at InterConnect?

    Peter Klenk:                Feedback.

    Chris Lazzaro:           I always love the expo floor and being able to talk directly with the clients and get that feedback and just see the cool things that are being developed.

    The other session or workshop actually that I’m looking forward to is the one around the method, where attendees will actually – by the end of the workshop they’ll have applications up and running in Bluemix that cover all the phases. So they’ll have the tooling plugged in for managing the app and the continuous delivery tools as well.

    Alan Shimel:                Got it. Peter, what about me?

    Peter Klenk:                For me it’s feedback. Last year at InterConnect we were certainly talking about the method and different tooling approaches and we had some previews, but it’s different now that we have our service out there in the Bluemix catalog with real users doing real applications and solving real problems. So I just want to hear from them and also hear some more perspectives from clients and other companies in the business about the trends they’re seeing.

    We’re going to have a couple good panels with some of the other DevOps companies. So that and then clients talking about the kinds of apps they’re building on the cloud is always fascinating.

    Alan Shimel:                I always enjoy talking to clients as well at InterConnect. It’s great stuff. And I will just mention that if you really want to sit in on a great session, there is one called “DevOps: It Takes a Village.” I’ll be hosting that one. I want to say it’s Wednesday at 9:00 AM at Mandalay Bay, but I’ll put more on that at devopsy.kinsta.cloud in the near future. Just a little personal plug guys. I’m sorry.

    Peter Klenk:                Shameless.

    Alan Shimel:                Shameless on me. Anyway, guys, I look forward to seeing you both at InterConnect. We’re actually going to probably have some devopsy.kinsta.cloud surprises there in terms of our coverage. So maybe we’ll get a chance to sit down and chat.

    But for now, Chris Lazzaro, Peter Klenk, thanks so much for being our guests on this episode of DevOps Chats, and we’ll see you in two months or so out in Vegas hopefully.

    Chris Lazzaro:           Sounds good. We’ll see you there.

    Peter Klenk:                Always a pleasure.

    Alan Shimel:    Okay. Chris Lazzaro, IBM Bluemix Garage Method, and Peter Klenk, IBM Bluemix and Cloud Services for DevOps, thanks for appearing on DevOps Chats. This is Alan Shimel of devopsy.kinsta.cloud hoping to see you on another DevOps Chat.

    — Alan Shimel

  • A Six-Step Approach to Enterprise DevOps Transformation

    A Six-Step Approach to Enterprise DevOps Transformation

    Agility of businesses to transform and adjust to market conditions is perhaps the most important aspect of managing today’s enterprise. With digitization of almost all facets of running an enterprise, it is safe to say that IT agility translates to either the success or failure of such adaptation. Smaller and new-age businesses are better able to adapt, while large, established enterprises struggle or are too slow to adapt. Large enterprises have been executing in an established, traditional way for decades and have solidified their existing processes and decision-making.

    New-age businesses don’t have a choice. They have to be agile because of the force to create something new. They either have cloud-native technology support or, even with traditional IT are able to embrace agile, automation and continuous delivery paradigms to stay nimble.

    So, what constrains large enterprises? There are three main elements: organization structure, legacy technology stack and culture.

    The good news is that there are proven industry approaches to embracing agility in delivering business outcomes. The bad news is that it is quite often a long, arduous journey. This long transformation is often riddled with compromises from “comfort zones,” is potentially career-redefining for executives and practitioners and, of course, requires a fair bit of time and dollar investment.

    In my travels and working with many clients across multiple industries, I’ve found that executives do not like terms such as “transformation.” Somehow it is often interpreted as “cost cutting” or “resource realignment” or “outsourcing.” There is some merit in using terms that are appropriate to each enterprise. But, the intent is to transform the way solutions are being delivered today and to do it faster, cheaper and better. The techniques of Agile and DevOps have been successfully implemented in many large and small organizations to enable those outcomes.

    To address the three areas of organization, technology and culture, let me present an approach that works quite well for most enterprises. There is always an element of customization of the approach to meet specific needs, but it should provide a basic framework of the activities and potential time frames necessary to implement the transformation program.

    The Six-Step Approach

    Step One: Initial Planning for Enterprise Readiness

    Participants and Inputs, Existing Collateral, Design Thinking, High-Level Outputs

    As stated earlier, these steps are customized to each organization, including the participants and inputs, among other factors. For example, the CEO may not be the program sponsor for a given enterprise as it could either come from the CIO or it could be business line-driven. Other enterprises may choose to launch the program at director levels. If possible, this should not be done. The highest chance of success is when the program is championed at the highest levels.

    Participants should absolutely include all the towers that make up the solution delivery. Business participation is imperative, along with operations, security and development. I always recommend that the workshops conducted in this step be led by an external experienced consultant or a coach. The key here is to get executive buy-in and create common goals and understanding on what an Agile-DevOps program will look like.

    Typically, there are several small DevOps programs already in place in silos that lack maturity to scale to the enterprise level. Design Thinking is a great method to use since it leverages the expertise of all stakeholders, enables them to come to a common understanding, and establishes the needed buy-in. The diagram below illustrates an initial plan for project readiness incorporating the components discussed. 

    Step Two:  Establish a DevOps Center of Excellence

    Identify an Executive DevOps Lead with Enterprise Authority

    Establishing a Center of Excellence (CoE) is not good enough if it’s not at the right organizational level and enterprise authority. It has to be led by an enterprise leader who has the support and buy-in from all the towers. Active participants of the CoE include representatives from all the delivery towers and also vendor organizations. These participants must be chosen wisely.

    I highly recommend that initial phases of CoE be led by an external experienced partner and transitioned over time. The initial phases help cement the vision and strategies of the COE and setup the best practices to support it. Typically, the time to transition from the business partner to internal is 12 to 24 months.

    Step Three:  Establish Program Governance

    Create Communications Plan, Enablement Program, Establish Program KPIs

    This is the most important step to make an impact to the culture of the organization. With Agile and DevOps, practitioners’ roles and responsibilities will change. They’ll need awareness, enablement and empowerment to succeed. It is extremely important they understand collaboration between organizations that historically may have had animosity so they can break down these organizational walls. KPIs must shift from individual metrics to holistic customer business outcomes.

    Step Four:  Establish Project In-take Process

    DevOps Subject Matter Experts (SMEs) Conduct Intake Workshops for Scrum Teams

    Project intake really sets the tone for how successful each sprint that onboards the program will be. It is not so much about tools and process, but the right sizing of tools and process. There needs to be a fit for purpose in the selection of accelerators, tool chain and development methods. Once established, communication of the intake process needs to occur across the organization.  Gather feedback and continually evolve and mature. 

    Step Five:  Identify and Initiate Pilots

    Applications Representative of Target Portfolio to Scale

    This step has the best chance of success if applied to a specific portfolio of applications or a domain solution. I strongly recommend having some working sessions prior to this workshop to identify an area of development work that represents a portfolio to scale to the enterprise.

    The purpose of this step is to conduct a value stream-mapping exercise of a specific application with participants from all towers. This needs to be conducted with the level of detail necessary to identify end to end as-is process, tooling, manual and automated processes, and skills and people involved.

    The next part of the project intake is the collaboration of the subject matter experts (SMEs) from the CoE with the project team. The purpose is to advise on “to-be” process with necessary tooling, reusable assets, automation and SMEs needed from operations, security and other applicable areas. These SMEs will comprise the application scrum team. As the application goes through its development/test cycle, identified KPIs for the program are captured. This is absolutely necessary to compare with existing KPIs.

    Step Six:  Scale Out DevOps Program

    Onboard Parallel Release Trains; Apply Intake Process; Support, Monitor and Manage

    The final step is to take feedback from metrics of the pilots and scale them by running multiple release trains from different application portfolios. It’s not good enough to just do daily builds and automated deployments. The final piece of the DevOps puzzle is the continuous feedback and optimization.

    Summary

    The above is an approach that can be implemented in a flavor that best represents each organization’s needs and constraints. Be considerate of large gaps or excessive deviations that may be red flags to be corrected.

    Now that you are equipped with the six steps for an enterprise DevOps transformation, you can look at each of them critically, see best fit, and start the journey!

    I will be @ Interconnect this year for a session on Environment As A Service. Stop and say hello. Other articles to reference are:  “Five things to understand about Enterprise DevOps Solutions,” “DevOps in a Hybrid Model,” and What is platform as a service (PaaS)?”

    About The Author/Sunil Joshi

    Sunil is an IBM Senior Certified and Open group certified Distinguished Architect. He is currently the Application Innovation Cloud Services Emerging Technology leader. His specialization is in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA). Sunil is a regular speaker in the industry on Cloud, DevOps, Microservices, Digital Transformation and related topics. Connect with him on LinkedIn | Twitter

  • How I Bet on DevOps – and Won

    How I Bet on DevOps – and Won

    One evening in late 2015, after the kids were in bed, I sat down next to my wife and said, “I’d like to do something irresponsible. I want to gamble some of our savings on DevOps. I’d like to buy some stock.”

    Nicole Forsgren’s 2014 presentation, “DevOps and the Bottom Line,” opened my eyes to the business impact of DevOps. Then the 2015 State of DevOps Report rolled out with the following tucked into a footnote:

    The publicly traded companies that had high-performing IT teams had 50 percent higher market capitalization growth over three years than those with low-performing organizations.

    I believed the data. It matched my intuition and experience.

    DevOps and the Market

    Companies doing DevOps win in the market. In a world where digital transformation has made competition between companies increasingly dependent on their ability to differentiate through technology, the ones who do best in tech are likely to win. As I heard an executive at an airline put it, “Anyone can spend tens of millions on a new Boeing or Airbus jet. There’s no sustained differentiation there. But a great booking experience … a great mobile app … that can win loyalty.”

    So I found myself thinking that I sit in the middle of a DevOps community and know which companies are bragging about their DevOps successes. I truly believe it helps the business win.

    The Bet, and Winning It

    So that brings me back to that evening in December and the proposal I took to my wife.

    1. This was gambling. We’d risk only a fraction of our savings.
    2. We would buy and hold for one year, then re-evaluate.
    3. I would do no research on the companies we’d invest in outside of their DevOps practices. We would assume other public information would be priced in by professionals acting in an efficient enough market.
    4. Investments would be in companies “doing,” not “selling,” DevOps. No vendors.

    After getting the green-light, I bought a dozen stocks based mostly on the “who talks DevOps at conferences a lot” criteria: Amazon, Bank of America, Capital One, Cisco Systems, Etsy, Live Nation Entertainment, Macy’s, Netflix, Nordstrom, Sherwin-Williams, Target and Verizon Communications.

    So let’s talk about a few of these companies. Amazon and Cisco arguably violate the “no vendors” rule. Amazon I’ve excepted, as the company has a good reputation for DevOps internally, and many of the other retailers included are motivated to DevOps by fear of Amazon. They’re included as a hedge against Amazon killing all retail. In fact, Amazon was my only retailer to beat the S&P. Over the past three years, I found Cisco’s talks of its transformation at conferences (including IBM’s) compelling. Further, the hardware-to-network functions virtualization (NFV) transformation they’re going through seems similar enough to a retailer’s brick-and-mortar to e-comm to warrant inclusion.

    My employer, IBM, is not included because it is a vendor and as an employee its performance already has a big effect on my life. Etsy and Netflix are my “unicorn” contingent. Etsy crushed it for the year (+38 percent). Netflix underperformed (+6 percent) and was a major drag through the first half.

    Retail and e-commerce was generally a weak segment with Live Nation (Ticketmaster), Macy’s, Nordstrom, Sherwin Williams and Target all underperforming the S&P 500. Compared to a retail index fund (XRT), all but Nordstrom and Target came out ahead, though. It was a rough year for the segment, but those investing DevOps seemed to outperform their competition.

    All in all, the approach beat the S&P 500 by about half for the year, albeit with considerably more volatility.

    Good Sentiment, Sketchy Investment Strategy

    That said, a deeper look at this approach makes me think it was more luck than skill. While I believe that high-performing IT yields business wins, I didn’t actually know which companies have high-performing IT. The DORA team has the best data. I don’t. A big financial institution is likely to have more techies than Facebook. Do a handful of them presenting at conferences really say much about their thousands of colleagues? I have doubts.

    DevOps transformations, like Agile transformation, are hard to do at scale. It’s the scale that counts, and will generate the business differentiation. Some transformations led by brilliant champions will end up failing. Mid-year, I was at one of our DevOps networking events talking with someone from one of the companies in this list and suggested that they must be nailing DevOps given what I heard at conferences. The answer was, “Not really … we’re kind of starting over and the people championing DevOps have all left.” I’m not surprised that company is one of my underperformers.

    Sophisticated investors will point out approaches for managing exposure to segments and better isolate DevOps effects from overall market moves. Not researching and using those is another flaw in the approach.

    And yet, if picking stocks at random would yield average results, but DevOps helps company win, and people talking about DevOps likely represent companies with more DevOps than others, it’s not shocking to see this strategy happen to get lucky.

    What Will I Do Next?

    My focus will remain on ensuring the IBM UrbanCode business embraces DevOps practices, mindsets and approaches in every way and supporting IBM’s overall transformation. While transforming myself, I’ll remained focused on helping my clients with their own transformations.  Check out some DevOps success stories.

    As for investing, I’m not a gambler at heart and may simply close down this experiment while I’m ahead and pick a nice index fund. Or, I may refine the picks to only take those that are publicly talking about how they spreading these practices to thousands of practitioners.

    Disclaimer: I’m a techie, not a financial advisor. I recommend improving your own business with DevOps. I do not have a recommendation for how you should invest. Past performance is not indicative of future results. This experiment could have gone badly, and for a while in the first quarter, it looked as though it would. Please don’t take risks you can’t afford based on the experience of a rank amateur investor like myself. This experiment was mine and mine alone. I speak for myself, not my employer.

    About the Author/ Eric Minick

    Eric Minick is a technical evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last 10 years helping organizations large and small adopt continuous integration, delivery and, now, DevOps. He is a frequent speaker on the topic, and co-authored “Application Release and Deployment For Dummies.” Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.

    — Eric Minick

  • Forecasting Culture: Sunny with Accumulating Collaboration

    Forecasting Culture: Sunny with Accumulating Collaboration

    Bryson Koehler believes the most important enabling factor for DevOps success is culture.

    Koehler is CTO of IBM’s newly formed Watson and Cloud Platform group. Prior to this role, he served as executive vice president, distinguished engineer and CIO/CTO of The Weather Company (TWC), an IBM business since 2016. He has a record of successfully leading significant business transformations and underlying cultural transformations, which he maintains in tech companies must be incited first at the developer level. As such, while at TWC Koehler built a DevOps culture and practice that encourages transparency, accountability and collaboration, and it is his mission to replicate the successful model in the transformation of IBM’s culture.

    Since I experienced some of the TWC culture firsthand, I asked if he would be willing to share his thoughts on enabling a high-performing culture as well as maintaining that culture during periods of rapid growth or change.

    He started the interview with a theme clearly central to his core ideology as a transformational leader, and one of TWC’s key factors for success:

    Culturally, the goal is to find people who really love what they do. I want people to wake up in the morning and love what they do—not tolerate it, not like it, but love it. We work very hard to find people who love what we do and love the mission we are on. If you work very hard to assemble a team that loves what they do, the culture will take care of itself as long as you enable it … it’s about enabling them, with as much freedom and flexibility as possible, while still maintaining some level of consistency and control. It’s a balancing act and at TWC we worked very hard to give the right tools that enable people to work on any device, anywhere, at any time. The tools were an enabler; it was the culture that really invented itself based on the fact that we hired people who love what they do.

    Koehler’s commitment to finding the right people with the skills and passion consistent with his company’s mission put the base focus of enabling DevOps practices where it needs to be—with the people.

    For those that have read some of my other blogs, one of the things I’ve written about before is the mistake of choosing tools without first addressing the critical underlying aspects of DevOps including, a solid agile foundation and the cultural changes required to facilitate DevOps practices. Needless to say, Koehler’s comments about tools being an enabler really resonated with me because it was clear he still views the tooling as very important but puts the real emphasis on having the right people. The other key message that really resonated with me during the interview was his commitment to accountability and transparency:

    … from a leadership perspective, it’s around making sure there is clear accountability. There is single-person accountability for work. If you walk into a meeting and you don’t know who the single decision maker is in the meeting, my recommendation to the team is to leave. Don’t have the meeting, because it’s a waste of time. There should be one person that everyone knows is the decision maker, whatever the topic. If we don’t know that, then it’s my job to make sure I make that crystal clear. You can’t walk into a meeting with five people all thinking they own the decision when also working to create a culture with high velocity, high throughput and high passion towards meeting objectives and getting stuff done. You hire people who love what they do, you enable them with great tools, you have crystal-clear accountability and decision-making so that things can get decided quickly and that we know who is accountable for making sure that decision was successful, and then constantly work against the goals of the business. You also have to be very willing to adjust your tools, very willing to adjust your people, and very willing to adjust your decision-making. We must be constantly willing to look at ourselves and figure out how we improve.

    Koehler’s willingness to continuously look inward and adjust what is not working demonstrates another key success factor for high-performing DevOps teams. Having an executive driving that culture of continuous improvement is critical for DevOps success.

    He also is dedicated to core agile principles that allow for flexibility and responsiveness while maintaining some degree of focus and clear prioritization. With the rapid TWC growth, we also discussed how he maintained and adapted the existing culture in response to that growth:

    It’s really critical for me as a leader to stay very in tune with how these teams work and function, calling out any bad behavior and correcting it quickly. I’m just as willing to roll up my sleeves and get dirty as the next guy, and I expect everyone else to do the same. Kingdom building is not something that will get you very far in how we work. If you do that [roll up your sleeves], then as part of your culture, everyone puts down their guard and realizes that nobody is any more or less important than anyone else. We are all here to accomplish the same thing.

    Common goals and people that love what they do! It’s a great mix and Koehler has some fascinating perspectives on driving cultural transformation in support of DevOps practices, not only for the efforts he successfully led at TWC but for the efforts he will continue to lead within IBM. His commitment to culture can best be wrapped up by one of his final comments:

    None of our great technical ideas has any chance of seeing the light of day if we don’t get the culture right.

    Thank you again to @brysonkoehler for the interview and insight into TWC’s amazing culture and your vision for IBM!

    About the Author / Bryson Koehler and Shelbee Smith-Eigenbrode

    Bryson Koehler is CTO, IBM Watson & IBM Cloud – GM & Distinguished Engineer at IBM Connect with Bryson on LinkedIn and Twitter

     

    Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM and has been in IT for 19 years.  She has worked across varying roles spanning the software development lifecycle.  Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices.  She is a member of the IBM Academy of Technology as well as an IBM Master Inventor committed to driving innovation and technical advancement. Connect with me on Twitter @Shelbee_SE.

     

     

  • Webinar: Adopting DevOps @ Scale: Lessons learned at Hertz, Kaiser Permanente and lBM

    Webinar: Adopting DevOps @ Scale: Lessons learned at Hertz, Kaiser Permanente and lBM

    DevOps has become a major enabler of business innovation that can drive digital transformation at an enterprise level if done well. Challenges remain, however. Crossing the chasm from successful DevOps pilots with “two-pizza” teams to full enterprise adoption, including cultural transformation, best practices and tools remains a challenge.

    Join Alan Shimel as he hosts a panel discussion with Hertz’ John LaFreniere, Kaiser Permanente’s Raghunath Raman and IBM’s Sanjeev Sharma on how traditional enterprises are accelerating innovation by adopting DevOps practices at scale across their organizations.

    Find out how: Hertz is accelerating transformation of their platforms, business process and operating models with Cloud, DevOps and Agile.
    Kaiser Permanente is managing the cultural, process and integration challenges of multi-speed IT.
    IBM has embarked on a DevOps transformation that has engaged over 10,000 developers already — including becoming one of the world’s largest users of GitHub Enterprise.

    Watch to learn how to assess your organization’s readiness for scaling DevOps, and to identify next steps.

     

    RECORDING

    SLIDES

    [slideshare id=69695263&doc=adoptingdevopsatscalewebinarnov29final-161130194249]

     

    — Jules Louis

  • DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps

    DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps

    In this episode of DevOps Chats we are again joined by Randy Newell, Director World Wide Marketing for DevOps. Randy had a bunch of news he wanted to share with us including the call for speakers for IBM’s InterConnect 2017 which is open until November 11th. Randy also gave us a preview of the IBM sessions at the upcoming DevOps Enterprise Summit.

    Randy always has some good news and point of views to share. This interview is no different. Enjoy!

    As usual the streaming file is below with a printed transcript below:

    Alan Shimel:                Hey, everyone. Alan Shimel for another DevOps Chat. Happy to be joined on this episode by Randy Newell, Director Worldwide DevOps Marketing for IBM and a friend of mine. Randy, welcome to DevOps Chat.

    Randy Newell:             Thanks, Alan. Good to be here.

    Alan Shimel:                Absolutely. Randy, I invited you on because it’s getting near that time of year again where we’re ramping up for IBM Interconnect and I know you and your team have spent – have already invested weeks if not months of man hours and blood, sweat and tears in getting Interconnect ready to rock for this year. Why don’t you give our audience some highlights?

    Randy Newell:             Okay, sure. Yeah, I mean this is absolutely the most exciting time of the year for a number of reasons. I mean we’re getting ready for Interconnect, which we’ll talk about. We’ve got really key events in the DevOps space like the DevOps Enterprise Summit. Gartner puts on a big applications strategies event in December and so forth, so this is absolutely, you know, my favorite time of the year.

    I think the – kind of the cool thing that’s hot right now is we have just gone live with the call for speakers for IBM Interconnect 2017. That event is March 19th to the 23rd in Las Vegas. Last year we had, you know, over 20,000 attendees. Next year, this coming year, we’ll be even bigger. So it’ll be over 24,000 attendees.

    Alan Shimel:                Wow.

    Randy Newell:             Yeah. Where we ended up last year – and you were there, Alan. I mean the – it’s exciting, it’s a big conference. DevOps is a major piece of what happens at this bigger conference that has, you know, cloud and cognitive and mobile going on as well, but the DevOps piece itself I think was almost 250 sessions last year, labs, workshops, sessions, and I think one of the big things that we’re doing this year is actually bolstering the ops side of this thing. So we’ll have over 300 sessions and labs and workshops this year with a really good balance across the DevOps lifecycle, if you will, and we’re pretty excited about it.

    Alan Shimel:                Yeah. Sounds great, Randy. Randy, I – you know, you mentioned the call for speakers. If I’m – I happened to take a look. I believe the call for speakers is open through November 11th, correct?

    Randy Newell:             Yep. We’ve just opened it up in the last week so now through November 11th, you know, we’d encourage everybody to get their proposals in. I mean if it’s not something that you want to speak at we would obviously encourage you to attend the event anyway but would encourage, you know, a lot of the subject matter experts and thought leaders that pay attention to devopsy.kinsta.cloud to submit papers to this. It is – you know, if people have not attended before or watched online, you know, just thinking about some of the highlights from last year, and you interviewed [laughs] so many of these people –

    Alan Shimel:                Yeah.

    Randy Newell:             – you know, Lloyds with Mark Howell and John LaFreniere at Hertz, Topo Pal who is a Cap One fellow from Capital One, Nationwide with Carmen DeArdo and just some really super innovative smaller companies like Security First Insurance, Ben Bomhoff, who I know you interviewed

    Alan Shimel:                Yeah.

    Randy Newell:             – and, you know, it just keeps going. Presentations from a lot of our cool business partners like Datical and Blue Agility and PointSource, so it’s really high quality presentation content from organizations big and small who have figured out DevOps and are scaling it and getting, you know, real success out of it, and then I think we’re also drilling down from an IBM perspective to provide labs and workshops and so forth to really get deep into some of the sever system tools that we’re providing.

    Alan Shimel:                You got some good hands-on stuff. Randy, for those who might be listening and saying, “Geez, I’d – you know, I’d like to throw my hat in, I’d like to speak,” what are you looking for in not only speakers, obviously, but in subject matter?

    Randy Newell:             Well, I think it’s actually an interesting topic for this year because I think we’re really expanding what we want to see. I think kind of standard fare, but we want to continue to push on these areas because we’re pushing the envelope on what we’re seeing clients able to achieve, you know, areas of continuous delivery, application release automation, software test automation including things like API testing and virtualization, but I would underscore and expand some of the areas on the ops side, especially where we’re looking for application performance management, IT ops management, IT ops analytics, and then I think especially kind of where we’re come over the last year with the introduction of the garage method as well as what we’ll be doing between now and Interconnect around tool chains. I think those are areas that are particularly exciting for us to see new presentation proposals on, so we’d really encourage some of those topics.

    Alan Shimel:             Yep. And I’ll just mention – ’cause, Randy, as I mentioned to you offline, I myself am submitting a speaking proposal. What’s nice is you can submit basically a one-man speaking proposal, you could submit a panel or anything in between there, so there’s lots of options and also if you go and register or to submit you will see – I think you guys did a great job of kind of guiding people what area you’re proposed session deals with so that it can be categorized and put in there and, you know, kind of so you could pick the best of the best, right, within an existing –

    Alan Shimel:                Yeah, there’s a –

    Randy Newell:             – subject matter.

    Randy Newell:                – lot of prompting, you’ve got a lot of prompting. So if people are going about doing this go to – you know, I mean the easiest way is just to search on IBM Interconnect 2017 call for speakers, and when you get into the tool just take a look. There’s two main topic areas where we’ll find the DevOps stuff. It’s listed directly under hybrid and DevOps and then also under Bluemix and Softlayer there’s DevOps as well. There’s an awful lot of prompts under the hybrid category for some of the topics that I just reeled off in addition to a whole bunch of others and don’t stop there. I mean people should have some fun with this; what they’re challenged with, where they’re seeing successes. I mean we want to push the envelope a bit on the type of topics that we’re seeing.

    Alan Shimel:                Sure. And Randy, just as an aside, it’s not all DevOps all the time – well, actually it is all DevOps all the time for me anyway, but IBM Interconnect also – like last year, for instance – cognitive and Watson and some of the really good kind of gee whiz kind of stuff that IBM’s working on is also on full display at Interconnect.

    Randy Newell:             Absolutely. Yeah, there’s a whole – as you’re aware, we did the whole _____ arena which is a lot of hands-on to be able to play with brand new capabilities, Watson APIs, [laughs] a foosball table that’s hooked up live to a Bluemix application. I mean there’s just – there’s so much kind of exciting stuff to do and it is – you know, while I think we lead with Interconnect as our key presentation of our cloud capabilities, we’re so integrated, you know, within IBM that you will see how that plays out in collaboration with Watson capabilities. We’ll see representation of our systems group and, you know, representation of Z mainframe technology. We’ll see mobile capabilities.

    It really is a great display. And I think it’s actually – in the industry, it’s probably pretty unique in the fact that – I mean historically Interconnect represents many different conferences coming together that IBM offered, and so you have a slice of the IT organization and now kind of increasingly bringing in line of business representatives and so forth so you’ve got – for me anyway, looking at it from a DevOps perspective, you’ve got dev, you’ve got ops, you’ve got your business owners, you’ve got everyone attending, you’ve got practitioners that are attending, you’ve got architects. It’s really a neat opportunity and I think when organizations are evaluating their attendance at Interconnect, you know, it’s really – the interesting part of it is we can bring a large organization and there is deep content for all parts as you drill down and get technical and there are also very interesting subjects for the organization as a whole, so it’s a very broad and deep context from an IT perspective.

    Alan Shimel:                Excellent. And Randy, for those who maybe don’t want to – you know, are not planning on speaking or presenting but would like to still attend, of course it’s open to anyone, right?

    Randy Newell:             Absolutely.

    Alan Shimel:                You can buy tickets. I mean, again, I would just probably Google search IBM Interconnect 2017. And Randy, the dates – I know you moved it later in March this year. Just again for our audience.

    Randy Newell:             Yep. It’s March 19th to the 23rd in Las Vegas –

    Alan Shimel:                Perfect.

    Randy Newell:             – at the MGM Grand and Mandalay Bay.

    Alan Shimel:                And Mandalay Bay, yep. That’s a big show. But Randy, that’s not the only conference IBM DevOps is kind of really exerting a strong presence. We have the Gene Kim’s DevOps Enterprise Summit coming up around Election Day, November – I think it’s 5th, 6th, 7th, perhaps in San Francisco.

    Randy Newell:             We will be out there on Election Day, yes. So all attendees make sure you do your absentee vote before you go unless you’re in the Bay Area. [Laughs] 

    Alan Shimel:                Yeah. Exactly. But you guys have kind of an all-star lineup and a bunch of different activities lined up for that week. Why don’t you just give us a quick preview, if you don’t mind.

    Randy Newell:             Sure. So DevOps Enterprise Summit, you know, this is Gene Kim’s lead event and it’s November 7th to 9th in San Francisco. IBM’s a platinum sponsor, there’s a lot of great sponsors. It’s an exciting event and so we’re really looking forward to it. I think it’s – you know, the content especially is very well curated and I think a lot of the success stories that are brought forward are really in tune with kind of the frontend of what’s happening with DevOps where organizations are achieving scale and real results, so I think in that case it’s particularly exciting among the many DevOps events that are out there. We’ve put together I think a really interesting set of presentations, and I’ll click through them real quickly here. I think one that’s particularly exciting is we call it adopting DevOps at scale, lessons learned at NBCUniversal, Kaiser and GitHub and IBM. So Sanjeev Sharma, who you’ve interviewed a number of times –

    Alan Shimel:                Sure.

    Randy Newell:             – he’s an IBM distinguished engineer and the author of DevOps for Dummies is going to kind of host that panel, and on that panel we’ve got John Comas from NBCUniversal, Raghu Raman from Kaiser,  and we’ll also represent some of what we’ve been doing inside at IBM where we’re about – you know, we’re kind of well into our DevOps transformation. We’ve got about 40,000 developers that are in the process of transforming to a DevOps approach and we’re through about 10,000 of those and a lot of that learning we’ll be bringing forward as part of this presentation. So the idea is, you know, how do we use that time that we’ve got in that particular session to really show off three or four very significant organizations that have been able to achieve some scale? And I think what Gene has represented as kind of the horses, but you know, the more typical, big, complex enterprise organization and how they can succeed at both, you know, the two-pizza team and scale it all the way up to, you know, kind of enterprise adoption.

    Alan Shimel:                Sure. You know what, Randy, I wanted to just mention – you mentioned Raghunath Raman from Kaiser Permanente and actually he and another fellow who I interviewed at Interconnect last year, John LaFreniere – I probably butchered John’s name, I apologize, I’m better with Indian names than French names but… [Laughs]

    Randy Newell:             Well, just say John’s name with a French accent and you’ll get by.

    Alan Shimel:                John from Hertz, doing an amazing transformation there. I have both Raghunath and John on a webinar. I think it’s on November 29th, so this’ll be after DevOps Enterprise Summit, but we’re gonna talk about, you know, transformations and checking in – both of these gentlemen, Raghunath and John have really done some pretty cool stuff with, as you say – you know, or as Gene says horses, right? Not unicorns but large organizations and especially the Hertz one, Randy.

    It’s kind of just an out with the old and in with the new kind of transformation and a little unusual where Raghunath I think has gone more of a traditional transformation, but he’s also pushed the needle a heck of a lot there. So for those – the audience out there, November 29th is that webinar on devopsy.kinsta.cloud. You can register online. Highly, highly recommend that one. Randy, I think there’s some news around Bluemix garage method around for Gene’s event as well or no?

    Randy Newell:             Yeah, definitely. And so let me – and let me tell you that there’s a couple of sessions, additional sessions at DevOps Enterprise Summit where we’ll be showing some of that off. So one is adapting the squad model with Ann Marie Fred, at – and she’s an IBMer – and she’ll talk about some of the transformation that we’ve done internally at IBM. So that’s an exciting one. And then, of course, you know Rosalind Radcliffe.

    She’s co presenting with Rich Jackson from Walmart and that is a mainframe DevOps team savings of the day at Walmart. So there’s a number of really interesting presentations. We’re also running a series of lightening talks, demos, in our booth area and we’ll publish a schedule. So for people who are attending that particular conference, you know, look for a theater presentation for what we’ll be doing in the booth, we’ll be driving down into some key offerings like method and tool chain into urban code into test automation, Bluemix, et cetera. So that can be a lot of fun, and then of course, encourage people to attend the overall conference and we’ll be highlighting these other presentations that we just talked about.

    But you asked about, you know, kind of methods and tool chains and I – you know, for those of your listeners and readers who may have missed it, last year at Gene’s conference we introduced the Bluemix garage method – we refer to it just generally as a method – and as I indicated earlier, we’re kind of, you know, a CIO-level endorsed movement, transformation to DevOps inside of IBM. We’ve got, you know, over 40,000 developers. We’re about 10,000 developers into this material transformation which impacts process and tooling and underlying infrastructure technology and methods that we’re using, and we’ve harvested a lot of the learnings from this significant transformation as well as what we do through global services, client interactions and codified that into a methodology, and so, you know, people can go to http://www.ibm.com/devops/method or just Google Bluemix garage method. And what you’ll find is we’ve populated this with elements of the methodology.

    What’s evolved since we announced this thing is we’re now rolling in reference architectures, a concept of tracks, you know, syncing with online courseware, the idea being, you know, as we’ve dealt with both transforming ourselves and as we see our clients adopting DevOps some of the challenges are how do we take the success of that two-pizza team where you have focused on business outcomes and technical outcomes and then scale that. And some of the challenges are cultural, some of them are process-related, some of them are tools-related, and so that’s a lot of what’s gone into the methodology, and so these tracks are somewhat – are basically use case-oriented. I am building, you know, some bimodal or multispeed application, I’m building a cloud native application, I’m building a mobile app, those sorts of things, and it surrounds you with elements of the methodology, of reference architectures, and now we’re moving towards this introduction of tool chain.

    And the tool chain concept is really cool and people will find it especially cool coming from IBM, is because based on that use case that you select, the specific tool chain, you will be prompted with a set of services that sit on Bluemix, which is our cloud platform, and it’s a mix of both IBM services as well as third party services that represent the key elements and key services that you need in your tool chain for the particular use case. So if you’re, you know, selecting a – you know, let’s say a simple cloud native application it would prompt you on, you know, GitHub and a WebIDE and our delivery pipeline service from IBM and you literally click a button that says, you know, build this tool chain for me and it instantiates that, provisions it and integrates those tools and presents it to you as your dashboard on Bluemix and all of that takes, you know, a couple of minutes. So the idea is that through method reference architecture tool chain you have the ability to spin it very rapidly and then some guidance and architectures for actually how to move forward and how to scale, and so that’s kind of it. And I know you’ve spent some time with Rachel and so forth who’s, you know, directly involved with the garage method and kind of expanding this thing in conjunction with how we’re using it in the Bluemix garages and really seeing some pretty exciting response to it.

    I think some of the customer’s names that we’ve mentioned earlier as well as others, you know, have seen some of this stuff firsthand and benefited from it, so we’re looking forward to gaining some commentary on that. It’s part of the reason that we’ve brought the GitHub team into the presentation that we’re doing at DevOps Enterprise Summit, because I think they’ve seen firsthand how the IBM transformation has actually utilized GitHub Enterprise, which is taking all the benefit of GitHub and using that within the Enterprise firewall through GitHub Enterprise and we have that instantiated as a, you know, full Bluemix service. So it’s pretty exciting execution.

    Alan Shimel:                Cool. Randy, we have gone significantly over our allotted time here. I apologize. I didn’t want to interrupt you and I think our audience finds it – will find it useful and informative, but I – for those of you who are still listening at the end of our interview, I thank you very much for staying with us and I think it was worth your time and I certainly hope so. Well, Randy, we’re gonna have to call it a wrap on this version of DevOps Chats. Perhaps we’ll have you back on if we have time before Enterprise –DevOps Enterprise Summit, but if not I’m sure we’ll have you back on before IBM Interconnect in March, maybe once we have some more information on speaker selected and stuff we can review some highlights.

    Randy Newell:             Yep. Fantastic. Appreciate the time, Alan. This was great.

    Alan Shimel:                Not a problem. Randy Newell, Worldwide Marketing – Director Worldwide Marketing for DevOps IBM. Thanks for being this segment’s guest on DevOps Chat and continued success and good luck. We’ll see you San Francisco I guess next for Gene Kim’s DevOps Enterprise Summit. Until then, this is Alan Shimel of devopsy.kinsta.cloud. Thanks for listening and we’ll see you on another DevOps chat.

    — Alan Shimel