San Francisco 2015

Breaking Traditional IT Paradigms to...

We’ve all heard DevOps can greatly accelerate velocity and efficiency. The challenge is how to transform a large scale enterprise with established processes and systems.

Through the looking glass of a number of DevOps myths (are they really?), we will share how HP goes DevOps, brokering relationships among our business unit and infrastructure IT teams to make the move from organizational silos to integrated teams and continuous delivery pipelines; from physical systems and storage to cloud infrastructure and Docker containers; from templates and forms to infrastructure-as-code; and from change requests to change records.


Ralph Loura

CIO, HP Enterprise Group


Olivier Jacques

CI, CD, DevOps Practitioner, HP Enterprise Group


Rafael Garcia

Director of Emerging Technologies R&D IT, HP Enterprise Group





Good morning. Uh, so we're gonna do a little bit of an, uh, a maybe different presentation. Uh, so we're gonna run through 30 minutes with three speakers in, I think, like 30 slides. So it's gonna move quick. Trust me. It'll be, it'll be fine. So why don't you tee us off with the first slide. Um, first of all, HP a big place. Uh, we're literally 12 days away from being live as two separate companies, so, uh, um, it's nice to be here instead of in a war room somewhere figuring out why something went wrong. <laugh>, uh, so, so far, so good on, on that front. Um, so this is sort of the numbers slide. Uh, the big scary how big we are. Slide, I won't drain it, uh, entirely, but, um, there's a lot going on at hp, as Jean said, 300,000 employees, um, massive amount of infrastructure data centers.


Just a little bit of activity in the last nine months, cloning and separating and, and splitting and re iPing everything on the planet. Um, uh, so big scale going on in the background here. And so how do you organize an initiative like DevOps in that, in that kind of back context? So, if we hit the next slide, one of the challenges we have is we're a big 75-year-old company, and we're organized like a big 75-year-old company. Yet at the core of our DNA is invention. Uh, you know, in many ways HP is the founding of Silicon Valley, right? The garage Bill and Dave, this is kind of where it all began. And so, um, we believe in invention and creativity and being different yet, you know, organized 300,000 people against a set of work in a predictable way with rational outcomes requires some sort of structure. So we are a very much a traditional kind of IT shop and a dev shop in the way we're structured organizationally, which presents a bit of a challenge. And part of that challenge is kind of what we're here to tell you about today, how we address that and kinda the progress we've made,


Right? So, yeah. So indeed, uh, you know, like many of you, I guess we, we started with unicorns. Uh, we have, uh, many projects in HPIT that have been looking, uh, you know, at doing things differently and looking at taking advantage of the cloud capabilities that we have in-house, uh, taking advantage of also the new automation capabilities that are, that became possible. So, lots of unicorns that, that, uh, actually started to, to, uh, to assemble. And what we started really to do then is to look at all of those unicorns and, um, take them and assemble, you know, define our new world. We knew that DevOps was the thing that we wanted to do for many reasons. Uh, but we didn't know really what it meant for us for HPIT. So we did this, uh, this pilot and this kickoff, and I will share more about that.


Uh, and to define our own HP IT DevOps manifesto. You know, in Agile there is a manifesto, the Agile manifesto, it's very well known. I know that there has been lots of debates about having a manifesto, um, for DevOps. But we thought that for us, we had to make our own and create our own manifesto. Something that we can rally around and something we can understand. I will share also, uh, more about that. So what, what's our new world? Um, how do we enable this parallel world, uh, that enables DevOps? And, uh, this is, this was really our journey so far. Where we are right now is that we are scaling this up. So we onboard more assets. Uh, we're looking at actually having, you know, more teams joining this DevOps mode. 'cause it is indeed a parallel mode, uh, that we are enabling for now.


And one way that we are, uh, looking at to enable that is, uh, what we call the DevOps academy. So the DevOps Academy is a mix. You know, it's not something that is like super formal. Uh, we have very basic one-on-one courses, like, you know, just get the basics. But it's all about enabling champions and enabling change agents, uh, you know, learning by doing. And I think that the presentations yesterday from Target was very interesting, uh, from that standpoint. But, uh, it's all enabling about, you know, enabling this, uh, this, um, this community of diverse practitioners that we have in within hp.


