devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

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

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

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

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

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

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

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

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

Shimel: Mm-hmm.

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

Shimel: Yeah.

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

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

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

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

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

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

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

Shimel: Oh, it’s okay.

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

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

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

Shimel: Yeah.

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

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

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

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

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

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

Plantenberg: Yes, it is.

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

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

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

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

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

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

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

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

— Alan Shimel

June 22, 2017
DevOps Chat: Waterfall Will Not Disappear, with Flint Brenton, CEO Collabnet

One of the perks of being editor in chief of devopsy.kinsta.cloud is I get a chance to meet with so many leaders of the DevOps and IT industry. You can really learn a lot by listening to what these folks say. This DevOps Chat is a perfect example. I sat down with Flint Brenton, CEO of Collabnet. Collabnet is not some johnny-come-lately. The company has been helping developers and IT professionals for a long time. Flint talks about the fact that while DevOps is a great path for many organizations, it may not be the right way for every situation. Waterfall is not going away entirely.

Have a listen to my discussion with Flint and hear for yourself what he has to say on the subject. As usual, the streaming audio player is immediately below with the transcript below that. Enjoy!

Streaming Audio

Transcript of Audio

Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Happy to be joined in this DevOps Chat by Flint Brenton, CEO of CollabNet. Flint, welcome.

Flint Brenton: Hey, Alan. It’s great to see you again.

Shimel: Great to see and hear you again. Flint, the last time I think you and I talked was back at the DevOps Enterprise Summit in San Francisco. I guess that had to be October or November.

Brenton: November. Actually, it was the same week that our new president was elected, if you remember.

Shimel: Yes. Yeah, a red letter day.

Brenton: Right.

Shimel: So, Flint, without getting any further into that, let’s turn the conversation to CollabNet. What—well, first of all, maybe some of our audience is not familiar with CollabNet in general, so why don’t we start with that? Can you give us a little CollabNet background?

Brenton: Yes, absolutely. So CollabNet is a SAS-based, cloud-enabled development platform focused exclusively on enterprise that delivers application lifecycle management capability for both Agile and waterfall development processes.

Shimel: Mm-hmm.

Brenton: The version technology to structure those builds and to maintain high quality and high quality control throughout the process. And then we also provide the DevOps infrastructure to build and deploy automatically whatever gets created in Azure or waterfall, with high quality, on time, and, to the extent we can help, under budget. So that’s really our focus.

Shimel: Sure. And you know what, Flint? I remember this about CollabNet. You guys have been in business now for a number of years, certainly before DevOps was what it is today, let’s call it, whatever it is today. How long have you been—

Brenton: Yeah, we’ve been in business—this is our 18th year.

Shimel: Absolutely. So, you know, DevOps is another technology innovation, if you will, that’s come down the road, but I think what—not unique, but what is one of the special qualities of CollabNet is is that you’re not out here saying that the whole world needs to go DevOps today, right, that everything—we should be all DevOps all the time. But you have customers who are still on waterfall and may very well remain on waterfall for the foreseeable future.

Brenton: Right. And we really invest very heavily in both waterfall and Agile development platforms and—although the growth rate for Agile’s higher than waterfall in enterprise, we still see roughly 70 [percent] to 75 percent of enterprises using a waterfall methodology. But the fastest growing segment in that area is clearly Agile.

Shimel: Sure. And I—obviously. But I think what’s important for our audience to recognize is even the biggest DevOps and Agile advocates or biggest—whatever you wanna call ’em, should recognize that there are still projects and places where waterfall might be the best way to skin the cat, to complete a project correctly. And it doesn’t have to be an all-or-nothing type of environment, if you will.

Brenton: That’s exactly right. You know, the industries that tend to be highly regulated, with a high need for security, compliance, and scalability, tend to lean more towards waterfall development. And, of course, once you started a process where you’ve got an established team that’s been using waterfall for a long period of time, they tend to prefer to continue with that. But it’s new projects, new projects where maybe time to market outweighs the need for compliance and security and scale—those tend to go Agile in an enterprise. But, either way, regardless of development methodology, the things you need beyond the tool chain or the process of building software is fairly similar, right? The way you use version control is fairly similar. The way you use DevOps technologies is also very similar.

And what we found is customers who are well grounded in Agile and waterfall—typically, in enterprise, they have both—getting your act together in DevOps and making sure you have a strategy, you created a culture to embrace and execute that strategy, then having the processes and tools in place to bring it to reality is critical because you don’t really get the return on investment for anything you develop, regardless of the methodology, until you put the build into production. And that’s what DevOps, at the end of the day, is all about.

Shimel: Sure is. Excellent. Excellent point, Flint. Flint, let me turn things a little bit ’cause, as I mentioned to you off camera, off mic, 15 minutes here goes pretty quick. Want to talk about some recent news around CollabNet in the industry. I understand you guys were just included in a Gartner Magic Quadrant, correct?

Brenton: Yes. Yes, thank you for bringing that up. Yeah, we’re very excited about it. It’s always a reflection of the investment our team has made in Agile planning and execution. So we’ve always been considered a leader when it comes to waterfall development, but, as we just mentioned, for enterprise, our enterprise customers are really demanding that we provide both, both equal value in waterfall and Agile. So we invested heavily in the last few years in Agile, and, as a result, we were just included in their Magic Quadrant as a visionary for Agile planning and execution, and we’re very excited about it.

Shimel: That’s nice. That is great. And I know everyone always wants to be in the upper right, but, really, having my background, being entrepreneurial and having started businesses, I’d almost rather be in that visionary quadrant than the upper-right leader quadrant and certainly in the visionary quadrant over, let’s say, the challenger quadrant, which is the upper left, because I think, with visionary, I mean, the recognition is that you’re setting a—you’re pushing the envelope, right? You’re pushing the vision—hence, “visionary.”

Brenton: Right.

Shimel: So congratulations to you guys. I know, in speaking with your team, you have rights for download of the quadrant, so what we’ll try to do is put into the show notes here a link to that where people can download the quadrant report and see if—check it out for themselves.

Brenton: Yeah, that’d be perfect and I’m sure that your listeners would very much appreciate that.

Shimel: Sure will. So, Flint, beyond the quadrant inclusion, though, what else do you see that’s happening with CollabNet or in the market in general?

Brenton: We’re starting now to get a number of customer wins that are embracing our motto of providing a cloud-based service where you can consume our integrated ALM, version control, and DevOps solution either in Amazon or on our own private cloud and, in many cases, a combination of on-prem and off-prem.

Shimel: Right.

Brenton: So we now have a number of customers who have completely moved their development process into one of our cloud-enabled environments, and it’s very exciting.

Shimel: That is exciting.

Brenton: It’s very exciting. And the great (thing) about that is, if it’s in the cloud, it’s actually easier for us to include, Alan, both open-source and compare it to components that we don’t own or control because then the need to test to get everything in your data center is lessened and our ability to innovate to your advantage is much greater, so we’re very excited about that.

Shimel: Absolutely. So, Flint, interestingly enough, I was reading an article this morning—I forgot where I saw it but it was a recent survey where 65 percent of enterprises still keeping the majority of their infrastructure on their own data center, not on a public cloud, not a hybrid situation. Is that about what you guys are seeing but is the arrow pointing up to the cloud? What’s your take on that?

Brenton: Now that’s a great question, Alan, and it’s absolutely what we’re seeing. So a thing to keep in mind, though, is “What is the variable that’s changing and what is the velocity of that change?” Right? So I would say, two years ago, that 65 percent number was probably 90-plus, right? So, as enterprises get more and more comfortable with the security and compliance options in the cloud, whether it’s in a public cloud or private cloud, they can see the tremendous advantages of driving down the cost of development and actually increasing the speed of innovation by going to the cloud.

I’ll give you an example. U.S. government, we do a tremendous amount in federal, and so both the Obama administration and now it’s transitioned to the Trump administration has really been pushing the department of defense to do a couple things. One, innovate faster, and so, if you just think about the U.S. government is barraged by cyberattacks from all over the world. Right?

Shimel: Mm-hmm.

Brenton: And so your ability as a professional, in NSA or CIA or the FBI, to deal with that is you want a complete toolkit of things you can use, and you want to choose the tools you need to deal with those cyberattacks, but you also need to do it quickly. So if you can use open source, it helps. If you can deploy it in a cloud, it dramatically increase—or decreases the time to deployment. And, three, it also tremendously helps you on the economics side. So even something as highly regulated and structured as the US federal government, there are advantages sometimes in doing things in a public cloud to help, and so we’re starting to see variations of that theme also in industry, primarily around enterprise, where there’s flexibility, increased ability to innovate, and improved economics by moving workflow to the cloud.

Shimel: Yep. You know, Flint, living in the tech world and you lived the world—you live that life; I live that life—I think sometimes we get jaded in that we’re in this bubble of, “What’s the hot new thing?” and it’s DevOps and it’s whatever’s next after DevOps, and then sometimes you get a reminder—65 percent still not in the cloud. And you say, “But I thought everyone’s in the cloud.” And I think it does good for us to remember that there’s a big world out there that moves at their own pace and their own—

Brenton: Right.

Shimel: Same thing with waterfall. Right? I think people would be—people in our audience from devopsy.kinsta.cloud would probably be surprised to find out how many organizations still either haven’t adopted DevOps or are primarily waterfall shops.

Brenton: You know, the key, when you’re a solution provider like CollabNet, is you need to meet people where they are. Right? So, if they wanna be on-prem, you need to be able to deliver them superior value on-prem. If they want to move part of their workload to the cloud, you need to be able to help lead them and sponsor that transition at that pace by which they’re comfortable. Right? So I learned a long time ago the key to success in this business is to give people what they want, right? He who can do that best with a quality solution at a great price is gonna win. Right? So that’s just the way it works, right?

Shimel: Absolutely—and that hasn’t changed, by the way, through all of these innovations, and I think it was true 100 years ago and it’s true today. Or maybe even more than 100.

Brenton: You bet.

Shimel: Anyway, Flint, listen, I think we’re about out of time here. I wanna be respectful of your time, so what we will do is let’s have you on again soon when we have some more time and we can delve into this. Are you gonna be at DevOps Enterprise Summit maybe in London?

Brenton: You bet. Yeah.

Shimel: Or San Francisco?

Brenton: Well, I always enjoy speaking with you, Alan. You’re a great guy and you’re—

Shimel: Thanks.

Brenton: —you’re a fun guy off camera too, I will add.

Shimel: [Laughs]

Brenton: So I look forward to our next adventure together. Thank you for the—

Shimel: Absolutely. Hey, Flint—

Brenton: All right.

Shimel: Flint Brenton, CEO of CollabNet, this week’s guest on DevOps Chat, thanks for joining us. This is Alan—

Brenton: My pleasure, Alan. Thank you.

Shimel: Thank you.

Brenton: All right. Buh-bye.

Shimel: This is Alan Shimel for DevOps Chat.

— Alan Shimel

May 31, 2017
DevOps Chat: Value Stream Mapping with CollabNet’s Eric Robertson

This DevOps Chat features Eric Robertson, VP of product and engineering at CollabNet. We discuss value stream mapping, which comes from Lean methodology and has been around for a while. But do you actually know what value stream mapping is? How can it help your DevOps transformation? Eric does a good job of explaining.

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

Streaming Audio

Transcript of our Chat

Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat and our guest on this chat is Eric Robertson, VP of product management and engineering at CollabNet. Eric, welcome to DevOps Chat.

Eric Robertson: Thank you. Thank you, Alan. Glad to be here.

Shimel: Yeah. We’re glad to have you here, Eric. I don’t think we’ve had anyone from CollabNet, actually, on DevOps Chat before, though I think we’ve done some video interviews over at DevOps Enterprise Summit—maybe it was San Francisco in October and November—but we’re—so we’re glad to have you here. We’re eager to find out about what’s going on with CollabNet and about some of the stuff you’ve been doing. Eric, if you don’t mind, though, there might be some people out in our audience who are not familiar with CollabNet, so, if you can, just—doesn’t have to be long, but maybe a quick elevator pitch on who CollabNet is, what you guys do.

Robertson: Sure. Sure. So CollabNet’s been around since, I think, 1999, and it was one of the foundational on the open source, with our Subversion version control software. We since then moved into the ALM, application lifecycle management, platform. It’s our product offering called “TeamForge,” where we started linking in that planning, development, and testing life cycle, with integration to tools. And now, with me, we actually extended that life cycle all the way down into the operations—thus, the concept DevOps. And now we are launching—have launched, actually, a series of products and partnerships around DevOps for our customers.

Shimel: Fantastic. Fantastic. So, Eric, one of the things that, when we spoke off mic earlier, we spoke about value stream mapping, and I know that’s something kinda, if not near and dear to your heart, something that you’ve been involved in with CollabNet. Why don’t you give our audience—let’s start off with this. There may be people out here who, just as they didn’t know CollabNet, maybe they’re not familiar with the term “value stream mapping.”

Robertson: Yeah. It’s very interesting. Value stream mapping is actually an older concept. It’s part of the Lean management framework. For example, many may have heard about Toyota. It was started there, as far as best practices around mapping material and information flow and how could we apply to, for example, the value chain, and pretty predominant in the manufacturing domain. And it’s kinda of interesting because I have a background in software engineering and I have degrees in computer science and engineering, but my first job was actually in architecture—not in software architecture, but actually designing building. CAD design.

And it was interesting that, during that time, they started talking about design patterns and best practices, as far as architecting and putting together systems and designing. And I said, “Wow, this is very similar concept to what I learned back in college, when I was doing software engineering, software design.” And, very soon, that started translating into object-oriented and design patterns and things of that nature. So it’s interesting how patterns and techniques that were very popular and used in other domains, like manufacturing and architecture, now being applied to software. In other words, software is maturing, right? The software development process is maturing. It’s starting to utilize these type of practices.

And the value stream map is just an example of that, right? It’s Lean management method for really analyzing that current state and designing a future state, based upon a series of events that take a product, a service, from its beginning through to its customer. Right? And, again, like I mentioned, Toyota—this is known as that material and information flow mapping, and it can be applied to any value chain, for example, right? And what is a value chain? It’s just a set of activities that take, for example—that delivers a valuable product or service to the market, right? So you got, in the manufacturing world, this was machines that did it; in the software world, it’s now tools that we use to deliver a product from a planning all the way to its operations stage.

Shimel: Yep. Got it. So, Eric, this is something, obviously, that you have written and you’re talking a lot about it. Can you tell our audience, if they want—maybe if they wanted to find out a little more, where can they go? Before we dive in more than that, maybe where can they get more information on this?

Robertson: Yes. Actually, they could come out to our website, collab.net, but, also, I recently published an article around how value stream mapping delivers a better DevOps tool chain, and we can post those links—I believe it was also on devopsy.kinsta.cloud and we have one that was delivered through TEDxBeacon, so there’s a series of outlets, and we’ll post those links there on where they can get more information about this.

Shimel: Excellent. You know what? We’ll, for sure, do that. And then, Eric, you had also mentioned that you guys were doing some sort of roadshow or a little city tour, where you’ll be talking about this, as well as other areas of interest around DevOps and what CollabNet’s doing. What’s going on with that?

