DevOps and traditional ITSM - why DevOps won't change the world any time soon

In which we discuss DevOps: the threat it presents to successful IT service delivery, and why I think DevOps will be a niche novelty for a while yet.

I've presented a couple of conference keynotes lately on the topic of how IT is "losing control of the centre" to IT cowboys backlashing against ITIL; to Agilistas and their cohort DevOps; and to Cloud hypesters. Blog post will follow one of these days. For now I'd like to look at DevOps.

[Update 20/1/2015: I did soften my position on DevOps, to the point of being a bit of a fan now. But actually, most of these challenges are still valid, in a slightly less confrontational form :) ]

What is DevOps?

That's a good question. Like any idealistic movement, that depends who you ask.

It seems sometimes to be about multi-skilled teams doing all the development, deployment and operation of their product.

Other times it is about the "sysops" staying separate but being nice to the developers.

To others it is about cool tools automating everyone but the developers out of a job.

Or DevOps is an attitude, a feeling, man.

What I like about DevOps is that it is a cultural movement, an attempt to change IT culture. To the extent that it attacks the misuse of ITSM principles by inept managers and petty empire-builders, I'm all for it. I like the way it tries to improve communications/relations between development/solutions/projects and delivery/operations/production.

I also like the way it tries to speed up delivery of new services and changes to services. IT systems and organisations can become sclerotic, like any other. A flush out of bureaucracy is a good thing. Challenging assumptions is good. All processes can be improved.

ITSM is predicated on improvement. So ITSM and DevOps are in agreement on these things. In other areas, not so much.

Why is DevOps a worry?

One of my concerns is that DevOps - and Agile - get seized on by IT cowboys as a blunt instrument to break down the controls around service delivery/production for political reasons that don't truly improve the situation. Instead of "turn us and them into just one us" it becomes "eliminate them so it's just us". I feel like the subtext of much discussion is "If developer-techs ruled the IT world, everything would be OK".

Another concern is the apparent lack of understanding of what IT Operations does by most (but not all) proponents of DevOps. Their conception seems to be primitive and simplistic. The way they keep calling us "sysops" or "sysadmins" is a symptom of this. The call for NoOps is a classic example. All Ops does is run up a server and database instance when needed, apparently. Oh, and some bureaucratic crap around that.

My main concern is that even the best-intentioned DevOps supporters have this peace-and-love concept that we can unite development and operations into one happy team. If this was really true I'd be right behind the DevOps movement. But it isn't. This flower-power will be no more successful than the hippies were in uniting mankind.

That's because DevOps is based on certain assumptions which don't scale. Agile and DevOps may one day succeed and become the generally accepted mode of running IT, but there is an awful lot of learning and failing has to go on before either one has the maturity to be handed the keys. They work with small impassioned teams working on small standalone projects, or pilots, or SMBs, or startups, or funky open source tools... anything standalone. Great. That doesn't mean they are ready for prime-time.

