The DevOps Enterprise Summit (DOES) is coming to London at the end of June. DOES London boasts an incredible lineup of speakers and presenters. One DOES London speaker is Ann Marie Fred, who will be presenting, “Compliance and Audit Readiness: The DevOps Killer?” In this DevOps Chat we caught up with Ann Marie to find out more about her presentation.
As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation:
Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud and we’re here for another DevOps Chat. Today’s DevOps Chat is one of a few we’re doing as a run up into the DevOps Enterprise Summit in London coming up later in June.
Our guest today is a featured speaker at the DevOps Enterprise Summit (DOES London). It’s Ann Marie Fred of IBM, and Ann Marie, of course, I’ve forgotten your title because it happens but would you mind sharing with our audience?
Ann Marie Fred: Sure. I’m a Senior Engineering Manager and I work in the commerce platform so that’s IBM’s commerce engine for selling things online.
Shimel: Fantastic. And Ann Marie this is not your first time speaking at a DOES event, correct?
Fred: That’s right. I spoke in 2016 in San Francisco and I really loved the conference: I had a great time and I learned quite a lot there so I’m definitely looking forward to London.
Shimel: Fantastic. So Ann Marie you know I always ask this of people who if you haven’t been to a DOES event and you’re into DevOps or you want to be into DevOps or so forth it really is such a great camaraderie – it’s a great place to be. And for me it’s really about two reasons. Number one, I think the presenters or the speakers at DOES are second to none. You get really, you know, really great insight into real DevOps transformations at organizations throughout the world and whether it be a so-called vendor like IBM or even Electric Cloud or Tasktop or one of these or a practitioner in a large – as Gene calls them – horse – you know a large enterprise, not a unicorn – it’s fascinating to see.
Because even organizations like IBM so much of their own DevOps offerings are based on eating their own dog food – on their own DevOps transformation, if you will. You know what I’m saying?
Fred: Absolutely. So yeah, we teach other people how to adapt DevOps but we’re also constantly learning ourselves and it’s great to sort of be together at a conference with people from other large companies who are running into similar problems.
Shimel: Yep. And you just hit the second thing. Beyond the great speakers the camaraderie of being able to network with people who have similar problems to you. And I think that goes right to the nitty-gritty of human nature, right? You know, not misery loves company but we like to understand we’re not the only one who are facing these challenges or thinking about these particular ways of doing it and it’s great to hear from other people who in similar situations are doing really interesting things.
And I think that’s really – that really is what I think makes DOES I think a special conference.
Shimel: Yep. That being said though Ann Marie your talk in London this year is entitled “Compliance and Audit Readiness the DevOps Killer.”
Fred: That’s right. It does have a question mark after that but –
Shimel: You know, I’m sorry. The DevOps Killer? I’m giving my inflection. But tell us what exactly do you mean with this one?
Fred: Yeah, well, you know we always had compliance and audit readiness as a thing that we care about but with the run up to GDPR we had to put a lot of focus on it. And in addition to GDPR we sort of took that as an opportunity to make sure that we had our ducks in order with other things like accessibility, IT security, open-source checks.
You know, the thing that we always tell people they should do – they wanted us to get to the point where we’d actually documented in a consistent way how we were doing them. And so it was a lot of work.
Shimel: Well, I mean just – we have some folks on listening who are not up on GDPR but obviously GDPR is the privacy and personally identifiable information rule that is EUI but really when we say EUI because the world is so interconnected it’s going to affect almost everyone. And it goes into affect May 25, so by the time you present at DOES London we’ll already be one month into the official rollout of GDPR.
So to be fair Ann Marie people have known about GDPR and when it was going to go into affect and what was in it for going on two-plus years now, correct?
Fred: Mm-hmm. Yep. Yeah, I was going to say I think it took a good year for us to start to figure out what the implications of the thing were.
Shimel: And you’re not alone – you know, a good year. I think, believe it or not – you know we cover a lot of DevSecOps whether it be on devopsy.kinsta.cloud or on our Security Boulevard site and I think there are a lot of people who even right now are a month out and are saying, “Gee, we better get serious about this,” you know? So a year isn’t so bad.
But let’s talk about – first of all – let me back up a second. You know what? Some people still view compliance and readiness almost as separate and apart from traditional security, let’s call it, and as we were talking about it off mic in my mind I’d love for us as a whole – as a world – to move to the point where compliance readiness, cybersecurity are really intertwined with quality, right? If you’re releasing quality software, quality applications, quality services it’s compliant by design and compliant by practice. It’s secure by design and secure in fact. And until we get to the point when this stuff is part of our quality I don’t know if we’ll ever be successful. What do you think about that statement?
Fred: For us? Yeah, exactly. For us part of this whole initiative was – I mean we use exactly those terms, right – secure by design – and what does it mean to be secure by design and what is an example of what you would do to be secure by design and are you doing that and would you sign a document stating that you feel like you’ve done what you need to do to be secure by design?
So we’ve done a lot of prep work, I would say, and like best practices sharing to make sure that we’re not all inventing the wheel here, you know?
Shimel: Well, let’s be fair. I don’t want to take credit for the term “Secure by Design” either. I think that comes right out of the GDPR and your reference to people having to sign off that it is secure by design that’s also in the GDPR, correct?
Fred: Yep. Yep. And you know you have to have it documented somewhere so we all have these compliance folders. Yeah, so a lot of my talk is about how do we get from knowing nothing about GDPR and having pretty poor documentation in some cases to a state where we’re confident as a company signing legal agreements with other companies saying that we’re GDPR compliant ourselves, right?
Shimel: Yep. So Ann Marie we’re talking about ten minutes and its time to really now – let’s zero in on this talk you’re giving. The DevOps Killer. Why is it the DevOps Killer?
Fred: Well, it takes time to document all of these things and it takes a lot of manual effort the first time you do it. And one of the challenges that’s unique to DevOps and continuous delivery is that unless you make a special effort you might not even know what all the services are in your organization, right?
Shimel: Mm-hmm.
Fred: If people can just spin up a service in the cloud without a second thought have they told anybody that that service exists so that you can ensure it’s compliant, right? So that’s kind of step one. And then it’s almost inevitable that it’s going to be manual the first time but how do we make sure that we don’t have to rerun the entire manual check every single time we deploy the software? You know, how much of this can we actually automate?
In some cases we can actually write tests for these things, so – because nobody really wants to keep paying that manual price.
Shimel: No, for sure not. For sure not. So one of the things – I was talking to someone yesterday or the day before and I mentioned that one of the things we seemed to have moved away from in DevOps – and I’m glad we did – was the frequency of release and the speed, right?
So, “I release 12 times a day,” “Oh, I’ve got you beat. I release 25 times a day,” “I release 100 times a day. And somehow the more releases I did a day the better at DevOps I was.” Right? And always said speed kills, you know? And what’s the right speed or the right release rate for your organization – whatever it is, right? And that is very different than the next organization.
So in my mind it – yes, not just compliance but security in general can be a drag on release velocity, if you will. But there are good drags and bad drags, right, and it’s interesting, we did a survey a while back Ann Marie and you know developers – when we filtered it by developers – developers said, “What’s the biggest drag on getting your releases out faster?” They said, “Security,” overwhelmingly.
And then the next question was, “Do you want that drag? Or in essence is that drag the right thing to do or what do you count on to ensure the quality?” And they said, “Security.” So sometimes being the drag but making sure things are done right and compliant and no one’s going to wind up – you know, the fines on GDPR are pretty stiff – is just part of the business cycle that we need to figure into things.
Fred: Yeah. I mean we compared – internally we compared GDPR to __2K problem – the Y2K problem – that’s what I mean.
Shimel: Yeah, __2K is another one.
Fred: Yeah. But the Y2K problem. And we had to investigate every single service that we have and figure out which ones process personal data – and it’s a pretty broad definition of personal data – and then for each one of them make sure we’re compliant. And then now that we’ve done that once how can we still continue to deliver changes to production? I mean, yeah, some services are managed to deploy several times a day and some are every other week but nobody wants to redo the entire audit every time, so what processes can we put into place to make sure that we just don’t break things?
You know, usually it’s a combination of every time you have a new feature here are the questions you have to ask yourself. And every time you do a code review here are the questions you have to consider, right? And then that combined with some regular reviews – maybe annually, for example – is I think the most pragmatic way to ensure that you’re actually doing what you need to do.
Shimel: Absolutely. And you know that’s a good word to use when we think about compliance and audit and time drag – it’s about being pragmatic. Another concept Ann Marie that I heard – where the heck was I? – I think it might have been – I was out at the RSA conference about two weeks ago and we were doing a panel on Dev Sec Ops and stuff and the concept was sort of minimal MVP, right – Minimally Viable Product – Minimally Viable Security – so, look, there’s a pragmatic balance to be struck in terms of how much testing, how much security we do prior to release but we’ve got to at least define what’s the minimum that is going to keep us above water and understanding that in a DevOps way even after we release we can iterate feedback loop and iterate and continue to improve our security and compliance and audit readiness, you know, and that’s part of DevOps too, right? It’s never fully baked: you’re always continuously improving.
And so the concept of a minimal viable compliance and audit readiness posture that would allow you to green light something being deployed versus 100 percent is something to consider. What do you think about that?
Fred: Right, exactly. I mean you could take this to the extreme and you could say, “Every single place where an IP address – which is by the way personal data – shows up in my system it has to be encrypted in a way that the data can never be decrypted again.” You could say that but then you wouldn’t be able to maintain your system, right?
Shimel: Yeah. It would be a monster.
Fred: Right. So, okay, that’s not the right answer. So now it’s about, “Okay, what controls do we need to put in place to make sure that a random person off the street can’t get our logs?” and that that information is protected enough that we don’t think we’re going to get hacked and if there was an attack on our system that the scope of it would be very limited and they wouldn’t be able to do much with the data that they got, right?
So yeah, it’s all very – there’s a lot of judgment involved in this and what’s your risk tolerance?
Shimel: Agreed. So Ann Marie believe it or not – I told you the time goes really quickly – we’re coming up on – well, we’re probably past our 15 minutes – so we’re going to need to kind of start tying a bow on this.
For people listening – and they’re listening to this before GDPR is in affect – it’s not too late. But for those who have just procrastinated too long what’s the best advice you can give them right now?
Fred: Whoa. Well, I guess I would say don’t be afraid to start, right?
Shimel: Right.
Fred: It’s better to do the best you can –
Shimel: Than do nothing at all.
Fred: – than to be completely overwhelmed and say, “I can’t even think about how to start on it.”
Shimel: And you know what? That is excellent advice though because that is the problem. So many people get paralysis by analysis, right, or they’re just so – you know, they look at this monolithic GDPR and all the articles and everything and they’re like, “Oh my goodness, we’ve got so much to do.” But it all starts with the first step. And from what I’ve been told Ann Marie no one – the E_U is not levying any fines or anything any time soon but you’ve got to start somewhere.
Fred: Yeah. If I were to say, you know, two things that we expect quickly – I think just basic IT security – like having basic IT security processes will cover you for quite a lot of it. And the other thing we expect to be hit with very quickly is the data subject access request –
Shimel: Yep.
Fred: and deciding how you’re going to handle those requests because they’re going to come in fast and furious I think.
Shimel: Yeah, I agree with you. And, you know, I think you’ve just got to get started with it.
Anyway, so we’ve got that Ann Marie. You are speaking – in case anyone going to DOES is interested they can find it – I think DOES has published the entire schedule now – but you’re speaking on Tuesday, June 26?
Fred: Yep. That’s right.
Shimel: And I think it’s out in – at 2:35 PM which is 14:35 over in the UK and in Breakout Room B as in boy. So anyone listening who’s going to DOES come check out Ann Marie’s talk at DOES London and maybe say hello afterwards or before.
Ann Marie I’m sure it’s going to be a great talk. We’ve heard you speak before. And thanks for joining us today on DevOps Chat.
Fred: Yeah, thank you Alan, it’s been fun talking to you.
Shimel: Absolutely. Ann Marie Fred, IBM and a DOES London speaker here on DevOps Chat. You’ve just listened to another chat. We’ll see you soon. Until then, have a great day everyone.
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.
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.
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.
On the heels of our latest DevOps Enterprise Summit London speaker and programming announcement, I had the pleasure of being joined by Tom Clark, head of Common Platform at ITV;Andrea Hirzle-Yager, head of Department, IT at Allianz Deutschland AG;Mark Schwartz, CIO and author of “The Art of Business Value” and “A Seat at the Table“; and Mayank Prakash, Chief Digital and Information Officer at Department for Work and Pensions for a live video chat—already our third installment for 2017! We huddled up for an hour and took a “deep dive into DevOps,” as my fellow panelists shared keen insights into their technology transformation experiences and leadership lessons learned from pioneering DevOps adoption in their own organizations. And as you’ll find out, these are all such great people!
Clearly, one of the responsibilities of technology leaders in DevOps transformations is enabling a culture of continuous and lifelong learning. In fact, this characteristic is one of the more profound conclusions after having seen nearly 200 leaders share their stories over the past four years. And holy cow, if there’s a great time to learn, it is now; personally, I can’t overstate how much I’ve learned since co-authoring “The Phoenix Project.” (For example, in Dr. Steven Mayner’s DOES16 San Francisco presentation last year, he confirmed that this seems to be a critical element of successful transformation—you can see what we learned about the role creating a culture of learning and transformation plays in successful Agile and DevOps transformations.)
These were among several questions that I had to privilege of asking Andrea, Tom, Mark and Mayank.
What will you be presenting on this year?
What can you share about what’s happened in your own journeys since 2016?
What can you tell us about your DevOps journey and technology transformation?
Can you tell us about where you decided to start, and why you chose there?
It’s been observed that DevOps transformations are easier in smaller organizations—what are the toughest obstacles that you’ve overcome as leaders in your journeys?
What are your favorite lessons learned that you think would be applicable for all leaders endeavor in to do similar things in their organization?
What are your favorite resources you look to (past and present) for leveraging the best practices and principles—this could be in the form of research, books, events, articles, etc.
Can you share you impressions of your two days at DevOps Enterprise Summit London last year?
It was fantastic hearing the specific lessons they’ve learned in their journeys that they thought would be applicable for all leaders doing similar things in their own organizations. It was interesting to hear how books and conferences play such a critical role for them, as it has for me—and I always love getting a glimpse of the bookshelves of technology leaders, because certain books keep keep showing up up again and again
Be sure to watch the video replay of the chat—there are some great nuggets of information about where these leaders are in their own transformation journeys and what you as DevOps Enterprise Summit attendees can expect at the event this June.
DevOps Enterprise Summit London Update
Plenty has happened since our previous live video chat with Jonathan Fletcher, Cornelia Davis and Jonathan Smart. The programming committee has made its final selection of speakers to round out the conference program, and we’re in the final planning stages for the event this June. One item on the agenda that I am particularly excited about is the “Ask the Speaker” portion of the program. This year, we are opening up an hour of time each day of the conference for question and answer sessions between our plenary speakers and conference attendees. It’s going to be a great way for attendees to pick the brains of the folks just coming off of the main stage.
Additionally, we have added another format (tested during DevOps Enterprise Summit San Francisco last year) that we called “DevOps Workshops.” These are small-group discussions using the Lean Coffee format, with a small army of trained facilitators at each table.
We’re expecting a phenomenal turnout for each of these sessions and we’ll have some world-class people helping to lead the discussions. More to come on that soon!
Want to join us in London this June? Save 20% on tickets using code “DEEPDIVE20” today!
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.
As adult learners and leaders, we tend to glean less from theory and seem to derive more from people actually describing the real-world problems they are trying to solve. Ever since the DevOps Enterprise Summit began in 2014, we’ve been adamant about providing a unique venue for the technology leaders of large, complex organizations to come together and share their DevOps transformation experiences—from how they started and what they did, to what the outcomes were and what they learned.
On the second video chat gearing up for DevOps Enterprise Summit London 2017, programming committee members Cornelia Davis (Pivotal), Jonathan Fletcher (Hiscox) and Jonathan Smart (Barclays) joined Gene Kim and spent an hour taking a “deep dive into DevOps,” to reflect on the first DevOps Enterprise Summit London last year. Panelists also shared some of their lessons learned and wisdom about their own DevOps transformation stories today and shared some of their favorite resources for leveraging best practices and principles while discussing the value of lifelong learning.
Just a reminder that Early Bird ticket pricing for DevOps Enterprise Summit London 2017 was extended to 22 March and the price is only £650+VAT. Register here >>>
All in all, it was an excellent conversation with Jonathan Smart, Cornelia Davis, Jonathan Fletcher, and Gene Kim as we all inch closer to the DevOps Enterprise Summit London this June. The goal (according to each of these people who are now on the programming committee for London) is to hopefully make the show even better than it was last year. We look forward to seeing all of you June 5-6 at the QEII Conference Centre.
Here is the video and a full transcript of the conversation below that. More links to DOES videos and interviews are down at the bottom. See you London June 5-6!
Gene: Summit 2017 in London. This conference is taking place on June 5th and June 6th. For more information on this, just go to events.itrevolution.com. I think what excites me so much about the DevOps Enterprise Summits is that there is just, no doubt in my mind, that the people who are presenting are the leaders and practitioners, who are pioneering how we’re managing and using technology in large, complex organizations. So on this Live Chat, we have Jon Smart from Barclays. We have Jonathan Fletcher from Hiscox, Cornelia Davis from Pivotal who’s also…In fact everybody is on the programming committee.
So my goal next hour is to have each one of you share what you’ve been working on, share some of your lessons learned and wisdom which is just, obviously, a fraction of what you’ll be presenting at the DevOps Enterprise Summit. So just one last reminder is that there’s an early bird ticket pricing that ends on the 8th of March, which is one week from today. So the next step is really to share what wonderful speakers that we have on the panel today. So let’s go around the table, and if each one of you could present your name, your role, company and, specifically what you presented on last year. Cornelia, why don’t we start with you?
Cornelia: Sure. Good morning, good afternoon, everyone, and, hi, Gene, and my fellow panelists. My name is Cornelia Davis. I am the Senior Director of Technology at Pivotal, and so Pivotal is a company that maybe is most well known for incubating the Open Source Cloud Foundry Project, and my role is that I work in the product organization. I work with clients and customers to take our products and use them effectively. Well, it turns out that our products are really disruptive.
It’s very different architecture and so they have to change everything. So that’s where DevOps and digital transformation comes in, is they actually have to in order to use our products effectively, they have to change organizational structures and you have to change processes. And I have this tremendous opportunity to work with very large enterprises across the globe, in then figuring out how that works for them.
Gene: It often can be very disruptive to the way we’ve done the thing for decades, absolutely.
Cornelia: Oh, yes.
Gene: Jonathan Fletcher, why don’t we start with you? I wanna go to you next and, by the way, congratulations. I hope you’re gonna tell us about your promotion, as well.
Jonathan: Yeah, so I’m Jon Fletcher. I am the interim CTO for Hiscox Insurance. Based out of offices around the world. I’ve been the CTO for a month, five minutes, it seems. So, it’s fairly new.
[Crosstalk]
Gene: Can we stand by a second? We’re having some audio issues. Let’s go to Jon Smart while we resolve that. Jon?
Jon: Hi, Jonathan Smart. So I work at Barclays. My role is Head of Development Services and I’m leading on better products faster, so better ways of working, adoption of agile dev ops, lean principles, and practices across Barclays.
Gene: Brilliant, and what did you present on last year?
Jon: Last year, I presented an Experience Report. So I gave an update of the Barclays journey across the whole organization. We started two years and two months ago, beginning in 2015, so last year, I gave an Experience Report, shared some of the lessons we’ve learned in terms of transforming a large organization. We are 130,000 people in 40 countries. We have 48 million customers.
We’ve got some main business lines such as the investment bank, retail bank, wealth, corporate. So we’re a very large organization, as I said. We’re 327-years-old, founded in 1690. Four years before the Bank of England existed so that’s a lot of legacy to change and it’s a large organization. So I shared our journey so far, and I’m looking forward to sharing an update this year, as well.
Gene: Brilliant. And I think one of the things that just left such an impression on me was just the scope of what you’ve been overseeing in terms of how many engineers and how many applications?
Jon: It’s 26,000 staff in technology and over 3000 applications.
Gene: That’s awesome, fantastic. Thank you, Jon. All right, Jonathan Fletcher, let’s go to you. Name, company role and what you presented last year, and you’re gonna to tell us about your promotion. And then we’ve gotta unmute.
Jonathan: I am the interim CTO of Hiscox Insurance. I’ve been in that position for about a month. So I’m not exactly seasoned, but I’m doing it so far. I’m really excited to be part of this and speaking in DOES in June. So I’m looking forward to that.
Gene: Awesome. And then you presented last year?
Jonathan: I did, yes. Sometimes it’s on our move to DevOps and a bit of my personal journey starting as a solution architect four or five years ago, and how I got involved, and how the whole thing started to happen, and I hope this year to carry on talking about that journey and where we are now.
Gene: Very good. Thank you. So why don’t we go to a little bit about the conference and your impressions on it? You know one of the things that many people have told me over the years is that DevOps Enterprise Summit is structured differently than most typical technology conferences that we go to. And I think many of us are, actually almost professional conference attendees. Would you mind sharing your impressions of your two days at the DevOps Enterprise Summit, London, last year? Jon, why don’t we start with you?
Jon: So what I really like about it is that it’s peer-based, so it’s people who are doing the job of transforming organizations and that’s what I like about it. It’s people sharing case studies, sharing their real experience so, you’re learning firsthand. It isn’t a series of sales pitches. It’s about people who are doing the job. Specifically in the horse is not the unicorns. I’m shy of horses, rather than the unicorns. People who are not born Agile, but are born Waterfall. So that’s what I like about it.
It has great networking opportunities, as well, with people who are going through the same journey. And also it’s interesting when you sit through a number of the case studies, you start to see the common themes emerging, and pretty much every single time, the main theme that emerges is it’s all about people. And often with DevOps people jump straight to the tooling and they don’t think about people and culture, often, but it’s all about people. So it’s great when you see these themes coming across from many different companies.
Gene: That’s awesome, and I’ll maybe just comment on that. I mean I think that’s one of the reasons that we choose very deliberately to have people share Experience Reports. Just because as adult learners, as leaders, we tend to learn less from theory. Instead, we learn from people actually describing the problem they’re trying to solve, what they did, where they started, what were the outcomes, and what did they learn. Jonathan, how about you?
Jonathan: I’d echo much of what Jon said, actually. So I like the fact that the very little of it is technical. So very people, focus, culture, process-based and I love being the least smartest person in the room. So it’s watching to learn from lots of other people. I think lots of DevOps conferences are very technical, although, they’re very at the beginning of the journey.
So being surrounded by other people that are at least where we are, if not further ahead. For me, it was a great learning opportunity and I can remember coming away reinvigorated about what we’re doing, and I guess hiring because you were pushing against people that, necessarily aren’t aligned to your way of thinking. So it’s just to get that we are doing the right thing, and we are going the right direction. That was really fantastic. So I really enjoyed those couple days.
Gene: Awesome. Cornelia.
Cornelia: Yeah, it’s all of those themes, but there’s some interesting…As you know, Gene, I work with you on the Programming Committee, have been in the U.S., and now this year in London, as well. I wasn’t at London last year, but we did something in the U.S. last year that we’re going to bring to London this year, and it’s really just an exemplar of what we’re talking about here. It’s a programmatic way of really fostering that peer-to-peer collaboration.
And so last year in the U.S., we did these lean coffees where we had this structured format where we got people together at round tables and had kind of a facilitated way of sharing ideas, and it was fantastic that the tables that I sat at, it was literally an hour-long period. And I think everybody at the table got three concrete takeaways of, “Oh, that’s a technique that I wanna try.” And so as you know, Gene, we’re talking about bringing that type of a format.
It’s not just conference sessions. It’s that type of a format to really foster that collaboration and that’s really very different from a lot of conferences these days.
Gene: Yeah, and I think both Jonathan and Jon will be joining the Program Committee starting this Friday. And I think one of our goals is, you know how do you create the conditions where those serendipitous interactions, how do you maximize the opportunities for the interactions that lead to learning, right? And part of that from a program perspective is we do both the talks, but also creating session formats like that. So one of the things that I’m just delighted about is that the conference will be featuring both Jonathan and Jon, again, sharing the continuation of the journey both at Hiscox and at Barclays.
What I love about this is it’s something that most conferences actually don’t…it’s actually quite unusual, right. But, for me, it seems like this incredible opportunity where we’re almost documentary filmmakers following these leaders, as they go through their own journey and we get to learn as they learn. So you’ll both be presenting for the second time. What can you tell us about what’s happened in your own respective journeys since you presented in 2016? Jonathan, why don’t we start with you about the Hiscox journey?
Jonathan: So last year, I talked about our starts with DevOps, and I guess the point of my talk was that I don’t think we’re really doing DevOps. We’re doing bits of Agile, and continuous delivery, but I think that’s really what DevOps is trying to solve. So there’s lots of stuff with testing in automation and application teams, but really I think the real nirvana is when we bring the Ops side into the equation. So in the last year, we’ve been doing a lot of stuff with cloud.
We’ve been doing a lot of stuff with talking around how we move to a more Agile operations team, rather than a sort of ticket-based system and doing projects in a Waterfall way. So trying to get some of those concepts that we’ve learned in an application mode into the operations teams, and the challenges of doing that, and how we get those two linked together so we can minimize and help the flow of feedback that goes through development into operations systems. This is the final bit of that journey, I guess.
Gene: And you could you talk a little bit about how the change in your role, maybe even going back, I mean how do you think the work that you did in terms of pioneering some of those practices at Hiscox, how did that lead to your change in responsibilities, and how does your change in responsibilities allow you to do more or less going forward?
Jonathan: So I started as a Solution Architect. So actually nothing to do with DevOps at all, and it was kind of just was born out of frustration. I was like, “We’ve gotta change the way we do stuff because this is daft.” So it’s coming in with a great new focus which, again, most DevOps translation started quite small which we got an application, and we did some automation around it, in terms of scale and CD and some automated testing. And then we saw these successes of that and went towards something else, and then it’s just kind of ballooned over the years. And, I guess, we’re really starting to see some of the business payback for that and that’s helped me.
I get more visibility to be seen as someone that’s trying to be more strategic, in terms of how as an insurance company we maintain a competitive advantage. And I think that this step to CTO is sort of the logical conclusion is to help to see that journey through. It’s helped me because now I’ve got a lot of guys rather than influencing up the chain over time, but other peers of mine are direct reports so that that’s gonna help…not that it’s a dictatorship. But it’s going to help my influence and ability to do that, as well as having own budgets and ability to spend some money on that.
Gene: By the way, conclusion sounds so terminal, Jonathan. Let’s not hope that’s the conclusion…haha!
[Crosstalk]
Gene: A continuation perhaps.
Jonathan: A continuation, yes!
Cornelia: I love what you said about Agile operations team instead of tickets. So instead of tickets, it’s so huge. It’s such an important part of DevOps, and it’s all about empowerment, right, but empowerment still in a safe environment.
Jonathan: Yeah, absolutely. I love that. And I think there’s a technology problem there as well. I think it’s very difficult to align the types of tooling that develop as you’re using along with the ops guys that also want to have things like, ITIL based processes and a change management database, and trying to get that transparency across the whole value stream is quite difficult. So that’s one thing I’m kind of wrestling with at the moment.
Gene: That’s great. Jon, how about you? Yeah, what has changed in your journey since you presented back in June?
Jon: So knowing why you’re doing this is important. So why is any company doing DevOps, adopting DevOps and why are active products faster with delighted customers and colleagues, better, faster, happier, safer? And so taking a broader definition of DevOps, in terms of better product, faster, safer, happier we’ve increased our adoption across the organization. As I said, we’ve been doing this across the whole firm for two years and two months.
If you go back two years and two months, it was a relatively small percentage of our change work was done with these practices and principles, and now we’ve got a fairly significant percentage of our change work now being done with Agile and DevOps and Lean principles. So in 2016, we’ve carried on that at-scale adoption, and we have done it apace. We have something like, rough order of magnitude, something like 15,000 people who are now working with Agile and Lean principles, and practices who weren’t two years ago and important to get the ball rolling.
It’s important that we do it with control in a highly regulated environment where as we know the impact of attitude is significant. And so we’ve also been focusing on control because we want both speed and control. Sometimes people might think that you can’t have both speed and control and people might think that speed is at the cost of control, but actually, it’s quite the opposite. You can do anything badly. You can do fragile or you can do Agile, and actually an Agile approach and a lean approach increases control. So we’ve been putting quite a lot of effort in 2016 into control, as to both we are balancing by speed and control.
Gene: Cornelia, you had a question for Jon.
Cornelia: Yeah, I do. So, I thought it was very interesting that you said it’s been two years and two months. So that’s a pretty specific date/time period. What was the catalyst? What was the starting point? What defines as two years, two months as opposed to roughly two years ago? Was there a specific event?
Jon: Well, maybe I’m speaking from my personal perspective. It’s roughly two years. It’s roughly two and a half years and, specifically, what any organization needs to do this successfully, it needs both top down and bottom up. So the specific event, this was a catalyst, in our case is with new leadership and new leadership saying, “Agile and lean is the way to go,” and then the natural champions in the organization, like myself, we put our hands up, “We volunteer to help move the needle.”
Gene: Okay. I mean so in other words, this signal of support from upper management is kinda what you mark as the real start of the journey, right, where it was now a sanctioned, important activity.
Jon: And it was articulated, formally as part of our strategy, yes.
Cornelia: And that is something that I see across, again because I get to see across a lot of different enterprises that are all on a similar journey and that’s not at all unusual. When we have new leadership that comes in, sometimes new leadership that’s brought in, specifically to shake things up, that is often kind of the defining moment where things start to change.
Jon: Yeah, and like I said, absolutely, mandatory criteria to be successful across and organization, you’ve got to have that top down support, as well as the bottom up community. You’re gotta have those two things.
Gene: By the way, I love the number that you put out, in terms of 15,000 engineers working with Agile principles, just to calibrate. That’s actually the size of the Google engineering organization in 2013. So it’s just amazing to see what happens when you can elevate the productivity of engineers that it’d impact that many people. Jonathan, you had a thought.
Jonathan: Yeah, Jon, I was really interested, you were talking about control. Barclays is a fairly massive beast. I was thinking with your move to Agile. How did you have that control at the scale that you’re operating in? I mean lots of Agile teams work very much, almost as a silo, themselves. They’re in back of their work how to orchestrate such a large transformation in such a large company.
Jon: The main principle has been to start with what we have now. So we clearly are operating in a highly regulated environment. We’re not starting from a clean sheet and working towards what we have. We’re starting with what we have and we’re iterating to improve control effectiveness. A starting point was a Waterfall lifecycle, and I’ve spoken about this at the last DevOps Enterprise Summit. We had NT8 mandatory artifacts, many hundreds of questions, and it was a very un-lean process, and it was evolved over time, multiple input, probably from multiple audits and multiple control findings, and so on.
But it became really catered to the lowest common denominator, but applied to everybody. So what we’ve been working on is improving the control effectiveness and leaning the process. So it’s more as a greater risk sensitivity now. So if you’re doing something which is, say, for example, an internal system, nothing to do with payments, no client data, it’s purely…I dunno…a seating map, for example, then it’s risk sensitive. So the controls that will apply to that are in line with our control framework.
Something that is to do with payments, some has client data, the control implications are much higher. The main thing is it isn’t a lowest common denominator for everybody. The thing is applying Agile principles, we’ve moved it to be more of an early and often conversation with our control professionals. So, previously in a traditional manner, you deliver something and we had a control engagement at the end, just before you’re about to put it into production.
And then that leads to another three months to six months of unplanned work, in a reactive manner is what we observed in some cases. So instead we’ve got long-lived controlled tribes, multi-disciplinary long-lived association with the customer value stream, and then you have a conversation at the beginning, and you have regular small conversations as you go, so there’s no surprise at the end. And there isn’t an end because it’s a long-lived product with regular deliverables.
Gene: That coincides with the regular audits that happened, right, the compliance reports. That makes a lot of sense.
Jon: Exactly, exactly. Exactly, the control effectiveness is stronger because you’ve got that regular interaction and the regular looking at an actual product that you’ve actually got something tangible to look at.
Gene: Just as a little side note that we have a group and, hopefully, you’ll be joining us, Jon, from MarkSoft, Capital One, and others, just really trying to help bridge that gap with compliance professionals using their terminology, using the design control effectiveness language, really to show that you know DevOps people aren’t crazy. In fact, you end up with better control effectiveness working all the time. So that’ll be a very fun interaction. I’m very excited about that deliverable.
Jonathan, one of the themes that have come up here is that wonderful things happen when you’re surrounded by fellow travelers who are facing the similar types of challenges and kind of the learning that can ensue. I actually had the privilege of observing one of those sessions that you and I were talking in, and you had a conversation with Scott Prugh who’s the VP of Development and Product Operations at CSG. They’re one of the largest bill printing companies in the United States, and the topic was how do you overcome some of the traditional challenges, how you get more traditional IT operations organizations on board. Can you share some of the challenges that you’re grappling with and some of the insights that came out of that conversation because it was absolutely amazing to observe?
Jonathan: Yeah. So in terms of our org structure, Hiscox a fairly federated business. So we have a number of British units aligned to countries around the world. Application testing teams tend to be aligned to their business units, but operations infrastructure is a group resource that delivers against all of those operations, all those departments. So what we’ve been wrestling with really is how do we or do we maintain that? Do we align infrastructure operation teams to a particular country or do we continue to measure out of a group resource? And if we do that, then how on earth do we have a backlog where we’ve got so many different stakeholders with different requirements, different projects?
And how do we prioritize amongst all those different business units and how do we still get projects done? How do we still get BAU done? I guess the questions that any Agile team has, it’s just on a much grander scale. So each business unit is operating independently. I don’t really care what some of the other business units are doing as much as it’s about their P&L. They want to first bust at the cherry. So does that mean then that BAU goes off to the side and we stop patching because there’s continued focus on projects? So there’s some of the sorta challenges we usually went over with Scott.
Gene: Yeah, mute button. And what was just some of the insights that you had or at least, maybe even validations of the problem? Specifically, how do they inform your thinking?
Jonathan: So I think what was quite interesting is listening to Scott’s talking about visibility of work in progress. And some of the frustrations there are between development operations is because both of them are almost black boxes. So a developer might say, “Look, I need an environment and it might go into a ticket system” and it goes from the server guy towards the SAN guy, and the storage guy, and it goes around in little circles.
How can we let the developers know what the ops guys are up to, and conversely, how do we let the ops guys know what developers are doing? So how do we get that work-in-progress highly visible and that, as a starting place, would be a good way of beginning to address some of the prioritization issues because they’re working off completely different backlogs. The left-hand does not know what the right hand’s doing. How do we start to make that happen? So that was a good sorta first head’s up from him, just to go and look at that problem.
Gene: All right, in fact, I think he’s spoken a lot about trying to get more and more of the ops work into the same work systems as development. So in their case, it would JIRA, and so forth, and less the remedy and so forth, right, just to have a single prioritized work unit.
Jonathan: Yes, but that’s pretty hard. And who’s gonna be a natural tendency for projects to trump everything else because that’s what a business is asking you to do and we’ve gotta change out the door? But you still need to make sure things are patched, and security’s done, and I really like that sort of conversation where you start to allocate points in a sprint, so that’s BAU and that’s projects. If you don’t do that it becomes a very difficult way to triage and prioritize stuff that’s coming because like BAU is gonna be on a loser.
Gene: Cornelia, as coming from a development background, I think you’ve observed something very similar in your journey.
Cornelia: Absolutely. And one of the things that’s really interesting that we found very effective is to take the same product-oriented mindset that the application teams have when they’re building and delivering their products, and actually have that same mindset at the operations and at the platform level. So that, instead of it being treated as just unplanned work, work that comes along, now it comes in, we have to prioritize it, they start to treat their offerings as products themselves. So that they do things like measure…they have a backlog of additional features that they wanna create.
They have release notes that say, “Hey. We’re patching the system on this day” or “You have the opportunity to apply your patches because the patches are queued up and ready to go.” And so really shifting that product mindset, all the way deep down into what’s kind of traditionally an infrastructure kind of role that tends to be a little bit more order cook-ish, and really transforming that into a menu-driven, “Here are the offerings that we have.” Of course, you can’t get rid of all of it, but that’s really, really powerful, is a product oriented mindset, even at that deep infrastructure level.
Jonathan: I think you’re entirely right. I think the mindset, yes, I think the practical application is more difficult. So if you build an environment, for example, you need a server person and a SAN person, and a storage person, and there are lots of techology-silos. So what isn’t very practical is go and take all of those resources, and go and stick them in a dev team because your Agile team’s gonna be 400-people strong all of a sudden which is not ideal. So I think I get the mindset implication or, I think, the technical implementation of that, I think is a bit harder.
Cornelia: Yep.
Gene: Jon, I can’t imagine that somehow Barclays is exempt from some of these issues, as well. I’m guessing that this has relevance, at least in some areas of the organization for you.
Jon: Yeah, absolutely. This really resonates. I think if you go back and my own personal experience, you go back about 20 years ago and, specifically, that’s when banking, we used to do all the roles. I was a developer. I did the analysis. I did the development. I did the support, and I sat next to the customer or the partner and we did everything, and over time, we’ve gone from a role specialization and the split between kinda ops, run, and build, dev. And so, yes, this absolutely resonates.
Generally, for Barclays, coming from a generally Waterfall approach prior to two years ago with islands of Agile, I’m looking at this topic, we’re looking at how we get closer to you build it, you run it. But still maintaining regulatory compliance around segregation of duties, Sarbanes-Oxley Compliance. But as we’ve discussed, the run specialists, the operational specialists, utter the feedback with the build and the dev specialists need to all be lined up behind the customer. And, obviously, what happens when you’ve got operations, you’ve got run who are working in their own world.
The feedback loop never gets back to the dev team, so developers need to feel the pain. I like the SRE Site Reliability engineering philosophy of hiring engineers into ops roles because when you put engineers into op roles, things tend to get fixed kind of at the root cause, rather than a band-aid, rather than a short-term fix. So we are absolutely this is a high priority for us, especially in 2017 to try to increase the feedback, and get more to being one team. But to Jonathan’s point here, we can’t do that with everybody in every role. So yeah, there’s going to be the product teams and there’s going to be secondary teams, and that’s absolutely something we’re trying to move the needle on.
Gene: Jonathan.
Jonathan: Yeah, I think when you start, I think, cloud for us changes that. When the infrastructure guys start to use the same processes, and tooling, and approaches that the developers do, then I think that becomes a lot easier. So I’m trying re-push infrastructure as code at the moment, and I think that is the way of really breaking it down. If infrastructure is just another software project, that becomes really easy to put into that Agile team with the application team. If you’ve got a mix of traditional, “I’ve gotta go and plug a server into a wall. Then I’ve gotta go and configure this” that doesn’t really fit in with a normal Agile team.
And you’ve got a guy was talking to me earlier, he wants to order new servers, six to eight weeks, and then we’ve gotta go and get finance approval for it and. “I think I’ll do this.” That’s not gonna fit in that tight feedback loop that Agile’s trying to work with. So, for me, it’s about transitioning some of the infrastructure skills into more software-led skills, and that’s where you’re gonna get that much closer alignment. That’s where you’re gonna get the DevOps cultural start. That’s where it is. I think trying to do in on-prem, in a manual way is kinda of a bit of a recipe for disaster.
Gene: I think the best people that really embody this is Jason Cox from Disney. His title is Senior Director of Systems Engineering at Disney and he’s talked tirelessly about how he’s tried to create, embed those ops, talent and engineers into the lines of business, into the dev teams, really helping them do things on-demand, and it’s been amazing to see his own journey over the last four years. Just a little joke here.
You talk about infrastructure is code, Jonathan, I love how Scott Prugh from CSG, he said, “The ops of that is infrastructure’s tickets” which is actually what we don’t want, right. We want those on demand. Let’s go to Jon, and one of the just tantalizing pieces that you had talked with us there at Prep Call, just before this panel was the Lean Portfolio Management work that you’ve been doing and how that’s become your newer areas of focus, and I think all our ears perked up about that.
Because of I think this realization that all of us have had over the years, is that you can have fast iteration loops within the dev test operations stream, but if you have an annual budgeting cycle and annual planning process, that really sets some very hard limits on how Agile you can be. Tell us about what you’ve been working on.
Jon: Yeah. So, as you say, we can have as much agility as we like. We can be practicing DevOps. We can have great continuance delivery, but it’s a local optimization when you look at the system, think a system’s thinking and a theory of constraints to deliver better products faster and with delighted customers and colleagues, it’s gotta be end-to-end agility. And so I think this is a natural evolutionary thing, having made some pretty progress, I think in the last couple of years, in terms of how we do what we do.
As we start to expand out in the theory of constraints, look at what the next constraint is. As a large, complex organization, we’re starting from the position of annual planning and annual budgeting, and that doesn’t give us enterprise flexibility as much as we would like. So this is a focus for 2017 for us, is to move to more of a courtly rolling wave type approach, more of a hypothesis-driven investment approach, more of a focus around outcomes, not a predictive plan. So once a quarter you said, “This investment should have achieved these outcomes. Has it?” And being able to build more agility into the system of work holistically.
Gene: Yeah, Jon, I’m dying to ask you. So I think the way I was trained there’s kind of two planning processes, right? You have the project budgets, right, which are owned by the business which tend to be…they can go up and down quite quickly. Whereas then you have the annual shared services budgets, right, where you tax every person, right, 2% of revenue or whatever, and then you a create work queue that’s prioritized, and maybe it’s not a good year now, maybe you’ll get it next year or the year after. So has your focus been primarily on the project on the business side? To what extent can you translate that to shared services?
Jon: So, that’s a good question and I think a caveat to what I said, as a public-listed company, we will still have an annual process. What we’re trying to do is we’re trying to push the courtly rolling wave, portfolio-management process as far…We’ll start at a certain point in the organization and then we’ll try to push it as far up the organization as we can. So that, basically, within our budgetary constraint whether it’s a business investment, you used the word project, whether it’s a business investment or whether it’s a shared service, irrespective of that, you treat it, your budgetary constraint, it is a constraint, and you wanna maximize the value on it.
So you would do it, you know my view is that we do it in both because, as well as about financial flexibility and being about to move money around, it’s also about de-risking delivery and getting away from the sum cost fallacy for a shared service. You know, “You said you’re gonna achieve this and, of course, this year, here’s this big chunk of money.” Naturally, “Have you achieved it? Are you going to slowly?” You know, “Can you cut the value chain? Have you delivered your value? Can you stop early? Can you pivot?” So it kinda serves multiple purposes.
Gene: Just a joke. I mean I was actually having a startling conversation with a friend of mine who was saying that they’re a publicly traded company and there was this sorta zombie operations project that they had depreciated over five years, and they couldn’t kill it because that would actually create a material change in the financial statements. But everybody knew that such a $7 million in a right world, we should just admit that it didn’t work. Kill it, so we don’t have to prop up this fallacy of a services actually running when it is not running at all. Does that resonate at all with you?
Jon: Yeah, it does. You know what we’re trying to avoid happening is exactly that kind of that sum cost fallacy and looking at a traditional approach, I’m sure we’ve all seen large initiatives which have that got multi-year sum cost fallacy that hasn’t delivered, but we’ve already spent so much money on it, we’re gonna carry on spending money on it.
Gene: Just to add color to that story. So they actually had this annual ritual where they’d have to run one transaction through it, just to prove to the compliance people that it is still operating, and so therefore, still eligible to be depreciated which is a shame. Jonathan Fletcher.
Jonathan: Jon, I love what you’re trying to do with that. It sounds fantastic. My question to you is are you forever stuck in writing businesses cases for return on investment? Does that slow the process down?
Jon: Hopefully not. You know we’re taking a lean canvas approach. So it’s not in the past in a traditional approach, you might have had to fill in a PID project initiation document which might be multiple pages long. We’re trying to keep it lean, so we’ve got a one-pager, lean canvas. You’ve got all of the information you need on that one-pager. Again, it’s conversation over contracts. That should be sufficient to have the conversation in terms of, “Do we feel this is the right way to go?” You know we might need to see more evidence. We might need to see more feedback from a proof of concept or experimentation or a customer focus group. We’re trying to keep it lean with this one-page lean canvas.
Jonathan: And is there a maximum budget that you would go with that project? Would you spend a $100 million on a one-pager?
Jon: We have a tiered approach and the tiering is the seniority of the people making the decision.
Gene: Conversations over contracts. I love it. So I’d love to know from each one of you, what are the favorite resources that you go to for finding your inspirations, practices, principles? I imagine this could be in the form of books, events, articles, research. Jonathan, would you mind sharing kinda what books are you reading these days that you’re finding most useful in your own daily work?
Jonathan: You looking for a plug, aren’t you Gene?
Gene: No.
Jonathan: All this here is homework. I think conversations of this kind of thing helps me immeasurably. So there’s this stuff you can get in theory, but it’s real world, practical, “I did this and it failed, and I could have approached it differently.” That’s where I get a load of value and I think just talking to people and getting out into the community. The DevOps community’s great at sharing information. Unlike like any other part of the [inaudible]. So I think people are always really generous with their time. So, for me, it’s not about reading papers. It’s about talking to like-minded individuals and the ones that are honest and go, “You know what? We tried that and it was a terrible mistake. Don’t go down that route.” That’s of much more benefit to me.
Gene: Great. Cornelia?
Cornelia: Yeah. I think a reason that Jonathan makes that point, and I can’t argue against that, is that we are still as an industry pretty early on in this journey. And somebody brought ITIL earlier and sometimes ITIL kinda gets a bad rap. But the reality is that ITIL is something that emerged over years, decades as kind of the codification of the best practices that we knew at the time. And when I was in college I learned about the Waterfall Methodology. That was the best practice at the time so, I’m dating myself, right?
Thirty years ago, in Computer Science Education, they taught us about the Waterfall Methodology and that was the state of the art. We created all sorts of practices around that. We created the books, the standards, and so on, and so we had a bunch of resources to go to. So when somebody was setting up an IT organization or evolving it, they had the manuals to go to and say, “Ah, here’s the codification of the best practices of the day.” Well, I think we’re still so early in the DevOps journey, not super early days because we’re seeing these fantastic success stories, but we don’t have the ITIL of the next generation yet.
So it’s hard to say that this is the go-to manual, this is the Bible. It is really about events like this, and it’s about, I, personally, I’m somebody who, when I’m on the treadmill in the morning, I watch videos, and I’m a propeller head, so I watch a lot of the tech videos, you know purely tech videos, but I watch the videos from previous events. Those things are incredibly insightful and really useful.
The DevOps Enterprise Summit, obviously, is just a fantastic event, but then there’s also what I consider more the grassroots events, like the DevOps Days which are not quite as focused on strategy, but definitely are focused on sometimes very pragmatic, very specific techniques and tools that are being leveraged. You need to bring that together with the high-level strategies. So it’s really still the community, but the good thing is that there’s lots of places to engage in that community.
Gene: Awesome. Jon, how about you?
Jon: So I think what Cornelia said that really resonates in terms of being early days, it’s not early days for Agile and Lean principles, at least in the 1980s, if not earlier, however, what we are learning is doing it to scale, and it’s been at the team level. It’s known at the team level. It’s not known at the enterprise level and so this is where a lot of the learning is. It’s, “How do you do this at scale?” And I’m not referring to scaling frameworks, necessarily. It’s more messy than that. It’s culture change. It’s behavior change. It’s involving everybody in the value stream. It’s not just technology.
Just technology is a local optimization. It’s everybody in the value stream, and we are learning, and this is a new way of working. This is a fundamentally new way of working for organizations with tech or without tech. I don’t know if this right term, but it’s like the fourth Industrial Revolution. We’re going from a tailor-ist way of working from the Industrial Revolution to not just a handful of firms working with multidisciplinary teams with long-lived products, and long-lived value chains, and fast feedback and fast learning, but entire organizations, and entire organizations trying to change how they do HR, how they audit, how they control, how they do portfolio management is a part of that, but it is a part of it.
So we’re absolutely early days. It’s a new way of working. It’s a more engaging way of working. It’s a happier way of working, and at things like the DevOps Enterprise Summit is where we come together to share on this learning. You know the question was, your question Gene was, “Favorite resources for learning…” so another really good forum which is quite similar which is around peers sharing is the SD Learning Consortium, sdlearningconsortium.org and it’s a community. It’s not commercial and we have a number of large companies sharing this journey and that’s where I get most of my learning from, as well as Twitter, as always lots of great content being tweeted.
Gene: It’s so true. I think six years ago I would have laughed at you, but just as a little side note, many people might not realize that one of my reasons for tweeting is actually too, is my mechanism recording things because, ultimately, of course, you’d actually write things down. Awesome. Jonathan Fletcher, you had a thought.
Jonathan: Just to add to exactly what you guys were saying. There’s next to where I work there’s a brand new building being put up, and I find it fascinating watching that process go on. So they’re damming in the foundations and from our floor, we can see right down to the foundations and see the guys that are working. And I often think of a parallel between a building and what we’re doing. You know IT is 20-30 years old. These guys who are building buildings since the pyramids, and they know what all the things are gonna happen, and they know the tolerances of the steel.
They know how much bricks they’ll need. They know the amount of concrete they need, and they know what order it has to go up. They know they need Planning Commission 1, 2, and 3. They don’t need to get halfway up the building, commonly knock it down and start again. And I think we should strive to get there in the future. We’re actually this is a common and understood journey and there are artifacts, and processes, and cultural norms that we can call upon, and I think this is the revolution that Jon was just talking about we’re going through now.
We’re trying to work out what these things are, and I guess I have one part which becomes routine. This is the university course of the future. I’m exactly the same as Cornelia. I can remember my sophomore engineering course and they’re talking about the silo model and Waterfall and this and that. That’s how you did it. So I think we go through that process now and I’m looking forward to that becoming more formalized and recognized, I think.
Gene: Fantastic. And love this, you know as you were reflecting on this, I was thinking about this quote that I think about all the time. As someone once said, “You’re only as smart as the average of the top five people you hang out with,” right, and so that is learning only happens when you’re hanging around people that you actually learn from, right? So that’s something I think about a lot. So we are all lifelong learners, now more than ever, at least for me.
I can’t tell you how many times, it’s difficult for me to overstate how much I’ve learned. I mean it’s just I’ve learned so much, even since the Phoenix Project came out 2013. I’d love it we’d just maybe go around the panel and just share one lesson that you’d like to share with everyone that you think it has significance and importance to everybody. Cornelia, let’s start with you.
Cornelia: Yeah, so one of the phrases that has really resonated with me as of late is this notion of radical curiosity and really just being continuously reminding myself that everything that I’ve seen so far is just what I’ve seen so far. And so I find my best days are the days where I get to talk with folks, where I get to ask the questions. I like to ask questions a whole lot more than I like to talk about things because it’s there where you get those insights. Even just this conversation for the last hour has just been the best part of my day and it’s only 8:00 o’clock in the morning for me.
So it’s really about asking questions and not falling into the trap of, “This is the way we’ve always done things.” I remember somebody asking somebody about how they do their firewall rules, how they determine what those are or how they secure something. And they said, “Well, we set the firewall rules.” And I was like, “No, no, no. I asked you how you secure things.” And it was all about the firewall rules. So it’s reminding ourselves and that we all fall into those traps of we have the solution, and we forget what the question is. I think that’s my answer.
[Crosstalk]
Gene: Yeah, that’s awesome. Jonathan Fletcher.
Jonathan: This is kind of a heavy thought for 4:00 o’clock in the afternoon. I think just that I’m really not the cleverest person in the room, and to keep an open mind about what others are telling you. Because as Cornelia says, this is a changing and evolving thing. People are reshaping IT and you know you don’t have to be the smartest person to pick up on some of this stuff. This is a movement and a cult of change that is happening, being able to set out some of these ideas and the Jez Humbles…All we’re doing is sort of following behind and listening, and picking the good bits and implement ourselves. So we’ll copy other people’s ideas, I guess, but that helps me get to where I want to get to. So just recognize that you’re not the smartest in the room, and just take the lessons that others have set out for you, and learn from them and move forward.
Gene: Perfect, love it. Yeah, one of the people I admire is Martin Fowler and I think he wrote kinda somewhere about his role, and he calls himself the best dumpster diver of other people’s ideas. I thought that was actually lovely beyond words. Jon Smart.
Jon: So in terms of a learning for me, I think in terms of culture change, an org change at scale, it’s going from, “I believe it when I see it” to “I’ll see it when I believe it.” So, you know I only really see it when I believe it and you to actuate new behaviors. So what I mean by this in terms of culture change, it isn’t about just going in there and saying, “Think this way” and trying to change the thinking. People need experience. People need to experience it, and actually you need to change the behaviors to change the thinking, to change the culture. I’ll see it when I believe it. That’s a learning for me.
Cornelia: Brilliant. That is brilliant. I love it.
Gene: I love it as kinda I’ll force it into being by sheer force of will. I love it, from Jonathan Smart. Fantastic. Well, to Jon Smart, Jonathan Fletcher, and Cornelia Davis, I’m so grateful that I spent an hour with us, and I know that your time is exceedingly valuable. You’re working on incredibly important things. I can’t tell you how much it means to me that you spent an hour with us, and for this hour, I hope that everybody else got as much value and delight as I did. So thank you, again. Now you’ll see more from us about the DevOps Enterprise Summit program as it shapes up.
Again, all three people here are part of the Programming Committee, and our goal is really to make that even better than it was last year. So I look forward to, hopefully, seeing all of you, on June 5th and 6th in London at the QEII Conference Centre. And, of course, an amazing venue in the center of Westminster and the center of London. You’ll see all the updates online at events.itrevolution.com, and again, early bird tickets end the 8th of March, so be sure to register as soon as possible. So with that, thank you so much and I look forward to seeing all of you on the Programming Committee calls or rather on the panel, and stay tuned for more updates. Thank you, again.
The DevOps Enterprise Summit in London provided another opportunity to speak to many clients about their organizations’ DevOps transformations. The key message is, “It’s all about people and culture,” but how do you make those changes? In session after session it was clear the source code manager (SCM) is central to this transformation. All clients included the SCM as a key part of the solution. SCM’s key value is as a common place to version all the artifacts from the source code to the system configuration. As such, it must provide visibility to all to allow for sharing and collaboration.
So how can z/OS participate in this transformation if its source code is locked away in some host-based SCM? The answer is, It doesn’t. In my interview with devopsy.kinsta.cloud editor Alan Shimel, we discussed this issue and he related it to the idea of separate but equal, which we all know does not work. What’s worse is separate but equal was really never equal, and the same is true for the host-based SCM to which the z/OS source code is relegated. I have asked many companies if they would move their distributed source to those host-based SCMs, and the answer is always, “Of course not; it does not provide what the distributed teams need.” How can it provide what the host teams need? It doesn’t.
Separate but equal does not work; it’s never equal and it isolates people. That’s not the way we should be looking at our z/OS source code. It’s critical to the business and should have the best support and capabilities, not the least. Now is the time to move to modern tools and processes and stop isolating the z/OS environment from the rest of the development environment.
The key is to focus on collaborative management solutions that do not separate, but bring teams together by providing one environment that all teams can use together for cross-platform collaboration. Various solutions include all the capabilities companies need to provide the modern agile development environment including z/OS. No separation—the z/OS code is in the same repository as all the rest. In these tools, the modern dependency-based build provided for z artifacts is based on Ant technology, so it can be extended just like existing build tools. With this tooling you can use your existing continuous integration pipeline and plug z into it.
It’s time we move z/OS development into the 21 century.
Read the thought leadership paper on DevOps for Enterprise System POV to know more on the essential tools and process that can enable disruptive technologies and an innovation at the speed the business requires.
About the Author / Rosalind Radcliffe
Rosalind is a Distinguished Engineer within the IBM Rational organization. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture. This includes System z and Power system. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM. Connect with Rosalind on LinkedIn / Twitter.
I am just recently back from London (again) where I attended Gene Kim’s DevOps Enterprise Summit London 2016. To me the theme from this years show is that at so many large enterprises (or horses as Gene calls them), we are moving from the initial “pockets of DevOps” trials to full blown DevOps adoption across the enterprise. This DevOps adoption is even moving beyond just the pure Dev and Ops team to include many different parts of the enterprise. Marketing, sales, business units and even HR are jumping the DevOps bandwagon to perform at higher levels.
Time and time again we saw speakers get up and describe how their organization started with pockets of DevOps adoption 2 to 3 years ago or more and now those successful efforts had been replicated in other parts of the enterprise.The results have convinced other parts of the organization to give DevOps theories a chance.
Of course not everyone agrees that DevOps has a place in the enterprise beyond Dev and Ops. I spoke briefly to John Willis about it and his initial reaction was that he is more of a purist who believes DevOps is still about Dev and Ops, not HR or other departments. I didn’t get a chance to speak to John more about this as it was a busy few days, but hope to follow up with him soon on it.
In the meantime the idea that DevOps starts with a beachhead or pocket of DevOps is one we have heard before. Carmen DeArdo of Nationwide has talked about how he has helped lead Nationwide’s DevOps transformation by picking a few smaller but important projects that generated visibility for the rest of the organization to see that DevOps does indeed work.
Of course Carmen is not alone in the concept of pockets of DevOps. We have heard similar from folks like Gary Gruver in his “Leading the Transformation” book, Damon Edwards and others espouse this approach. What is interesting to me though is the follow through we saw at DOES.
I think we can all imagine that if DevOps works in a few projects, we would see it rolled out to more Dev and Ops teams. What I think was really surprising was that it doesn’t stop there. The fundamentals and principles of DevOps are proving to be useful beyond the borders of developers and sys admins.
One could say that it would be easy to see how adjacent players like QA and security admins would also see the benefits of DevOps. But as we saw at DOES London even HR and other business units are joining in the DevOps fun.
This goes to something I have been saying for some time. While DevOps certainly originally referred to Dev and Ops, it seems to have outgrown the original intent. Maybe this is due to the fact that we never had a real definition or manifesto. In failing (not sure failing is the right word even) to do so, DevOps has been given a little more freedom to expand into areas that perhaps no one really thought it would. To me DevOps has become an umbrella term to refer to “the new way things get done”.
Now granted this may not sit well with John Willis and some others. I respect that they have a more narrow view of what DevOps is and what it is supposed to be based upon their years in the trenches evangelizing and helping to drive DevOps adoption. However, as I said I think it has grown beyond that and at least some of that is due to the hard work that people like John Willis, Patrick Dubois, Damon Edwards, Jez Humble and others have put in over the years.
There were many sessions and speakers at DOES London on a wide range of topic as well. We did almost 40 video interviews that will be available on our YouTube channel, DevOpsTV. There will be a separate playlist for DOES London 2016. More videos will be added to that as soon as we receive the approvals from the participants. In the meantime I wanted to show you one with my friend Helen Beal of Ranger 4 and Soren Pederson of Lego.
I had a chance to speak with CTO of technical sales of DevOps for IBM right before the recent DevOps Enterprise Summit in London. I also interviewed Sanjeev at the DOES London event and that video will be available shortly, but I wanted to give you a preview of what he was speaking about in case you didn’t get a chance to attend DOES London 2016.
Below is the audio file of our chat and below that is a transcript of our conversation.
Of course Sanjeev is a frequent contributor to devopsy.kinsta.cloud and you can read more of his articles here.
Alan Shimel: Hi, everyone, Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here with another DevOps Chat. Today’s guest is Sanjeev Sharma, CTO of Technical Sales of DevOps IBM. Sanjeev, I mangled that probably. Why don’t you correct me?
Sanjeev Sharma: Sure. No, Alan, you got it right. My title is CTO for DevOps Technical Sales. I’m a Distinguished Engineer here at IBM and happy to chat with you, my favorite topic, DevOps.
Alan Shimel: Yeah and always happy to have you on, Sanjeev. Sanjeev, today, specifically, I wanted to talk a little bit about the upcoming Gene Kim’s DevOps Enterprise Summit event taking this Thursday and Friday, June 30 and July 1, over at the Hilton Metropole in London, England. You, of course, I think are handling or moderating a panel at the event. Correct?
Sanjeev Sharma: Yes, sir. Yes, Alan. I’m really excited about it, and as you know, Gene has been hosting these events. This is his third year, if I remember correctly, but this is the first time he’s having it in Europe, so very excited about it. IBM, of course, is a sponsor for the event, but I also have the privilege of hosting a panel.
On the panel, we’ll be focusing on how to assess a large enterprise’s readiness to adopt DevOps. People ask about – ask the question, “How long does it take to get from here to London? I live in Washington, D.C.” Well, I have to ask them the question, right? First of all, where in London do you want to go? Secondly, where in Washington, D.C. do you live? It can take you about an hour just to get to the airport. Knowing your Point B, where you want to go, and knowing where you are, your current state, your Point A, is very important. We will be focused on that.
I’m pleased to have a very exciting panel. I have the leader of DevOps adoption at Lloyds Bank with me on the panel, Mark Howell. I have a VP of Application Development from Monetize on the panel with me, and then I have my peer, Rosalind Radcliffe, who is the CTO for DevOps Architecture for our Enterprise Organization aligned here at IBM. She comes from the mainframe side of the world, also as a third panelist, talking about this topic.
Alan Shimel: Got it. Sanjeev, before we jump exactly or primarily into the panel, as you said, this is the third year for Gene’s DevOps Enterprise Summit, first year in London. It’s happening at an auspicious time after all of this Brexit, right on the heels of it. For those who may not be familiar though, they’ve never had the chance to attend a summit, you have, obviously. Can you give our audience an idea of what the summit or what these DevOps Enterprise Summits are about? What are they trying to do? Then, we’ll dive into it specifically.
Sanjeev Sharma: Sure, Alan, sure, sure. I think DevOps, as folks listening to this and people who follow your phenomenal devopsy.kinsta.cloud probably realize, it came from – had its origin primarily in what we like to call the “unicorns” of the world, the cutting-edge companies, the startup companies, who are normally leaps and bounds ahead of your traditional enterprise.
Gene Kim started this event. I think he had this as the tagline for his first one, I don’t know if he still uses it, saying, “DevOps is also for the horses, not just for the unicorns.” Right? The focus of this event is how are large enterprises, with all the complexities, the legacy, the sheer inertia of it, which comes from the size of them, how are they adopting DevOps?
We, obviously, at IBM found that very exciting because that’s our sweet spot. Every DevOps Summit I’ve attended, the speakers Gene has been able to go find, and of course, being from IBM, I have to look at everything a little bit through my own lens, but this is not a vendor-specific event. It is totally agnostic. It is people sharing their real-life’s journeys of adopting DevOps, what stumbling blocks they encountered, what challenges they had to overcome, and these challenges, while they vary from company to company, the ones, if you’re a large enterprise with a large legacy install base, with a large distributed set of practitioners, vendors, and business partners, outsourcers, geographic time issues, these are common problems.
You hear a lot at this summit about how large organizations are addressing these challenges, which companies face. For anybody who does not work in the proverbial startup with the proverbial “two-pizza” team, but works in such an organization, I think this is a must-attend event. This will be actually my first time speaking. I’ve attended the previous events, but I’ve not had an option to present or speak, so I’m really looking forward to it, to be a part of the action.
Alan Shimel: Got it. Sanjeev, thank you. That was actually dead on, and I hope that gives people a good sense of what the DOES shows are about and why they may want to attend. Let’s now jump in though. As you mentioned, you’ve got a great cast. I’ve met the gentleman from Lloyds Bank, and for those maybe on this side of the pond who aren’t familiar with Lloyds Bank, would you call them a mid-size or a large bank, as banks go, Sanjeev?
Sanjeev Sharma: I would qualify them as a large bank.
Alan Shimel: Yup. What’s interesting, and I always find this interesting when you talk to DevOps people, Sanjeev, is we think of financial and the whole financial industry as being rather conservative. But yet, when it comes to new technology, such as DevOps, or I don’t want to say new, but a little more out there technologies and things such as DevOps, we see large banks and financial institutions, whether they be insurance, banks, but finance, really kind of leading the way here. Lloyds Bank is, I think, a great example of that.
Sanjeev Sharma: Yes and I think, in fact, both the companies I have on, Monetize is the second panelist. In fact, Garret Evans, who was a VP of AppDev at Monetize, is the other panelist other than Mark Howell from Lloyds. They’re both in the financial services industry, and they both come at it from kind of a different angle in the sense that Monetize is a service provider, and you would call them as a company. They’re not a bank themselves. They provide services to financial organizations, and they’re on the cutting-edge of technology. They’re way ahead of their – on the innovation forefront, and Lloyds too. But Lloyds still has that whole legacy, like more large banks, still has the legacy, “keep the lights on” applications that they to run.
But it is interesting what you mentioned about how financial services, which we, until a few years ago, one would think of them as the slow plodding conservative people in their suits and ties and risk-averse, being at the forefront of DevOps adoption, and that is very true. They are a prime example of how adopting things like Agile and DevOps actually reduced your risk, actually makes you agile in a disciplined and organized manner, as an organization, rather than some people’s view of it being the Wild West.
I think they’re a prime example. Why are they doing this? They’re doing it because of all the industries out there, they are one who are going through probably the most transformative change in their existence they’ve ever had. Financial services, banking, peer-to-peer lending, peer-to-peer money transfer, these are all undergoing a massive transformational change. They’re getting challenged by these FinTechs, or financial startups.
I think this has become a very interesting place for them, and I worked with financial services, it’s kind of my core industry, all over the world. Right? When you go to the developing nations, you see these financial services companies facing the challenge of, “How do I go and reach the un-banked populations who need banking services without – but cannot access a traditional bank?”
Then, in the developed world, you have this challenge of, “HOw do I go access the Millennials, who, again, do not want to go into a traditional bank, but need banking services, but do not consume and access those banking services the way you and I, and the folks with much more grey hair than them, are used to doing so?”
It is ripe for transformation, ripe for disruption, and DevOps provides that enablement for the IT organizations in these financial institutions to be ready for the disruption and enable it, and not be the inhibiter, but be the enabler.
Alan Shimel: Excellent, absolutely. Sanjeev, we’ve left an important person out of your panel though. Haven’t we? Besides yourself and the two financial institutions, we also have Rosalind Radcliffe on here.
Sanjeev Sharma: Absolutely. I didn’t want to – I’m not intending to ignore her [chuckles].
Alan Shimel: Why don’t you give our listeners a little background? Rosalind has been a frequent guest on our podcast, but for those who may not be aware, why don’t you give them a little background?
Sanjeev Sharma: Absolutely. Rosalind is my peer. She’s also a Distinguished Engineer here at IBM. She’s in the Development Labs in our Enterprise Modernization side of IBM. She focuses on the very – to simplify it and make it very generic – on the mainframe end of the world, although, her influence extends across to all aspects of DevOps, and she’s been a great person we’ve worked with, a great partner, in expanding IBM’s DevOps capabilities.
She actually has her own session also, I think, a couple of sessions before my panel, where she’ll be talking about DevOps and how it’s adopted in the mainframe world, especially talking about testing, which is a major area where we’ve seen a lot of traction when it comes to DevOps adoption on the mainframe.
She is going to be bringing to our panel the mainframe point of view, and I’m generalizing here when I say “mainframe.” Right? It could be Systems Z, or Series I, or large traditional legacy systems, but bringing that because if you look at large organizations, especially large organizations who have been around for a while, be it they’re banks, or retail, or government institutions, and those which are transaction heavy, they still rely on the mainframe to run their core businesses.
How they are adopting DevOps has been a surprise, a refreshing surprise, so to speak, in the sense that a lot of these large organizations have come forward and their mainframe teams have the lead of saying, “We want to adopt DevOps first.” It is unique, and when we tell people that, they’re usually surprised going, “Mainframe?” One usually thinks of them as being at the laggard end of adopting new technologies and new processes.
But we have found that to be exactly the opposite. I’m sure there are organizations out there where their mainframe teams are going, “Hey, it’s not broken. Why should I try to fix it?” but most mainframe organization’s mainframe teams are in the process of modernizing their application-delivery capabilities. I think DevOps has given them the opportunity, the platform, and the capability to move into the modern world. There’s a significant C-change going on in how customers are consuming the mainframe.
Linux’s own mainframe is a great example. OpenStack’s own mainframe is great example. And, of course, the z/OS, which IBM’s operating system for the mainframe has also evolved and become extremely modern. She has a very – is going to be able to bring a very unique perspective, which I think will apply to a lot of the attendees, so I’m very fortunate to have her on the panel.
Alan Shimel: Absolutely. Sanjeev, believe it or not, we’re almost out of time already, but real quickly, specifically now to your panel, give me, if you can, three reasons why it’s a must-attend panel for those who may be in attendance in London.
Sanjeev Sharma: Sure. Number one, people don’t want to hear theory, and I’m sure all our attendees, or our listeners who have the opportunity to attend, don’t want to come and listen to theory. I mean you can Google DevOps, you to YouTube, watch 100 videos on the theory of DevOps, read some books. People want to hear how a company actually undertook that journey and succeeded with it. Right?
That’s what we have on this panel. We have three examples of people, and I’m not even counting my own experiences working with the dozens of companies I’ve worked with in my role. My goal is not to talk there, but be the facilitator, but the three people we have on the panel are bringing tons of experience, real-world experience, and they will be, hopefully, sharing very openly. I know these folks. I know they’ll be sharing very openly and are willing to talk about all the pitfalls and the speed bumps they hit along the way, so real-world experience.
Number two, it’s an interactive panel. We are going to have no slides, maybe one slide in the beginning just so people know who we are. The idea is – in fact, we are going to do it very uniquely. I’m going to have my iPad up there with me, with these organizations, both Monetize, Lloyds Bank, and Rosalind. They’re going to give me some drawings before and which I’m going to draw out during the panel, so people can, in real life, see real-life versions of what their application delivery pipelines and their architectures look like, and what changes they needed to make.
Thirdly, we are going to focus or talk a lot about culture because the biggest bottleneck, the biggest inhibitor to adopting DevOps, is cultural inertia, especially in a large organization. Right? Things have been going on for a while. This is how we always do things, always start things. The responsibility is not mine. It’s not broken. Why should I try to fix it? These are all the specific examples of cultural inertia. We intend to spend a lot of time talking about how, in a large organization, which has set ways of doing things, which have highly distributed teams, how does one overcome that cultural inertia?
I would say those are three very good reasons to come to our panel. We are on Thursday, I believe, at 2:45 PM, but please check the agenda, they’ve been moving things around on the agenda, for the final time and location, but come there. Our plan is to open it up for questions from the audience, so you’ll be able to ask your own questions, and, of course, all of us panelists will be around for the entire event to meet with you and answer any questions one-on-one also. I hope to see you all there.
Alan Shimel: Absolutely. Sanjeev, thanks for giving a quick preview of both DevOps Enterprise Summit and the great all-star panel you’re hosting there. I will be there. We’ll be filming. I think we’re actually going to video interview, so we’ll follow-up then. But for anyone who is attending DevOps Enterprise Summit in London, please be sure to take in Sanjeev’s panel. As most things Sanjeev does, I’m sure it will be a great event.
For those who are considering going to DevOps Enterprise Summit in London, I highly encourage you to do it. If you can’t make London though, the San Francisco version of the event will be in the fall, and I encourage you to go there. Sanjeev Sharma, IBM, thanks for being today’s guest on DevOps Chats.
Sanjeev Sharma: Thanks, Alan. Thanks for the opportunity and I look forward to working more with you.