Robertson: Yeah, so we’re actually having a series—we’re also doing it through webinars, but we’re also doing it through seminars, and we’re gonna be having these seminars throughout the different series. And, basically, what we’re doing there, what’s really critical there, is that we’re going to be not only talking about the value stream as far as more of the how this applies into the DevOps—in DevOps world, but also we’ll have customers there talking about how they are leveraging value stream mapping and how they’re mapping that to their tool chains and how they’re able to, from bare, start applying measurement, which, to them, is what they’re calling “the last mile” of DevOps, right? And it’s really—they’re gonna talk about how that provides a window to allow them to monitor, measure, improve their workflow processes, all around a series of KPIs, both velocity KPIs and also quality KPIs.

Shimel: Mm-hmm. Excellent. So, again, I think, Eric, what we wanna do is post a—maybe if you have a schedule of cities that we can post with the notes from today’s show.

Robertson: Yes.

Shimel: I think that’s the way to do that. So—

Robertson: Yeah.

Shimel: —let’s return, though, for a moment, to value stream mapping and kinda dig in here a bit. One of the things—and, again, as we spoke about off mic, I’ve had some experience with value stream mapping—one of the things, though, in speaking to potential customers of value stream mapping, is it’s easy to say, “Oh, yeah, that sounds good.” Right? “Oh, that’s something we wanna do.” Okay, well, let’s schedule some time and I’m gonna need the right people at the table because, if you don’t have the right people there, it’s very hard, number one, to truly map out the value stream and, number two—

Robertson: Exactly.

Shimel: Right? And harder than that is let’s get some consensus on what we’re gonna do to make it happen.

Robertson: Exactly.

Shimel: You know, unfortunately, it can’t be some developer who raises his hand and says, “I really wanna make a digital transformation here and I need to convince my CIO. Can you come in and give me a value stream mapping kind of session or workshop or can we discuss it?” It’s not a one-man show.

Robertson: Exactly. Exactly. And it is very interesting you said that because, because value stream looks at the lifecycle from planning to operations, there’re different stakeholders, right? And what’s happening in, especially in enterprise, is these stakeholders now—they have implemented the tools or they have guys that work for them or folks that work for them that implemented these tools, and they’re starting to ask questions or they already started asking questions around value. What I mean by that—you have the executive and he’ll say, “You know, my folks are telling me we did four deployments today.” Great. What does that really mean for the business?

Shimel: Yeah.

Robertson: Did we get little features out to the business, where they get utilized? Are they utilizing that? Did I actually place the right emphasis on those features? Right? The last release that I deployed on time, at least from a developer perspective, said I deployed this, I deployed it on time, but I’m having this increase of service desk tickets. What’s going on here? Why am I being called? Right?

Shimel: Yeah.

Robertson: And I _____ –

Shimel: Oh, yeah. Exactly.

Robertson: Right? [Chuckles] And it means that the IT office guys, right? They have their own set of—type of metrics that they’re looking at, right, and they wanna understand, right, “Is there anything impacting this release?” and without having to chase down and talk to every other person or look into every tool, to try to gather this information, right? And then you’ve got the engineers, like the QA engineers, and now compliance, security’s coming into play as well, right?

Shimel: Absolutely.

Robertson: So now folks wanna know, “Before I deploy, did all this pass through the quality gates? Was this sufficient?” Right? “What about security and compliance checks? Can I automate that feedback? Can I get that feedback to the appropriate stakeholders?” Right? So they’re already involved in asking these questions, but they really don’t have any direction there on how to get that information. And this is where—this is the impetus to say, “Well, you know what? Now’s the time to start looking at these tools, where you’re gathering this information, what’s generating this information flow, and how we bring this together.” Right? So it kinda starts to endow that value stream mapping conversation pretty well.

Shimel: Yep. Excellent. Excellent point. Because, like DevOps itself, value stream mapping is a team sport, right? And—

Robertson: Yep.

Shimel: And it’s cultural and you need that group kind of involvement to make it happen. So, Eric, I’m sure you probably have a few war stories around this, though. Can you share with us sort of—you know what I always say? You learn more from your failures than you do from your successes.

Robertson: Oh, my God.

Shimel: Can you share with us maybe some value stream mapping engagements that didn’t work out and, of course, only if you’ve learned something from it, and what was the valuable lesson you learned?

Robertson: Exactly. I mean, that’s—it’s very interesting that you said that because we had one customer—and I can even use it from my experience. I mean, I worked at a company and I used to dread Wednesday mornings because Wednesday mornings was—wasn’t really a scrum meeting, but it was more of a meeting as far as, “What is the latest status of this release that went out the previous day?” because we did weekly deployments, weekly deployments. And everybody would dread that because it was really no place to go to get a full understanding that, “Well, if this release actually was deployed, what was in that release? If it wasn’t deployed, what was the bottleneck in there?” Right? “Was it that it failed a certain testing that it didn’t get through or did we discover that, in this environment, we did some monitoring and it didn’t pass this stage?” We had no idea. I mean, did the builds fail? Why? There was no insight to anywhere in that chain, right, from the planning, ’cause it’s all kinds of activities that are happening in the coding, the building, the testing, the deploying a release.

And so, if you don’t really have an idea, as far as that information flow in a place where you can go and view that information and quickly understand “What are my exceptions, right, that I need to quickly identify and quickly address?” everybody’s chasing their tails there. And I’ve been on so many projects where that transpired and happened. And so this was really impetus of why we wanted to start having—start putting—leveraging this best practice, leveraging these practices, and then the tooling becomes more secondary type of aspect, rather than primary goal for driving processes.

Shimel: Yeah, I agree with you. The tooling then winds up taking sort of a backseat to it. So let’s—well, we’re almost out of time, unfortunately, Eric. As I mentioned to you, the 15 minutes goes quick. We do the best we can.

Robertson: No worries.

Shimel: Let’s put—

Robertson: I’m enjoying it.

Shimel: —value stream mapping to the side a little bit. What else is—

Robertson: Sure.

Shimel: What else is going on with CollabNet?

Robertson: So CollabNet is also partnered with a company called “Clarive”—it’s release automation software—and what we’re doing is is that we’re linking the release automation capabilities into our value stream management platform. Now what’s nice about this is that this allows us, very quickly, to start getting metrics across different type of applications and projects. And what I mean by that is, if you go into a larger enterprise, for example, they – of course, they’re experimenting with container type technology and Web-scale IT technologies, but they’ve also got some legacy applications, right? There may be Java, right? There’s—or on WebSphere or a traditional type of applications or architecture. They may even have mainframes or they may even have package apps, right?

So one of the things that we’re doing is that we’re getting—we’re creating this abstract _____ layer around all those tools, so customers can have, enterprises can have a common user experience around release automation, whether or not—so, again, we’re abstracting the tools, so you’re focused on the process, and it doesn’t matter what tooling is utilized underneath. If it’s Webscale IT technologies, container-based technology, it does not matter. You can basically have a common release process across your different type of applications—package, legacy, and traditional—so we’re very excited about that.

Shimel: Excellent. Sounds very cool. Eric, we’d love to talk more to you about this, but we kind of are over time. What I’d like to do, though, is maybe invite you back and we can talk. You know, we’ll leave value stream mapping for a moment and we’ll talk about other stuff next time, but I think we’d like to hear what’s going on in the world of DevOps, obviously, and with the players in it, and CollabNet has certainly been on the scene here and lots to tell. Until then, though, it looks like we’ll call it a wrap on this version of DevOps Chat and we’ll speak to you soon, and I—Eric, we’ve gotta get those links over. There’ll be in the notes for people who are listening in. But until then—

Robertson: Great _____.

Shimel: Eric Robertson, VP of product management and engineering at CollabNet, thanks for being our guest on this episode of DevOps Chats.

Robertson: Thank you, Alan. Glad to be part of this.

Shimel: My pleasure. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening in today and we hope to see you soon on another DevOps Chat. Buh-bye.

— Alan Shimel

May 16, 2017
DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

Puppet made three major announcements today around new versions of their flagship products, new products independent of Puppet Enterprise and a major expansion of partner programs and offices in the face of record growth over the last 12 months. As I detailed in my article on these announcements, these 3 taken together paint a clear picture of a market leader solidifying its position as an enterprise DevOps solutions provider. I had a chance to speak with Michael Olson of the Puppet product team about what these announcements mean.

As usual, the streaming media player of our conversation is below. The transcript of our conversation follows immediately below (transcript will be updated shortly)

Streaming Media

Transcript of our Conversation

Alan Shimel:                Hello everyone. This is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here on another DevOps Chat. Very happy to be joined on this episode of DevOps Chat by Michael Olson from the Puppet Product Team. Michael, welcome to DevOps Chat.

Michael Olson:           Thanks Alan. Thanks for having me. Good to be here.

Alan Shimel:                Pleasure. Pleasure to have you here Michael we always – actually we’ve had more than several people from Puppet over the years appear on DevOps Chat and we always – that’s always a great conversation.

But today Michael you’re on here regarding several news announcements that Puppet put out recently today on May 11 and wanted to kind of go over them with you and cue our audience in to what I think are several major announcements coming kind of down the pike from Puppet.

So if it’s okay with you Michael, you know the news as well as I do, do you want to lead off with what you think is the most important one or do you want me to pick?

Michael Olson:           Sure, I’m happy to dig in. And today’s been certainly a pretty big day at Puppet, we’re pretty excited to announce a very significant set of investments that we think really continues to deliver on our mission of empowering IT to deliver better software faster, so looking forward to digging in to what that entails.

It’s really around new products that help IT manage the complexities of their evolving and modern infrastructure as well as updates to some of our existing products that give really IT better control and situational awareness for the software that they deliver and run.

And then new partnerships and company investments that are really focused on ensuring that Puppet is where our customers need us to be, that our customers and our community and ecosystem really have the talents and the support needed to scale their success wherever they are, so looking forward to digging into it with you.

Alan Shimel:                Okay. So if you don’t mind Michael I’d like to start off with the announcements around new products – Puppet Cloud Discover – and if I mispronounce it I apologize – Lumigon? Is that how you pronounce it?

Michael Olson:           Alan, you nailed it. Well done.

Alan Shimel:                Okay. Well every once in a while even a blind squirrel finds a nut. But anyway, so we have Puppet Cloud Discover and Lumigon – and these are offerings in the container and cloud native technology areas, but beyond that Michael why don’t we dig in a little bit. What exactly is Cloud Discovery first?

Michael Olson:           Sure. And you’re exactly right. And I think before we dig in it’s useful just to set a little bit of context Alan and I’ll start by saying that our heritage really at Puppet has been rooted in helping IT professionals cope with sort of the complexity of managing an ever-growing infrastructure and application estate really by kind of harnessing automation.

So for more than a decade our core focus has really been around helping our customers define a desired state model for their infrastructure and applications and then providing an engine that translates that desired state of how they want their infrastructure and applications to look into reality.

So that has benefits of doing things like preventing configuration drift and eliminating manual intervention from the software delivery process.

And one of the things that we’ve seen is – you know, over the course of this journey over the past 12 years is we’ve been very fortunate to be supported by a passionate open-source community that’s helped refine our offerings, coving every aspect of systems management so that our new users that are getting onboard with Puppet can hit the ground running so to speak as opposed to having to start from scratch.

And so in light of that we are making investments to better support that journey for our customers and answering some of the common questions that we’re hearing from them. Things like, “How do we get started with automation and modeling?”

And one of the most common starting points that we see our customers looking to solve for is just know what software they have running across their datacenter and their cloud and container environments: answering a simple question of, “What resources and applications do I have running today? How do I bring those resources under management?” And I kind of refer to that general category of problems as discovery

So what we’re announcing today is really a new set of investments and offerings that are intended to give IT teams much better situational awareness into what they have running across their application and infrastructure estate regardless of whether that’s running in the cloud, in containers or on their traditional on-premise datacenter.

Alan Shimel:                Got it. Got it. So Michael I think that kind of explains a little bit what Cloud Discover is – Puppet Cloud Discover. And I’m looking at these two names of Cloud Discover and Lumigon – I’m reminded back to my days at one of the security companies I helped co-found – Still Secure – but we always had this sort of battle between descriptive names or kind of catchy marketing type of names.

And when I look at Puppet Cloud Discover that’s certainly a descriptive name, right? I think you almost get what it is from the title and it obviously fills a real need in the market as we get these – I guess you call it cloud sprawl – of an ever-expanding infrastructure and understanding what we’ve got there.

Talk to me a little bit about the other one though, Lumigon. How did we come up with that name and what does it do?

Michael Olson:           You bet. Yeah, Lumigon is a new offering from Puppet. It’s open-source so it’s something that is available for our community as well as anyone who is responsible for managing containerized environments within their organizations to go to our website and just simply pull down and start using today.

And I think as we all know containers have really emerged as a new and common way of packaging applications with that container image being the artifact that’s handed off from development into operations, and we think containers represent a really big opportunity for orgs that want to accelerate their product delivery.

But today what we’re often hearing is that those container environments are largely black boxes from an operational standpoint. What’s more, since there’s so many of them, containers tend to be ephemeral, so to speak, they tend to have shorter lifespans than VMs and that brings a whole set of challenges where you’re looking at bringing containers into production environments.

So what we’ve announced today is a new offering. It’s open-source and free and available for anyone to go and pull down and start using of Lumigon which is an offering that really focuses on discovering what’s running inside all of those container environments and giving operators really better visibility and control around their container estate.

So because this Lumigon effort is an open-source tool that can analyze applications – you know, we’re initially targeting docker containers and exposing application metadata about those but certainly looking at extending that over time as we continue to get feedback from the community.

Alan Shimel:                Great. Now Michael over the years we’ve spoken to several Puppet people – among them Gareth Rushgrove, D-Pack, Sonja himself – and we’ve talked here at devopsy.kinsta.cloud about Project Blue Shift at Puppet which is kind of, as you probably are well-aware – Puppet looking at new technologies and making sure that they – that Puppet’s mission encompasses working with these new technologies.

Is Lumigon something that maybe comes out of Project Blue Shift or independent of that?

Michael Olson:           I think it really represents a common vision from Puppet which is you know we see a lot of organizations in our customers that are really looking to automation as a bridge to their future. As organizations look to modernize physical infrastructure and move it into the cloud, adopt containers in production environments they’re looking to have automation really baked in from day zero as they look to do that.

And so Blue Shift is, as we’ve talked about in the past, really represents Puppet’s vision for helping our customers adopt the cloud and containers in consistent, repeatable and reliable ways. So it encompasses things like using automation to install docker or lay down operating environments in docker, for example, as well as do things like define and deploy the services that run inside of docker containers giving our customers really better portability to be able to kind of lift and shift workloads that they may have defined and are running on virtual infrastructure, for example, and getting that running in containers without having to adopt platform-specific tooling to do so.

Alan Shimel:                Make sense. And certainly – I mean I’m fresh out of Docker Con two weeks ago now – it seems like two weeks – maybe it was last week – but in any event I mean the shift to a containerized application infrastructure is well underway and so a product such as this obviously I think should find a ready market and the fact that it is an open-source tool and everyone can get involved.

                                    Michael what is – or other – I know it’s early in the game but are there any plans to have an Enterprise or pay-for version of Lumigon out there?