This post by Stephen Nelson-Smith (guest-posting on Patrick Debois's blog) is considered seminal in DevOps. It holds up IT's poor track record in project delivery as a problem, claims that silo-isation is the cause with no evidence for that claim, then promotes DevOps as the solution without noticing the following un-scalable assumptions:

Assumption: We can all be one happy team instead of in silos.

This works up to Dunbar's Number, so it works just great in the smaller teams of WebDev, and pilot trials of DevOps. It ain't gonna work in anything larger.

People will split into tribes and there isn't a damn thing you can do about it other than manage it. One good way to manage it is to build formal processes so everyone knows and agrees who does what.

Not only are silos inevitable in any organisation with more than say 100 IT staff, but silos are not a bad thing when managed well. Two of the key benefits of large organisations (and society) are specialisation and economies of scale. We centralise our BAs, operators, support, DBAs, coders, change control, account managers, librarians, testers, sysprogs, PMO, webmasters, architects and so on for very good reasons:

  • we use the most expert people on the organisation (who are invariably in short supply).
  • we set and follow standards to improve compatibility, consistency and efficiency; to reduce rework, duplication and redundancy of technology, skills, and effort.
  • we make the organisation as a whole more efficient and effective. What so many developers seem unable to grasp is that it isn't just about their baby. One project may need to wait at times for access to centralised resource, but the overall effect is that they'll get the best result with minimum effort; they'll make maximum re-use of existing resources; and they'll minimise the introduction of additional overheads for new things to operate and support.

Instead DevOps wants to take us back to an era of self-sufficiency where developers live in communes, providing for all their needs locally. It didn't work when the hippies needed a tractor and it won't work when DevOps needs someone to support their live database.

Besides, if you organise your systems as self-sufficient teams doing everything from business requirements definition to infrastructure problem resolution, you've just moved to vertical silos instead of horizontal silos. You'll still get us-and-them, you'll still get animosity, 'cept it won't be between Development and Operations, it'll be between services. Ooh that'll sure improve the organisation's view of IT, not.

And if DevOps is not about building vertical silos, if it is just about improving communications between Dev and Ops so we can get on better, then we all agree this is a Good Thing, so can we all have a group hug and get back to work without this hype about revolutionary new approaches please?

Assumption: Good people are easy to find.

We sent my son to a Montessori pre-school. I quite like the Montessori approach, but more than that I like the fact that such an idealistic philosophy attracts the most passionate and professional teachers. You can't replicate Montessori success across the educational system because you can't get that many teachers that good.

In the same way, Agile and DevOps philosophies are predicated on an unrealistically rosy view of the standard of people available. Because they are exciting revolutionary new approaches, they attract passionate and professional people who make them work at exceptional levels with a minimum of oversight or controls. This simply will not scale. For every Dilbert there is a Wally. You cannot use the "empowered professionals" model on a large scale across the industry. You need accountability, formal controls, and performance management.

What's more, Agile and DevOps (and Lean) prefer small teams of multi-skilled individuals. I've already blogged about how that is also going to fall on its face the first time anyone tries to scale it across a large organisation. Stephen Nelson-Smith talks about

...experienced, talented 30-something sysadmin coders with a clear understanding that writing software is about making money and shipping product...
There’s been a certain amount of popularity recently around the concept of ‘polyglot programmers’. These are developers who know multiple languages, and multiple approaches to programming, such that when appropriate they can move swiftly between object-oriented Ruby and a functional language such as Erlang or OCaml. This is simply an example of a larger observation - there is no one IT skill that is more useful or more powerful than another. To solve problems well you need all the skills. When you build teams around people who can be developers, testers, and sysadmins, you build remarkable teams.

Remarkable indeed. Let's have a hundred million of these people then, to run the world's IT systems. More selfishly where can I recruit 200 of them locally to run just one of my client's shops?

Assumption: Tools can fix any problem.

Face it, DevOps people are tools people. They love technology. Most have an inherent assumption that any problem can be automated away, including cultural ones.

Even when automation prevents a problem, the secondary question that gets overlooked is whether that automation
(a) is worth the prize - whether the value exceeds the cost of building and maintaining it.
(b) is simply eliminating many small errors to replace them with the likelihood of one massive error one day when the automation inevitably fails.

And don't get me started with this concept that seems to be prevalent in DevOps of mixing and matching to produce a soup of languages and technologies as a solution. No considerations of risk, TCO, skills resourcing, supplier management, obsolescence...

Assumption: Process?

A lot of talk in DevOps is about freedom, giving people room, loosening up.

You'll look a long time to find any mention of

  • capturing best methods and encapsulating them in the organisation in case the star performer gets another job offer
  • measurement and accountability
  • quality control and improvement
  • managing interactions outside the team with other groups e.g suppliers

Process seems to be a dirty word in DevOps. You can get away with that in teams who go to the pub together. You can't manage large groups without it.

Assumption: We build it not buy it or outsource it.

I'm puzzled by the huge emphasis in DevOps on "coders" and "sysops". This seems to be going against the trend worldwide to off-the-shelf solutions, or - increasingly - outsourcing.

You hear DevOps talk about Cloud a lot as a driver for Devops, but their conception of Cloud seems to be lots more server instances to automate (read: play with), not SaaS. Once again, I think this is a reflection of the tiny environments in which DevOps is currently operating. Nobody builds new huge monolithic company-wide systems any more.

The more we outsource, (and buying solutions is just a form of outsourcing), the more process, controls and disciplines we need, and the tighter the risk management required.

Assumption: We can control risk in Agile software development.

This is the biggie. There is a reason why IT evolved all the controls it did. DevOps seem to think it is because Operations people are assholes. We like to think it is from bitter experience.

Agile and DevOps are risky.

Software only has a small number of correct states. Nearly all states are wrong, many of them catastrophically so. And with more interfaced systems, the number of states goes up exponentially. I will take a lot of convincing that changing these systems faster and more often with less controls does not increase the risk of introducing an incorrect state.

It is worth bearing in mind that it is not our money, nor our organisation. If the owners of your enterprise are telling you to take more risks in IT, then you should consider Devops. I bet for 90% of you they are not. Developers may think they are risk averse but I'd love to see some research: I bet the majority would have a higher risk appetite than Operations staff, and a higher risk appetite than their employers.

Much of the weeping and wailing of DevOps is because of the "unfair" constraints imposed by those who are more risk averse. People have different ideas of "good". And a lot of IT people have a different idea of good than say the Board of Directors. The governors - the Board - define good. Others must comply. They may not want to.

I don't disagree that "High performing people work better when they have freedom". In IT generally, dev and ops, I'd bet there are hundreds of millions of practitioners worldwide. They range from "high performing people" to those you wouldn't trust to organise lunch. So I think Agilistas are naive and optimistic. Neither is a good trait when you are tasked with protecting the organisation and managing risk, which I contend are some of the primary functions of IT Operations. And as Cary King said on this blog , that only becomes more important as more is externalised to third parties. I don't think these Agile ideas of looser control are enlightened, I think they are dangerous.

The future of DevOps (and Agile)

More and more large companies are going to perform the great experiment: base all their IT on Agile and/or DevOps principles. I'm betting it will end in tears: more projects will get delivered more quickly ... but sooner or later availability, continuity and data integrity will go down the toilet.

As I said above, there is an awful lot of learning and failing has to go on before either has the maturity to be handed the keys. Right now, Agilistas look like teenage hippies, propounding simplistic solutions to complex problems, based on naive and idealistic assumptions. Similarly it will end in tears. They'll crash the car, get pregnant, and come home for money. And long-suffering IT Operations will have to clean up the mess.

As I also said above, it is possible that these ideas represent the future. Every generation thinks it is smarter than its parents and every few centuries it is true. If this is one of those times, we still need to get these ideas into clean clothes, a bath, a job and a haircut. They aren't ready to run the world.

How to deal with DevOps (and Agile)

In the meantime they aren't going away. The hippy-dippy Agilistas will continue to sit on their Swiss-balls and espouse the wondrous benefits of agility. My view: ring-fence them. Build a safe fenced-off portion of Production. Let them have control. Let the SLA state that the DevOps team is responsible for operations and support, and accountable for availability, continuity and integrity. This includes running daily tasks (reorgs etc) and running a service desk, because I can't see how operational support staff can be expected to work with a system that changes daily or weekly, unless it is the only system they work with. Make sure the customer understands (and signs off) that the increased agility comes at a risk that is outside Operations' bounds of responsibility and accountability, and that taking it on would place the rest of the organisation's IT assets at risk.

These sorts of New Age ideas tend to spring from Marketing and HR and similar business units whose systems are thankfully often fairly self-contained.

What if they want to integrate with existing production systems and modify the data? Tell them to fuck off. They can pilot in their agile sandpit, but anything that impacts existing Production comes through existing Production change control. We want to see:

  • Documentation that will still be useful after all the passionate and professional team have moved on to new and exciting opportunities to demonstrate their agile genius for fast results
  • Sociability testing with other systems
  • Training and tools for the operations staff and support staff who will be left to care for the system after the passionate and professional etc...
  • An operational readiness checklist as evidence that this system is past playtime and ready for grown-up industrial strength IT.

What if management decide that all IT is to be Agile, and modeled on DevOps? Leave. Or hunker down and wait for the inevitable.

I leave you with one great anonymous comment I saw:

[Naive] people in the industry constantly think they are inventing a solution to the problem when they are only the continuation of the problem. Software is expensive and risky and needs to be managed properly. A good software developer will understand the bigger picture, the stake holders and be able to communicate with the stake holders. A good software developer will be able to say they aren't an expert and that one will need to be consulted.

Next up: DevOps and ITIL


Dealing with the kids

This is an excellent post, and each of the points you make is quite defensible. However the time at which the car keys can be handed over may not be as far off as you think.

Firstly, DSDM is behaving in a responsible manner; the beard is trimmed and he's wearing a suit. Secondly, it is quite possible to encapsulate XP or Scrum crusties within a PRINCE2 work package. I have done this myself on a number of occasions.

still in the playpen

Yeah it's coming, but right now Agile and DevOps are still encapsulated. And I'm starting to think they will be for a long time - limited to those systems where high rates of change are competitive and hence worth the risk (see comments above)

To continue the analogy: they're still in the high-sided play-pen with all sharp objects moved out of reach :)

The DevOps Binge...

Been missin' you Skep. I need to make a mental note to read this post in full detail, but this is what came to mind… can't wait for the ITIL/DevOps post!!

I was somewhere around Change Management when the ITIL took hold. I remember saying something like, "this virtualization and cloud computing stuff is awesome…" and suddenly there was yelling and screaming all around us, and Dev was screaming: "let us drive! We can get there faster!!" No point in mentioning the huge pothole right in front of us, the poor bastards will see it soon enough. Our organization had the full compliment of ITIL, PMI, COBIT, ITSMBOK, et al. Not that we really needed or used all of this, but we were definitely into Best Practice. The only thing that worried me was DevOps. There is nothing more helpless and irresponsible and depraved than an IT shop in the depths of a DevOps binge. And I knew we'd get to this pretty soon.

John M. Worthington
Third Sky, Inc.

Don't drink and drive

love the post... also liked very much Jez's Continuous Delivery post very much!

Truth be told, whether you're on a DevOps or ITIL binge really doesn't matter.... it's really all the same Kool-Aid. If DevOps results in both Dev and Ops working together to understand and capture end-to-end service dependencies then by all means let's get the party started! Sure beats the finger-pointing that seems to go on right now (in which both Dev and Ops lose). This paragraph said it all to me:

"Because operations personnel get to see the application from early on in its development, they can feed their requirements (such as monitoring capabilities) into the development process. Because developers get to see the system in production, they can run realistic load tests from early on and get rapid feedback on whether the architecture of the application will support its cross-functional requirements. This early and iterative release process also exerts a strong pressure to ensure that the system is production ready throughout its lifecycle."

While establishing these Change, Config and Release processes --- and achieving real service monitoring intelligence --- is not easy, the concept of continuous delivery is right on... and much of it right from the Good Books.

My hope is that posts like this can help each of us reach a better understanding of the other (Dev...Ops) and share a few laughs along the way.

So let's go have that beer, but let's not drink and drive!

John M. Worthington
Third Sky, Inc.


You write, "Not only are silos inevitable in any organization with more than say 100 IT staff, but silos are not a bad thing when managed well."

Recognition of the division of labor at last!

Some context. In my former place of employment, three of six directors were moved under directors that the VP hired. Our titles were changed from director to manager. This wasn't a disciplinary action: there was no notation in anyone's personnel record. It was a "consolidation". The DevOpportunists had triumphed.

Exhibit A. My new manager said he did not know what my department (research computing) did, but call it a "little silo" despite admitting he didn't know what it was.

Exhibit B. We were required to attend many more astronomically dull change management meetings. Directors and managers of all departments had to attend to the ephemera of Windowlogical systems administurbation and superficial reports on the cleaning of digital bed pans, whether this was relevant to their job. Not to do so would encourage "silos".

Exhibit C. Job descriptions were changed to generic civil service titles, for "flexibility", we were informed. Another move to break down "silos". My job description no longer reflected my education, interest and abilities--I said so at my exit interview.

Exhibit D. We were told that we needed to work with others. Research computing had collaborated on some technically challenging projects with this director's group, but they were discounted. "Maybe you did, but I would fault you for not immediately consulting with everyone else before changing anything. You solve your own problems. By not immediately consulting with everyone else in the department, you're limited by what you know.” That we were the only group with the requisite experience wasn't the point. The perceived failure to consult with others first, no matter their level of interest, availability and expertise, was a "cultural" problem.

After a few repetitions of this mind-numbingly boring drivel, I decided that I was wasting my time in IT and that I would no longer support anyone else's research. Those days were gone. Masterful inactivity in not a panacea: while it could extend the range of fools one could suffer gladly, it cannot do so indefinitely. I would do my own research, or get out of academia altogether. I quickly obtained a research position elsewhere, and handed in my resignation.

In fact, I had waited too long to get out. Once research computing falls in the hands of IT, it ceases to be research computing, if it is subject to the same kinds of risk management appropriate for service, as opposed to research. Development is somewhere in between--tensions are inevitable since managers want to expand the domain of their responsibility. The principal-agent problem again.


Pressed for justification, a Change Manager can lose his equanimity. ”Change, change, change, change, change! That’s what we’re about!” It was an uncharacteristic outburst for a Christ-like figure with his own nimbus.

I have been critical of the absence of citations in these discussions. Let be provide a few on the subject of change.

“We believe from molecular evidence that fig wasps and fig trees have been evolving together for over 60 million years,” says Dr. Compton. “Now we have fossil confirmation that gets us a bit closer to that date. Although we often think of the world as constantly changing, what this fossil gives us is an example of something remaining unchanged for tens of millions of years — something which in biology we call ‘stasis’.”

— Science Daily (June 16, 2010), World’s Oldest Fig Wasp Fossil Proves That If It Works, Don’t Change It.

But innovation, like “change,” has no inherent value. It can be bad … as well as good.

— Joseph Stiglitz, Capitaiist Fools

You don’t need a Nobel Prize to state the obvious, but sometimes you need a Nobel Laureate to endorse it.

The same old argument...


Since you are new to this debate I'll give you the benefit of doubt. However, your arguments has been used for over a year now and each time it is used it is debunked and the authors tend to come around (remember cloud?).

Short and sweet...

1) Devops s not about Cowboys. There are cowboys in every disciple; however, cowboys are not welcome in true devops implementations.

