Welcome!

Rule #1 for your Digital Transformation is to Fail, and Fail Fast!

Christopher Harrold

Subscribe to Christopher Harrold: eMailAlertsEmail Alerts
Get Christopher Harrold via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: DevOps for Business Application Services, DevOps Journal

DevOps: Article

Taking Back IT - DevOps: Part 2 By @CHarrold303 | @DevOpsSummit #DevOps

The _____ as a Service mindset

One of the things that is bugging me about DevOps and the current conversations about it, is that they are all really heavily Dev focused and talk a lot about tools as they relate to the developer. This isn't a bad thing, but I find myself asking constantly where's the Ops in DevOps!? As an operations person (as I spoke about in my first blog in the series) I really want to speak for the other side of the coin and talk about the ways to marry the Dev concepts of continuous release, test-as-you-go, and agile development into the more static and often rigid world that traditional operations so often finds itself in. Operations has long been the guardian of the platform, acting as the gatekeeper to it for users to consume its resources which has created the stereotype of the aloof, surly, IT person hiding in a cave in the basement (thus the "IT Crowd" reference in my image for this blog). If you are going to truly embrace the DevOps mindset, that has to change.

I said in an interview on TheCUBE last year that analytics environments are the "Killer App for DevOps" (you can see the interview here: http://bit.ly/1PWn6y1and if you are impatient, the quote is at the end). Since I gave that interview, I realized that I haven't really given much time to explaining the reasoning behind that statement aside from the point that analytics environments by their very nature are perfect use cases for a mature DevOps approach. As I have been thinking more about this and working more and more on analytics platforms for a variety of customers and verticals, it occurred to me that the reason for the alignment of the DevOps mindset and process and the analytics environments that companies need is more than just the basic case of "because it makes stuff easier". There are some key areas that make this the perfect storm of a technology set and a cultural shift coming together to actually cause radical change across the industry. At least it can, if organizations get on board with the key alignments (http://bit.ly/1PEmhhD read the first blog in the series about the power of communication as the primary tool in the DevOps arsenal!).

In my next few posts, I want to talk about those areas of alignment in more detail, starting with the first area that Operations has got to start understanding and embracing:

____ as a Service
It isn't just software, or infrastructure, or even analytics, data, apps, whatever. It is literally the concept that EVERYTHING should be a service. If I cannot take what I have built, package it in a highly-automated, simple to manage, and easy to reuse manner, and then set it free in the wilds of my enterprise then I simply shouldn't be doing it. Period. Said another way, if I cannot run it as software it's no good to me. Why? Because in the new DevOps world, everything has to be software defined to be functional enough to support the agility we have come to expect. This is one of the most painful things for legacy operations (and indeed a lot of legacy IT infrastructure vendors) to come to terms with, but if you want to know why it has to be, take you phone out of your pocket and download a new application. That experience, it's speed, simplicity, immediate functionality, and seamless user experience is now the expectation of every user you support.

To be fully clear, this is not something simple to introduce, or even to build, because as I will say many, many times, you cannot buy a DevOps - it is an ecosystem of things working together. Building this ecosystem is a process that takes time, effort, and the willingness to fail before finding success, but simply put it cannot and should not be put on the back burner. It will take a lot of relaxing of the "old normal" experience of operations wherein we didn't experiment and we wanted to have a constancy of steady-state days. The demands of the agile digital business means that operations has to accept that steady state is what happens over night when you aren't working, or in between operation and environmental releases. It is no longer something we reach and stay at as long as possible. Operations is now a constant journey between points in time, from one stable point to the next (or possibly back to the one before - we will talk about the specifics and techniques of the Ops journey in a later post)

This mindset of wanting operational systems to remain more or less static has also become increasingly seen as a roadblock, and while there is merit to this argument, there is something important to consider. Part of the Operations charter (our Hippocratic Oath if you will) is that Ops is there to prevent people from doing something dumb. In the world of seamless technology and speed it is all too easy for people to do things that are very, very dumb with no chance at recovery. Things like this (courtesy of the guardian: http://bit.ly/1cnCkzl), this (also the Guardian http://bit.ly/20keiaV), and this (from PC World http://bit.ly/1mVLicY) you can find many more with simple google searches for data breach and data loss. There is a specific commonality to all of these in that there was someone in a traditional operations/security/policy role, trying to protect the company and trying to protect the data, and in the interest of speed, simplicity, and innovation all of those controls were ignored/deprecated/or not implemented at all. It isn't that the intended result was bad, but that we are all so ingrained into the "share it all and move as fast as possible" world that on-demand tech has created that security and policy become afterthoughts to everything (take the NHS England example; mapping patient issues can highlight real environmental health concerns and I am a huge fan of innovating in all areas with data analysis). This is exactly why Operations still matters. The proper marriage of Dev and Ops is not simply to remove Operations from the equation, because that is just another way around policy for the sake of speed.

DevOps is also not just about the "cloud like" experience, or even just automation and management tools. It is about marrying up all of the tools, the platform itself, proper policy and governance, and then stitching it together to make something more; a system that enables something much greater than the sum of its parts. Why is this so important in the discussion of DevOps/Analytics alignment? Because this is the same mindset that every analytics model follows - build the model, test the theory, and then iterate and improve constantly. That is DevOps and it is also analytics, and so this must become the new Ops mindset for DevOps:

  • Rapidly prototyping - trying new solutions for specific problems in small, but measurable chunks
  • Moving quickly on from any failure and trying new paths - letting go of the pride of ownership (not easy!)
  • Acceptance that steady state is just a momentary point in time and not the end of the journey
  • Agreeing that there is a right balance between the speed desired and the governance required
  • 100% commitment to the overall goal - to keep ahead of the competition which is everyone and everywhere

This last one is a big part of the need for the conversation we talked about at the beginning of the series, because in the Digital Wasteland everyone is the competition and failing to transform is agreeing to die.

I will talk more about this next part of the alignment in my next post. Please let me know what you think and what other topics you are interested in, in the comments or on twitter: @charrold303

For more posts visit my LinkedIn Blog Series.

More Stories By Christopher Harrold

As an Agent of IT Transformation, I have over 20 years experience in the field. Started off as the IT Ops guy and followed the trends of the DevOps movement wherever I went. I want to shake up accepted ways of thinking and develop new models and designs that push the boundaries of technology and of the accepted status quo. There is no greater reward for me than seeing something that was once dismissed as "impossible" become the new normal, and I have been richly rewarded throughout my career with this result. In my last role as CTO at EMC Corporation, I was working tirelessly with a small group of engineers and product managers to build a market leading, innovative platform for data analytics. Combining best of breed storage, analytics and visualization solutions that enables the Data as a Service model for enterprise and mid sized companies globally.