Michael Olson:           You know it’s certainly something that we’re looking at longer-term is as we continue to build off of this foundation, you know, ensuring that we’re meeting the needs of our large Enterprise customers as well as the broad community of more than 36,000 organizations that rely on Puppet technology today to deliver and operate their software

And I think what we’re focused on right now is really making sure that we’re nailing that core set of problems with a sledge hammer which is, “How do I expose the black box and know what’s running inside of my container environments so I can do things like identify if I’m vulnerable to a potential CVE or if I’m vulnerable to a bug in a library dependency. You know, to know if for example my OS standards are being followed and adhered to within my organization.” These are the types of questions that Lumigon will help users answer today.

And then shifting to the Cloud Discovery announcement that we talked about briefly earlier we’re also introducing a new offering here at Puppet that’s really focused on giving IT teams better situational awareness into what’s running in their cloud infrastructure specifically in AWS.

And so it’s really focused on helping IT teams go back and discover all of the resources and applications that are running in AWS. This is a limited preview that we’re offering for Cloud Discover today really to give those teams a better sense of what they have running in the cloud so they can make better decisions about how they want to bring them under management through automation.

Alan Shimel:                Great. So Michael both the Cloud Discover and Lumigon in some ways are maybe the cabooses on the engine here with the announcement of a new version of Puppet Enterprise – or at least the availability of a new version of Puppet Enterprise.

Why don’t you tell our audience a little bit about that?

Michael Olson:           Sure, yeah. So Puppet Enterprise – we’ve introduced a new version, we call it 2017.2 per our naming conventions – and I’ve been at Puppet for a few years now and in my opinion it’s really not an exaggeration to say that it’s one of the more significant releases that we’ve had in several years, really with a focus on giving our customers better visibility into the software that they have running on premise in their datacenter no matter how they’re managing it, as well as easier, simpler tools to be able to orchestrate deployments and run deployments across infrastructure and applications using visual workflows.

So the first set of innovation that we’ve introduced into the latest version of Puppet Enterprise is really around being able to inspect software packages that are running across your datacenter.

And one of the areas of feedback that we frequently hear from IT teams is it’s hard to know what software packages are running across their infrastructure, what versions they’re running, for example, in order to easily identify packages that may be vulnerable to security risks.

So we’re introducing some new reporting for our Puppet Enterprise customers in this version that’s really focused on giving IT easy visibility into the software packages that they’re running regardless of whether they’re being managed today by Puppet in order to really provide that insight to identify potential security issues a lot faster

And then as our customers look to use automation in order to drive change across their software stack we’ve also introduced a whole set of orchestration capabilities over the course of the past year-and-a-half. With this release we’re extending that to the Puppet Enterprise Web UI essentially giving our customers the ability to define, run and monitor deployment jobs entirely using visual workflows within the Puppet Enterprise Web UI.

So it’s easy to do things like define a deployment job, target a specific portion of your infrastructure, run a phase deployment for doing things like canary workflows, and then monitor the status of that deployment in real-time so if things aren’t going well you can hit the stop button, investigate, tinker as needed and then restart that deployment; so giving our customers a lot more flexibility into how they drive change across their software.

Alan Shimel:                Fantastic. And I love the naming conventions here – I remember speaking earlier about it – I think it makes it easy for people to see where they are and what they have – but the simple naming kind of hides the fact that there’s a lot more punch in here. And by the way, that’s available now Michael?

Michael Olson:           Correct, it is. Yeah. It’s available today for – certainly for current Puppet Enterprise customers – and for anybody who’s new to Puppet out there you can simply go to our website and pull down a copy, it’s free to try on up to 10 different servers, devices or applications.

Alan Shimel:                Sure. Michael, and I didn’t ask this – my apologies – for the Cloud Discovery and Lumigon – what’s their availability?

Michael Olson:           Yeah, Lumigon, which is really around, again, kind of exposing the black boxes of containers, is – that offering is available to try today and you can find a way to get there directly from our website at Puppet.com. And then the Cloud Discovery offering is available as part of a limited preview so what we’re really looking to do is if you’re interested sign up through our website and we’ll be in contact with you if you’re interested to discuss next steps.

Alan Shimel:                Perfect. Next Michael let’s talk a little bit about the last announcement today, and this one was more around sort of momentum – it looks like a bunch of new Enterprise customers added as well as new locations and partners and partner offerings. I don’t know if I left anything out but give us some of the details there if you can.

Michael Olson:           Sure, yeah, happy to do so. And you know you get this Alan, obviously you and I have talked before, but what we’ve really seen over the course of the past several years is just a huge surge in growth and momentum for Puppet and I think it’s been fueled by growing demand in the market for dev-ops and for digital transformation.

So we’re really taking that momentum and using it to grow more aggressively and really help our customers be more successful, you know, laying the foundation for dev-ops wherever they are in the world.

So what we’ve also announced today is a new set of partnerships with organizations like AWS and Cisco and others as well as global expansion for Puppet: we’re opening up new offices in Singapore really to better serve the needs of our customers internationally and ensure that Puppet is with them wherever they are and however they want to engage with us.

Alan Shimel:                That’s great. What about from a partnership point of view though? Any new partners to announce or just partner offerings?

Michael Olson:           Yeah, from a partnership perspective – I’ll touch upon a couple things – one of which is we have a new marketplace offering up on AWS that we also made available today and really the key takeaway there is as our customers are increasingly looking to kind of recognize the value of cloud-based environments – they’re using AWS – we’ve really deepened our relationship with Amazon Web Services and deepened that partnership with a new offering that basically makes Puppet Enterprise available on the AWS marketplace on an hourly pay-as-you-go basis.

So it’s really focused on simplifying the installation of Puppet Enterprise and providing a way of securing configuration and getting better visibility into your AWS infrastructure through Puppet directly from within the AWS marketplace.

Alan Shimel:                Yeah. You know, to me Michael that’s a huge winner, right, because number one – I’m familiar with the AWS marketplace and there’s no lack of solutions up there – but once you’re in there and you have the ability to kind of piggyback the AWS billing, if you will, for hourly service and hourly offerings – it allows people to consume their services in the manner that they’re used to consuming them in AWS, right?

I think early on there was a big rush to the AWS marketplace but if you weren’t truly integrated into AWS it just, you know, from a billing perspective and usage monitoring and all that, it – I think their customers just did it – it was just too clunky frankly, right? So this makes things a lot smoother in you’re an AWS customer.

Michael Olson:           I think that’s spot on Alan. Like the constant feedback that we hear from our customers is they want us to meet their needs and engage them how they want to be engaged, so to speak, and I think this is a marker that helps payoff that objective that customers have is, you know, if you’re looking to bring automation into your cloud environments – you know, looking to get started for the first time – just, you know, click a few buttons and spin up Puppet directly through the AWS marketplace.

And we’ve also really extended our partnership with Cisco in some of the partner-related announcements that came out today as well as we see more Cisco customers that want the power of Puppet as a way of defining, deploying and operating all of their software. So with our expanded partnership joint customers of Puppet and Cisco can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco value-added reseller.

Alan Shimel:                Cool. Very cool. Okay. Michael, you know, I promised you we were going to do 15 minutes and here we are for over 20 – I apologize – but before we wrap things up did we miss anything in the announcements?

Michael Olson:           I don’t think so Alan, this has been a great conversation and I think we touched upon most of the highlights.

Alan Shimel:                Yeah, I think so too. You know not everything fits into a 15-minute bucket though in life so I apologize but I think it was well worth the time spent digging into these new, exciting developments and announcements over at Puppet.

Michael Olson from the Product Team at Puppet thanks for being this episode’s guest on DevOps Chat. Hope to have you on again soon.

Michael Olson:           Likewise. Thanks for having us Alan and it’s always great to catch up with you.

Alan Shimel:                All righty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening everyone and we’ll see you on another DevOps Chat hopefully very soon.

— Alan Shimel

May 11, 2017
DevOps Chat: Taking Care of Your People with Rob England, IT Skeptic, DOES Speaker

In this DevOps Chat we speak with Rob England, the IT Skeptic. Rob joins us from New Zealand (you have to love the internet). Rob is going to speak at this year’s DevOps Enterprise Summit London, June 5-6, about the importance of taking care of your people in the DevOps transformation process. Rob is always an entertaining fellow and this chat is no different. If you are attending DOES London this year, you don’t want to miss his session!

As usual, the streaming media of our conversation is immediately below and the transcript of our chat follows that:

Transcript of the Chat

Alan Shimel: Hey, everyone. This is Alan Shimel from devopsy.kinsta.cloud here for another DevOps Chat. We’re lucky to be joined on this DevOps Chat by a friend of mine and a person who’s actually appeared before on our DevOps Chat, all the way from New Zealand: Rob England, the IT Skeptic. Rob, welcome to DevOps Chat.

Rob England: Hi, Alan, and, hi, everybody. It’s a pleasure to be here.

Shimel: So, you know, Rob, actually, I didn’t ask, but are you back home in New Zealand right now?

England: I am, so I’m about to have my breakfast. [Laughs]

Shimel: Okay.

England: Tomorrow. Your tomorrow. So –

Shimel: Yep, it’s my tomorrow. You’re already living my tomorrow—that’s interesting. So, Rob, of course, I think you’re well known within the DevOps community and the IT community at large, but, for anyone who’s listening may not be familiar, why don’t you give us a quick little background?

England: Okay, thank you. Yeah, so I come from a service management background, so I have a bit of a presence internationally with a small blog that got a service management following, so that’s how I sort of became internationally networked. And, originally, I was a bit of a skeptic of the whole DevOps thing, but I was gradually turned, by Gene Kim and by John Willis and by Jez Humble and others, into a bit of an enthusiast, and now my whole life is DevOps, really. I consult here in Wellington, New Zealand to the DevOps community and I’m working with a couple of the largest government departments here in New Zealand now, helping them on their DevOps journey.

Shimel: That’s just great. And, Rob, you’re traveling from New Zealand to London, June 5th and 6th, for this year’s DevOps Enterprise Summit, DOES London. It’s at the –

England: I am.

Shimel: – QEII Conference Center. And you’ll be speaking there as well.

England: I am. Oh, I’m really, really pleased and honored to be selected to speak; I think that’s fantastic.

Shimel: I think it is too. So, Rob, we’re lucky enough to interview a few other speakers from DOES—not only from London but in past DOES events in San Francisco, but can you give our audience a little bit of a flavor for what it’s like or what’s the process like or what motivates one to go speak at a DOES event?

England: [Chuckles] Oh, in this case, what motivated me was Gene Kim, so I was talking to him about some of the people stuff that I’m quite passionate about, and he said, “Hey, you should write that up and submit it,” so I did. And, from there, it was pretty straightforward—I put all the details in and had my proposal accepted—so that’s very exciting. As I say, I’m very passionate about the people side of things and the cultural change, and the focus for this presentation is around taking care of our people through that transformation.

Shimel: Excellent. And so, Rob, when you mention people like that, I’m reminded or brought back to a—I think it was Adrian Cockcroft’s presentation in San Francisco this past—don’t remember if it was October or November, but you may remember. And Adrian’s presentation was very much that,“Hey, people are your most valuable asset and you gotta treat them right. And, when you think about the money you spend on tools and all of these other things, it pales in comparison to the importance of spending money on people.”

England: Yeah. Absolutely. In the past, even before my DevOps life, I used to write about how, if you look at any project, when we’ve had projects, and how the money was allocated within that project, if it wasn’t sort of one-third people, one-third process, one-third tools, then you had a very strong indicator it wasn’t gonna be a successful project.

Shimel: Mm-hmm. Repeat that again, though, ’cause you know how you New Zealanders are – you talk so fast. [Chuckles] That it was one-third, one-third, one-third?

England: Yeah, yeah, yeah. So one-third people, one-third practices, one-third tools. If it’s not something like that, it’s very typical to see project proposals that are going to spend 50 percent of their money on installing the tools and 50 percent of their money on redesigning their processes—oh, and, by the way, there’s a day’s training. You know, and it’s like, well, there’s nothing else recognizably about workshopping with people or collaborating with people or, you know, coaching people or all the other people aspects. It’s very common to see projects that are not planning to spend any money on all that, and I think that’s a –

Shimel: I agree.

England: – a formula for failure, right?

Shimel: Yeah, no, it is. I mean, we tend to take the people part of it for granted, and, just as you said, you don’t spend the money on it, will spend a ton of money on tools and infrastructure. Right?

England: And I have to say, I think that’s one of the two primary reasons why service management initiatives were so often unsuccessful, was that, I thought, didn’t coach us enough to focus on the culture and the transformation, and we spent too much time on process, so DevOps—for me, the power of DevOps or a big part of its power is it’s focused on people and culture.

Shimel: I have to agree with you. I have to—you know, Rob, I’m reminded of, back in my security days, the co-founder of StillSecure, I went to visit a rather large bank out in New York, and it was about vulnerability management. And we were talking about the vulnerability management program they had in place and I mentioned to ’em that the way they were doing things, it was forcing his security team not only just to scan at night, which is, you know, normal, but to actually only do remediations on weekends.

England: Mm-hmm.

Shimel: And I said, “You know, that means that your security team is working every weekend, in addition to working during the week, ’cause you don’t have enough people to stagger that.” And he said, “I don’t care. I pay them by the week; I don’t pay them by the hour. I don’t care if they work seven days a week.” And that –

England: There’s a good boss, eh?

Shimel: Yeah, no, that’s someone you’d wanna work for, right? But this, unfortunately—you know, we talk about culture and the whole “Kumbaya” thing that many people kinda try to say with DevOps, but it’s real. You gotta treat your people as your greatest asset, and that was Adrian’s message, right, at DOES San Francisco. They’re not –

England: That’s powerful.

Shimel: Yeah. And they—if you treat ’em like crap, crap is what you’re gonna get, I’m afraid.

England: Absolutely. And my particular focus for this presentation is about the effect of the transition on people in your organization and, in particular, there’s this “Get on the bus” thing, but we don’t wanna actually throw people under the bus, so it’s giving people the opportunity and the time to grow and to make the transition. There’s very often a “revolution, not evolution” thinking in management’s mind: “Are we just going to change everything?” And, again, we’re very neglectful of the fact—the old bell curve—we’re very neglectful of the fact that just because a few people are coming along doesn’t mean we—we still have to allocate more time for the great masses to get their head around this thing and absorb some of these really quite challenging and radical concepts that underpin Agile and DevOps—it does people’s heads in, as we say down here.

Shimel: Yeah. So, Rob, let’s talk about that a little bit, if we can. You know, you’ve now consulted, as you said, with a bunch of government departments and companies, both in New Zealand and in other parts of the world. What, from a people point of view, what is the hardest things that these guys or these people have to kinda wrap their heads around to make it successful?

England: Oh, I’m sure the biggest challenge is getting—well, actually, one of the biggest challenges is getting away from that silo-ed thinking, and so the other power of DevOps, along with its focus on people, is its focus on systems and systems theory and systems thinking. And so I think that they struggle to get out of their silo and start thinking holistically and seeing the whole flow of value and understanding their role in that. That is a big challenge to just about everybody.