So, so the basic idea is we started small. We, um, so we didn't take, you know, 4,000 people in IT, dev and reorganize 'em in a DevOps model and run 'em through training, right? That would be silly. I didn't take, uh, a thousand projects and immediately apply a new model and let's go see how fast we can go. So we took a few things that sort of fit. We did a kickoff in a pilot. Um, we got a bunch of people in a room. Um, you know, the, the, you know, I remember back in the, the, the old days when voiceover IP was a novel technology. We had the ip, you know, kind of stack guys. And we had the signaling system seven guys. They didn't talk to each other. The two orgs didn't trust or value what each other did. So the only way we ever got voiceover IP off the ground and unified communications was the equivalent of organizationally taking both orgs out in the parking lot, letting 'em sort it out.


And then kind of the winners came back in the room. This was what we did here, right? So this was our kind of parking lot conversation. We took the ops team, we took the cyber risk team, we took traditional developers, the database guys, we had folks complaining that, you know, gee, that that, uh, that grid and that cloud is not reliable enough for me to run my app on it yet. So once, once it becomes, you know, 9, 9, 5 nine's reliable for that particular node, then I can move my app. And I'm like, well then, then you should probably leave because we're never gonna get there. 'cause the answer is, you need to fix your app to understand that you're managing in a grid-based world and not assume you know that you've got a fault tolerant engine so you don't get it. Let's move on. So, so it was kind of this, get 'em all in the parking lot, sort it out, get him back in the room and see who wanted to play, play for the future. Well, and


I think one of the key things was that Ralph was actually in the room the whole time. So having that CIO sponsorship in the room with all the players, when those kind of misgivings start to come up, Ralph was able to be able to say, no, this is where we're going. This is the place made a big difference.


Alright, so this, this really helped. So throughout this, uh, you know, our experience report that, uh, that Jen was, uh, talking about, we are going to share, you know, techniques and, and, and things that work for us. Uh, but we also wanted to make it real. So we are going to talk about two of the, uh, applications that, that we are using and that, that actually went into this DevOps mode. Uh, there are more than that. Um, uh, but two applications. So one is a mobile app. Uh, this is an app that is in the pocket of all of our hp, uh, vendors or salespeople, sorry. And, uh, that's 10,000 vendors, uh, salespeople, <laugh>. And any progress, any change that we make there, um, you know, is good for our revenues, <laugh>.


So one of the key here is you want to pick an app that matters and, um, 'cause you don't wanna just do some little widget on the side that nobody cares about. So an old boss of mine used to say, uh, in a, in a very, I think tender and endearing way, uh, salespeople are coin operated. And, uh, and at the end of the day, you want them to be right. If you build your incentive plan correctly, then you incent people to go do the things that are gonna grow the company and, and meet customer needs. And so on. My comp mobile was our answer to that. So before this, what we had was, you know, salespeople are wondering, am I on quota? Am I not on quota? You know, where am I, uh, you know, am I, do I need to sell more, you know, cloud?


Did I meet my, did I hire my all flash, you know, quota? Am I gonna get my payout? What percent right? And they're spending way too much time with their personal spreadsheet, arguing with sales ops on whether or not I made something this way. It's real time. It's in their hand. They can check it on the fly. Understand what do I need to do this week, today, this month, to crush it, to kill it, to go get, to get paid and meet the needs of my customer. So kind of hit 'em where the heart is, or the wallet in this case,


Right? And one of the other, uh, application that actually is business critical is what we call support automation. So it's a internal, you know, application that is really a social network between all of the equipments that we sell, uh, you know, to customers, uh, so on premises and, and various people. So, you know, the system administrators, the, uh, the support, uh, analysts and the service delivery, the sales so that we can have a mesh and really understand where our systems are breaking in the field, and also predict, uh, when parts are going to break as well. So it's a very key capability that, that we


Have. And I think one of the key points here was that these are just two examples of the DevOps ones that we tried out in the, in the initial pilot. The reality is we had everything from, um, microservices built to monolithic solutions. We had mobile applications, we had every type of application that we wanted to be able to try this out with versus just thinking it was the unicorn stuff, the web-based native apps.


