 Welcome to yet another OpenShift Commons briefing with the Global Transformation Office team. Really thrilled to have Kevin Beer here today and we're going to do some debunking and have some conversation afterwards and see if we can't dispel some myths, I think, as well. So Kevin's going to talk about DevOps versus Eitel and hopefully explain to those of you who don't know what Eitel is, a little bit about that as well. And I'm going to let Kevin take it away for probably a half an hour or so and then we'll have some live conversational Q&A. So if you join us on Twitch or on Blue Jeans or wherever you are, we'll bring you into the conversation or we will just ask each other wonderful questions. So Kevin, take it away. Thanks Diane. My name is Kevin Beer and I'm the co-author most recently of the Phoenix Project. Before that I wrote the Visible Ops guidebook with Gene, Kim, and George Bafford. Before that I wrote the definitive guide to IT management and the adaptive enterprise for Hilo Packard. Before that I wrote a book on PKI called Managing Certificate Life Cycles where I started to send all those books before that into more technical topics. But I'm just a little bit of background on me. I am a serial CIO CTO but don't hate me for that. I started out as a developer, quickly got kicked out of development, became an infrastructure person and held every job in infrastructure until one day the CTO of my company was no longer present and I was standing in their office and got made the CTO. So literally my career has been a continual challenge of my competence and always kind of pushing me to a place where I'm not comfortable. For some reason I accept those challenges and so a lot of that has brought me here today and I want to make sure before I start talking that I don't come across as like an ITIL advocate. It's not really my point. I have contributed to the ITIL in all truthfulness. I have recently contributed to the ITIL practitioner guide a lot because I wanted to make sure that that guide started to focus more on continuous improvement which is what I believe will actually take us out of this false choice trap that we're in right now. So I want to talk to you a little bit about DevOps versus ITIL. Basically this is a false choice and I want to talk a little bit about why it is. So first thing what we're going to do is this is my buds here at the Global Transformation office on the left, Andrew Clay Schaefer, the Surly guy next to him is me and John Willis is to my right and J Bloom is to John Willis's right. We all have different backgrounds. Andrew I like to say basically invented DevOps with Patrick Dubois. I like to say that John Willis who is just an incredible sage, lots and lots of years, 35 years plus I believe in this industry working from everything from basically traveling around every DevOps days that basically ever happened to working just really, really hard in the software defined networking space and just doing lots of really, really cool stuff with containers and technologies and DevSecOps now. So I had to kind of gush on John because he's like top of mind right now. Jaybe is amazing. He's finishing his PhD at Carnegie Mellon in actual design the only I believe university in the world to offer a PhD in design proper. In other words not design of a thing but what is designed. So Jaybe among us is what I would call kind of a real treasure in synthesizing things from kind of parallel worlds and bringing them into technology and showing us how they're relevant and how they can change our thinking. So to that end I want to talk about where we're going to go with this. This talk is literally not to describe what I tell is to you although I will tell a little bit about it and it's not to advocate it to you. It's about an intersection of interactions that can be problematic in our organizations and I want to also suggest that in digital transformation which most of us in infrastructure and development should get a little twitch whenever we hear that word because a lot of times that's meant that we've been thrown hand grenade after hand grenade of unreasonable set of expectations and impossible changes that we can't make ourselves. So I think enterprise transformation tends to feel like some lofty crazy far-off goal and in the process of those transformation projects which is how they often unfortunately you know kind of materialize we struggle with existing processes versus novel ideas and one of the things that pre-exists in most shared services infrastructure organizations in the enterprise is an approach called IT service management and a specific approach to that called ITIL. So we're going to talk a little bit about these archetypes. Some of that's mildly useful but I think it can help you understand maybe some frames. We're going to talk a little bit more about what ITIL and ITSM are and then yes there are some ISO things in here. So there's reasons to do this stuff that don't actually have anything to do with whether these are the right things to do or not which is a very interesting problem and there are actual versions of ITIL. So when you're talking to people about it you may not be talking about the same thing and I think that's really important to understand but when you do understand ITIL you can actually begin to understand that the way ITIL may have been implemented in your organization has nothing to do with what is in the guidance. This is pretty common. People take it literally when it's not literally made its guidance right and then basically I want to talk about some of the places where you're going to have these interaction friction points in your daily jobs and what they may feel like. This all leads to a future series that I'm going to do. I'm not sure how we're going to do it here but you're going to see me doing it everywhere which is expounding on this in a lot of ways. So this is kind of a first talk to kind of that I'm going to put out in the community to start to just talk about this and then as I move on I'm going to start to move into more how we actually break these conflicts which ones are the false conflicts themselves the assumptions behind them I'll break these down socratic style eventually with actual evaporating clouds current reality trees I'll use some tools from Goldrat's theory of constraints eventually. So today is just to kick us off like what is the topic and why is it a problem. So you may have heard some of this friction happening in your organization developers constantly saying these things gosh why do I have to interface with a ticketing system I just want something from another human right and so why do I have to fill out this form that has choices and it don't make any sense to me just to get an environment right and a lot of places people still talk about servers if we're still talking about servers I think we're lost right and and and this is a sign in many cases when developers are asking for servers that's really not necessarily what they really want to be asking for in many cases we've forced developers to ask for raw materials to make things that they need to do experiments right and so one of the friction points we get is developers have an emergent need and or maybe even an ephemeral need I just need to try this thing out tear down the environment blow it back up I just want to see what happens I don't need to put this in production and so that kind of ephemeral need runs right into a very process-oriented structured approach to delivering things to people services products all those kinds of things and what happens when it hits that process is sometimes if you have a ticketing system those particular workflows get broken down into individual work queues they get sent out so you put in a request for a environment that request after you say small medium large and you kind of do all that sizing that request will be sent to possibly two or three different teams to fulfill parts of that work in the breakdown what happens is is in many cases you will hit two to three different queues of work that are not aligned across each other so what you will instead maybe get is the equivalent of if you ordered a car you might get a headlight two chairs and a rim and you're going wait a minute I ordered a car and they're like yeah yeah yeah but this other group has to do a thing this other group has to do a thing and then you'll get the rest of the parts and you're like but I ordered a car I don't want to have to build a car right and so very simply we start to have this fundamental very simple breakdown and a lot of people said well infrastructure you know basically infrastructure codes how we solve this and I was like well actually there's a social problem here that actually has to do with understanding each other's frames and developing empathy for why that's a thing and so when you understand the relationships from a developer standpoint and again I'm going to make stereotypical archetypicals type of statements here that are very broad and maybe mildly offensive or limiting in the way they're put I reserve the right to be much more reasonable later on in conversation if we have a talk but I'm trying to make impact here so one of the things that can broadly happen in these organizational groups is development typically has a very small amount of relationships to the developer in other words this is one thing that we do on purpose right we don't have 35 people talking to a developer in a sprint it's important not to right we're talking about hey we need to take very powerful skills and put some focus on them like horses have they're not blinders they're focusers right the extraneous information makes horses very nervous they're not developed for that so or never evolved for that right our modern world so we need to focus and we do this with sprints we do this with stories we do this with reducing scope of development right if you move to operations typical infrastructure operations in an organization it's many to one relationships every operator has potentially hundreds of requests and relationships from discrete people that all have different priorities but everybody thinks their thing is the most important and your job is to work at scale and scale means one person relating to many many many pieces of infrastructure thousands and so one of the problems with scale is is if everything is unique scale breaks because I have to master a ton of different things so one of the things you will hear from infrastructure people and you will think of slowing things down is their attempt to homogenize whatever is being offered or put into production so that they can maintain scale and that is a real conflict point when you have a one to one or one to twenty relationship from a developer and you have a thousand to one relationship for an infrastructure person they have completely different mind frames about what is necessary to achieve what they have to do and how they're rewarded by the way infrastructure people aren't rewarded for very much of anything they're yelled at when outages happen and so one of the things that we've developed is a risk aversion inside of infrastructure and one of the things that I think as you look at some of these kind of patterns here in conversation what you're seeing is structured versus novel thinking some people call this old thinking versus new thinking right operations tends to look to the past because the end of the day they're left with everything everybody makes and so they have to think about things like you almost think about children like rearing infrastructure right and which is why I maintain there's a level of phenomenology in infrastructure groups there's a level of care that doesn't make any sense like when you understand how this infrastructure doesn't care about you how it crashes how many things are involved with it most infrastructure people that I talk with when there's a problem they're more worried on a level that actually has care in it and I find this really unique so a lot of times you'll see this archetype kind of battle between developers who might have a lot of passion and infrastructure people that might seem like Spock from Star Trek but that's actually not true the caring in the infrastructure side manifests itself very differently and and and so what what I actually think is is that both groups when they're in their passionate and best frame may not actually be able to have the kind of empathy staying in their frame that they need to to get things done in a modern world so what we're looking at is old frames of thought that are built around stability the IT infrastructure library was really made to actually stabilize the approach to managing infrastructure provisioning infrastructure and maintaining it and in the British government when this started in the 80s there was a lot of different results coming from different the same kinds of projects so one of the things the British government thought to do was hey let's get all of our sage people all the people that have been working in this space for a while and let's build a best practice library of what we know works so that we can share that not reinvent the wheel all the time and get more stable reliable and predictable results from our IT spending and our IT projects and operations so if you think about it the goal was stabilization predictability and consistency this is not something you ever really hear devs talk about right it's novelty we're going to build a new thing we're going to fix an old thing we're going to bridge things that work together all of this is change thinking but if you go into operations changes risk because they know all outages basically are the unintended consequences of things we meant to do and and and so they have this cause-effect relationship that many people don't and the more that development organizations are traditionally shielded from that kind of on-call uh incident response type of scenario you may not be able to have empathy for the fact that your release basically means a lot of people's kids and operations don't get to see their parents over the weekend and I worked at one particular organization and one of my people in an OSS group that worked for me many years ago was a really really pretty still brilliant guy and his daughter he had a brand new daughter and and she literally never saw her dad because every release started at 6 a.m. actually 6 p.m. on a Friday night come in at 6 a.m. on a Saturday morning and a group of people would have to just sweat over this thing and you know maybe by Monday it was stable and so what I realized was this whole process was putting everybody in their worst position right but we were all just doing what we thought we should do and what I said was is how come what we're doing results in all these people being separated from their families and so we started a project because we all agreed that was dumb but we all thought that there was not a better way to do this right now but we agreed to start a project and we named it after the kids that were getting left behind because that's what's important sustainable releases right and these groups came together and started to work across these processes to figure out how to do it so here's one of the kind of dispositions that can be hard for the when you're in ops you see a developer running up to you you see them chasing a shiny object now maybe all developers aren't quite as outgoing as Tigger right they're not all type A's I'm certainly wasn't and you know I think we all kind of there's a spectrum of our social behavior that we even individually as a sine wave to it and and so you know you can see a developer running up to you well if you're in operations and you know somebody in dev comes up to you you might look like this guy which literally says he's not necessarily the personality of the individuals remember it's kind of the archetype of the organizations and the ops guy is like listen appreciate that you saw that I'm here but I'm already doing something and I'm already kind of like I'm kind of already worn down about what I'm already doing and I maybe got yelled at yesterday for something that wasn't even my fault and and and I'm worried that I might lose my job if that happens again and and there's a lot of worrying here about performance about making mistakes and about leaving the building and whether it's warranted or not it's there and it's real it's palpable especially during times like this so whenever your finds out about a new release he kind of sometimes feels like he's getting jumped on by Tigger right and if you try and resist the release because you don't think something's right or unstable or something smells wrong you're just a bad guy it's gonna happen right so there's this kind of almost pessimism that kind of develops over time and maybe what happens is we give in and so change becomes the one pivot point that operations can control the that when you go to do it change you're going to touch my backyard so if we refresh ourselves this whole notion of IT service management remember I said ITIL is like a de facto standard worldwide approach to IT service management and so basically what is IT service management it's really basic it's like a process-based management approach right to deriving business results that are less terrible than they are awesome so that we can continue to function as an organization right it's basically a management approach now ITSM there's a lot of approaches to ITSM out there I can tell you that none have gained a lot of traction in comparison to ITIL and like I said originally ITIL was published by the British government but now it's actually owned by a third party called Axelos and they're marketing it and developing it so you'll see much more aggressive maintaining publishing of guidance certification all that kind of stuff now I will tell you Axelos for the ITIL they do provide certifications for individuals like hey you mastered this material or whatever but you know certifications are what they are to me a lot of times they just become confirmation bias afterwards it's like we stay stuck into things we get certified on because we see it as like a sunk cost right so I really feel like that you know the certifications they do individually you know I don't want to talk bad about that because I think a lot of people put a lot of effort into that and the mastery and I think that's a great thing but they don't certify bodies and that kind of leads me you know so just to finish this up you know I'll use the all crevasse a is brandy but not all brandy is crevasse a you know all ITIL is IT service management but not all ITSM is ITIL just a confusing just so you know the BS 15,000 courtesy of the people that brought us the inch the pound the mile and the qubit I believe the british standards kind of BSI codification of service management using the ITIL which is called the BS 15,000 they made it a standard is really really useful and I'll show you when we look at these pictures because I tend to use the BS 15,000 picture of ITIL 2 yes there's versions to actually just as the simplest most baseline way to say this is what IT does and so the ISO 20,000 actually which came out not that awful long ago is a certification to show that you are actually doing these processes in your organization and that they are functional and have controls so this is really a way if your organization is ISO bent and I said this in the back and in the in the original part of the presentation of the beginning part where some of the reasons we adopt ITIL don't actually have anything to do with ITIL there are a lot of organizations that are really really hell bent on ISO certifying everything and so they're going to want to say hey we want to have this ISO 20,000 cert to show that our IT processes rock as much as our manufacturing or back in business processes or whatever they're trying to win a bid or you know differentiate in the market so the 20,000 winds up getting dumped on people and then all of a sudden they're like we have to have an approach to meet this and ITIL becomes the approach that's pretty much default but neither the best BS 15,000 or ISO are ITIL basically their certifications for organizations to show that they are doing those things correctly and won't talk anymore about that crap all right but you should know this drives a lot also there's another slide that I don't have in here because it's a future conversation which compliance in organizations drive standardized process frameworks and one of the reasons is there are standardized audit frameworks for IT like COVID control objectives for IT and so you know they are actually and I'm going to throw this crazy word out there ITIL and COVID are orthogonal so ITIL actually describes the processes and does have some controls in it change management by the way is a preventive control it's one of the best kinds of controls to have the problem is is when it's run wrong it prevents all the good things right and only lets you risky things so kind of one of the ways we have to start to think about the relationship between audit and ITIL is that when you're a person doing DevOps and you might be working in a collaborative scenario you might be like oh gosh you know that's what's killing us is doing that change management process filling out all those forms having all those people get involved in my change and say whether it's good or not that's ridiculous well it may be ridiculous and you probably should change but the audit framework that's associated with it in your organization that allows you to demonstrate compliance and prove that your controls are actually being used in work that's tied to that so when you start to think about changing processes you have to start thinking about a bigger picture in the system of how do we demonstrate that the things we say we do we actually do and that wherever there's risk we have appropriate level of preventive detective and corrective controls so one of the things that we don't really get exposed to in the development side of things a lot is you know GRC right um compliance regulation we may get exposed to it in our particular vertical if we work in finance or if we work in a particular vertical there are regulations associated with that vertical but we may not be aware of the fact that our tech friends in the IT groups or in the operations group have a whole host of things that they have to comply with and the ability to demonstrate that they can reproduce critical systems as exactly as they need to be um so you know never mind the fact that they're a key part of certifying um you know socks uh the underlying capabilities to go to demonstrate that our financial reports or what we say they are so this kind of stuff is tied to these processes so when you throw a Molotov cocktail at change management I get it I've thrown many myself matter of fact I've detonated change management programs only to find out when I have GRC people running up to me going um we've got examiners from the FDIC that want to see this and you just blew up the process that tells us we have that oh right so like whenever you're thinking about these things there is a system around them and while I think we need to improve and change and eliminate a lot of these concepts with modern attestation done by machines um those kinds of things um we we have to get there through a process that allows us to be circumspect and understand what are all of the attachments to these things it's just like service dependencies and software you know we've all said oh yeah you can turn that server off nothing will happen only to find out things do happen because people build dependencies that we didn't know about right and so uh that kind of stuff um it you know happens with processes in a very big way just understand that all work in a process comes from somebody and goes to somebody else and all of those handoffs that form that chain are called a value stream right and so one of the biggest things we have to look at is in a value stream how do we actually make changes to get rid of things that are causing completeness and accuracy issues or causing value to be lost or even worse somebody's name is in a value stream that is a credible organizational liability like we need to have a system not a person right um and and so I think the uh the larger kind of thinking around how do we create value is there value without compliance you know what is the end state of value is a conversation that needs to happen and does not happen when we say your ITIL is stupid and your DevOps is scary it prevents that conversation because first of all DevOps is not a best practices library complete with a framework for process controls functions uh as well as behaviors right DevOps is a novel sociotechnical cross functional alignment capability that organizations have and or don't have and and so it fits into something like this and DevOps could be the catalyst for improving these processes cross functionally and turning them into something that doesn't look like the idol anymore it looks like what your company needs right and by the way that was the original point of the idol none of the original authors said adopt this the way we wrote this and take every process area and make it a functional person they never said this and so a lot of the ways people have adopted idol has been with this literalism that has no basis in the way it was presented to people to be used so I want you to understand that it was not intended to become dogma not but it has because humans so I think what's important is that we figure out how to undogmatize it because it was never really intended to be that way when it gets coupled with compliance and it gets coupled with expectations and reporting it's really hard to change so gotta be circumspect so like I said the idol de facto standard for service management um it does come in versions and this is really great because our version our tech industry is this you know completely obsessed with version dot numbers which I think is bizarre um but revision control being what it is it's nice to keep track of things so idol two started in the early 90s came to the came out it was actually funny the first real kind of formal idol guidance I believe there were some books in the 80s and the problem with the books is they were very incomplete and they're very like almost just like a snapshot of that time period the way we refer to things like MIS I think was in those books like they're you know there's there's a lot of old terminology so what you'll see is as these revisions come out they trail what's happening because it's consensus based so it's never going to be pushing what's happening so right off the bat you have a difference in devos people tend to be more involved in pioneering just by archetypal scenario and you kind of have the town planners and the settlers with the itel folks so pioneers and settlers and town planners don't get along really well because they have very different priorities right pioneers don't care about settling towns they're just off but they do come back to the towns to get supplies and borrow things i'm sure right and so I think there's this kind of strange relationship between people that actually mature the way things get done versus people that are on the novel side so I think we don't need to be bimodal like I don't love that concept I call it bipolar it I really believe that at the end of the day all of us have to learn to modulate what we're doing based on the context that we're in so big big big problem because that's hard for us to do so idle two very very simple very much process focused I think it had like I can't remember how many processors I want to say covered like 10 processes and like maybe one function or two functions in idle three we kind of went again process based approach more processes more functions idle four changed completely which is kind of interesting to me idle four said it's more about practices and process but it's not just process and there are values and we want to have an outcome based approach so it's much more you kind of incorporate more modern language about digital things it's incorporating much more modern language about value chains and value it's brings mention of lean and dev ops matter of fact there's even they modified their product project management the british government had a project management standard now that axolace owns called prints to it's basically the british version of like pmp our project management certification that's been pretty pretty common here and prints to actually made an adjustment for agile which I thought was very interesting I don't complete to be honest with you I don't completely understand it but I think it might be genius or it might be crazy I can't actually figure it out and I need it's not because it it's a bad idea it's just I need to do more work on that but point is is that the approach changes over time but it always trails and I think that's very different for developers to understand maturity comes later now maturity also can lead to stubbornness right so this is where these things can you know I kind of have a joke about how a lot of times we're wandering through the wilderness and somebody finds something that works to get you to the other side and so what happens is enough people take that path and somebody finally decides to build a memorial to the fact that this is the way so they build a memorial everybody gets disillusioned knocks the memorial over and their subsequent generations just trip over it and I think they don't even know what it means that it's just in the road and I actually feel like that's the state we're at right now with devops and idle a lot of us don't even know why we did it to begin with when we try to undo some of these processes or start to make them lighter and faster we run into compliance problems organizational problems reporting problems hey don't move that thing because it's mine and I invented it so there's a lot of hooks into this stuff but as we even see there's a progression with the versions of idle and so what I would suggest to you is is there's a notion that some change can happen it's about how we interact with each other to make it happen so I want folks to stop just taking guidance like this from the outside with like idle and saying this is exactly what we will do I would love people to say hey the idle was invented by these folks in the government and they had this problem and they had these constraints we have these problems too but we have different constraints so maybe what we need to do is not do some of this do some of that and adjust it so we can deal with our own constraints you just made a recipe for yourself right so if you ate every recipe that was out there I'm guessing you wouldn't be in a good place but if you made recipes that sounded good to you and actually then said I can adjust these to my diet and my particular needs then you are actually doing something that's really cool you're taking care of yourself right and so I think one of the things that in maturity models that we've got to understand is why we're doing what we're doing and where it came from more and more more of our guidance about what we need to do at the actual tactical level can be informed by these frameworks like SRE which I think is a much more modern approach to looking at how we do with service delivery and service operations again not as heavy as idle has some of the same language some of the same thoughts but a completely reimagined way of doing it right so I'd like to say what are our constraints what are the universal principles that we identify with as an organization now how do we take our those principles and adapt them to our constraints so that we now have approach internally that can work this is what Toyota did there's an article that Eliyahu Goldratt wrote many years ago about this concept it's called standing on the shoulders of giants and I will definitely make a point of figuring out how to get that link but it is a great article you can google it just type standing on the shoulder of giants space Eliyahu which is Eliyahu Goldratt and that article is essentially about how you can appropriate practices in your organization oddly enough also it was very controversial in one sense it shows why lean adoption fails at some companies because of constraints and how Toyota actually built a version of the Ford production system that's what they wanted to build but they had no space no money were bankrupt could only make a car if they had an order and only could buy enough inventory for one car where do you think one by one flow came at the lowest cost they turned that constraint into an advantage that allowed them to produce one product that was completely different than another product on the same line at the lowest cost and in Japan you don't have huge inventories of car you order your car the exactly the way you want it and you get in about a week so the idea of auto distribution in Japan is much more about consumption and tied to uptake and also they've learned a tremendous amount of what people want right and and so that interaction is very personal it is very rich in terms of the data they get and at Toyota one of the most important things to remember at the beginning of when they started to really take their improvement bent their philosophy changed and their phrase even changed they had this great phrase better cars for more people it put improvement before the work in ital there's a continuous improvement in ocean in ital three that gets added and in ital four the problem is is it's not the central engine of everything they do in the Toyota production system you improve your work before you do it you have a systematic approach every day where your interaction with middle management and your managers are about your ability to improve things towards a target that everybody shares not what to do how you think about what you do is the coaching they don't solve your problems for you this builds this daily approach their kata their improvement kata builds scientific thinking in the edge at manufacturing to the point where some Toyota factories can do hundreds if not thousands of reorganizations themselves without hr that's powerful that's really powerful and it's not because they're god there are messy and low performing Toyota factories just like every other company but this is a really neat example of how reconstructing and thinking system-wide and understanding that the most important capability is to incrementally improve I think is pretty amazing so when we look at ital and we say okay ital has all these process areas but if we had devop style efforts going to continuously improve these process areas and align them with our new more important modern needs so we're collaborating on this versus fighting it's a big deal I know a lot of people don't have energy to get in and fix everything but a lot of us love doing that kind of stuff so I think one of the things that can be really healthy is is if this is stuff that's in your environment and you're facing clashes maybe step back and think about your entrenched position and if it's working for anybody are we making effective change right are we trying to use politics to change social things versus empathy and interpersonal relationships I think that that's one thing that we can start to think about so again here's some pictures of the idle so this is three different versions here I mentioned that there's version two that's the top one it's pretty low-tech I mean you can actually make a version of this in emacs the you know text right but sorry about my fidgeting and if you actually look it's really simple this is everything that you know you need to deal with at a large scale level like a high level right in an IT organization you've got kind of the delivery things like capacity management service reporting and all that stuff but right in the center control processes and I think if I'm a dev I look at this and I'm like control is right right and and because we get to control the change and the way configurations happen but if you think about this that's the hotspot because that's where a lot of people in infrastructure realize this is where bad things start like if I let a bad thing in through this now it's an outage now it's my problem now it's my weekend now it's you know potentially an executive escalation with my name in it on a quad call right it's a bridge that nobody wants right so but what we found you and Kim and I actually back in a day when we wrote with George Smapper wrote visible ops we found we've got some permission from our CEOs to put on pith hats and go study our best performing customers which was awesome and so we went out and we found out they all had these three things in common that was unbelievable they all called things different stuff first of all the reason why we have an ITIL one of the best reasons standardized names for processes right because then in operations you can say if we do this work and we do these processes we need these kinds of people and these skills so then you could standardize position names and actually have the ability to hire in a fair way and help away so that was kind of one of the ideas right so now you see how deeply entrenched this can get into an organizational model into people's positions careers and trajectories so when you come and say I want to get rid of this you threaten a lot of people's existences so we might use a more tactful way to do this right but this is a really great thing for you to think about if you're a developer what the hell does IT do all this shit in v2 now we call it different things there's more things that we've added there's a lot of compliance related stuff that's not there so that's a v2 picture that started out in the 90s then all of a sudden v3 somebody got really really awesome capabilities with excel or some sort of powerpoint or something and we made this wheel and because we hate the idea of linear processes and we wanted to show ITIL as a life cycle and I think I think actually there's some valid things that are in here if you look at this wheel the the notion is is that kind of everything starts with a service strategy in the center of this so we have a grand design about what we're trying to do what services and things we need to offer to help meet our company strategy and that's projects so those things would then go above it into this service design thing and then would flow right into after design being implemented at some level now I kind of call this little wheel that's in here I called it out it it's an old school concept called plan build run and and it's not very very agile or modern this is like the waterfall approach to delivery infrastructure and so I take flak for saying that but I think this is still very useful again we understand in transition things are moving into production we have more control around them when things are novel up towards the top you know in in the design phase and in the strategy phase there's less constraints but as it moves through this process it gets more and more locked down when it gets into service operation that thing is pretty close to static so from a from an infrastructure standpoint so again an interesting picture here but and showing motion but again look at this continual process improvement ring on the outside I don't even know what that means this whole thing kind of looks like a manhole to me and I feel like at the end of the day this is just the edge of the lid it doesn't have any motion it doesn't show any integration I think that's supposed to mean that all this stuff is getting improved but I like the idea that it's at the center and what actually feeds strategy feeds process improvement we have to do these things and we can't right now how do we get those capabilities we have to improve into them some of them you can do as projects but not all of them so I think there's a notion that strategy results in projects products focus which means we're not doing things right and so I think one of the biggest things that we have to understand is as we develop those things we are constraining things so developers used to having less constraints operators fully constrained different points of view now idle four below I took a picture of idle four here but this is an idle four all of it you can't show all of idle four on a freaking single page now and it bothers me they have these weird amorphous arrow drawings that just have ideas and concepts I think we need more than that kind of stuff to really have these conversations but what I will tell you about idle four it is kind of the idle du jour and and basically it's got to focus more on practices than just processes because I think the authors realized that people needed to know what the things needed to be done look like also the values that drive those and the outcomes that they can provide so I think they're trying to get people to think much more like they were in version three about a lifecycle but now I think for the first time idle four goes outside of it operations and gets into a lot of other things it has interfaces with software development it has digital kind of notions in it it even has DevOps notions in it and so but again imagined from this frame the stability frame right so we need to understand that these frames are important stability frame is not a bad frame the other day you actually benefit from this frame as well as have problems it does keep you out of a lot of conference bridges hopefully and escalations right but maybe you need to be part of those two to get some of that pain because it it man I'll tell you there I've sat on a lot of conference calls I don't talk on them as an executive because I think that's just terrible but unless people ask me to but I do think that it's important to understand the morale of your team and I think it's really important to understand the interactions and what they sound like and feel like not specifically to call people out all the time although sometimes it does help to take people aside and talk to them but what I find is is that it's important to just know because the words you say as a leader as a manager as a director can either and I don't like either wars but what I say is that they can cause folks to feel boxed and they can produce behavior that is not the kind of behavior you want versus kind of more optionality thinking and including people in the intent of what's happening and starting to try and build a bigger frame that more than one person can see I call it expanding the movie screen right we all have a phone screen and we can turn it in 16 by 9 but there's no comparison to that than a letterbox on a movie screen we can all see a lot better right there and we can have a shared frame right one of the big reasons why directors love that long format that crazy letterbox format that's what they see when they film that's what they want you to see how they're choosing their shots how they're choosing all of it where it starts and ends and so when you get that wider frame you're now seeing like a filmmaker so frame adoption the idea can you see what's in the frame of somebody else a little bit can you move your frames together so that there might be a little bit of overlap in what you see that is DevOps like I maintain that it's not the full then affinity getting crossed like we just don't have dev on top of ops and circles right we have that affinity that is about 80 20 and I think that that's really important and these areas where we meet each other to interact to make value have to become focused on differently not as why we can't get it done but what we're going to change to get it done together so I talked about the friction around patching is one of the areas where again it's change developers don't want to deal with the fact that in many cases things have to be patched and where you patch them is one thing I mean a lot of operations folks are still doing what I call this old house which is basically taking servers and upgrading them in production patching them in production and basically caring for them that's a lot of work the more modern organizations are basically building you know you know kind of what I call like a merge approach to building infrastructure in the sense that we're building it in source control we're building the images we're building and combining all the artifacts together to build a server on the fly and we don't necessarily and all of the stacks above it we don't necessarily actually now have to focus on modifying things that are in production because I always say I'd rather patch 15 or 20 different builds that we have in source control than I would patching thousands of servers that are all going to react differently to the same software I would rather mint them from scratch right and one of the reasons why we do this in many cases it's not the solution for everything is you solve two different things at once infrastructure people are patching and worrying about much smaller set of things which allows them to have more mastery of those configurations versus having hundreds of thousands or like most organizations an unknown amount of different configurations and trying to master something as it breaks and so I feel like one of the more kind of empathetic things we could do is work together to say hey we can architect a way of doing this that frees up massive capacity in operations and also allows developers a lot more flexibility I just I love stuff like that right because we get to win right and we get to also slide past a lot of really really silly assumptions and you can say they're silly in retrospect after you've been through them they're really hard when you're looking at them right the consequences so we see the friction in change management we see the friction in the way tickets happen we see friction in the fact that you know when people need I've started this classic tired line you know our devs don't respond to incident callouts well again it's the frame it's a totally different frame and we need to make sure that we both have context for each other's frames here and share a frame together about how we resolve things together and you know I can I can tell you I've sat on release conference bridges a lot and and I can tell you that one of the things that drives operations folks nuts is and builds a lack of confidence across that relationship is the amount of config files that just get botched in releases and ironic as it may seem most ops departments that I've been in have not been really crazy about source control and a lot of software is written in in operations some people call them scripts but they're not in source control and so it's very common in operations to have config file problems and batch files that don't run and scripts that don't work correctly and break that's normal but nobody outside of that group sees that right but when developers bring a thing in and their config file doesn't work right it's because the operator doesn't understand it in many cases and it becomes a like why don't your config files ever work why aren't you shipping me things that are run ready and then all of a sudden we get this big conversation about we need to build a path to production you guys need to satisfy all these requirements before we'll let it in and what we basically institute is a troll in front of a bridge that asks you what your favorite color is right and so from a developer standpoint this is not satisfactory so you get these friction points where we're trying to do things and the processes just they don't fit and so the thing that a lot of people don't realize is that if you look at these processes that don't work where all the wars are there's a there's a ton of deer paths out around the processes one of the things I often say to people is why don't you look at the deer paths and move the processes to those that's where people are we used to build you know roads on cow paths and deer paths like we learned how to follow things right that's why there's nothing straight in Pennsylvania but I think that the the the idea of how we are actually getting things done and looking at the way they're supposed to get done tells us a lot about how the supposed to get done is working and and so I mean I hear the conversation it is one of the most old and tired things I've ever heard an infrastructure person who sits back and says you know what everything would be great if people would just follow my processes inside the devs mind he's thinking something that's probably pretty similar it's just he hasn't articulated processes with drawings and you know all kinds of crazy you know meetings and sticky notes and done all this stuff he basically in their mind they think about an outcome they should get really quickly and and so I think that we have to step back from defending what exists because neither of none of those things will get us where we want to go and we've seen that so friction's a clue it's a symptom it's most awfully not the problem with the process so if we stop here and we decide that we need a better patching solution or we need a better ticketing solution or we need a better call-out solution we're going to buy pager duty for devs or whatever it is maybe step back and go why do we have to do that right I'm not going to tell you to five why this to death but these aren't these are symptoms so one of the things I want to talk about about these things you know so I want to kind of introduce this conflict and I wanted to briefly frame it a little bit and I also want to frame it as completely useless but I think it can be made useful and and so I often tell folks be very very very careful at intervening in these battles um oftentimes what's being presented at face is a face value isn't really the issue it can go back to the archetype and the frame and many times I've heard brilliant folks in operations trying to explain why they need to do something but they aren't even aware of the overall frame that they're in compared to the frame of somebody else in and and so frame thinking by the way um it's kind of something I'm throwing out here um and I think maybe this is something that jabe and myself probably need to do a talk on at some point um and jabe's really great at explaining the concepts of frame thinking I'm pretty decent at explaining how they play out um and and what they can look like in technology and one of the reasons why I think it's important to understand frames is that um we make a lot of assumptions about why people do things and very seldom are we right at first and um but we think we are and because of gut feelings and our past experience and stimulus right so we bring a lot of bias no matter who we are to these things and one of the things that we have to do is adopt this notion I've learned it because I've been humiliated enough times by thinking I have the answer um is this notion of humble student right when you're learning a new thing understand you don't know it and that you're trying to get closer to it humility in understanding is very important and when you think you understand another person's point of view but you keep running into this rock of resistance maybe you don't understand where they're coming from and how they're measured and what their fears are and so what we have is these stances that become almost political and what I find is is that when we polarize we seldom we really really seldom optimize something together and in order to optimize we have to understand both parts of an equation what you're trying to tell me and what you're trying to tell me are probably both right and so if we step back from the fact that what you're trying to do is probably the right thing the way we're doing it doesn't work right now that's a big deal right and so I think can we frame can we frame these things with as we talk to each other with a little bit of understanding of the stability the goals that we have in operations versus the goals that we have in development um and I think that as the more we see it we see that these aren't verses they're different parts of value chains and everything we build only really delivers value when it's in operations matter of fact business school definition of operations harvesting value from operational assets in other words we build software we put infrastructure out there we want our value back so operation the continual elimination of the constraints that the software provides only in operation of that software is it eliminating constraints and providing actual business value now there are the things that we can make that are patents or code that we could sell that does happen but by and large in the enterprise the way we make value is by running those things that we built so if you understand as a developer the only way your software is valuable is when operators can operate it without talking to 24 7 you're going to want to maybe make that happen together right and they want to be able to take that thing that you hand to them into that next part of the life cycle and they want to be shaking hands and go in high five we got the next chain here got all of our backs we're getting value now that thing you gave me has the potential to generate value and it's my job to realize that potential that is powerful and when we think about that as a relay race together if somebody drops that baton we don't finish the race so if we're sitting there arguing about who has the baton and how it should be handed and what color it should be and if it's handed only on Thursdays like that's a bad thing so understand that the goal of operations is to be able to safely absorb as much change as the organization needs to to allow it to meet its mission and strategy and satisfy the needs of its customers so if change is not at that velocity and does not have a successful spin in other words your change success rate is very low and you need to make a lot of change you know what you're going to create a lot of incidents right in the early 80s GM bought a ton of robots during the labor crisis some of us are old enough to remember when gas was not cheap and there were labor riots in the auto factories and the economy was terrible and interest rates were 14 percent and things were bad and so GM says well people are kind of a problem we're having these striking auto workers so maybe we should just deal with machines because they're a heck of a lot more simple and cheap well boy was that wrong they spent I think billions on buying robots during the middle of that maelstrom and but they wound up throwing them out a few years later and then they asked Ford's CEO I think during that time saying hey why didn't you guys join the arms race when GM did and buy all the robots and the CEO of Ford said something to the effect of basically realize our biggest problem was consistency of practice and if we sped up the rate of delivery without consistency of practice we would just accelerate the rate of delivering defects so I think this lesson is something that we need to think about together which is in the car industry a lot of things have moved really really far towards the direction of design for manufacturing in other words let our design limitations be the things we think that we can manufacture quickly so these are called enabling constraints this is something that a lot of people don't realize sometimes by limiting your focus you can do better in blues we call this seven bar blues in a sense that we know we just have to name a key and everything after that has a basic structure why do we do that because it's the same core possessions because it allows the vocalist to improvise over top of it because they know where the song is going to go that's an enabling constraint it enables the expression extemporaneously of pain joy which is a very searching process right so when we think about hey how are we going to work together we understand that sometimes enabling constraints making things that we know can readily be available in production now the other thing is is that production has to move enough to support the ongoing strategies so that we're not having to use old crap all the time so there's there's a hybrid thinking in there make new friends but keep the old one is silver but the other's gold right it's like the Girl Scout theme song I used to pick my daughters up from Girl Scouts so one thing that permeated me and it is operational thinking which is these assets that we know have been eliminating constraints and providing value for a really long time you're telling me this new friend is going to be really cool and I want to make this new friend but in order to make this new friend I have to keep the old ones working I got to keep those relationships going and so that is a different way of thinking I also like people that when they want to make a new friend with you also consider the old friends because I'm an old friend of a lot of people I don't like to get dropped right whenever they have a new one so I think you know if we start to think about these processes these cold infrastructure things as more human relational emotional and sometimes not really logical and also far more complex than we might think we actually can approach them with the humble you know the humility that we need to actually start to talk about how do we socially come to a common frame or enough of a common frame so that we can actually improve these things together and actually get different outcomes so I've seen many organizations and I think this is something that I need to probably bring to the forefront of how are organizations and I can talk to some folks actually melding these two approaches and creating something that is neither idle nor traditional DevOps in a sense traditional DevOps that's funny but legacy DevOps so but I think that you know that is what we're after we're not after legitimacy for name banner sakes of agileing and DevOps saying and idling everything we're here to deliver value to our business and some of these things make that easier if they don't then we need to question what's happening right and and then the last thing to say is is that I think one thing that we forget and it's as developers I think it's important to understand is idle is actually a very descriptive versus prescriptive set of guidance so I'm going to give you a little bit of power here not that I have it but this is the thing I learned question the prescriptive nature of the adoption is that really what people had in mind but don't do it in a conversation with the next person like that's running that process going I'm pretty sure what you're doing is not what they had in mind because now you're going to have an argument about points of view and odds are that's not going to be productive but what people can do is actually start to say hey I I think I get why some of these processes are important but can you help me understand why they're important to you and oh boy oh boy talk about a list of things right it's like asking the UPS guy what he does but I think at the end of the day what's really important is listen to that because that's what you're going to come up against if you say that stuff's dumb and try and understand why they think that stuff's important and ask them what happens when it breaks and how they feel and I know all that takes time it's a lot of session build up if for some people but I think at the end of the day you're not going to just waltz around these processes and continue to successfully build things in an organization for a long time it's just not going to happen and so I think in order to help people do things we have to understand why things are the way they are and with that I'm done ranting about eitel and debops