Shimel: Agreed.

England: Then there’s also—yeah. And then there’s also peculiar challenges to each organization as well, right? So I’m thinking of one where a particularly psychopathic CIO had moved on, and it was trying to teach people that, “It’s okay now. You can come out from under your rocks, you know? It’s gone.” So that’s –

Shimel: “Out from under your rocks.”

England: Yeah. That’s a—they all sort of crawled away into shelter, you know? And so that’s the peculiar problem in one situation. So there’s—you know, every place has its own challenges, but a universal one is that siloed thinking and another universal one is just the letting go of the—do you remember the Bastard Operator from Hell, BOFH, or –

Shimel: Mm-hmm.

England: – or Dilbert‘s Wally? You know, these characters that—it’s considered funny in IT that people have dysfunctional behaviors and are misanthropic, and part of the DevOps message is just we don’t tolerate that anymore. That negativity is not allowed—we just don’t tolerate it—and getting rid of some of that old cynical bitter and twisted IT thinking is also a common challenge.

Shimel: I agree. I agree. And you know what? I think part of it is not only the negativity from whether it be a supervisor or peer; I think the other biggest thing that I personally see and when I talk to organizations around DevOps and stuff, and not just dev and ops—when I talk with QA and security and management and so forth—is the finger-pointing, is the—it’s almost like American politics, I’m sorry to say, in that “Yeah, I know this is screwed up, but blame the other guy,” or “If you think this is screwed up, you should see how screwed up the other guy is.”

England: Absolutely.

Shimel: You know? “And it’s not my fault; I inherited a mess,” and all of this kind of thing where one of the refreshing things about DevOps is it started with the blameless postmortem, but it’s more than just a blameless postmortem—it’s about “Stop pointing the finger and let’s work on solving this together, instead of just saying, ‘Hey, it’s this mate’s fault and it’s his problem.’”

England: “I’ve got your back.”

Shimel: Yep. I mean, and that –

England: I’ve got your back, buddy.”

Shimel: You know, and that may sound hokey and “Kumbaya-ry” and all that, but, really, I think that’s when you start building a team.

England: There’s a really good cartoon, that might be a Paul Wilkinson one, where the ops guys are at one end of the boat, looking down at the dev guys at the other end of the boat, trying to deal with a fountain of water and saying, “Not my problem, not my end of the boat.”

Shimel: Right. Uh-huh. Exactly. And we’re all on the same boat, though. So –

England: Yeah. Yeah.

Shimel: So this is a real thing. Rob, other than DOES, have you been talking about this kind of subject at other events and so forth?

England: Oh, for sure. So, actually, it’s been an interest of mine since before I was consulting. I used to work in—for my sins, for a vendor, and I used to do work on professional development there and trying not to let the technical people fall under the bus and trying to get them to skill up to be consultants, rather than just product jockeys. So I’ve worked and talked in this field for a long time, just as a personal passion. I hate to see good people lost, you know, just because their organization failed to make sure they were coming along and to take care of them.

Shimel: Sure. Sure.

England: So that’s a long-term passion, but this particular topic now I’m hatching especially for DOES, to put together a presentation specifically about the DevOps implications of—it’s called “Surviving DevOps,” so making sure everybody’s—it’s not just that you individually survive, but that “no person left behind,” you know, as well.

Shimel: I agree with you. So, Rob, geez, I’ve met you—wasn’t this year’s San Francisco DOES; it was last year’s. So it wasn’t 2016; it was 2015 DOES San Francisco. And we’ve, of course, seen each other several times since, but –

England: And, you know, I’m one of the few people in the world who’s been to every single DOES in both the U.S. and the UK.

Shimel: So I think I’m one of them too, actually, but –

England: Yep, you would be.

Shimel: Yeah, which is interesting, when you think about it that way. But let’s—I mean, many in our audience may not have been lucky enough to even get to one, let alone five or six of these things. Can you give our audience a flavor of why? Why do you keep coming back? Why did you feel compelled to wanna speak at this one? What makes this a great event in your mind?

England: Well, I think it’s the fount of knowledge for DevOps, especially DevOps enterprise, so my interest is DevOps for hoses, not DevOps for unicorns. And, very much, the focus of the enterprise conference is around DevOps in the real world, DevOps in the enterprise world, so that’s the first thing. The second thing is that Gene does a fantastic job of focusing and coaching presenters to make sure that their presentations are really short and pithy and full of value, and they also make sure that the presenters are practitioners, so there’s not a lot of talking heads, except for some really high-value experts like John Willis and Jez Humble and Adrian Cockcroft, the people who are up there purely because of their intellectual strengths. But most of the speakers are there because they’re reporting back from the coalface about their own experiences and learnings, and so that, to me, is gold.

Shimel: Yes. Any—well, I guess that kinda says it all, Rob. If anyone had any doubts about whether they’d wanna go to this or not, that clears that up. Rob, anything else happening exciting around DevOps you think people should be on the lookout for?

England: Oh, well, I’m not sure about _____ – the value for me is that I live on the last rock on the planet, so I actually get quite a different lens on DevOps than perhaps those, like yourself, immersed in the big economies and big societies, and, certainly, it’s going gangbusters here. There’s a huge wave of interest in the mainstream—in government, in the airline, the banks—and I’m gathering that that’s not necessarily the case everywhere in the world, so, you know, I think that –

Shimel: No, I think it is. I really think it is.

England: Yeah. Yeah. But they’re not just dabbling anymore, right? They’re actually transforming; they’re restructuring the way they go. And, to me, that’s the excitement of the moment, is that this thing is mainstream. You know, it’s bridged the chasm. Remember the Star Wars book about crossing the chasm? You know, the –

Shimel: Yeah. Sure do.

England: – DevOps has gone from the early adopters to mainstream now. It’s definitely –

Shimel: Oh, it’s certainly mainstream, but I –

England: – the majority.

Shimel: So I think it’s in the early majority, though, not the later majority.

England: That’s true. That’s true. It’s still not everyone; it’s still not—but, yeah, but it’s certainly jumped—it’s certainly bridged the chasm and it’s on its way up that curve.

Shimel: Oh, no doubt about that. No doubt about it and, hey, we live it every day here at devopsy.kinsta.cloud, as we continue to kind of chronicle all this. Anyway, Rob, we’re about out of time. I wanna thank you for joining us all the way from New Zealand. Look forward to seeing you in London and your presentation and thanks for doing everything you do, Rob. I mean, you know, you’re a healthy IT skeptic. In IT, skepticism is healthy, right?

England: It sure is and I love doing it. Thanks, Alan. It’s always a pleasure to talk to you, my friend.

Shimel: All right, Rob. You be well. We’ll see you in just a couple—well, it’s about two months now, probably.

England: See you there.

Shimel: All right. Rob England, IT Skeptic, speaker at DOES London on June 5th and 6th at QE Conference Center. This is Alan Shimel for DevOps Chat. We’ll see you soon on the next DevOps Chat.

— Alan Shimel

May 5, 2017
DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team
Blue Ocean brings easy-to-use continuous delivery for teams to everyone. Years in the making, Blue Ocean is a major project built from the ground up for Jenkins Pipeline. I had a chance to speak with two of the key contributors from CloudBees and the Jenkins community, James Dumay and R. Tyler Croy. Tyler is on the Governance Board for Jenkins.

Blue Ocean provides:
- Sophisticated visualizations of CD pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
- Pipeline editor makes creation of pipelines approachable by guiding the user through an intuitive and visual process to create a pipeline.
- Personalization to suit the role-based needs of each member of the team.
- Pinpoint precision when intervention is needed and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
- Native integration for branch and pull requests enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.
As usual our conversation in the streaming media player is immediately below.

Streaming Audio

Transcript of our conversation

Alan Shimel: Hey everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Welcome to another DevOps Chat. We have two guests today on DevOps Chat. We have James Dumay and R. Tyler Croy of the Jenkins community. James, Tyler, welcome to DevOps Chat.

James Dumay: Nice to be here, Alan.

R. Tyler Croy: Thanks for having us.

Shimel: Thank you. Let’s start off though with just a little background of each of you. James, you’re coming to us all the way from Australia. In deference to the distance, we’re going to let you go first. Why don’t you share with our audience a little bit of your background?

Dumay: Yeah, sure thing. So I’ve been probably building development tools for the last 10 years. I think I’ve found my calling here. I love making developers more productive. I also want to make developers happier. So I do have this bee in my bonnet that developer tools are difficult when they’re boring and they’re not very pleasing. It’s my life’s mission to turn that around.

Shimel: Excellent. Tyler, how about you?

Croy: I’ve been with the Jenkins project a little over eight years now. I started using it when I was a back-end services engineer, a few startups ago. Every single company that I’ve joined needs more continuous delivery or some non-zero amount of continuous delivery stuff. So I found myself getting more and more ingrained in the Jenkins project and bringing Jenkins to bear in companies to ship products faster. Now I work at CloudBees talking about how you can do that and help other people see the light with some of the Jenkins stuff I’ve been doing for a while.

Shimel: Tyler, I don’t want to embarrass you. You actually are—I don’t even know the word, but you’re one of the—on the steering committee or the governing committee for Jenkins. Is that the right way to put it?

Croy: I guess you would say I’m on the Jenkins governance board. In the beginning of the Jenkins project, there was Kohsuke Kawaguchi who was the founder of the project, and then there are a few other core folks that were floating around that helped get Jenkins off the ground. Andrew Bayer who is a major contributor to the pipeline toolset, is one of those people. So I’ve just—Jenkins became a really important part of my life. I started spending a hell of a lot more time with Jenkins, and now I’m one of the people that makes sure that the project continues to move forward.

Shimel: Excellent. James, I don’t know if you mentioned your role other—at this point, other than you’re cuckoo for Jenkins. What exactly is your role right now?

Dumay: I’m director of Product Management at CloudBees, but I’m also a community leader for the Blue Ocean project. I do all the outreach and talk to all the users. It’s good fun, but previously before I was at CloudBees, I was at a small Australian startup called Canva. They do an online design tool. Prior to that, I spent seven years at Atlassian, where I was product manager for actually a competing product.

Shimel: Absolutely. Well, we’re allowed to have competing products. They may not be any good. I’m only kidding. James, you mentioned the magic word. You get the first prize today. That was Blue Ocean. Today’s a bit of a—more than a bit—today is a big day in the Jenkins community. This release has been highly anticipated. It’s been in beta and in testing, alpha before that for some time. Talk to us. What about it? Why should people care?

Dumay: All right. That’s a big question. So I guess we’re living in a really interesting time in the industry. We have this—there’s this ride of exponential change that is happening across our industry, whether it’s tooling and technology and process, or just the raw number of people writing computer software in the—we’ll be in the year 2020 soon. I think if you look back in the previous 10–20 years, the amount of companies out there that are writing software today and were not writing software 10 or 20 years ago. So Marc Andreessen speaks about software eating the world, where all the value that companies provide slowly but surely are being made, not by the engine in a Ford motor vehicle, but it’s the software on board the Ford motor vehicle.

So it’s an interesting time to be a software developer, or to be in this field, but it’s also a really interesting time to be a tools creator. I think with this increase of people in the industry—it’s not like we have lowered the bar to what we call a software developer, but I think there’s a lot more people today who, in their jobs, whether it be financial services, or in other industries, who are finding their job involves writing software. I think there’s a big challenge here, and Blue Ocean is founded on going out there and solving this problem, that how do we make the millions of software developers or even people who are just writing software as part of their jobs, how do we make them more productive? How do we make sure they can get what they need to get done as quick as they can get it done at the highest quality that they can get it done with the best tools possible?

So with Blue Ocean, we’re sort of focused in on the practice of DevOps and on continuous delivery. We set ourselves a goal. What if we can make it really easy for people to adopt continuous delivery? Blue Ocean is our answer to that.

Shimel: Tyler, James—I think James made some important points. What can you add there? Why—let’s step back a second. Let’s say our audience is vaguely familiar with Jenkins. Most of them probably use it, but there’s some maybe that don’t. What is—let’s start with what is Jenkins to them? What does Blue Ocean represent to Jenkins?

Croy: Sort of at a high level, Jenkins is an automation server. Jenkins is probably the most well-known tool of its kind across the entire software industry. As far as helping developers build and test and deploy their software, chances are with most organization today, if someone doesn’t think they’re running Jenkins, they might just not be aware, or they might be so far removed, or that it’s hiding, that they don’t know that it’s actually there. It’s pretty omnipresent in the industry right now.

One of the big things about I would say the shift in the industry that has made Blue Ocean important—when I first started in northern California about 10 or— [inaudible] 10 years ago, continuous integration was this really big, important thing. I kept coming to companies who either didn’t have a continuous integration server, or didn’t practice—nobody but the developers knew that there was a continuous integration server. As the industry has shifted towards this more and more rapid pace of “Let’s practice continuous delivery. Let’s get product and value to our customers as soon as possible,” it’s no longer acceptable for just the developers to get feedback to what’s going on in that process.

So I think the important thing for Blue Ocean, and I would say broader software industry, is that continuous delivery is not a developer thing. It’s an entire team thing. It’s an organizational thing. Blue Ocean is designed from the ground up to make sure that people who might not be writing code every single day, or they might be designers, or they might be product managers, or stakeholders of some form or fashion in the software development process. They need to know what’s going on and Blue Ocean is going to give them a window into what’s going on in the delivery pipeline. That’s a pretty dramatic shift from the Jenkins that was created 10 years ago, which was just for developers.

Shimel: Got it. Got it. Now guys, I’ve had the—I don’t know if the word is a pleasure, but I’ve had the—well, it was a pleasure in a lot of ways, but I’ve had the experience of being involved with open-source projects in the past. It’s a fickle thing being part of a community. It’s even harder when you have a corporate entity such as CloudBees in this—CloudBees isn’t alone in this. There are many companies that are mentoring, managing—whatever you want to call it—open-source projects. Talk—I loved what I saw of how that relationship was handled as it applied to Blue Ocean.

Guys, can you give us a little color on that? No pun intended with Blue Ocean and color, but a little background on how you worked with the community to deliver, I think, what the community consensus was what was needed.

Dumay: Just to preface this. So this is my first time working full-time on behalf of the commercial entity for _____ community. So I—when we started at Blue Ocean, I kind of put myself in Tyler’s very capable hands. Tyler had had a lot of previous experience, not with Jenkins, but with other projects, walking that fine line between community and the need for the business sponsor, I guess. So it’s been an interesting process. I think certainly for CloudBees, a healthy Jenkins community is a healthy CloudBees, and a healthy CloudBees is a healthy Jenkins community. It all feeds into each other. As long as, I think, we take things from a project perspective, like what’s good for Jenkins, we’re making good decisions in both aspects.

Certainly, we had been running—more in terms of Blue Ocean itself, we had been running for multiple years Jenkins community surveys, and one of the top issues people would have liked to see addressed in that feedback had been the user experience with Jenkins. They really wanted it to be easier to get started. They really wanted clarity when they’re looking for particular cases, information. I think there was a real groundswell there to see some improvements, and see some sort of more modern thinking around how to solve problems. I hope that we’ve done that. Certainly the feedback that we’ve been getting from the community has been pretty great.