And we actually started with SAP in


Last, and we have SAP starting now too, can


Share about that. So, you know, sharing about all of the techniques and all of the things that we have learned so far, we wanted to, you know, show, highlight some, some key points there.


Yeah. And one of the first ones we wanna talk about was collaboration. So at first we were wondering, uh, we know we wanna break the silos. That's the whole point of starting some of this stuff. But we're wondering, does that mean we have to reorganize in order to make that happen? We had heard a lot of people talk about a DevOps organization. We weren't sure that quite was right, where a lot of people were talking about changing your org and combining people, combining changing management structures and the like. We weren't sure that was very practical for us. Uh, like Ralph mentioned, we're a very large distributed kind of, uh, organization. And on top of that, we really didn't know where we wanted to go. I mean, we didn't, we didn't know that, um, this is the target organization we're going for, so it didn't make sense to make a, a big change. So instead, what we, what we chose was ChatOps as a mechanism to do that. And, um, I'm sure many of you know what ChatOps is. Um, there's, there's talk of it downstairs in the demo site as well. Um, but if you don't, I would highly recommend going and, and finding out about ChatOps. Uh, for us, it's a massive enabler. Uh, but basically what it is, is persistent chat rooms that are combined with bots interaction with the system, the environment that's associated to the particular service or application. So,


Shameless plug, uh, tomorrow afternoon, if you're really interested about this, some more HP folks are gonna be talking about, uh, ChatOps in particular and what we've done in that space. So you can catch that talk. I think it's like two,


It's two in this room, but b and it's actually, it's a live demo, which, you know, I've not seen many live demos yet. <laugh> for


Action. So yeah, we're, we're putting it all out there, right on the line. Uh, the other thing that's interesting, so this kind of idea was frankly inspired by the old internet meme that on the internet, no one knows you're a dog. Like basically you can be anything you want kind of behind the screen of a computer. And so the idea was, hey, listen, I don't have to reorg, you know, an IT org that's literally 8,000 people spanning the globe in order to figure out how to do something like this. I can, you know, by day I'm a, you know, third shift, uh, you know, a, a a warranty support operator, but, uh, by night I'm a chat ops, you know, expert that's driving, you know, code delivery across to certain, uh, a, a certain pipeline. So, um, you know, the kind of, you know, on the internet you can be, and no one knows you're a, you're a chat ops dog, I guess,


Well, in, in some of the other aspects of the ChatOps stuff. So it, it's not just a place where people come together, right? The whole concept is that now you're bringing in the environment itself. So everything from, uh, what, what's the status of the build? What kind of tests, uh, are passing? Is there a production event? Um, what kind of self-healing maybe is happening? And all of that is coming into the same place with everyone that's a part of this, uh, this ecosystem reacting or interacting, um, real time. And, and then the, the other aspect of it is that that is what engenders the trust across these different organizations that in the past we're really playing the blame game, right? So now you have everything very visible and transparent. Everyone's able to see and, and, uh, and interact together,


Right? And, and, you know, DevOps is really about collaboration, and it's really about, uh, trust enablement. And this brings a lot of visibility and many things beca become transparent, uh, thanks to shut ups. The other aspect is that, you know, we are social animals. I mean, that's, that's what we are. And, and that's who we are. And, um, you know, in chat ups, you get the opportunity to talk to each other. Um, you get to have fun. You get to ask the ball to, to, to make fun of someone else if you want to <laugh>. Um, but, uh, the other thing is that you have the systems that plug into this, uh, social collaboration. So we are social by default. And on top of that, we had, we had the systems that do help us do work, which is not the other way around. We are not living our way, our lives in the tools and, you know, adding social on the side. No, we are social first.


Well, and, and it's not just about the, the social aspect and the fun part, so that, that's a really big one and enabler for the trust piece. But by having the systems engage, you avoid a lot of the surprises that have were occurring with us, uh, in our traditional models. So for instance, we would have someone from a support side reacting to a production event unaware that something's happening on the development side, pushing into production miscommunication. There's supposed to be policies and processes to avoid that, but the reality is those things break down, and this environment, everyone sees what's happening and they're able to raise their hand and go, Hey, why are you doing that? And that's helped us avoid a lot of surprises as well. Yeah,