2) Agile dones't scale... See Jez's comment... Absolutely silly and border line ignorant..

3) Devops wants to create a race of super human systems operations folk. Not even close. See CALMS (Culture, Automation, Lean and Sharing). That's what defines #devops.

4) Operations is relegated to hacks and not useful. Wrong bunch dude, pick a fight with the NoOps guys. Operations as a strategic weapon is one of the core fundamentals of Devops.

5) Devops is tool centric. CALMS starts with culture. We don't even talk about automation until behavior is understood. Yes we want to automate everything; however, we know that not everything can be automated. What's wrong with that ideal?

My friend.. take a deep breath. Change is hard, especially when on the outset it tends to disrupt something you represent .. very well. My advice is "Lean into it"... My guess in a year from now it won't seem as bad as it does now. Remember cloud?

Love the tone

My this is patronizing: "My friend.. take a deep breath. Change is hard, especially when on the outset it tends to disrupt something you represent .. very well. My advice is "Lean into it"... My guess in a year from now it won't seem as bad as it does now. Remember cloud?"

I fail to discern any reference to the literature in these remarks. I see yet another manifestation of the principle-agent problem: managers attempting to control each other's behavior. Repulsive. State your argument, if you have one. Cite the literature. Show us the data. Access to and control of data processing systems is one thing; if only capturing system and time logs amounted to the analytical prowess of a doctorate in sociology.