Just on the community itself, I think software developers can be a pretty passionate tribe of people. So it’s—the Jenkins project is no different from the wider developer community. They’ve been passionate in a very encouraging way, in a very forgiving way as well. Particularly when you go ahead and think about any product that has—web product that has been redesigned. So the people get very upset. They’re very invested in the tools that they use, or the products that they use, and then you move their cheese, and people go “Where did that thing go? Where did this other thing go? No. I was using that. Bring it back.” I think with the Jenkins community, I think they’ve been very—I think they’ve wanted the change for so long that as things change, we—they’re getting some new goodies in their bag and they’re happy to let some of the old bits disappear.

Croy: I think there’s also—if you look at that feedback from the Jenkins user list going back years and years and years, there’s been—most people, I would say, that contribute to the Jenkins project, note they’re new, I guess past tense, because Blue Ocean is one meadow now—knew that something needed to get fixed, and someone needed to do something to really improve and set up Jenkins for the next 10 years. The skill set and the passion and the vision really wasn’t there.

So when James and his team, his colleague Michael Neale and some of the other people, really started to get involved, I think it was easier for other contributors in the project to rally around that. It was clear that not only did they know what they were doing, but they understood the challenge in that we needed to think about the design from the ground up, as opposed to reskinning or reseaming Jenkins. They needed to evaluate it from a user experience standpoint and start from 2016 rather than 2006, which is when the project really started. So I think that was really helpful to have some—a passionate group of people with vision to drive it forward.

Shimel: A passionate group of people with vision can accomplish a lot. That’s for sure. Guys, let me ask you—we’re almost out of time. What—for each of you, and we’ll go with James first. James, what do you think is the single biggest aspect or feature of Blue Ocean that our listeners should take a look at?

Dumay: That’s very unfair, Alan. I love them all.

Shimel: How can a parent decide? But guys, so pick one. Doesn’t have to be your favorite or biggest, but one that we’d like to call out.

Dumay: The official pipeline editor. So _____ delivery pipeline is difficult at the best of times for people to create. So we set ourselves a challenge. What if we could make it very easy for people to create a continuous delivery pipeline using Blue Ocean UI. The one thing I really like about it is it really is for everyone. We talk a lot about—we’ve got a lot of plans for the Blue Ocean in the future. One thing we talk about is the Fisher Price’ing of the editor. I don’t know if you’re familiar with Duplo blocks you give a toddler. But you can get all these different attachments, all these crazy things, and you can customize your own creation using Duplo. It’s non-checkable Lego. So really, Duplo is for everybody. So anybody of any age can—of any skillset, can construct something from Duplo.

The thing that I like about the—I guess the vision behind the editor is anybody can construct a continuous delivery pipeline, even if they don’t have coding knowledge. Maybe they want to take—they have—we can go as far as they can have a PHP website on a Dropbox folder and they want to upload that, deploy that continuously to their webhost, their DreamHost or something like that. That’s the kind of—we want to bring continuous delivery to everyone.

I think the communal pipeline editor is the vehicle to do that. One of the great things about the editor as well is that it is what you see is what you get. So when you build it in the editor, that’s exactly how you visualize it later on in Blue Ocean, as that pipeline is executing. It’s really powerful in that way.

Shimel: Great. Makes sense. Tyler, how about you?

Croy: So my interactions with Jenkins are typically when something goes wrong. I think that’s maybe a bit more common for an infrastructure administer or developer. So, for me, I would say the No. 1 killer feature with Jenkins—with Blue Ocean and Jenkins is that the clicks to get from a failure or something going wrong to seeing what actually went wrong, it’s pretty much one click. So the visualization of status is so much faster and more immediate in Blue Ocean that when I come to Blue Ocean to figure out what test failed, or what went wrong in my pipeline, I get that in a matter of seconds, as opposed to drilling around and hunting through console help. So for me, that’s probably the killer feature.

Shimel: Make sense. Guys, we’re going to wrap up here in a moment, but just quickly, for people who want to find out more about Blue Ocean, where can they go? James, Tyler?

Dumay: No problem. They can go over to Jenkins.io/projects/blueocean or the Jenkins blog, which is Jenkins.io/blog.

Shimel: Okay, Tyler, I’m going to hit you with the last question. Now that Blue Ocean is 1.0, what’s next?

Croy: [laughter]

Shimel: [laughter] You didn’t expect to get a rest, did you?

Croy: No, no. I think the really important thing that’s next for the Jenkins project is I would say the next three months of Jenkins pipeline and Blue Ocean adoption. Now that we’ve got the tools that we’ve brought to the broader software industry for building and constructing and running continuous delivery pipelines, we’re going to need to iterate, on them and we’re going to need to make them better as more and more people start to adopt continuous delivery. I think we’re, certainly before the end of the year, we’re certainly going to find new things that we can add into Jenkins to make that an even more enjoyable experience.

Shimel: Absolutely. Hey guys, congratulations. I know it’s easy on release day to say something came out. There was a lot of work here, an awful lot.

Croy: Indeed.

Dumay: Very much so. Thanks.

Shimel: Thank you, James, Tyler, great job. R. Tyler Croy, James Dumay of CloudBees and Jenkins talking about Blue Ocean, the big news around Jenkins and CICD Pipelines. Guys, thanks very much. Hopefully we’ll have you back soon on another DevOps chat.

Croy: Thanks a lot. See you later.

Dumay: Thanks.

Shimel: This is Alan Shimel with DevOps Chat. We’ll see everyone soon on another DevOps chat, but until then, have a great day.

— Alan Shimel
May 2, 2017
DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet

The results and analysis of the State of DevOps Report 2017 report are due out in early June. just in time for the DevOps Enterprise Summit London June 5-6. In this DevOps Chat we speak with Puppet exec and one of our favorite interviews, Nigel Kersten.

Of course, Nigel and the folks over at Puppet have been co-producing the State of DevOps report and survey for six years now. For this year, Nigel along with Dr. Nicole Forsgren and Jez Humble of DORA, will be co-presenting at the DOES London, where they will announce the results of this year’s survey. It should be quite interesting.

Nigel gave us some sneak peeks and early trends for this years report, as well as discussed the DevOps Enterprise Summit and, as usual, some good info on what is happening at Puppet and the DevOps world in general.

You know the drill by now: The streaming audio of our conversation is immediately below and the transcript of our conversation is below that. Enjoy!

Streaming Audio

Chat Transcript

Alan Shimel: Hey, this Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. And we’re happy to be joined again by a repeat guest on DevOps Chat, none other than Nigel Kersten of Puppet. Nigel, welcome.

Nigel Kersten: Hey, Alan. Nice to talk to you again.

Shimel: Good to speak with you. So, Nigel, we’re not talking about the latest and greatest from Puppet today. Well, maybe if you wanna just mention it quickly, feel free, but I wanted to really talk a little bit about the upcoming DOES London event, Gene Kim’s DevOps Enterprise Summit, which is June 5th and 6th in London at the QEII Center, and you will be presenting there. Correct?

Kersten: I will be. Yep, with Dr. Nicole Forsgren, who’s one of the other authors of the DevOps report, and DevOps Enterprise Summit London last year, I think, was honestly one of the best events I’ve been to in this space for a long time and I adore London for lots of reasons, and so it’s always great to be back there.

Shimel: Yeah. And, Nigel, correct me if I’m wrong – is Jez Humble also presenting with you and Dr. Nicole?

Kersten: I think Jez probably will be, but I’m not sure if it’s quite confirmed yet. We’re sort of trying to work out how we’re covering all of the different events, for the various roadshows and webinars we’re doing around the DevOps Enterprise Summits and the DevOps enterprise report.

Shimel: Yep. Okay, so I guess we’ll stand by for final confirmation on that, but, certainly, you and Dr. Nicole will be on, and, of course, Nicole has appeared on our show before and we’ve talked a little bit about not only this year’s DevOps survey but past years’ as well. But, Nigel, for some of our listeners who maybe weren’t lucky enough to hear previous talks about it, this is what? The sixth or seventh year of the State of DevOps survey?

Kersten: This is the sixth year, which is kind of amazing ’cause, you know, I think, when we first started with the fantastic Alanna Brown, who also works here at Puppet, everyone was a bit skeptical about it. I think this was even before you’d started devopsy.kinsta.cloud and people were like, “Is this really a thing? Do we really need a survey about all of this?” but I think it’s just gone from strength to strength over the years. So, yes, I guess, for the people who are sort of new and may not have come across the report before, what we essentially do is we survey a whole bunch of practitioners—we’ve done tens of thousands of ’em around the world over the last six years—and what we do is we ask about the practices and the tools that they use, but also some metrics about “What’s your mean time before failures? How quickly can you deploy your software? What sort of practices do you use?” as well as what sort of outcomes you have. And then we do a statistical analysis on all of that so that we can—and we actually end up showing that there’s a huge gap between what we call “high-performing” IT organizations and everyone else.

And, in fact, interestingly enough, over the last few years, we’ve shown that the gap is increasing over time, so the people who’ve adopted DevOps practices—because, essentially, what we’re showing is we’ve been able to show statistically that what we tend to call “DevOps practices,” around using CI, using CD, using infrastructure-as-code software, doing continuous deployment, using testing, storing things in version control, all of these practices, when you cluster them, are the people—the people who employ these practices are the people who have high-performing organizations. And they’re really huge statistics—they tend to be thousands of times better, being able to deploy just ridiculously faster—and, essentially, what this ends up showing is you really don’t have to sacrifice quality for speed or vice versa, so we’re seeing that these people are both producing high-quality infrastructure and applications and they’re doing it far more quickly than everyone else.

I think one of the things I’m really proud of with the DevOps report is that it’s useful to sell DevOps practices within your organization, so I talk to an awful lot of customers and practitioners out there who are really thankful for the report because it tends to be focused on business outcomes. So, even though we’re surveying practitioners, it’s something that’s really applicable to C-levels and VPs and directors. They can look at this with them and go, “Ah, this is where the industry’s moving and these are the sort of benefits we’ll actually get.”

Shimel: Excellent. And, Nigel, in typical humble Nigel self, you’re—I mean, let’s give a little bit more flavor, if we can. Over the five previous years, I think there’s over 25,000 responses to these surveys.

Kersten: Yeah, no, that’s right. 25,000 over five, six years. It’s pretty crazy.

Shimel: So that does represent a—in a field like DevOps, which is fairly new, right, it represents a sizable amount of people and organizations who have taken the time and contributed to the data that you guys have analyzed over the years. And another important thing, I think, to note for our audience is not only the analysis of the data but even the questions themselves are, from a statistics point of view, a statistician’s point of view, rigorous—rigorously designed and rigorously analyzed. And, look, having a Ph.D. statistician helping you with it doesn’t hurt, but so these are not just some –

Kersten: No, it’s not your average –

Shimel: – go up and doing surveys.

Kersten: – sort of marketing survey at all, and I think this is why it’s always really important for us that—you know, we’re a software vendor and we’re in this space and there’s a lot of people in our space who do pretty fluffy kind of surveys that only take two or three minutes and then some sort of ridiculous claim gets made, so this is why we’ve always been really keen on working with the external parties of Gene Kim, Jez Humble, Dr. Nicole Forsgren. Particularly Nicole. She’s a trained statistician who’s literally got a Ph.D. and has spent her career working on studying organizational performance, which overlaps with DevOps in really interesting ways, but I think having that external rigor, and I think it helps keep us honest as a software vendor. So this is something we really loved, having a partnership with them, ’cause this is their specialty.

They actually—to give them a little bit of a plug, they have their own organization, DORA, DevOps Research and Assessment, where they’ll come in and do benchmarking of your organization and actually measure how you’re actually doing, so I think it’s just really great. We’re clearly really plugged in as Puppet into this whole community, but they plugged in at a different level, and working together, I think, means that we both get to expand reach and bring a bunch of statistical rigor to something that could easily devolve into a self-serving survey, which ultimately doesn’t –

Shimel: Hey, Nigel?

Kersten: Yep?

Shimel: I thought I lost you there for a second. I apologize. Agreed, I mean, on all of the above. And that’s really—I want people to understand that, that this isn’t a marketing survey they up and have done now for six years running. I wanted to make another point, Nigel, and that is, certainly, over the last two years at least, and I would imagine for this year as well, one of the real nuggets of wisdom that have come out of this analysis is really just how high-performing or what high-performing IT organizations mean to the bottom line of these companies that are doing it. I think, at some level, we all at a gut level say, “Well, if you’re performing better, you’re releasing faster, it should translate into a better company,” but, certainly, the State of DevOps report—survey and report is one of the few that are out there that really connects the dotted lines here.

Kersten: Absolutely. So you look into the sort of things that people are actually sort of seeing. What we’re seeing, so to sort of hit some of the boon stats from last year, is that we’re seeing the high-performing IT orgs, three times lower change-failure rate, 200 times more frequent deployments, and 24 times faster recovery from failures. And those are really amazing stats because I think they really resonate, both with practitioners who’re the people who are getting woke up in the middle of the night or having to deal with the pain of a deployment that didn’t work properly, but they’re also the sort of stats that your average, been-away-from-the-technology-keyboard for a few years, high-level executive, can look at it and they go, “No, that’s actually what we want. We want to be able to deploy more frequently,” because, I think, one of the lessons that SAS has taught us is the reason a lot of SAS companies outstrip on-premise competitors is because, every time they deploy, it’s a chance for learning, it’s a change for feedback.

And Agile has taught us, from traditional software development, the more frequently you can deploy, the smaller the deltas are in those deployments and you can do more frequent cost correction, so you can actually produce a much better outcome over time by deploying more frequently and being able to correct course more frequently.

And, to, I think, bring it back to enterprise folks, not everyone always thinks about deployments in this way, but, every time you get a patch from your vendor, that’s another deployment. Every time you respond to a security incident internally, every time you have to follow through a recommendation of your audit and compliance committee—all of those things are deployments and the more pain-free and friction-free you can make the ability to deploy within an organization, the more responsive you’re gonna be to all the different stakeholders.

Shimel: Yeah. Let me give you my favorite stat that you omitted or you just didn’t get a chance to, and that is these high-performing IT organizations have 50 percent less vulnerabilities post-deployment.

Kersten: Yep.

Shimel: That’s huge.

Kersten: It’s a major. And you’re spending less time on that. And I think the other related one that’s really amazing is that the high-performers spend 22 percent less time on unplanned work and rework. And, for anyone’s who’s been neck-deep in infrastructure, it’s the unplanned work that kills you. It’s the context switching. You’re not making progress on your defined road map every time you’re having to spend time on unplanned work.

Shimel: Yeah. So, Nigel, these are all fantastic insights and metrics, so now, of course, though, we’ll turn the table on you and say, “Hey, what have you got for us this year?” I know it’s early; I know you haven’t released the report yet. You’ll probably be announcing a lot of the results, I think, come out just at the time of DOES London, which, again, is June 5th and 6th, but is there anything you can share with our audience as maybe a preview?