Exactly. So, um, the other aspect is, is pipelines. Um, so, you know, there are many talks about pipelines. Uh, you know's really a key and a very important point in many talks. And if you have not, you know, if you have not bought the, the book continuous delivery, uh, by jazz and, and, and others, it's, it's really a must read <laugh> if you're technical. But pipelines are, you know, it's a set of tools and they're very important. Um, we also think that pipelines, what we have seen is that, you know, we could come with a very defined, well-defined pipeline, you know, awesome rockstar. I mean, there are people in OpenStack that are doing awesome things with their continuous delivery pipeline and say, this is going to be the pipeline going forward, end to end for all of HPIT. Uh, we think that one size does not fit all.


Um, so instead we are looking at having something like a con flexible continuous delivery pipeline. And that's what we have been enabled. So we enable the teams to basically have whatever they, they, they want, however, uh, so there is a lot of flexibility, however, we have few anchor points, and those anchor points are kind of non-negotiable anyway, right? Uh, gene was mentioning about the source code management. So like Google have one as one code repository, uh, at hp we are also, we also have one code repository effectively. Um, and, and this is kind of non-negotiable anyway, right? So we have those few anchor points that are very important to us, and that allow us to allow flexibility while at the same time, uh, you know, bringing, uh, ability to, to, to be different.


And this was particularly important for us because we had a number of pilot teams that the ones we chose to participate were already fairly mature teams. They already were doing continuous integration. They were starting to continuous delivery. We didn't wanna come in and say, okay, you're doing it all wrong. This is the set of tools and pipeline and processes you have to follow. It was more of what is the challenge you're running into, and what can we do in order to remove that challenge? And then from there, what we expect is some kind of commonality across these pipelines is gonna surface. Yeah. And over time, we'll start understanding what's what, what are the choice points that are the best for us? Mm-Hmm, <affirmative>, right?


Right. So, you know, in this pipeline, I was talking about source code management, uh, maybe a little bit zoom on this one. So one change is one deploy. Uh, the cool thing about, uh, we have two kind of models, right? So I think, oh, by the way, the war is over. So the war on source code management tools is basically over. Someone has one, and this is git. And if you're doing a subversion, this is hard for you. So I'm sorry about that, but, but, um, so, and gi, gi different workflows, right? There is a gateway workflow and there is a pull request, GitHub kind of workflow. We have both. Uh, but bottom line is that each and every change is one deploy. And, uh, we have lightweight peer reviews. And I think what is also very interesting is we also have, uh, the ChatOps integration.


So same thing, right? Every time there is a cut commit, every time there is a review, every time there is a, a command to a review, uh, this gets integrated in our, in our chat off system. So it's all very visible and we can always refer to it, uh, so that we can we continue to add on top of it. The other aspect, the other big anchor point that we have is our change records. So, um, in our existing world, um, we have a big process that we call the RC process, the Request for change process. And, uh, that's, uh, basically the cab, you know, very optimized in the manual world, uh, very optimized when we have teams that need to be interlocked, uh, with each other. And so that can get work done by another team. Uh, but in a world where many things are automated, if not everything, this, this is not the best way of working. So we have this, uh, change record mechanism that we used to basically, um, fulfill the same needs, uh, in terms of auditor or, or audits and traceability, et cetera. But we do, we take advantage of all of the automation that we have put in place. Uh, and, and that's, that's our system. Yeah,


I mean, at times at hp, the RFC is a four letter word, right? If you're a developer or even an in the ops team, um, this, this request for change and this moving records through can be perceived as being somewhat bureaucratic and, and frustrating at times. Um, so a, this is a delight to move from the manual paper-based, the committee-based process to one where I push a button and a predictable things happens if I followed the right sort of sort of policy. And then two, uh, as we said, it's an auditor's dream, right? At the end of the day, uh, instead of kind of parsing through logs and run books in the minutes of a meeting and, you know, other areas where we story and record record decisions, I literally just pop up the chat ops, I can go see what happened, who did it, when it was done, why it was done, uh, the dialogue around it. It's just, it's amazing. Yeah.


