Sunday, May 26, 2013

DevOps- a preliminary look

This is a posting I've been working a bit on for sometime.  I decided to at least get this out, as its a topic I will probably be visiting more in the future.

As a long time IT professional, I've had to deal with process and procedures.  These are needed to manage the systems we are responsible for and deliver the services we should be.  Even as security professionals, we need to understand that our job is to secure these systems to help ensure that the delivery of them is not interrupted.  And often times this means doing so in a consistent matter, which happens when we follow procedures.


Often times others in the field are more interested in getting things out quickly.  Or, they are so busy "putting out fires" that they don't want to be bothered with process/procedures.  These people don't understand that often not following process/procedure, doing things quickly, is the cause of many of the fires they fight.  And many times the issues this causes can lead to management basically wanting to throw up their hands and outsource the whole deal.

When I came to work at my long-time former employer, the group I worked with had a well defined development process based on CMM (Capability Maturity Model), most likely because they worked to support software and hardware engineers, and so following something similar was understood.  Not everyone in IT agreed, as most felt it was too complex.  As part of the group, I was involved with helping improve things, and we eventually got evaluated at CMM Level 3.

I do think one result of this is that we showed our value to the company, and when our company outsourced IT, they didn't outsource our organization, as we showed we could do as good or better then the outsourcers, for less money.

Others out there were also working on IT process/delivery improvement.  A series of books by Harris Kern and Randy Johnson (and others) in the mid-1990s focused on this as well (Rightsizing the New Enterprise, Managing the New Enterprise, Networking the New Enterprise, Building the New Enterprise).  Harris Kern continues this work with his Enterprise Computing Institute.

Sadly, the work of that organization I was a part of was abandoned.  We worked on it over several years, and I don't think anyone even bothered with documenting it or the like outside the organization.  I tried a few times to propose a paper to the LISA Conference, but never got any traction.  Now all that work is long gone, the people involved in it long moved on to other companies.

After that, our group looked at a couple of other methodologies that came later.  First it was COBIT (Control Objectives for Information and Related Technology), then it was ITIL (IT Infrastructure Library).  Nothing got adopted.  We eventually went with a vague Plan-Build-Run concept within the corporation, with most of IT doing "Run".

Lately, I've been hearing of interest in something called "DevOps", which is meant to be a way to effectively organize IT.  A combination of Development and Operations.

A leading work on this is actually a novel, called The Phoenix Project.  The people behind it developed a trio of books called "VisibleOps", as a way to roll out ITIL (am way oversimplifying it).  They are now working on a DevOps Cookbook that would better explain it.  I am currently reading the The Phoenix Project.  And yes, some of what it says does apply to IT Security, tho its focus is on the broader realm of IT.  I hope to have a review on it in the near future, and topics I touched on here will be brought up again.

Anyone have any experience with the above?  Please comment.

Here are some resources.  

For more on VisibleOps, check out the IT Process Institute.
For more on DevOps, The Phoenix Project, and the upcoming DevOps Cookbook, go HERE.
Gene Kim, one of the authors of the book, has his own site HERE.  Lot of good info.

1 comment:

  1. I'm currently right in the middle of "we don't have time to follow procedure" firefighting. It's unfortunate as they could easily become far more effective with structure and "doing it right once" instead of a new "quick and easy fix" every time.

    Core lesson is that you need IT mgt to push the changes (like Bill in the Phoenix Project). Otherwise nothing will change. And convincing management of anything is not always easy...

    ReplyDelete