Kersten: So I think one of the things that I could share is we’re still going through doing the analysis, but we’re seeing that, again, the high-performing orgs are achieving just as well compared to everyone else, as they have in previous years. It doesn’t look like there’s only sort of peak, as far as implementing these practices. I think the whole industry, even people who have been doing this for a while, have still a fair way to improve.

I think one of the really interesting things—well, there’s two big ones I wanna call out. One is that, this year, we spend a bit of time working on non-profit performance ’cause, in previous years, we’ve shown that commercial companies who are high-performing IT orgs tend to outperform their financial metrics, outperform in the stock market, their internal company goals, but, this year, we decided to focus on non-profit performance, and so we’re looking at things like, “What’s their operating efficiency like? Customer satisfaction? Quality of the products that have been shipped?” So we’re actually, I think, showing that DevOps practices in high-performing IT orgs impact in a positive way all sorts of industries, so I think that’s gonna be one of the really interesting sections.

The other section, I think, that’s gonna be really fascinating is that we’re actually looking at what’s the—there’s a myth out there, to sort of back up a little bit, that DevOps practices tend to work if you’re building all of the software yourself, if you’ve got a web app, if you’re building a whole bunch of stuff in Node.js or something like that, and deploying it to the cloud, sure, you can do DevOps—you can do continuous integration; you can do continuous delivery—but, for those of us who are sitting there running commercial, off-the-shelf software, we can’t actually do that and we can’t actually obtain the benefits that are available by employing DevOps practices. So I think what we’re gonna be showing is that this isn’t true, that there’s a couple of things you can do as an organization, in the way you consume commercial, off-the-shelf software, to actually let you employ continuous integration, continuous delivery.

Now the reality is you’re not gonna be able to test all the same kinds of things because, unfortunately, you know, lots of vendors that release software don’t necessarily have an API-first policy, so you’re not always gonna be able to test everything inside the application, like you can’t run unit tests, necessarily, ’cause it’s not your code, but there are a whole bunch of things you can do. And one of the big bits of guidance that we’re gonna be pushing is that, when it comes to commercial, off-the-shelf software, really try to make the installation as vanilla as possible. Don’t spend forever customizing it. And, if you’re having to customize it because that’s what your business processes say, in many ways, the lower-cost and better-outcome approach is to not customize the software and adjust your business processes because there’s something within your control, generally. And if you adjust those, then it becomes simpler to deploy that software into a CI system, to have Jenkins or Bamboo or whatever do deployments of it, do external black-box testing, make sure that it actually works, and then roll it out to production.

So we’ve got a pretty strong belief that, when it comes to utility computing, to sort of use Martin Fowler’s distinction between utility and strategic computing.

Shimel: Yep.

Kersten: There are huge efficiency gains to be made there, but there’s a few things you can do to avoid those problems. The analogy I kind of come back to is that there was a period, I think, in the late ’90s and early 2000s, when lots of people would customize their Apache installs. They would sit there and come up with this fine-grained list of modules, configured in specific ways, and, every time they deployed a new version of Apache, they’d eke out another one or two percent performance by having this really customized installation. It turns out the actual cost to the business is really great because those tend to be manual processes—you’re turning yourself into a snowflake when you didn’t actually need to be—and I think the more you can commoditize the software you’re buying and that you’re building and that you’re deploying, the faster and more friction-free a lot of these processes are gonna be.

Shimel: Got it. You know, Nigel, that—so I’m old. That’s firing up some old synapses in my brain back from the dot-com days, when I helped start a company called “Interliant.” We were an early ASP. And, mind you, this is before we have a modern cloud and virtualization and ubiquitous connectivity, but we were offering hosted Lotus Notes, PeopleSoft, Oracle applications, Lawson ERP—I don’t know if you remember Onyx was an early CRM tool back then.

Kersten: Oh, yeah. Yep.

Shimel: That’s a blast from the past, huh?

Kersten: Totally.

Shimel: Anyway, so our thought was to offer hosted versions of these applications. This is early, right? We called them “application service providers.” And what we quickly learned in—you know, when you go to market, and we did the whole IPO thing, all of that, but what we learned from our enterprise customers was that, as much as we wanted them to run a vanilla PeopleSoft or a vanilla Lawson or Onyx or even Lotus Notes, for that matter, the best we could hope for was about 80 to 85 percent of out-of-the-box, just plug-and-go. They always needed—and so what happened was we had to change our whole business model and we wound up acquiring a bunch of service bodyshops, for lack of a better word, who would come in and do that last-mile customization, if you will, that last 15 percent. And, as a result of that, I will tell you, the business model failed, ultimately bankrupt. And, if you look at all those early ASPs, none of them really succeeded—USinternetworking and Corio, some others—because we weren’t able to get people to use the vanilla configs that would have been easy for us to host, spin up, and put down.

I think you see the same thing a lot today, with kind of bare-metal hosting. Right?

Kersten: Yep.

Shimel: Versus a traditional cloud virtual, you know, kind of hypervisor thing. How many people are using just vanilla bare-metal kind of config versus how many have—and you guys are Puppet, right? You’re dealing with this more than most, right? How many people are highly, highly customizing their bare-metals?

Kersten: I think we’re seeing people shift away from customization. I think there’s probably a few things. One is I think people are realizing that a lot of this industry is sort of commoditizing, and so you may as well use off-the-shelf stuff. And so, if you’re just consuming stuff the way it was sort of shipped from the vendor, whether it be hardware or software, there’s sort of a general expectation that, I think, both software quality has improved—as much as we like to bitch and complain about software, I generally think software has gotten better than it used to be. There was no sort of Golden Age of incredibly rigorous enterprise software, as far as I’m concerned. I think stuff’s getting better. So I think there’s a couple of different pressures there, is that software’s gotten better, people have gotten more used to the idea that various things are being commoditized, and so they’re more willing to entertain the notion that the next layer up is getting commoditized.

Shimel: Yep.

Kersten: I think we’re also seeing things like—so here’s a good example, I think. If you consume Atlassian’s JIRA, the hosted version, versus the on-premise version, you can’t customize it as much. And, if you’re consuming GitHub the public service, versus GitHub enterprise, you can’t customize it as much. And so there’s a general understanding from people that, you know, an uncustomized version, or as much as is sort of possible, is actually pretty good and we don’t need to make everything completely different for everyone else because it means that documentation just works out of the box and people who’ve used the software somewhere else can join the company and have much faster on-ramp.

And I think we’re seeing that—and this is a somewhat optimistic approach—that there’s a general desire for people to adopt software engineering principles and sort of DevOps cultural changes to get to that higher-performing IT organization state. And I genuinely think, if we keep pushing this sort of attitude out to people that, “If you don’t customize your software, adjust business processes to fit instead, that’s cheaper and you’ll get a better outcome,” I think all of those things combined sort of give me hope that we’re actually heading towards a world where people are giving up unnecessary customization.

Shimel: I hope so. But, Nigel, we’re so far off our course here. You know, we were supposed to be talking about DOES London, and let me try to bring you back. So, I mean, obviously, all of this is background and the—this is why this survey is so important, so that we see these trends and we see it manifest itself in how companies are doing things and so forth. Let me ask a little bit—so, Nigel, you’ve presented at DOES before and I did an earlier interview today—I was talking to one of the program committee’s members for London, Jonathan from Hiscox—and –

Kersten: Ah, yes.

Shimel: Yep. And, forgive me, his last name—Jonathan Fletcher from Hiscox.

Kersten: Yeah.

Shimel: You know, and I’ve known Jonathan for some time—great guy. What we—you know, we forget—all rolled into one place in the space of two days, we’re gonna be jam-packed with all of this great information around DevOps and what we’re seeing and not only what we’re seeing but people are gonna talk about what they’re doing right now and what they did last year versus this year versus next year, what the findings are in our surveys, and I think that’s what really makes for a great event. Right? I think –

Kersten: Yeah, I think there’s a couple of things that are really unique about it. I think one is that it’s not a vendor event, and I’m in the business of working the software company and we make and sell software, but it’s also really refreshing to go to an event where everyone who’s on stage is really there just telling case studies, their real-world stories. They’re not product-pitching to you. We’re not getting up and pitching Puppet Enterprise to you at all. We’re getting up and talking about the DevOps report, and everyone who’s there is—I think this is Gene’s big focus, is that everyone’s telling a real-world case study about what they’re actually doing, where the challenges were. It’s war. It’s honest. So I think that’s one section of it, that it’s real stories from out in the field.

But, perhaps more importantly, it’s not just practitioners. And I think those of us who sort of have had a technical background can sometimes get too in the weeds about going and watching someone’s talk about this incredibly interesting deployment they’ve done and what they achieved, but we’re seeing business leaders talking about the actual impact on the business, how they ran large departments, large transformation projects. You know, the term “digital transformation”’s been kicking around for quite a long time, but we tend to see very sanitized case studies, driven either by a software vendor or a large consulting firm or the PR department of some multinational corporation talking about what they’re doing, and these tend to be really warts-and-all stories, going, “This is what we did and this is how it worked or this is how this didn’t work.”

And I think some of those are some of the more fascinating stories, where people are getting up and talking about “Here were our lofty ambitions and we only got 60 percent of the way there and these were the problems we ran into.” And that, I think, is just really, really powerful, so I think the fact that you’ve got senior business leaders and executives there, as well as the fact that they’re all real-world case studies, is just a really, really powerful combination.

Shimel: Yep. I agree with you. As a matter of fact, one of the things I’d love to see is more people get up and talk about failures, right, where maybe DevOps, they didn’t do it right, or what they could have done differently or what have you, where it didn’t work out right and this is what we did as a result, ’cause I think too many people come out of these events, out of Gene’s things, sometimes, and it’s like it’s all rainbows and unicorns and horses and such, and that’s great, but we—you know, as a dad, I try to teach this to my kids—you don’t always win. And that’s why you gotta learn to deal with failure and how to recover from that as well. And I think those are some of the best lessons for people to learn, is we learn more from our failures than from our successes sometimes, so.

Kersten: Absolutely. And I think it’s hard because we haven’t always had a culture in the IT industry of actually performing postmortems and retrospectives on large projects that we’ve done, so it’s people don’t always have great answers for how they would have done things differently, but I think that’s something that’s actually also starting to shift quite considerably. We’re seeing DevOps has been a big part of that, of “Let’s do blameless postmortems,” and, hopefully, that continues so that we see more people being open about their failures.

‘Cause I think one of the things I find really frustrating—this has happened to me more than once and I don’t think this is gonna identify me, one customer or user, because they do so many of them—seeing your executives at Amazon summits get up and talk about how fantastic their whole cloud migration journey has been and that they’re all in the cloud and everything’s done and it’s absolutely wonderful. And then you go talk to the VPs or directors who are actually running those deployments and they’d be like, “Oh, God, no. We’ve only moved five percent of things and it’s been a miserable failure and we’ve now added three years to the project because we’ve fallen over organizational boundaries.” So I think that gap between the sort of PR-style business leader talk and the reality—that’s not a gap that actually exists at the DevOps Enterprise Summits, which I think’s been really fantastic.

Shimel: Yep. Agreed. Agreed. Well, Nigel, our little 15-minute chat has turned into a solid half-hour, and I think we’re gonna need to call a break here. We are looking forward to the release of this year’s analysis of the survey, looking forward to your presentation along with Dr. Nicole at Gene Kim’s DevOps Enterprise Summit in London, June 5th and 6th, and just always looking forward to what you’re up to and what the folks in Puppet are up to. Many people, you know, when they think DevOps, they think of companies like Puppet, right? A leader in—I don’t know if they’re ever gonna do a DevOps Magic Quadrant, but—or some sort of stuff like that, right? But, I mean, seriously, Puppet’s one of the cornerstones here and you’re one of the cornerstones in Puppet, so it’s always great to hear what’s happening from you and getting caught up. It’s a pleasure.

Kersten: Aw, thanks, Alan. So I will get one little pitch in, which is, because of DevOps Enterprise Summit being in London that week, we’re going to be announcing pretty soon that we’ve got a Puppet Camp happening pretty soon afterwards, so there’ll be a Puppet Camp in London, and this will be a slightly different tweak on the Puppet Camp format. We’ve run hundreds and hundreds of these events over the last few years, but we’re doing a slightly different thing, where we’re having a sort of more executive-manager-focused morning and a more practitioner-focused afternoon. So, if you’re someone who’s an IT architect, you might find mornings and afternoons both applicable, but we’re really looking to try and join together the conversation for sort of senior executive leaders as well as practitioners on the ground. So we’re already collecting a whole bunch of really great talks, both for the morning and for the afternoon, but, for those of you who are into Puppet, look out for a Puppet Camp London coming soon after DevOps Enterprise Summit.

Shimel: All right. We’ll try to get info on that up on devopsy.kinsta.cloud for anyone interested. Nigel, fantastic, man. Thank you so much for the time today. We appreciate it. Nigel Kersten of Puppet here on DevOps Chat. This is Alan Shimel for DevOps Chat. Hopefully, we’ll see you soon at the next—on the next DevOps Chat. Until then, have a great day.

— Alan Shimel

April 26, 2017
DevOps Chat: Hiscox CTO Jonathan Fletcher

Our guest on this DevOps Chat is Jonathan Fletcher, CTO of Hiscox. Jonathan will be quick to tell you that he is actually “interm” CTO. But as I told him in our Chat, if Hiscox is as sharp a company as I think it is, it will make that title permanent soon. I have known Jonathan for about 3 years or so now; I believe it was at a Ranger4 event in London where I met Jonathan. It was readily apparent to me that he was the driving force behind Hiscox’s impressive DevOps transformation.

Jonathan is on the program committee for this years DevOps Enterprise Summit London. We spoke a bit about what it is like to be on the programing committee for DOES. We also spoke about what he is presenting at DOES. You will have to listen or read along to find out.

As usual, the streaming audio is directly beneath, with the transcript of our chat below that. Enjoy!

Audio of our Chat with Jonathan Fletcher

Transcript of the chat with Jonathan Fletcher

Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m very happy to be joined by our guest for this DevOps Chat. It’s Jonathan Fletcher, CTO of Hiscox. Jonathan, welcome to DevOps Chat.

Jonathan Fletcher: Hi, Alan.

Shimel: Great to hear from you, Jonathan. I probably haven’t spoken to you since, oh, maybe DOES London of last year, which was also in late June and –

Fletcher: No, that’s right.

Shimel: Yep. Since that time, looks like you’ve got a new title over at Hiscox. Is that correct?

Fletcher: That’s right. Interim at the moment, but, hopefully, that will develop into a permanent role in the not-too-distant future.

Shimel: Well, if they’re smart, they’ll make you permanent.

Fletcher: A CTO office.

Shimel: Yep. Excellent, John.

Fletcher: Yeah, I think you’re quite right.

Shimel: And well-deserved.

Fletcher: Yeah

Shimel: Well-deserved.

Fletcher: Thank you.

Shimel: So, Jonathan – excuse me – Jonathan, I wanted to speak to you today, though, a little bit about the upcoming DevOps Enterprise Summit London 2017, which is June 5th and 6th, at the QEII Conference Center in London. And you’re actually one of the speakers lined up for the event. That’s correct?

Fletcher: That’s right.

