| | July 20179CIOReviewscale (that changes with scale, but even at scale, the role is different than what it was historically). Suddenly developers found themselves responsible for both creating code and managing infrastructure.But here's the thing: nowhere in DevOps is there a license to eliminate control and transparency requirements, particularly in regulated companies. There seems to be an understanding that being a DevOps shop somehow absolves a company of the need to meet regulatory /industry-compliance standards (e.g. SOX, SOC II, PCI, etc.), or that it obviates the need to implement auditable Change-Management procedures, or to maintain an authoritative configuration management system, or to have a formal mechanism to track and eliminate recurring incidents (Problems), or to manage assets, etc. I could go on.In reality, ITIL and DevOps are perfectly complementary. In fact, there have been provisions for DevOps since ITIL V3--even if those provisions weren't designed explicitly for DevOps. In one of my previous positions I led the development of a hybrid cloud. It was a big shop with thousands of developers. DevOps was well adopted. Within six months of the launch of the hybrid cloud the developer community had self-serviced their way to building 20,000 VMs. What the developers knew was that they were programmatically creating and tearing down operating environment capacity--the liberation of self service and on-demand operating-environment capacity. What they didn't know was that they were all operating in perfect compliance with our IT Services Management processes and the controls framework.For all 20,000 VMs there was a change record created through the ITSM suite and a Configuration Item created in the CMDB. Since the creation of a cloud VM was a "Standard Change," all that was required was a record of the change --no manual change review required. And that change record was created in an automated way. The same thing with the Configuration Item--information about the VM(s) was (were) collected during the instantiation process, and fed through to the CMDB.Why is this important? Less controlled shops work okay in startups, when the ratio of scale and velocity to the people required to keep mental track of assets, relationships, etc. is pretty low. The need for a more mature process (which, again, doesn't have to represent a lot of friction) emerges at scale and/or when companies become regulated, either by becoming publicly traded and falling under the purview of Sarbanes Oxley, or by being in an industry regulated by another agency or standard like the SEC, the FDA, etc.Keep one thing in mind as you navigate toward DevOps, or as you integrate it more deeply within your organization. The functions included in ITIL will still have to be performed. You'll still need to fix things when they break (Incident Management); you'll still need to track down the underlying cause of recurring incidents (Problem Management); you'll still need to know which technologies you're running in your environment and what their relationships are (Configuration Management), etc. DevOps is a great enabler, but it's a method of execution, not a replacement for an IT Services Management Framework. ITIL is still the definitive reference for that--alive and well. Less controlled shops work okay in startups, when the ratio of scale and velocity to the people required to keep mental track of assets, relationships, etc. is pretty lowDave Blodgett
< Page 8 | Page 10 >