It's the Ranger4 #DevOpsFriday5 series - today's contributor is John Rakowski. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
Reading this question I immediately thought of a bickering family – specifically in regards to DevOps and ITIL. Firstly, let’s start with Agile, the reality is that a lot of DevOps principles were born out of Agile software development. The original Agile Manifesto has principles such as focusing on customer satisfaction through continuous delivery of software, welcoming change requirements etc etc. These principles were all carried over into DevOps thinking which added the importance of Ops and the business into these areas. Hence – DevOps. So you could say that Agile is the Mum or Dad of DevOps and that DevOps is the plucky upstart teenager.
In terms of DevOps and ITIL. Well if DevOps is the plucky upstart teenager then ITIL is bit like the embarrassing uncle that no one wants to talk about today. ITIL focuses on delivery quality but in many circumstances, at the expense of speed. Problem is that speed and quality go hand-in-hand in today’s digital business. I know I have sat on my fair share of needless CABs in the past! The issue is that many enterprises that I have worked with have tried to implement rather than adopt ITIL and I am sorry to say, have failed to think about their processes from an outside-in perspective. The reality is that ITIL was never supposed to be just lifted from the books and implemented. Also the last major revision of ITIL came out in 2007 meaning that some of the described best practices are very out of date. All of these points make ITIL the embarrassing uncle today.
DevOps and ITIL really have to get on, especially in the enterprise. Many enterprise IT organisations (for better or worse) are structured via the ITIL processes and ultimately; both approaches/ways of thinking/frameworks want the same thing – What’s best for the customer. I see a big disconnect between DevOps and ITIL today, which really needs to be repaired.
2) Can you describe what DevOps looks like when it’s ‘done’?
Depends on how you define DevOps? In my time as an analyst at Forrester and now Director of Technology Strategy at AppDynamics I have heard different DevOps definitions. From my perspective, when DevOps is ‘done’, then there is a fluid relationship between the business (marketing, line of business, digital etc), development and operations. Everyone understands the needs of the customer and their role, plus importance in the software lifecycle. This means that technology, process and people decisions are always made with the customer top of mind. I would also love to be able to state that when DevOps is done right then this removes organisational politics and creates perfect harmony between teams… but I think that’s really a bit far fetched!
3) What do you think are the key metrics for DevOps?
I think organisations need to think about DevOps metrics in three areas:
In my experience most measurement strategies in regards to IT based initiatives focus on technology, but it’s ultimately your focus on people that will lead to success. This means employees and the customer. Two key metrics here are:
- Key employee retention – There will be employees in your team and your business that are key to DevOps success. Those who understand that DevOps is about taking an outside-in approach, focusing on business outcomes and delighting customers. Also those who can combine Development and Operations skills. These are skills you will want to hire, develop and retain. DevOps is a hot area from a job market perspective so you will want to make sure you keep talent in your business. Therefore identifying those employees who are vital to your DevOps efforts and then tracking retention is a must.
- Customer satisfaction/experience – Ultimately DevOps success is not about fast release, collaboration or automation etc. Rather it’s about making sure that software fuelled business services satisfy and delight customers. This means that tying DevOps to customer satisfaction or experience measurements is vital. One option here is to link your DevOps measurements with Net Promoter scores if your company uses this popular customer satisfaction metric.
From a process perspective, the essential metrics which focus on release and change are:
- Release/change frequency – One of the key drivers for DevOps adoption is to release new features or applications quicker than before. The aims here are to make sure that your application users (customers or employees) receive the value they need, are happy with functionality and ultimately stay loyal to your business. So measuring release/change frequency is essential. It could also be said that release/change frequency is one lagging metric for the leading measurement of customer satisfaction/experience.
- Volume of failures – This measurement goes hand-in-hand with the measurement above. There is no point being able to release quickly if these releases fail and have to be rolled back.
- Time/cost per release – Okay, maybe this should technically be two metrics. Time is money and money is required for a successful business. This means that it’s critical to measure the time taken and cost per release especially in regards to E-commerce based applications. If the cost of frequent releases outweighs the profit brought in by the application, then your DevOps adoption is not generating the business benefits that it needs to.
There are a number of technology metrics that you may choose for your DevOps adoption but here are my three essentials:
- Mean Time To Resolution (MTTR) – As mentioned, ultimately DevOps is about making sure that software strategy drives successful business outcomes by providing applications that help to deliver the service customers want. As such performance or availability issues are a DevOps strategy killer, and focusing on keeping MTTR measurements as low as possible is important. To improve, an end-to-end monitoring solution, which monitors end-user experience through to the application database or data store is critical.
- Mean Time Between Failure (MTBF) - This metric comes from software engineering practices and focuses on making sure that applications are available. In the software-defined business highly available applications are key as they fuel business success. Therefore this metric is important BUT
- Mean Time To Customer Impact – The reality is that failure only becomes an issue when it impacts a business process or the customer. Also failure as per my culture blog post is not a negative in DevOps as the mantra should be fail-fast, fail-forward. A good APM platform will help you to isolate and automatically remediate emerging application issues quickly before they impact the customer. Therefore focusing on Mean Time To Customer Impact is an essential metric for DevOps and monitoring efficiency.
4) What attributes constitute a culture embracing DevOps?
To define culture and what it means for DevOps you have to understand the starting point, or the challenges that your enterprise’s operating model currently faces in regards to software strategy and what the end, new ‘DevOps’ operating model looks like. Here are a couple of examples:
- Shift from a fear of failure, to a fail-fast, fail-forward approach.DevOps is about speed. If your operating model today promotes zero failure and employees are scared of failing then you will stifle the ability to innovate, to promote new ways of doing things, to move fast. Failure can be good so long as we learn and improve. This is all part of innovation, which is central to DevOps.
- Shift from a tech obsession, to a customer obsession. In today’s digital world, it can be so easy to get caught up with tech buzzwords such as mobile, wearables and cloud. But the rules of business have not changed. Deliver what your customers want, delight them, and hopefully they will help to promote your brand. This means that every employee has to think about the external customer, their needs, their wants in order to guide strategic decisions. It’s about moving from an inside-out to an outside-in operating model.
- Shift from organisational silos to a collaborative model. Let’s face it, the desire for collaboration across different business functions has always been a goal. But collaboration is never as good as it can be. I could write a whole book about why, but largely this is because business = people = different agendas = politics = failure to collaborate. To move fast, deliver quality software rapidly, and then it’s essential we get collaboration right. This is not just about collaboration between Dev and Ops, but an operating model that promotes collaboration across business functions (e.g. digital teams, marketing), development and operations.
- Shift from big data confusion to real-time information driven insight. In the fast moving world of DevOps information and insights in context will be your business lifeline. This means that having application data such as engagement, technical and business data (revenue etc.) changed quickly into information that can be consumed by different business audiences is essential to making fact-based strategic decisions. So we have to move away from the current confusion around big data and analytics and shift to an operating model that makes an analytics solution that focuses on applications, a core part of making strategic decisions in regards to software strategy.
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
No, continuous delivery is a capability of DevOps but is not the ultimate end goal from my perspective. It’s also important to define what continuous delivery means. It’s not just about releasing applications and features frequently and quickly. It’s about making sure that your release cadence is in line with the market and most importantly, customer needs. The ultimate goal for DevOps is to make the organisation fluid in relation to customer needs – to be able to change quickly plus respond, and this means that everyone in the organisation – business, development and operations must be able to work without friction.
About John: John Rakowski is Director of Product Marketing for Application Performance Management (APM) and analytics at AppDynamics. Prior to his current role, John was the lead analyst for APM and IT Operational Analytics (ITOA) at Forrester Research helping clients with their APM and analytics strategies. Earlier he worked at Fujitsu and Capgemini architecting and implementing systems management technologies for enterprises in the financial and utilities sectors plus UK government. John has more than 10 years of experience with systems management and monitoring technologies.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.