Make a sociologically substantive statement, "my friend." State the definitions of "culture" and "behavior" as these are understood in various IT methodologies. If these are deficient, improve them. Define those terms in a way that can be measured. Compare this with the "culture" and "behavior" of control groups versus some methodologically enlightened groups.

cloud and devops

PS. You talk about Cloud as if it is a solved problem, old hat. No its not. There are still huge legal, business, logistic and management issues around Cloud. Just like DevOps the jury is still out.

You guys no doubt think I'm closed-minded. I already recommend cloud--hosted servers and SaaS apps to clients where appropriate but that doesnt mean I wholeheartedly embrace Cloud, see it as the panacea, or regard it with anything less than the deepest suspicion until time proves it generally safe.

So it is with DevOps. I can see me recommending it in certain circumstances, but in general I see dangers to watch for, potential failure points. Only the tests of time will address those.

talking to each other

John, I expect an enlightened view from you, and I like your writings on the topic.

But even with your exposition of CAMS or CALMS I still struggle to get a consistent view of what DevOps actually is. Like any new movement it is whatever followers define it to be.

And many of them define it to be a way to overcome evil change control and release processes. Holding up worst-case scenarios of bureaucratic change control as Jez does as a justification for rejecting processes is as bad as my characterization of dev techs. Change management without Standard Change is inexcusable - if only ITIL made that explicit. And I'm a huge fan of people actually talking to each other... but so is any good manager.