Shimel: And, Jonathan, can you – I don’t know if it’s too early or not, but can you give our audience maybe a little bit of a preview of what you’ll be talking about?

Fletcher: That’s a good question [chuckles] and I’m not sure really sure yet. I think what I’m gonna be talking about is a little about a continuation of our journey, particularly about moving to cloud and what that means, the business results that can be found from doing that, along with sort of where we started and how that changes the IT organization. ‘Cause moving to cloud isn’t just a move of technology; it’s change in skills; it’s a cultural change. It changes things that I hadn’t really thought about, a way we budget, I mean, in fact, from a legal compliance teams. It’s a real transformation program for us. I kind of keep (saying) that savings isn’t IT 1.1; this is IT 2.0. This is a new IT department. So I’m really excited to kind of talk about that. We’ve got a long way to go ourselves, but seen some good early signs with cloud adoption, so I think that’s where I’m gonna focus my time.

Shimel: Fantastic. And, Jonathan, of course, in addition to your speaking role with DOES London, you’re also on the – is it called the “speakers committee”? Is that what it’s called?

Fletcher: Yes, right, programming committee.

Shimel: Programming committee. I’m sorry. Jonathan, can you – our audience, the overwhelming majority of them have not served on the program committee. Can you give us a sense of what is involved in that?

Fletcher: So there are dozens and dozens of people who want to come along and share their story next year, so the program committee really is around trying to filter some of those down – not everyone can come and talk – and trying to make sure they are as much relevant to the audience that’s coming, so I think it was worth reimbursing in last year. it was real stories from people doing transformations at real enterprises, and not unicorns, not ace, but is this a real bank, real insurance company, real companies with a legacy of acquisitions and different types of IT, different technologies, and hearing about how they’ve got on and what they’ve got to do in the future, so that’s really powerful. So program committee’s trying to turn a number of – dozens and dozens of submissions to the program down into a really good, tight sets to deliver over two days in June.

Shimel: I got it. And, Jonathan, I don’t know if you even know the answer, but can you give our audience a sense of how many submissions versus how many speakers are actually selected for an event such as DOES London?

Fletcher: So I’ve seen a bit of pre-filtered list, so I couldn’t speak on Gene’s behalf how many there were, but I’ve seen hundred – in the hundreds, I guess. And I think that’s down to 30-something; again, I don’t wanna get the numbers wrong, get the (incorrect) stats, but it’s significant amounts and significant amounts of people that Gene has conversations with, I guess, _____ _____ _____ _____ get through to a formal submission, so it’s very significant, which I think is a really good thing. Obviously, people are seeing a value in DOES London and wanna come share their stories, so it’s a shame not more people can do it, but it’s only those two days.

Shimel: Yep. Absolutely. You know, and I have some ideas around that I’m gonna talk to Gene about. But, Jonathan, was there any – obviously, the DOES, the Dev-Ops Enterprise Summits, traditionally focus on large organizations, “horses,” as we call them, telling their transformation story. And some of these stories we’ve now seen and followed over multiple years and we’ve seen that transformation evolve. Were there any particular themes or things that the committee wanted to really bring out for this year’s event?

Fletcher: I think it’s lot of different things. I think a – in terms of sense of continuity between last year’s and this year’s, so what are the results that we’ve seen, in terms of transformation and – that seems to be a bit of a theme. To share that continuity _____ _____ years is quite an interesting thing to look at. The theme, obviously, is try and – the _____ tend not to be technically focused, so we don’t have too many groups talking about technology, more about the people and process of things. So I think a lot of what you’ve heard last year, the same kind of thing, but, hopefully, just seeing people a bit further along the journey, where they’re going to and the challenges that they’re running into.

Shimel: So, Jonathan, this – you know, I’m gonna attend this year’s DOES London event, and this will be the, man, the fourth or fifth DOES that I’ll be attending. And, though I think I’ve come to – I think all of us have come to appreciate hearing the transformation stories of these various organizations, bigger picture, in order for DevOps to continue to grow, right, what else needs to come to the forefront at conferences like DOES, other than “Hey, we tried to do this DevOps thing and here’s how we’ve done”? Do you think at some point we need to hear more than that around DevOps?

Fletcher: Sorry, what do you mean?

Shimel: So, in other words, at this point in the game, depending on who you believe and who you listen to, a majority of enterprises have at least dipped their toes in the DevOps pool, if you will. Not many of them have undergone an enterprise-wide transformation, but at least they’ve started along their way. What more – so, in other words, what is there beyond the “We’ve tried to transform the company” type of lessons that the DevOps community needs to learn from these events? Or maybe there is nothing more.

Fletcher: That’s a good question. Well, I don’t know. It’s a difficult question to answer, really, ’cause it depends on the strategic direction for those companies and how far they need to push the barrel. I mean, not everyone needs to release 400 times a day _____ _____. You know, the different companies got different requirements. And I think, really, DevOps is such a all-encompassing term now that it’s kinda lost its meaning. If your company is about improving quality or that’s your strategic goal, rather than the pace of change, there are different things for different people, so dipping your toe in the water is fine. I think DevOps is for everyone, regardless of scale of company, so those focused on enterprise, well, that doesn’t mean that, if you’re a small shop, that’s not relevant to you ’cause it is.

I think, really, it’s such a wide topic that seems to encompass Agile and Lean and technology and people, and it’s so vast in topic that, actually, the next step for people in the transformation program ought to stop worrying so much around necessarily what other companies are doing. The war stories are good, but it’s focusing more on what that really means to your company. It’s no longer about DevOps transformation; it’s about business success transformation and what you need to get to get you there. So I think a bit of maturing thinking from companies that started on this program is really actually what they tried to achieve and where they need to get to because I think there’s an assumption between certainly some people aspect where it’s all about Puppet and getting 4,000 releases out the door, and that’s not always the case. So _____ _____ big business goals and I think really trying to realize some of the results so that the business benefits ’cause we’re doing this not because it’s cool and it’s _____ cool IT; it’s because there’s tangible business benefits in doing it. And I think that’s really what the community needs to focus on and _____ –

Shimel: Yep. And I think you’ve — Jonathan, I think you’ve hit that right on the head and that’s just what I was looking for, which is so many people, especially in the IT industry – I don’t know what it is about the IT industry, but we suffer from “shiny trinket” syndrome, right? Where everyone wants to latch onto what the new cool thing is. And the risk you run is that, when the luster is off of the trinket, people tend to start looking for the next trinket, instead of doing what makes sense for the business, what’s best for the business. You know, ’cause to my mind –

Fletcher: Yeah, exactly.

Shimel: Right?

Fletcher: It becomes a – go ahead. Sorry.

Shimel: No, no, go ahead. I’m listening.

Fletcher: Yeah, it becomes a little bit of a statistics race, like, “How fast can I get a release out the door? How many servers can one person look after?” And, actually, that’s fairly meaningless, unless there’s a business benefit behind it, so that sort of arms race to be the fastest becomes less and less relevant, so. And, as I said, DevOps is such a wide term now that it kind of – it’s just about doing IT better.

Shimel: Yeah. And that’s exactly it. I mean, Jonathan, to me, in my many, many years in IT and in business, there’s very few revolutionary things. There’s more evolutionary type of developments, right? And, when we look at DevOps, we look at the Agile that came before, right, and we see kind of where Agile is and its effect, but yet we still see plenty of organizations that are doing waterfall or some may call it “fast at waterfall” or “Agile waterfall” or whatever you wanna call it. But, you know, it’s a very – the inertia in our systems is such and entropy in our systems is such that nothing moves – we don’t move at the same speed across. And even something like DevOps, though you may have organizations that are now presenting for the third or fourth year at a DevOps Enterprise Summit, there’s still plenty of organizations that are still just starting on that journey, and they will be on that journey for many years going forward. And I think we lose perspective of that when we live in this bubble of “Who’s releasing the most often? Who did this first? Who’s on to the next thing?” That’s not who wins the game, necessarily. People who win the game are organizations –

Fletcher: Well, and –

Shimel: – and their customers. Go ahead. I’m sorry.

Fletcher: And some of these things are – all these things are less relevant, so, if you’ve got a system you’re gonna throw away in two years’ time, there’s – ROI to spend tons of time automating it and putting all that engineering in place with, you know, sort of – is kind of mothballed. So, again, it’s picking the right application, the right teams, to get benefit from this. I don’t necessarily see the – you have _____ all of these other _____ everywhere. Waterfall has its place. It’s about picking what is right for the business and getting the business _____ _____ _____. It’s not about a blanket “This is a right way or this is a wrong way of doing IT.” I just don’t believe that.

Shimel: Mm-hmm. I agree with you. And so, Jonathan, we’ve come full circle in our short little chat, but this is what makes DOES a great conference to attend. Right? Where we are hearing these transformation stories, and some of them may be old hat to some of us, some of it may be a revelation to others. Right? But it’s – the last part of this that I wanted to hit is that it’s, at the end of the day, it’s about the community. We as a collective community learn from each other’s experiences and these shared experiences, and that’s how we evolve and that’s how the whole movement moves forward, not just Hiscox, not just Disney, not just any particular organization, but as an industry, as a movement, that’s how we move forward. And then I think that’s what DOES is about.

Fletcher: Yeah, and that feels fairly unique. I can’t remember, in my 20-odd years of working IT, a movement with such a community feel, with so many people who want to help other people, and it’s – I think that’s amazing. And I don’t ever get – when I speak to people much further down the line than we are and they do better things then we do, I never get that looking down their noses or “You should be where we are.” It does feel like a real community sense of being, that everyone’s gonna help each other. And I don’t know what it is about DevOps, but I think that’s amazing, and you really see that at DOES.

Shimel: Yep. Absolutely. Jonathan, we’re about out of time here – probably, we’re over time – but, listen, I wanna thank you for joining us today on DevOps Chat. I look forward to hearing your presentation at DOES London and we’ll check in before then and get more of a final version of what you’re speaking about. And, also, I wanna thank you for being on the program committee. I’ve been on organizing in program committees of events in the past and I know it’s, in a lot of ways, an unsung job – you don’t get paid for it and God knows there’s ton of work that goes into it – so thank you for your service.

Fletcher: You’re welcome. Thanks very much.

Shimel: No, my pleasure. And, Jonathan, I’ll get together in London beyond that. Maybe we’ll catch up on a video or something. Hey, but continued success. I hope, by the time I see you in June, the interim title’s gone. They couldn’t find a better man or person for that job. All right?

Fletcher: Thanks, Alan.

Shimel: Cheers, Jonathan. Jonathan Fletcher, Hiscox and the program committee at DOES London 2017. This is Alan Shimel for DevOps Chats and devopsy.kinsta.cloud, and we’ll see you on another chat soon.

— Alan Shimel

April 24, 2017
DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

OK, I admit it. Thinking of Maslow’s Hierarchy of Needs and DevOps doesn’t seem like an obvious connection. But Omed Habib of AppDynamics gives us the connection of how Maslow’s theory applies to developers and DevOps people. Because after all, they are people too, right? Right?

Anyway, this is a great conversation that I think you will enjoy. As usual the streaming audio of our conversation is below and the text is below that. Enjoy!

Alan Shimel: One, two, three. Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on DevOps Chat is Omed Habib from AppDynamics. Omed, welcome to DevOps Chat.

Omed Habib: Thank you, Alan. Pleasure to be here.

Shimel: Thank you. So, Omed, I would imagine most of our audience is already very familiar, at least pretty familiar, with AppDynamics. You guys have sort of become just a huge success in the APM market, though some may call what you guys do not exactly “APM”—I’m not even sure if AppDynamics calls it “APM” anymore—but, nevertheless, company that’s had tremendous amount of success. What’s your role at AppDynamics?

Habib: Well, I originally joined AppDynamics as a product manager. My first couple of years, very proudly brought our PHP, Node.js, Python APM agents to market. And, as of a couple years ago, I joined the product marketing team, so I’m now helping lead the strategy behind all of the outbound product responsibilities.

Shimel: Sure. So, Omed, in simpler times, just three, four years ago, it was easy to put AppDynamics into that sort of APM bucket, if you will, but that’s not necessarily the case anymore, is it?

Habib: You know, the term “APM” itself, like you said, is starting to put into question. What AppDynamics does, at least in my opinion, is very simple. I think what is becoming—the definitions that are changing right now are the processes within the software environments and where AppDynamics plays a role or, rather, where AppDynamics—sorry, APM as a concept plays a role. Historically, we’ve had divided teams, right—operations are responsible for production monitoring, and so they would have the production-monitoring tools; developers had their siloed environments—they would ship their code—and so they had their decouple tools.

But what we’re starting to see now is a shift in runtimes becoming far more sophisticated, and the barrier to entry to production is so much lower now that developers and operations—I’m gonna introduce a whole new term; we call it—it’s not new, but I’m just gonna call it “engineering teams,” “application teams,” are now responsible for the entire software development life cycle of the product, so developers are now deploying code; operations folks are now responsible for not just the infrastructure and the production monitoring, but also they’re starting to look at everything from an application perspective, versus an infrastructure perspective.

The other thing that I’m noticing, Alan, is that we’re starting to see far more abstraction here of the infrastructure and the deployment models of applications. In other words, teams are no longer responsible for spinning up servers and configuring hardware and configuring the specs behind the infrastructure. All of that’s becoming abstracted, and so it’s causing—again, I’m not gonna call it “dev teams” or “ops teams” because I see these two teams merging, I’m talking, five years, maybe possibly in 10 years, possibly even sooner than that, down the line. I’m just gonna call it “engineering teams.” Engineering teams responsible for the application, the product itself.

And I see these roles starting to merge. We’re starting to already see _____ the ops responsibilities. You know, Google’s introduced the SRE role, right? The site reliability engineer. And the nature of that role is someone who comes from a developer background, facing the challenges of operations and the idea behind that is to have a developer mindset of “How much of this can you automate using code?” And so they’re trying to solve—again, it goes back to the abstraction idea, right? Everything becoming abstracted. So what they’re essentially trying to do is automate as much of the infrastructure as possible so that, end of the day, a developer can do what they do best, which is checking code and work on features and work on the backlog.

What we’re seeing today, right now, is the crossroad of development teams starting to take a step back and realize that, “Hey, what the heck is going on here? We have this giant backlog full of features and we’re doing nothing but putting out fires all day long. We have bugs; we have performance issues; we have database issues; infrastructure issues.” Right? So if you were to look at it—[chuckles] it’s kind of funny. I get very Maslowian here, but if you look at Maslow’s Hierarchy of Needs, right?

Shimel: Mm-hmm.

Habib: I’m getting kind of philosophical here, but I got a point. [Chuckles]

Shimel: No, no, go ahead.

Habib: Maslow’s Hierarchy of Needs, essentially, states that everybody, every human with a purpose, goes through this journey, but they have to go through levels, and it starts with the foundational layer, right, into the second layer and a third and fourth layer. But the very top of that pyramid is what they call—what he calls “self-actualization.” And self-actualization is when you, as a human being, as a person, you get to actually do what you were on this planet to do, where you solve for everything else—shelter, security, your social needs, your physiological needs. And so you get to a point where you say, “Well, what is it that I was here to do to begin with?” Right? And so you get to actually work on the things that are larger purpose of you as a person.