And the other thing on that change record is that we involved the auditors right up front. So as we defined what this service would look like, we didn't just go into a room and say, okay, we don't need all this request for change stuff. Let's go and decide what a, what a change is. We had the auditors in place, um, the SOX folks, the security folks, and started to really understand what is is the bare minimum you need to understand about every change that comes through versus this six week lead time 40 artifact thing that we have to create every time. Yeah,


They were some of the people in the virtual parking lot in that first Yes,


They were <laugh>.


Yeah. So telemetry and the feedback loop. And you know, the second way that that is very well depicted in the, in the Phoenix project book is, is very important. So this is the telemetry for the, um, you remember the MicroComp mobile application. Uh, so we, we can see where our users are going, in which screen, how they navigate between the screens. Uh, that's very interesting. Uh, lots of telemetry, I think. But you know, the other one where we see here, it's, it's, uh, our performance, uh, depending on the, the, the, the phone that we have in hand. So we know that we have an iOS nine issue on, on the iPhone five C, we can see it. Uh, but, uh, the other concept that I think is extremely important is what we call the fund deck. And the fund deck is, uh, something that, um, basically it's a composite metric and for a, for mobile apps, right?


Uh, but you can create the phone deck that you want, right? So, um, and, and in mobile, what you want is to, you want, you know, speed. You want an application that is fast, you want an application that doesn't crash, and you want an application that doesn't drain your battery nor, uh, you know, uh, you know, use your data plan like crazy, right? So, so we measure all that, we aggregate, and we use it as a composite matrix that we call the fanex. And, and because, uh, you can drill down, but at the end of the day, if we can just have a one metric that cannot summarize all of the aspects of it, uh, that's really something that, that, uh, is very interesting for us. And


That's one of the things guys like me look for is a nice pretty dashboard with, uh, you know, colors and bars.


Looks green,


Looks, it looks good. It's green. I like it. It's good.


So <laugh>, so the other, the other aspect here is that, um, this is just one example, right? The whole point is that the pipeline has, uh, a feedback loop built within it. And each of these teams have a flexible capability of building out the monitoring, the self-healing, whatever they need in order to apply to their particular situation versus what our traditional models were, which was, you know, you establish some kind of central monitoring system with some basic functionality that works across the board. And anything beyond that that you need is like pulling teeth to be able to, to enable it. This, this, uh, enables the teams themselves.




So, so one of the concepts we talked about, um, so we talk about pipeline, we talk about anchor points. Um, so it's interesting, I think if you're too prescriptive, you turn off a lot of those, uh, people at, at the core of their DNA look at themselves as inventive. If I tell you, here are the tools you use, how to use them, when to use them, where to use them, um, it, it feels too rote. And frankly, a lot of our creative engineers, even if it's the best tool or the best process, almost on principle, we'll go find something else to use, right? You, you guys, you, you get this, right? Um, and so our philosophy is essentially buoys not boundaries. So we're not drawing like hard lines. You have to stay within the lines. It's really this idea of, okay, we're gonna kind of cut a channel fairly deep.


That channel is a kind of safe harbor. If you go down the channel, middle of the channel, you're gonna know you're gonna make it safely into port. Your code will launch and you'll be fine. If you choose to, you know, you can kind of test the waters, right? You can get to the edge of the buoys. Uh, you can kind of maybe even go 10 or 15 feet past the buoy. There's probably a little safety zone where that kind of shoreline tapers off. So you can go experiment with different tools, different tech techniques, different approaches, as long as you're staying true to the anchor points, right? Those are non-negotiable, and you're consistent with our, our our, uh, you know, manifesto in, in behavior. We'll let you go experiment, right? In fact, how are we ever gonna see the next interesting thing, the next innovation, the next thing that allows us to get there faster or better, or, uh, with a better, uh, customer outcome if I'm not exploring and testing at the edges. It's just, you've gotta, you gotta find a way to navigate the channel, mark the channel, and then give people permission to, to test where proper, where appropriate.