Even more folk, including yourself, define it as a cultural movement to get dev and ops to work more closely together. I'm all for that. See my Dead Cat Syndrome. I fail to see why we need Automation or agile cross-disciplinary teams to achieve that. And our course Lean, Measurement and Sharing have always been essentials of ITSM.

So the only unique aspects of DevOps I can identify are a passion for ops automation, a belief that agile scales, and a desire to tunnel through traditional IT production controls. Those are where we disagree.

Incidentally my new improvement methodology Tipu advocates agile methods for process change. It is only software change where agile makes me nervous. I believe it is a primary function of IT Management (I don't like "Ops" - too narrow and techie) to be calming influence, to promote stability, risk control and maintenance of big picture and ling term considerations. Rapidly changing software with reduced controls over architecture, continuity, securoty, integrity etc does not help. I'm all for agile development up to pilot phase. I'm happy for dev to run up infrastructure for dev and test in an automated fashion. I'm cool with level3 techs having controlled access to prod to restart machines. But beyond that I think a risk-averse culture is not only appropriate, it is professional responsibility.

Now it may be in years to come that the anti-ops factions fall away from DevOps, and Agile becomes proven to be safe, and deployment and control can be automated in cost effective and low risk manner. That will be a happy day.

Until then i'll go on promoting standard change, operational readiness (dev/ops collaboration), evolutionary process improvement, and most of all cultural change programmes, all within existing ITSM frameworks.

DevOps and Agile are risky

Part of the reason I think DevOps is kept so nebulous is so that you have to engage with the actual arguments rather than using ad hominem attacks, although I admit that they can be a lot of fun.

However, the truth is that a bunch of us - including several of the people who co-authored the agile manifesto - actually come from a background working in huge IT shops where we perpetually saw big IT projects fail miserably - both in terms of value delivered, and in terms of scalability, availability, security, business continuity etc.

There are a bunch of criticisms I have of your post, but my main one is against your statement that "Agile and DevOps are risky"


Agile is not risky! Cowboy coding is risky! I thought that we got over the whole Agile = cowboy coding thing ten years ago. Apparently not. Agile requires high levels of discipline and is focussed on "satisfy[ing] the customer through early and continuous delivery of valuable software" (first principle). High quality, scalability, availability and the rest should be part of the definition of "valuable" if that's what's important to the customer. If you're really doing agile, you're using empirical data to identify and manage risks - for example by ensuring that cross-functional characteristics of your software are validated continuously from early on in the delivery process, rather than waiting until right at the end of the project to get a production-like environment to validate them in. Agile - done properly - is all about effective risk management.

However implementing segregation of duties by not allowing dev and ops to communicate, and implementing a change management process where somebody has to send an Excel spreadsheet to somebody in another country who has no idea how to evaluate the risk of the change - both implementations of ITIL & COBIT that I have seen in real life - are really, really terrible ways to manage risk.

Personally, I think that agile and devops done right actually have a lot in common with ITIL and COBIT done right. Throwing bricks at the other tribes, while entertaining, is exactly the problem that devops is trying to solve.

Your point about process is also way off base. Many of us are discussing process and trying to catalogue good practices (I co-authored a book which is an attempt to do exactly this). We talk a lot about measurement, quality control, improvement and many of the other things you mention. Yes, agile says "individuals and interactions over processes and tools", but that doesn't mean that process isn't valuable, just that you can't compensate for having crappy people by imposing a bunch of process.

However this leads me to where I think you are actually dead on target: "Agile and DevOps philosophies are predicated on an unrealistically rosy view of the standard of people available". Agile is definitely glass-half-full in this respect, and one of the conversations I have a lot with my Chinese colleagues is how the hell they're going to be able to get teams of tens of thousands of people to effectively adopt agile methodologies. Agile depends on having enough responsible adults to enforce the discipline necessary to deliver high-quality software. However, your criticism doesn't just apply to agile - it's true of *any* process. Good luck if you think any process implementation is going to make a bunch of Wallys magically deliver high performance, scalable, maintainable software (I am pretty sure you don't think this, but it's a corollary of your statements that "you can't manage large groups without [process]" and that it's impossible to find enough good people to scale agile).

To say that "You cannot use the 'empowered professionals' model on a large scale across the industry. You need accountability, formal controls, and performance management" is a false dichotomy. Believe me, I - and all sensible agilistas - are all for accountability, controls, and performance management. What I am against is when the controls are so rigid that team is unable to engage in continuous improvement because they're not allowed to make any changes to their process.

Finally, I'm totally in agreement with your statement that when you have a cross-functional team responsible for managing a service throughout its lifecycle (I dislike the term "noops" because the team should include ops people), that the SLA should state that this team "is responsible for operations and support, and accountable for availability, continuity and integrity". I am all for devs carrying pagers, performing L3 support, triaging critical incidents, and rotating through ops team, because it's the only way for them to learn how to write production-ready software.

The devops conferences I and my colleagues have attended in Europe - where the movement started - were overwhelmingly attended by folks from ops background - and much of the focus of the movement is finding ways to make devs accountable for what they do. It's a movement that cuts both ways. The tragedy is that many devs see it as ops folk bashing them, and many ops people see it as devs taking a pop at them - exactly a symptom of the problem the movement is trying to address.

an awful lot of proving

Hey I'm an active proponent of cultural change - it is my primary focus these days. And I'm all for a big part of that being better communication between groups.

Likewise I'm also a big believer in ITIL-done-properly, and this blog has a long track record of attacking ITIL zealots and ITIL-the-cult.

Especially i agree that testing, change control, release, and deployment should be as slick and painless as possible. But no more. Controls are there for a reason.

So I'm on page with some of DevOps' primary goals.

I don't doubt that some of the core thinkers of DevOps such as yourself are Ops-sympathetic or even ex-Ops. But DevOps as a movement still has a hefty element of SmashOps, which drives that polarisation you speak of.

Dev are from Mars and Ops are from Venus. there is a huge cultural disconnect and I for one don't believe it is artificial. As one comment I read put it: "the gap between dev and ops didn't used to be there. It was put there for a reason". Right now it seems to me most DevOps practitioners know more about dev than they do about ops, and the minority who do know ops think that it is all about tools and automation. To me Ops is about managing and stewarding (and protecting) the business's IT services to provide service delivery to agreed standards, and adopting new services with maximum value and minimum risk to the organisation. Not many puppets and chefs in that definition.

Right now DevOps is a good idea finding its way. The suggestion that I might propose to most of my clients that they unwind thirty years of IT process evolution and open the gates to their precious production systems today on the basis that it seems a good idea is just laughable. I'm watching with interest but there is an awful lot of proving to be done first.

Creating resilient systems

I accept that there is a deeply ingrained difference in mindset between developers and operations - a combination of a (lack of) experience and the fact that dev is measured by throughput and ops by stability - and I would never allow devs carte blanche access to prod. In fact, I don't think anybody should ever be logging directly into prod except in an emergency.

The problem is that the barrier that has been put up has, in many cases, actually made things worse overall in terms of the ability of organizations to manage risk. This isn't the fault of ITIL and COBIT, but it is the fault of many of the people implementing ITIL and COBIT, and many of the people auditing these implementations who come from an accountancy background. I like reading your blog because, as you say, you are pretty spot on in your attacks on ITIL zealotry. I actually think ITIL and agile can co-exist - I blogged on doing [ ITIL change management in an agile fashion] - and I co-authored an article in the August 2011 edition of the Cutter IT journal which discusses at a high level how they can work together.

You're quite correct to say that unwinding 30 years of IT process evolution is madness. It needs to be evolutionary change, backed by evidence. Devs need to prove they can create production-ready software and reduce the risk of releases before ops should begin to trust them and give them more access to environments. However in order to do that, devs need help from ops - the ability to spin up production-like environments for testing purposes, for example - there is a long list. Devs also need to understand what happens in ops, which is why they should be doing L3 support, rotating through ops, and carrying pagers. But fundamentally I believe - and I have seen evidence that shows - that stability and increasing the rate of change are not a zero-sum game, and that in fact increasing the rate of change can actually improve the stability of production systems, *if you are disciplined about your delivery process*.

I do take issue with your claim that "most DevOps practitioners know more about dev than they do about ops, and the minority who do know ops think that it is all about tools and automation". Automation and tools are definitely part of the story, but I've always said that progress with automation should happen incrementally as part of a programme of continuous improvement rather than as an end in itself, and that tools are never the right place to start, although of course they are important to enabling any automation effort.

As you say though, the proof will be in the pudding. Like you, I am not advocating that people drop everything and go agile / devops - but [ for strategic projects under active development], it definitely does make sense. If enterprises don't start adopting agile for these kinds of projects, many of them are not going to be around in 10-20 years' time.

agile change

Jez, I don't recall seeing your ITIL change management in an agile fashion post. It is a superb post, everyone should read it, especially bigots at both ends of the spectrum. It lays out precisely how ITIL Change doesn't have to get in the way.

But how telling that the very first comment you got was in the "this'll never work with those ops assholes" style.

And the next one from Peter Brookes was on "how do you have continuous training and awareness of end-users and support?" It is all very well to change software at lightning speed but you can't change process at the same pace and you certainly can't change people that fast. Peter's point is:
When someone calls the service desk to say they don't understand the new feature, how the heck do the service desk know what they are talking about?
When someone calls to make a new kind of request, likewise how does anyone know how to action that?

Your other post I don't agree with so much. i think "if you don't do all your strategic development in agile you won't be around in 10-20 years" is melodramatic. Well actually its not because the majority of organisations wont be around in 20 years anyway :)
If extremely high rates of change in a system is a strategic essential in order to compete, then you better be considering high rates of change. But that is true of only a small percentage of all "strategic" systems which are in turn a small percentage of all systems - most are utility. I maintain my position that agile development and agile ops are niche techniques. Most of the time stability wins.

but going back to your first post, i am still in favour of the concepts in any case. Change Mgmt will only ever achieve successful cultural acceptance if it minimises pain and maximises efficiency, which is all about Standard Change and easy CAB and all the "agile change" you describe :)

