The expansive views across London from Puppet Lab’s new office in Aldgate Tower were a fitting backdrop to a great evening of DevOps discussion and debate at the XebiaLabs DevOps After Dark event. As the sun set and the city lights rose, myself, Andreas Prins of ING, Tim Buntel from XebiaLabs, and Jon Boero from Puppet Labs got down to some serious DevOpsing!
Over the course of the evening many key connected themes for enterprise DevOps emerged, here are the top four.
According to Andreas Prins, IT Manager at ING, the key reducing complexity in the enterprise is to “simplify everything”. For example, all nine countries where ING has a presence share a central set of APIs, a “harmonised engine”, in his words, that brings consistency and predictability to IT across the business.
Reduced complexity and automation means that the chances of manual errors occurring is greatly reduced. Over the three years that Andreas has been at ING, he has seen the average number of open operations incidents fall from 150 to just 50. This frees up huge amounts of time, which his teams can use to build new software that adds value to the business.
He also touched on an often-overlooked consequence of reduced complexity. We focus so much on the technology that we forget its effect on the human beings using that technology. Complex, frustrating IT systems leave you with unhappy, low-energy teams.
But how can you tell if what you are doing is working?
This was the second key point and where Tim Buntel’s presentation stood out. XebiaLabs’ VP of Product’s focus is metrics, metrics, metrics. And so should yours be.
Metrics, metrics, metrics...
Tim sees enterprise IT metrics as being divided into two phases. In the first ‘DevOps’ phase, the focus in on time to delivery: delivering quality software at scale in a highly-efficient manner.
He suggests honing in on the following metrics:
- Time to delivery: this helps you find out which phases of your development process you should tackle first
- Deployment frequency: this simply provides more opportunities for improving your software
- Change volume: releasing frequently is only useful is what you’re releasing is impactful
- Success rate: your releases have to be successful to have an impact!
- Mean time to recovery (MTTR): failures aren’t inherently bad, you just need to be able to react to them quickly
But, as incredibly useful as these phase one metrics are, reducing the software cycle is a waste of time unless someone actually cares about what you’re developing.
According to Tim, two-thirds of software changes are wasted because they either go unused or are simply worse than what was originally there.
This is where Tim's phase two comes into play: reacting to human feedback to improve the software in ways that are actually useful to the end users.
Here, he added four more advanced metrics to look out for:
- Adoption: is anyone using it?
- Happiness: are your changes delivering value?
- Business impact: does it help meet business goals?
- Cultural impact: does it help you retain happy staff?
I took the stage after Tim, to talk about the enterprise journey to the cloud. And I picked up exactly where Tim left off, by highlighting the ultimate metric that should be the guiding light for enterprise IT: the reduction of the time to value.
Time to value and shifting everything left
As Andreas and myself both highlighted, DevOps is not an end in and of itself. The third key point of the evening was that the end goal should be improved time to value. It should not be jumping on the latest bandwagon.
Too often, organisations jump straight into the cloud as the first step on their digital journey. But moving to the cloud might not be the most important step you should be taking right now. Before you do anything, you need to be aware of how you’re spending your time. You need to have key engineering processes in place first: Continuous Integration, Agile, Continuous Delivery etc.
Once you have these processes in place, the next crucial stage is to include key activities (integration, testing, monitoring, compliance etc.) as early in the software delivery process as possible. This means that any deviation from the quickest route to time-to-value can be identified and rectified as soon as possible.
For example, include testing as early as possible, and make sure that you end security and compliance requirements are baked into your testing processes.
To summarise, make sure you identify where you are, where you want to be, and how you can embed the necessary processes that will get you there as far left in the delivery pipeline as possible.
You’re not a special snowflake
Last up was Puppet Lab’s Senior Technical Solutions Engineer, John Boero, to talk about all the myths surrounding DevOps - and why they’re misleading.
Without going into each in detail, it’s worth pointing out that most of these revolved around the tendency of IT departments and their managers to see their own department as a special case, with an utterly unique situation that means that DevOps isn’t applicable to their case.
Needless to say, these myths are more-often-than-not predicated on imagined fears about what will happen with their team (we’ll all be fired!), that other departments will not approve (auditor says no), or - the worst one of all - that you can just upgrade your technology to Continuous Delivery or containers, without simultaneously upgrading your processes and culture (i.e. DevOps).
Any enterprise stands to gain from making progress towards DevOps, because ultimately, as mentioned above, DevOps is about reducing time to value. It’s about taking the value that your organisation creates already, and ensuring it gets delivered in the most effective way possible.
DevOps is more of a no-brainer than ever
Many thanks to XebiaLabs for hosting the event, and to Puppet Labs for providing the venue.
DevOps After Dark demonstrated that the business case for DevOps in the enterprise is only gaining in strength as the number of use cases climbs and concerns are ironed out over time.
To summarise in a single sentence, the experts at DevOps After Dark suggest the following for any enterprise looking to move to DevOps: start by simplifying and automating, then focus on the right metrics so that you can be sure you’re delivering the value you need quickly enough to ensure competitive advantage, shift everything left as much as possible and, most importantly, no excuses!
Start your journey to DevOps today with our Enterprise DevOps Strategy Accelerator!