And that, and that kind of goes to the last point here, which is about trusting your, your people, trusting the organization. So, um, one of the, one of the aspects that we had was we worked more of a command and control kind of model, which I think is pretty traditional, and everyone's built into this, where you establish a central policy or a central process, and you, you're looking to avoid or, or prevent people from making mistakes, essentially. So you're not trusting the people to have the right visibility, the right knowledge to be able to make the right choice for themselves. So you establish a process that, that that steps in and does that for them. So instead, we moved more towards this concept of integrated and empowered teams, right? So integrated meaning that these folks had, for any particular application or business service, they had everyone in the team that actually would be able to, uh, touch or, or feel a part of that ecosystem.


So that team is self-sustainable, essentially. Uh, it's not a team that has to reach outside to be able to correct an issue. And that included DevOps, but then pieces of ops like, uh, support and, and network and DBA, et cetera, et cetera. And so, so this is integrated. They're actually, uh, working real time basis, uh, continuously. And in addition to that, empowered, so what do we mean by empowered? For us, it was getting the right skills in the room, uh, in the team, getting the right, uh, access, uh, being able to access production, for instance, uh, getting right visibility. So that's where ChatOps came in. Uh, ChatOps gave the transparency to what's happening in the environment to all of the players, so that way the DevOps teams has the right visibility to make the right choices. And, and we, we brought this back to this whole concept, then.


Um, if policy and process is not gonna drive this, then how do we approach every time that we have a decision on what we should do? And, and basically we fall, fall back on this minimum viable process. So instead of resorting to a process as the first default kind of mental reaction, it's empower the team. And what does it take to give that team the ability to make the right choice? Because that team is the closest to the situation, the closest to the issue. They typically know the best thing to do for their particular situation. And, and, um, so we consider that so critical, that whole trust the people that as we, you can go to the next one. So as we developed our manifesto of defining what DevOps meant to us, trust is at the foundation of that, right? You'll see it at the bottom, and it, and it really means everything. It's the, the fallback position on everything that we do is trusting the people closest to the situation. Yeah.


And I think this is interesting. The manifesto, uh, idea was, okay, what do we have to do, right? We were talking about all of the techniques, all of the organizations that we needed, needed to, for the teams to buy into. And we thought that we had to have a vehicle, vehicle, uh, to communicate what's going to be their new world. We wanted to make sure that they, they take, they took advantage of, they're really jumping into something that's going to be different. You are going to be trusted. Yes, the, the interfaces between the silos are going to be APIs. And it was an awesome discussion yesterday in, in, in, in the morning session. So, um, so it's a new world and it's a parallel world. So this is the manifest. So this is the, this is the contract that you have to sign, and yes, you will be on call as well. So that's scary




So, so one of the key questions kind of, I get a lot as a CIO when I talk to other IT leaders that maybe haven't started the journey yet is, hey, isn't, is DevOps just another way of doing work? Isn't this just like another methodology? It's itil, it's waterfall, it's agile, like what's the big deal? And kinda my answer is typically, um, uh, yes, it is just another methodology. It's just another way of working, and it's a fundamental belief system that changes everything. So it's both, right? So it depends on how you look at it. It requires a different level of thinking, a different letter level of leadership, a different commitment to a process. Um, and, and that commitment is, has to be pervasive. It has to be vertical. Uh, it has to go cut through the whole organization. It doesn't necessarily have to be, you know, kind of horizontal.


It doesn't have to be everywhere all the time. You know, uh, uh, one of my favorite te sort of, uh, tech or sci-fi quotes is the future's already here. It's just not evenly distributed. And that's probably true at hp, right? So we're doing a lot of things in innovative and different ways. DevOps is one of them, but we're not doing it everywhere all the time in the same way, right? And, and we want the freedom to be able to do things differently based on maturity of the team and appropriateness of the, of the situation and the problem on the other hand. So, so when we're talking to the folks that kind of, uh, at their core believe this is a movement, um, it's very easy to connect with those people and drive that as a movement. But when I'm talking to the people who just, who, who just want life to be simpler, just can, can we just stop all this change stuff?