doesn't reflect the attitudes

"I don't doubt that some of the core thinkers of DevOps such as yourself are Ops-sympathetic or even ex-Ops. But DevOps as a movement still has a hefty element of SmashOps, which drives that polarisation you speak of."

I'm really baffled by this - the DevOps strawman you attack in this article doesn't reflect the attitudes of any of the self-identified DevOps crowd that I've spoken with. Straw polls at meet-ups generally find 50+% of attendees working in operations (I'm one of them).

The "NoOps" crowd are derided by the DevOps folks as entirely missing the point, for exactly the reasons you mention. I don't see credible calls to minimise or eliminate Operations (unless you're giving far too much credence to Forrester), nor for system administrators et al to have an active role in writing application code. A team of specialists collaborating effectively can create better outcomes than a team of generalists sharing only shallow experience with the various skills required.

I hope that your forthcoming "DevOps and ITIL" article will focus a little more on those facets (or interpretations) of DevOps that you think are compatible or shared with ITIL, and the ITSM view of the world. Dismissing all of DevOps on account of a few loony interpretations is no less counterproductive than dismissing all of ITIL because some organisations make change management their business prevention process. Well-run ITSM may be the foundation on which the DevOps culture can flourish, and wouldn't it be great if a bunch more people were actively working to increase the number of organisations that are doing it right?

I'll be looking through your archives as you've clearly got a lot of valuable experience to learn from, and I don't imagine the audience you had in mind for this piece is the crowd who develop a nervous twitch at the very mention of ITSM.

Thanks for writing it, in any event.


moderate DevOps

So if you mix in moderate DevOps circles, what do you make of all the assumptions I cite? If I accept that I'm being over-defensive and DevOps are not the barbarians at the gate wanting to undo all the good work (which I don't yet), then let's get past the cultural clash issues: convince me it will work in a traditional moderate-to-large scale legacy-IT setting. I say it won't scale.

And convince me there is some difference from the way we do IT now other than improvements which good ITSM is striving for anyway. Some visions of DevOps sound like the status quo but with a sprinkling of new automation toys. In that case DevOps is equally attacking a strawman "failed IT" which doesn't relate to actual experience.

Syndicate content