Developers, I’ve noticed, are actually going through a Maslowian hierarchy. The very premise, the very foundational premise, of what they do is their toolset—their development environments or sandbox environments, their pre-production environments—and so what we’re noticing here is that developers are starting to go through their own Maslowian-style pyramid, in that the foundation of the pyramid, essentially, is a development team solving for their proper development environments, sandbox environments, embracing a DevOps culture, ensuring a pragmatic, iterative software-dev life cycle, ensuring for proper infrastructure, making sure that they have the proper monitoring tools in place. And so, as they continue to move forward and advance from one layer to the other, they no longer have bugs in production, they’re no longer solving for bad code being shipped, because they’ve already solved for that. Right? The teams that have not are stuck at the bottom of the pyramid, and the teams that have advanced forward are hitting a point of self-actualization.

And so, if I were to draw a parallel with Maslow, I’d say that developers—development teams, applications teams—today, have hit a point of self-actualization, which essentially says, “Well, what are you actually here to do?” And what you’re actually here to do, as a development team, is to work on moving the business forward—work on the backlog, work on the features. And what are those features? Those features come from a road map and have been prioritized, from business strategy perspective. So you’re essentially getting your development and engineering teams back in line with what they were there to do to begin with, which is “Now let’s start to move the business forward.”

From a philosophical perspective, that’s what DevOps was to begin with, right? That’s what developers and operations teams are hired to do to begin with. Unfortunately, because of the lack of sophistication in the tools and the processes, what we’ve seen in the last few decades is that, developers and engineering teams and operations teams, they’ve been stuck in this rut on the first foundation of that pyramid or the second level of that pyramid. And it’s change blindness, right, from a psychological perspective. It’s, when something happens, some kind of change happens, so slowly over time, you don’t notice it whatsoever, and so you start—you eventually start seeing these development teams accept. Unfortunately, they’re trying to accept their roles as, “Yeah, I just fix bugs all day long.” Right? “I just put out fires all day long.”

Shimel: Yeah.

Habib: [Chuckles]

Shimel: And you –

Habib: That’s because you’re stuck at the bottom of that pyramid.

Shimel: Yeah. And you know what? It’s funny you say that, Omed, because I’ve been in technology, oh, 25 years, and so we used to call it “They’re working in the sausage factory, but they really don’t know how we make sausage.” Right? And this happens. I see it in software’s life cycle and supply chain, where everyone kinda does their job but they don’t realize how their job is part of the larger picture. Right? If someone’s just stuffing meat in the sausage machine, in the back of the sausage machine, but they never see what the sausage looks like when it comes out or what it tastes like, it’s very hard for them to imagine or to empathize with the guy who has to eat the sausage. And, all too often, that happens, especially in software development. I’m sorry to say, but –

Habib: Yeah, no, you’re absolutely correct.

Shimel: Yep. So –

Habib: What’s funny is that not only is the pyramid very similar to how software developers evolve, but Maslow also said that, if you’re stuck at any one of the foundational layers or, for example, if you don’t even have the foundation, that actually goes into the symptoms of what a person experiences. For example, if you don’t have a roof over your head and you’re constantly worried about the elements, right, the symptoms of that is gonna be anxiety and paranoia and discomfort, right? Development teams—I mean, you can draw the exact same parallel and say, “Well, if you don’t have a proper DevOps environment, then the symptoms of that are gonna be X, Y and Z,” right? Anything that is lower than self-actualization is gonna have symptoms, and those symptoms, obviously, are bugs in production, application issues, the backlog growing ever so bigger without you actually even touching it, technical debt increasing, so on and so forth.

But it kinda reminds me—when you talk about the guy that works in the sausage factory, it reminds me of the famous story of the three—I might butcher the story, but it’s the three workers that were working on a cathedral. A passerby comes by and asks the first person, “What are you working on?” and he says, “Oh, I’m just—I’m working on this stone and I’m just hacking away at the stone.” And then he goes to the next person and says, “What are you working on?” He goes, “Oh, I’m just working on this wall, and it’s something that’s gonna be used on this home.” And he goes to—and, by the way, all three of them are doing the exact same thing.

Shimel: Mm-hmm.

Habib: He goes to the third person. He says, “What are you working on?” And he says, “Can’t you see? I’m working on a cathedral.”

Shimel: Hmm.

Habib: So, when you’re at the bottom of that pyramid, you lose sight of what you’re doing to begin with.

Shimel: Got it.

Habib: When you’re at the top of the pyramid, a point of self-actualization, right, where you’re supposed to be to begin with, where you’re supposed to be doing what you’re actually supposed to be doing, then you begin to realize the big picture. When you realize the big picture, then, as an engineering team, you are realigned back to the strategy of the business. And self-actualized engineering teams understand not just what they’re working on and how they’re working on it but also why they’re working on it. And with that comes the additional responsibility of, “Well, if you know why you’re working on it, then how do you measure success?” ‘Cause you already measured success at the bottom of the pyramid, for your application, but, if you’re now at the top of the pyramid—and, as a self-actualized engineering team, you’re not just measuring the success of the application, right—performance of the application, the technical performance of it—but you’re also measuring the success of the business performance of your application.

Shimel: Sure.

Habib: And that is what we’re starting to see today. A lot more engineering teams who are moving to the top of that pyramid are now getting reintroduced to having a seat at that table of “Hey, I’m not just a software developer. I’m not just an IT cost center. But I’m a partner in the business strategy behind this application.”

Shimel: Yep. “And I deliver customer satisfaction.” Fantastic. This was a great—great conversation, Omed. Very insightful. Unfortunately, well, we’ve gone way over our time, but we’ll deal with it.

Habib: [Chuckles]

Shimel: Omed, we’d love to have you back on at some point, though, ’cause our audience is so developer-centric and ops-centric too, but “tech-centric,” I guess, is a better word, that I’m sure they identify with this, and I’d love to continue this conversation. So perhaps we’ll –

Habib: Yeah, it was a pleasure chatting with you.

Shimel: Yeah. We’ll find some time and do it—do more of it. Or maybe you wanna write about it on devopsy.kinsta.cloud. We’ll talk about it offline. Anyway, Omed Habib, AppDynamics, thanks for being this episode’s guest on DevOps Chat, and thank you for everyone listening, and we’ll see you again on another DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud.

— Alan Shimel

April 19, 2017
DevOps Chat: DOES London 2017 Speaker Jose Quaresma, Accenture

In anticipation of the DevOps Enterprise Summit (DOES) London 2017, we are interviewing a series of the announced speakers who will be appearing there. The first in our DOES London 2017 speaker interviews is with Jose Quaresma of Accenture. Jose is a leader at Accenture and has a lot of knowledge on real DevOps transformations. I think you will find this conversation very enlightening.

As usual immediately below is the streaming audio of our chat, followed by the transcript of our discussion below. DOES London 2017 is shaping up to be another great conference. Also as usual, we will be live on-scene with coverage.

Alan Shimel: Hey, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is Jose Quaresma—and I probably messed that up, but Jose is with Accenture, and he’s based over in Denmark. Welcome, Jose—how are you?

Jose Quaresma: Thank you, Alan. I’m pretty good. First of all, thanks a lot for having me. I would say it’s quite an honor to participate in this chat with you.

Shimel: Oh!

Quaresma: Oh, and yes—and by the way, you got the—

Shimel: Well, flattery will get you everywhere.

Quaresma: [Laughter]

Shimel: But we’re talking a little bit today, and it’s regarding, you know, the second annual DevOps Enterprise Summit London is coming up June 5th and 6th at the QE2 in London, and you will be presenting there, correct?

Quaresma: Yes, that’s correct—yeah.

Shimel: And I wanted to—well, before we get into your presentation at DevOps Enterprise Summit, why don’t we give people a little bit of your background?

Quaresma: Sure. I can give it a quick try. So, as you said, I’m Jose, and Quaresma is the last name, so you actually did pretty well, Alan. And I’m originally from Portugal, but I’ve been living in Denmark for almost eight years now. I kinda moved in here to study, and kinda after university, then I started Accenture here in Denmark as well, which I’ve been for around three and a half years now.

I am an Application Development Associate Manager in Advanced Technology in a subgroup called Advanced Technology and Architecture, and I am the DevOps lead for Accenture Denmark.

Shimel: Excellent. And Jose, as part of that, why don’t—any particular engagements of interest that you can talk about right now?

Quaresma: Yeah. So I had, I can say, so, there were two main engagements that I’ve been involved with, and the first one was actually not so much involved in DevOps. I kinda started more as a middleware developer and kind of then walked towards the kind of web service design and team lead on that middleware area, and there was some DevOps work related there kind of with deploying the web services. But that wasn’t really something that I was driving.

But then around two, two and a half years, I kind of, it was actually, my manager—and I guess I have to thank him for that; thanks, Jarom—he kind of, he was the one kind of guiding me towards, “Okay, we have this kind of DevOps domain getting a bit more traction, and we would like to, how would you like,” it was actually asking, “How would you like to lead that domain and try to raise a bit more awareness of DevOps here in Denmark?”

So that was an interesting opportunity that I saw and yeah, from then, I was also then transitioned to a new project, which is actually the project that I’m going to co-present at DevOps Enterprise Summit now in London in June, and I’m co-presenting that with Amin Budali from Nordea, and that is the client that I’m currently working with, and this is a huge project. So Nordea, for the ones who don’t know, it’s a huge Nordic bank, being active in Denmark and Sweden and Norway and Finland. And this is, the project is about replacing their core banking application across the four countries. So it’s a huge project, a five-year project where we are working on replacing the core application with a new T24 application provided by Temenos. And that—

Shimel: Go ahead. Go ahead, Jose.

Quaresma: —and then that’s where kind of the more, it was, the DevOps, it has been very relevant now in this project, and the main thing is that, what we are, the part that we are presenting at DOES now, it’s, as I was saying, it’s not really a finished story, I would say it’s a story that has started around one year ago and we already have some interesting successes that I’m happy to talk about, but it’s hopefully a story that will have one, two, three more years until we have this very successful destination that I’m hoping I can come back to, to the DevOps Enterprise Summit and talk about that in one or two years. That would be great.

Shimel: That would be great.

Quaresma: Yeah, and that’s something I hope for, and I work for as well.

Shimel: So I’d like to ask you, Jose, for our listeners out there who maybe are listening and saying to themselves, “Man, I sure would like to present one day at a DOES, you know, a DevOps Enterprise Summit or a similar thing.” Can you give our audience maybe a little bit of background on how it came to be?

Quaresma: Yeah. I can try. So, it was actually, we have, this all kind of started with, we have a DevOps Week internally in Accenture as well, and in that internal DevOps Week, which was maybe one or two months ago, around there, maybe one month ago, we were actually, I was—I got to present this kind of, a little bit this story as well together with the client at our kind of internal DevOps Week.

And then the idea came, from that point on, it’s like, “Oh, we actually have, there’s this really amazing conference in London. Why don’t we just try, maybe?” And we did have—I confess, we did have some doubts whether we would get in, and I think the main part is thinking that, okay, we don’t actually have this beautiful, happy ending story yet. We’re still struggling, we’re still halfway through our journey. But then, also, reading through the description, we saw that these kind of ongoing journeys are also welcome at the conference, so we thought, “Well, let’s write down the things that we have learned and what we would like to present, and then let’s see if they think that will be interesting.”

Shimel: Got it. And sort of, you know, I think that’s a great description of the process and everything. Have you spoken at other events, Jose?

Quaresma: No, not really. Not at this magnitude. I’ve given kind of more internal presentations and also outside Denmark, but not really, not an event of this magnitude. So yes, I’ll be pretty nervous. [Laughter]

Shimel: What? There’s nothing to be nervous about. I’ve always found that as long as you are fluent in what you’re going to speak about, as long as you’re comfortable with that, you know, whether it be a big audience, a small audience or have you, it’s all the same, really.

Quaresma: Yeah. That’s a good point. I’ll take that with me. And not only being fluent, but also that, I think it will help that I will be talking about something that I’m really excited about and that I’ve been working hard for, so I think that will make it a little bit easier.

Shimel: Got it. You know, one of the things I wanted to talk to you about is, you know, working for Accenture, you—a little different than working for just a single company in that you work with multiple clients, right, and so that gives you a chance to see sort of transformational issues, you know, across multiple organizations.

Quaresma: Yeah.

Shimel: Where a lot of people, you know, they work at Disney or they work at NBC Universal or they work at a company and sort of very much—and even at jeans events like the DevOps Enterprise Summit, it’s very much, “Here is my company’s transformation story.”

Jose, having looked at multiple companies’ transformations, what do you think you can share with our audience that sort of transcends any one organization, right, and go into multiple ones?

Quaresma: Yeah, there’s—so, one thing is, I won’t lie to you or the audience. I mean, this is the first big DevOps transformation that I’m involved with, so I can’t really kind of pull out of my hat kind of the 10 transformations that I’ve been involved with and share some kind of overall wisdom on that.

So this is definitely an advantage that I see and that I hope to use more in the future once I kind of, as you say, keep getting the experience of several different transformations in different clients with different scenarios, when you kind of—once you’ve started getting more experience with all those different transformations, there will always be things that are different, then I hope I can kind of learn from that and be able to extract some knowledge from those differences as well.

Shimel: Sure, sure. Jose, we’re almost out of time. As I promised you, it goes really quick. But let’s talk for a moment about, and this is something—so you did it, when you started your career and, you know, you said you’ve been in Denmark now eight years. Certainly it wasn’t to do DevOps transformations and so forth, but where did you come from to get to here, kind of, if you know what I mean?

Quaresma: Yeah, and that’s a pretty tough question. So, it’s kind of, my background is mostly on security and also related with—so my Master’s was actually called Security in Mobile Computing, and then I also had a, after that I had a Ph.D. in network security, mostly related with formal methods and how to kind of analyze the security of a communication protocol.

But I think the, kind of my career evolution, if—[Laughter] I never thought about it like that, but if you can say that, it has been pretty, I would say pretty organic. I mean, I have—it’s not like I’ve been forcing myself or have this five-year plan that I think, “Okay, in five years, I wanna be there.” It has been mostly about doing the things that I kind of enjoy doing and that I can see that I’m providing some good value, and also following the interesting thing.

So, for DevOps, it was actually that, before it was my work, it was already kind of a hobby in that I was at home outside working hours playing around with some Docker setup and trying out some different technologies there, and then I think that also made it easier to bring that to work, because if it’s something that I’m excited about also outside work, then it was even easier to just bring that excitement and motivation for something that I do in my everyday life.

Shimel: Excellent. Well, Jose, I’m sure you’re gonna have a great presentation with the bank at DevOps London, DevOps Enterprise Summit London, and we’re looking forward to seeing you there.

Quaresma: Yeah.

Shimel: And thanks for being our guest on this episode of DevOps Chat as well.

Quaresma: Yeah, thanks so much, Alan.

Shimel: Thank you, and continued success, Jose Quaresma of Accenture, who is a speaker for DevOps Enterprise London 2017 on June 5th and 6th, our guest today on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Thanks, everyone, and have a great day.

— Alan Shimel

April 17, 2017