It's kinda getting outta hand. Um, I can say, no, no, no. It's, I mean, really, it's just another way of doing work we've been doing. You know, if you think of the way you build, you know, building code is, it's, you know, I gotta think about what I'm gonna do. I'm gonna de design what I'm doing. I'm gonna code it, I'm gonna test it, I'm gonna deploy it, I'm gonna support it. None of that changed. When we went from that, you know, waterfall, we went to Agile. Instead of doing all those steps in a room with a bunch of people reviewing at phase gate, I did it in a, around a table, and we called it things like a scrum, and I did it in a few weeks. And then in DevOps, I'm just doing it in a few seconds or a few minutes. And all those steps are happening as well. They're just happening in an automated way or in a collaborative way or a different way. So if I'm talking to someone who doesn't want the world to change, I can talk about it in comfortable terms about evolution. And if I'm talking to somebody who's ready to change the world, we can talk about the cultural change that's required to make this all happen.


So our our key takeaways, uh, as, as Jean requested, uh, we were overachiever. So we only only came out with four instead of five. We kinda condensed this for you guys. Um, so, so you guys heard that trust is essential to change the way we work without trust, um, none of this kind of comes together, right? 'cause if I have to, uh, uh, think about it ahead of time, set policy, and do all this kind of, uh, heavy handed work over, over top, it doesn't really open, uh, what we're trying to open up here, enable collaboration across silos using ChatOps. So again, if you're one of an org like us who can't essentially take everyone that's doing this work, put 'em in a room and just reorganize everything around this work, you have to do this iteratively, globally, uh, uh, in silos. ChatOps we found is a great tool to kind of, no one knows you're a, you're a dog in, in ChatOps, encourage experimentation, buoys, not boundaries, really make sure, um, you're giving people license.


Yes, you have to have anchor points. Yes, you have to have, um, clarity around pipeline. You have to have the religious debate, um, uh, and, and work through that. Um, but encourage experimentation where possible because that's how you find the next thing that drives value. And then of course, a balance between trust and and control. Um, so collaboration isn't a free for all. Uh, trust isn't a free for all. This is about creating e equity and balance and, and, and, uh, you know, in terms of how much risk I'm taking and how I'm encountering that kind of work. Yeah,


And I would just add for the key takeaways is that actually we are collaborating a lot with our professional services at hp. We do actually that for our customers. So what the journey that we are in, in hp, it, we are working with our professional services to also, you know, share it with our customers and, and is the place where this, we are condensing a lot. Yep.


So how can you help us? Uh, well, well, so when to apply DevOps, right? We keep getting this like, do I apply DevOps to my ERP rollout? Uh, do I apply DevOps to just, you know, kind of unicorn style apps? Kind of where, where do you, is there a method, a methodology, a filter, a rule, a rule set, a flowchart that helps figure out kind of what methodology applies best to what kind of work? And then we're still struggling a little, not with the, you see, we've got metrics, right? So metrics to measure DevOps, but, um, it's really more from a leadership perspective. How do you create incentives? How do you incent teams? So how do you measure and create incentives so that people are working in the right style and achieving the right outcomes in a DevOps style world versus the measures relative to, you know, things like, like, like, you know, number of releases and so on, which are kind of easier to, easier to track. So those are, those would be our asks, and I think we're kind of right on time. So thanks everybody very much. Thank you.




You so much. Actually, I have one, I have one question that one of the things that really stood out in our prep calls, uh, was this phrase, Ralph was always relentlessly helping break down barriers and obstacles, right? Whether it security, compliance or the daily coffee. Can you talk about that? I'm not sure who, who wants to speak to this, but, uh, you know, what did that look like? What did it feel like? Um, how did it help?


I think it was very, it's, it was a lot about enablement. So we had, you know, the, this parking lot and, and the fact that yeah, there was, there was question about security. How do we access the system securely? How do we make sure that, uh, you know, our systems are not going to, to break down everything? And, and the fact that you could have the, the point of view of the CIO that says, you know what, this is going to happen. It's kind of not negotiable. Also <laugh> and, and this is going to happen and we just need to find a way to do it in a way That's right. That's


So, so I think maybe this goes back to my, so in college I was a offensive lineman, so maybe it's my, in my DNA that I go, I go clear the path to let let other guys come through




Awesome. Hey, thank you so much.


Thanks guys.