The journey to DevOps begins

My experience with technology operations started about 1998.  I had it ingrained into me that the right model was Plan Build Operate.   I was never entirely happy with the model.  It worked. But it was very waterfall paradigm.  The Planners were usually oblivious to Operational issues and usually they had moved onto the next project so had no incentive or interest to fix problems.  More often than not Test added no value other than letting Operations know what didnt work when it went live. 

All in all it was a bunch of silos leading to Operations being the poor citizen with things being blindly thrown over each wall inexorably destined to Operations.

Over time I started experimenting with organisational structures to address these short comings.  Letting Developers loose on the network didnt work.  They had no discipline.  If they "fixed" something and it didnt work, they didnt know how to get back to a known state and it was left to Operations to clean up the mess.  The Ops guys were cautious since change equals risk.  The end result was often  obsolete software versions as the mentality was if it isnt broken, don't touch it.  End result service velocity, innovation etc were stifled by the resistance to change anything on the network.   Services works great but equally there was nothing new. With my business head on this felt wrong.

I was resigned to the Plan Build Operate model and became involved with ITIL and eTOM concepts to make the best of a bad situation.  Problem Management became my friend.  It was a great way to hold the Planners and Builders to account for incidents they had caused.  It definitely improved quality of service.  IT Service Management concepts also moved the mindset from boxes to customer experience.

Configuration Management became close to my heart.  It is the documentation of the network or rather should be.  I had many attempts to get documentation right but it never was right when it mattered.  I referred to it as the port 10 problem.  If a Build instruction says plug into port 10 but the engineer gets there and there's something plugged in what should he do?  Should he unplug it?  Should he abandon the job (usually in the middle of the night)? Or should he use his own judgement.   My policy was abandon the job - this had consequences of course - rework, lost time and all the other business consequences but it at least meant whatever was on port 10 wasnt broken.

About 2005 I started to see a different mindset for Configuration Management.  It was that the network was right - what the equipment said was the configuration was the right configuration.  The offline CMDB (Configuration Management Database) could never be right unless the process was perfect - and it seemed that no amount of process ever made the CMDB right - the network was a moving target.   Looking back, this idea that the equipment had the answer was the first hint at the DevOps model.   I had some attempts at getting the network graph dumped back into the CMDB but it never quite worked.  About this time I started getting into Agile and interestingly Agile did make some progress at making the CMDB right if done on a small scale - everything else always seemed to be a boil the ocean project.

Also around 2005 I started getting involved with virtualisation and blade technologies.  Having been frustrated with error prone server deployments this seemed great.  The ability to spin up servers rapidly was a great concept.   The automation side was also highly attractive - invariably building services was error prone - I guessed 10% of the network was wrong in some way.  I liked the idea that it was possible to programmatically build the network - it was more likely to be right since there was less human involvement.

And so things progressed - it wasnt until about 2011 that I first heard the term DevOps. The journey had begun.