DevOps shouldn’t be a straitjacket

The companies implementing DevOps are diverse; so are their needs

Posted by Trevor Pott on Mar 15, 2016 in Blog | Comments Off on DevOps shouldn’t be a straitjacket

The DevOps movement has a dirty little secret it doesn’t want anyone talking about.  DevOps isn’t about making you money, or making your life easier.  DevOps is about making vendors and consultants money.  If you’re lucky and wise you will be able to choose good partners who, in the course of enriching themselves also make your business significantly more efficient.  But how to narrow the playing field?

The most important thing to do is ask “where does the money go”?  Anyone banging on about an IT industry buzzword wants your money.  The question is how much do they want and what are they proposing to give you for it?

In almost every case you don’t need a consultant to get to DevOps.  I can tell you the secret sauce of their advice right here: DevOps is hard to implement.  This is not because the tools are difficult, the theory is complicated or the value vague and nebulous.

DevOps is hard to implement because it means radical change for many people, many of whom cannot easily see how or why they will still be employed after the process is completed.  Fear, and a very human resistance to change are what stand in the way of “implementing DevOps culture”.

No consultant can change that.  No consultant can do anything to ease people through the process or soothe their fears.  Management of the business in question need to recognize the fears of the technologists they employ, engage with them, and provide assurances that everything will be all right once the dust settles.

No consultant can do that for management.  The best they can do is spend their time trying to serve as a translation layer: explaining to management why the tech staff are reluctant, and explaining to the tech staff that management says they have no choice except compliance.

Whether or not you need a consultant for the above, (instead of, for example, management with an iota of human compassion and empathy,) is something that is up to each organization.  No blog can make that decision for you.  That leaves an exploration of the tools that make implementing DevOps easier.

Practical Tools

The easiest for everyone is if there is a specific product is on offer.  “Buy this product and it will do X” is usually a fairly straightforward proposition.  Admittedly “buy this product and it will change your corporate culture so that you achieve DevOps utopia” is likely to be a scam, but there are plenty of products I’ve encountered that are excellent steps forward.

Trying for a DevOps culture all in one shot usually fails, but if you change things incrementally with tools that make everyone’s life a little easier then getting there from here encounters a lot less resistance.  This means that selecting products and services that solve a piece of the puzzle (instead of claiming to be the whole of the solution) can often prove beneficial.  It gives you the advantage of being able to phase change in at a more acceptable rate.

DevOps tools can be difficult, however, because each vendor has their own ideas about how their piece of the DevOps pie should be made.  Vendors understandably want to make tools that are easy for them to make.  Unfortunately, this all too often leads to vendors asking customers to change what they are doing (or planning to do) in order to conform to the tool they produce.

Rarely do you find a vendor willing to listen to customers (or potential customers) and seriously take questions, concerns and suggestions on board.  What if it didn’t have to be this way?

The importance of listening

There are plenty of vendors who are waking up to the fact that DevOps is a huge movement that is changing the face of IT around the world.  If they want to survive they need to adapt their products to be useful in a DevOps world.

These vendors are learning DevOps just as their customers are.  Vendors who aren’t DevOps-specific startups (hopefully) aren’t jumping in with a set of preconceived notions about how things should or must be done.  In theory, they should be willing to listen; to grow and evolve just as their customers are growing and evolving.

I hope to find many such vendors.  DevOps is a seemingly inevitable change in how IT will be done at any organization that develops its own software, and the number of organizations developing their own software is exploding.  This means we’re going to need a largish number of vendors who can offer a diversity of products that meet the needs of the innumerable companies all moving towards DevOps.

Topically related vendor plug

I have been working with a DevOps tool vendor recently who would love a chance to talk about the above: Catalogic.  Like any vendor, they have their story to tell.  Unlike many vendors, they also have a keen interest in listening.

On Thursday, March 17th I will be hosting a webinar with Catalogic that is all about their take on DevOps.  You can register for it here.  What’s important isn’t that you listen to how they can make the transition to DevOps-style IT easier.  What’s important is that you bring a fistful of questions and your own unique perspective, thoughts and ideas to the table.

Here is a vendor willing to listen.  A vendor ready to grow, adapt and change to meet the needs of its customers rather than demanding that customers change to suit them.  That’s rare.  It’s something I’d like to encourage.  So let’s all get together and talk about the practical realities of implementing DevOps.

Speak and be heard.  For once, someone is listening.