From the course: Putting ITIL® into Practice: DevOps for ITIL® Practitioners

The traditional enterprise IT shop and the breakdown of separation of duties with digitalization - ITIL Tutorial

From the course: Putting ITIL® into Practice: DevOps for ITIL® Practitioners

Start my 1-month free trial

The traditional enterprise IT shop and the breakdown of separation of duties with digitalization

- [Instructor] So what are DevOps and enterprise DevOps? What objectives and challenges do they share? What's different about them? Let's have a look. In traditional IT shops, Dev and Ops are separated along a number of dimensions. Separated into different teams, organizational units or departments with completely or mostly separate objectives and responsibilities. Values and principles, methods and practices, cultures and mindsets, incentives and rewards, knowledge and tools and environments and invisibility. Also, Dev tends to have primary responsibility for what ITIL calls utility. The functional requirements or features and Ops tends to have primary responsibility for warranty. The non functional requirements, the keep it up and running part. This was a source of friction. There wasn't yet a strong notion of design for our operation let alone operation for design. In this traditional scenario, Dev's primary circle of concern is innovation and making changes happen and Ops' concern is stability. Minimizing risk and efficiency of operations. From an ITIL point of view in this scenario Dev is concerned with the strategy, design and transition phases of the life cycle with the focus for Dev in transition on pitching verses catching. Ops is also concerned with transition so there's some overlap but Ops' focus is on catching verses pitching of what gets released into the environment. Both Dev and Ops are concerned with continual improvement but typically with the focus within their respective circles of concern. In the traditional IT scenario, Dev and Ops' objectives are not only separate they're also in tension. The idea behind tension metrics is that separate teams with separate incentivized opposing objectives creates a tension that is a grain of sand that makes a pearl. So for example if you and I work for a tractor factory and you're in sales and just when the ship builds a hundred tractors you just sold. And I'm in manufacturing QA and I want to make sure we check things out before we ship them. That's a good thing, both the push and the push back and that's the idea behind tension objectives. Lastly in traditional IT releases themselves are larger and more physical in nature. The frequency of releases is less often and the level of automation is lower. That is releases are more manual in nature. This is fitting for the scenario where releases are physical rather than digital in nature. A general rule of thumb for automation is that you automate things that are low risk, repetitive and frequent. So in this light, less automation makes sense. Along with the fact that automation lends itself less to physical artifacts than to digital ones. And because the transaction costs of moving forward or rolling back releases are much higher with physical verses digital artifact. The culture of a focus on reducing risk makes sense as well in this light. Traditional IT shops set up these kinds of separation of duties and large releases with slow release cycles and low automation for a good reason. It worked, it worked under conditions where the primary artifacts in the workflow were physical verses digital. As workflow was constrained by that physicality and the higher transaction costs that come with it. Under these conditions, traditional IT shops did things like waterfall project management. Slow release cycles and mega releases not because they were cave people but because they were for example shipping physical media. They couldn't just roll back a mistake or try something out and pull it back as you now can. With things like blue green deployment. The transaction costs were just oo high. You can still see something like this in the methods used for subscription services verses packet software. DevOps practices work well if the thing your developer commits to is running a service. If instead you're shipping packet software the customer downloads and runs. The ISV model, some DevOps practices are awkward. To summarize, when the primary artifacts to be managed are physical in nature and the pace of flow of changes and releases is relatively slow and the size of changes and releases is relatively large and the automation level is low. The benefits of separation and tension objectives can outweigh the costs. Think about it, if you're going to ship a million physical DVDs of software and the transaction cost to make a mistake or change is prohibitive. Having a separate test and quality function makes sense. You couldn't move that fast before digitization. So at the pre-digitization phase, checks and balances didn't get overloaded. Now we know, with the advent of the cloud the conditions have changed. The problem with separation and tension objectives comes in when you start to march from traditional more physical IT to hybrid and to the cloud. As you move from physical to digital artifacts the pace of work increases dramatically. Think about it, as you ratchet up speed faster and faster at some point the hand offs and checks can't keep up and get over run. Turning what had been an enabler into a barrier into getting things done. So in a primarily digital environment, the benefits of separation of duties are lower than the costs. In DevOps, the traditional separation of duties between Dev and Ops is known as the wall of confusion. Where for example Devs write code and then throw it over the wall to Ops who are supposed to deploy and support it. Please note that it's not like there isn't a place for separation in enterprise DevOps or even cloud native DevOps organizations. For example, in modern IT organizations identity management is often cored off in its own team for a number of very good reasons. The point here is that the traditional places where separation was institutionalized are not working and there are new places where it does make sense. Some people assume the wall of confusion is caused by the stereotypical assumption that IT professionals have poor people skills. Well this may be the case in some specific instances it's not the case in general. The main cause is that part of the separation is the institutionalization of incentivized opposing behavior. Which can be an enabler when the work target is primarily physical and becomes a barrier when it's largely digital. Creating the wall of confusion. Under increasingly digital conditions, separation of duties results in warring tribes of developers, sysadmins, security professionals, netadmins, DBAs and so on. They're in conflict with each other more often than not. That's the wall of confusion. Digitization enables high levels of automation and lowers the transaction cost of moving forward or reverting back. Enabling much more frequent smaller releases. Breaking the utility of separation and tension objectives. In a traditional IT shops, Dev teams are charged with innovation. Developing new functionality, making changes fast and moving fast and Ops teams are charged with maintaining stability, reducing risk and controlling change. At a slower pace, separation and tension objectives can be that grain of sand that creates the pearl and as pace increases dramatically. The institutionalization of separation and incentivized opposing behavior instead becomes the grain of sand in your shoes that wears you down. Something's got to give. So what's an IT professional to do?

Contents