devopsy.kinsta.cloud

Tag: velocity

The Real ROI of DevOps

Many established enterprises are stuck in reverse. Dragged down by legacy IT systems and sclerotic software workstreams, these businesses simply cannot adapt and get up to speed in the continuously changing, high-velocity global marketplace of the 21st century. Delta Airlines’ recent technology crash, for example, dramatically illustrates how aging and inflexible IT systems can cripple a company in 2016 and lead to millions of dollars in lost revenue, as well as the dissipation of a hard-won reputation among customers.

But an increasing number of organizations are accelerating their cultural transformations to become software-led companies that can consistently deliver new products and services as a result of automated and collaborative workflows. Alaska Airlines, which focuses relentlessly on measuring the innovation velocity of its business, is a powerful case in point.

This is DevOps at work, and it’s how IT must operate to be the business engine of our quicksilver digital economy.

Measuring the return on investment (ROI) from DevOps is critical to convince organizations falling behind that they can still shift course, transform and head to the IT future. Measuring DevOps ROI is also essential for companies that are embracing the industry’s forward movement, so they know if they’re on the right track and can keep turbo-charging their DevOps efforts.

The most proactive approach for measuring DevOps ROI is to gauge the impact of products and services on customers. But, to get there, we must also assess and analyze the efficiency and effectiveness of the software development process.

Which brings us to the one metric that’s truly relevant in business today—velocity. Without velocity, you can’t quickly recognize and remediate problems. More significantly, you’ll fall behind in the marketplace because you can’t innovate fast enough to keep pace with competitors and customer demand.

Enter DevOps: The culture of innovating at velocity.

Of course, that’s easy to say, difficult to measure. The real ROI of DevOps is how rapidly you can ship your new ideas to customers—and, importantly, understand if those ideas meet customer needs.

Many may look at cost savings and headcount as their first DevOps metrics. These are important barometers but don’t measure long-term value back to the business. Two places to start for value-oriented metrics are time to delivery and quality of release.

Measuring time to delivery shows how long it takes to get new product from code checking to production. Ideally, you want to see your time to delivery drop from months to weeks to days, and then literally to hours and minutes.

Quality of release reveals how many bugs and errors are found in each iteration of the product. Companies should look to remedy these immediately and to develop a pre-production environment and workflow of automated testing for issues.

It’s equally important to measure how rapidly you can get feedback from customers and incorporate that into the next development cycle. Development teams must get clear, direct and actionable feedback about whether their products are moving the business forward. For example, did the two-week sprint to build a new landing page for a bank’s website increase customers’ online banking sessions? Did it generate more cross-sell for the bank’s product portfolio? How soon can we see an uptick in customer satisfaction? This is significant information, and the question is, how fast do the developers respond to this feedback?

The bottom line is that DevOps metrics should always connect back to the business; they need to show a measurable improvement in the customer or staff experience. This could be more quality touchpoints with customers, an improved customer satisfaction score (such as a Net Promoter Score) or increased customer activity in areas such as online billing or account management.

“Delivering on the final product is key,” says Adam Mikeal, director of Information Technology at the College of Architecture, Texas A&M University. “Your job’s not done if the customer can’t accomplish what they want. If the customer can’t do it, it doesn’t matter if your section of the code was good. The customer experience is all that matters.”

Another important part of this equation is measuring your team’s efficiency on the road to velocity. To truly ship ideas at speed, and positively impact your business and its customers, you also need to understand how smoothly your teams are working—in addition to how quickly they’re delivering.

Banks Cash In on DevOps

Westpac Bank in New Zealand fully grasps this imperative, for example, and it enacted DevOps practices to deploy a new pricing engine for mortgages in just three months—from concept to customer. In the past, this project would have taken Westpac 18 months.

Additionally, Westpac measures how well it’s using resources—for every $1 spent on a problem, how much is chewed up by politics and how much actually goes to solving the problem? Before adopting DevOps practices, Westpac was delivering a return of about 20 cents to 22 cents. Now, that number is just shy of 40 cents. That’s a near-2x increase in the value delivery. Westpac’s goal is 3x. In addition, Westpac has increased the amount of work its development teams accomplish by more than 40 percent over the previous year.

Like Westpac, Standard Bank in South Africa has boosted efficiency, thanks to a thriving DevOps culture. The cost of production at Standard, for example, has dropped from about $4,000 to $700—a 300 percent improvement.

The goal for companies in every industry and economic sector around the world today is clear: Accelerate your business so that you create and provide greater—and faster,—value for the customer. But, to drive a robust ROI on this journey, it’s crucial that you carefully measure the true velocity of your organization, whether you’re just beginning with DevOps or you’re well along in the transformation.

— Justin Arbuckle

October 26, 2016
Iterative Indicators: Measuring DevOps ROI

It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

July 8, 2016
It’s web performance, let’s not call it WebDevPerfOps

Velocity was great this year. It was only my 2^nd time out to Santa Clara, but from what I understand every Velocity conference is great. Few conferences can provide such rapid payback. Velocity does a good job setting the right vibe. The talks are often as entertaining as they are informative. This video of Scott Hanselman is a great example of that. He did an artful job of telling an open source audience they can run their code in the Azure cloud too. I happen to know a few companies that are doing just that. It’s good to see Microsoft continue to embrace open source, as I am a fan of running C# on Linux myself.

Getting a room of passionate experts together and making them laugh over plenty of food and drinks is a setup for awesome collaboration. When this crowd is having a good time the conversation drifts to tech talk naturally. If you’re not working the hallway track at the conferences your attending you’re missing out. I always enjoy finding others dealing with problems similar to the ones I’m currently facing and the two way peer review that comes out of it. On occasion someone has a silver bullet too, where they killed a problem dead in their organization and the solution ends up being easy to implement and highly portable.

As Velocity wrapped up I found myself with a 3:30pm flight back to Atlanta but a hotel with a strict 12pm checkout. I knew devOpsDays was coming up, google.io was going on, and a friend at the conference reminded me webperfdays was about to happen as well. Webperfdays was at Google’s Mountain View campus just up the street. When I looked into it the ticket was only $15.00, so why not spend half a day on Google’s campus talking about web performance if I didn’t have anywhere else to be?

The session was awesome. Webperfdays was a much smaller group than at Velocity. The day included open spaces discussions in addition to main talks and an ignite session. I was learning so much I actually called at lunch to move to a red-eye back to Atlanta so I could stay for the full day.

There were a couple of things that factored into staying after lunch. The first was I didn’t really know anyone there. I recognized a couple of people but it wasn’t anyone I had spoken with much. Looking at the line up for DevOpsDays, I didn’t see too many new names and had talked to most of the main presenters within the past couple of months.

This was all enough to lure me in the door but I stayed because they blew my mind. Andrea Giammarchi’s talk on mobile web performance did real time demos showing how slowing your app can provide a more consistent experience across devices, but assuming only state of the art equipment can lead to performance problems for the majority of your audience. This blog post walks through the talk and provides links to benchmark tools used during the demonstrations.

I also enjoyed Tony Parisi’s talk on webGL. In contrast, he made a lot of good points on how awesome our hardware can be and the crazy things it can do for us. This video covers a lot of the same points Tony made at webPerfDays. I was not aware of the 3D capacity our browsers have or how accessible it is.

My mind sufficiently blown, I came to the realization I hadn’t really been thinking of web performance at all. I’ve been very focused on the CAMS model of devOps, which for the most part meant getting changes to production as safely and quickly as possible with lots of monitoring and reporting. The focus was really on not breaking anything. A degradation in performance does qualify a change as breaking if it’s severe, but making sure our numbers don’t slip isn’t the same as actively trying to make them better. This is a cultural perspective within a shop, and to promote that from within I have to become a web performance advocate myself.

I don’t think I’m the only one guilty of adopting this devOps anti-pattern. It is human nature to pick teams and eventually get competitive. DevOps wants to de-silo our organizations, but I have witnessed industry experts self-segregate at the conferences where we’re working on correcting such problems. This is why I hadn’t really spoken with anyone at webPerfDays while at Velocity: We had all stuck to our respective tracks. The folks I knew were either at devOpsDays or had gone home.

I didn’t have a lot of session overlap with the folks I work with because they were mostly on the web performance track. Since I’m a devOps Engineer it only seemed natural that we stuck to our areas of interest. I’ll even admit I’m guilty of actively turning off my attention on some deep dive performance discussions, because, “it’s not my area and I need to stay focused”.

That thought process stopped as soon as I got back to Atlanta, and I hope you avoid viewing our industry so myopically as well. We have the capacity to study devOps, web performance, and more all at the same time. While we may not always be the experts in the room we can be fluent enough in other areas to be mindful of our impact and appreciate the wins and losses our teams face daily in their respective arenas. We can create a culture of sharing in our organizations, but if we can’t empathize with the information we’re receiving we cannot respond proportionally.

August 14, 2014
DevOps Rock Star dinner
I have been so busy running from conference to conference lately. Next on the agenda is the Velocity conference in Santa Clara, Ca. While I am sure the conference is going to be great, I am super psyched about attending a dinner on the 24^th that promises to be a blockbuster. It is a “State of DevOps” event with an all-star cast including:
Sounds like DevOps Rock Star panel doesn’t it?

Part of the agenda is:
- The Why andWhatofDevOps?
  - Who is DevOps for? Startup, Enterprise, Unicorn
  - Business drivers?
- What will theimpactofDevOps be 10 years from now?
  - ROI and business value
  - How will DevOps cross the chasm?
  - What job functions go away? What methodologies / tools go away?
  - DevOps as a title?
  - Investment landscape?
- How do we get there?
Sound interesting? I am really looking forward to this one

I will be following up with a report from the dinner later next week.
June 20, 2014
What’s new @DevOps.com

All of us here at devopsy.kinsta.cloud have been very busy. In addition to adding some new writers and great new content, we have been working “outside the 4 walls of the website”. Here is an update on what’s new:

1. Camp DevOps – We held our first Camp DevOps event last week in beautiful Boulder, Colorado at the University of Colorado, Boulder Campus. It was a great event featuring a lot of great sessions. Sanjeev Sharma of IBM, author of DevOps for Dummies (and a devopsy.kinsta.cloud contributor) kicked things off with a great keynote. Andi Mann of CA had a great talk on implanting DevOps from the top down. Rajat Bhargava and Topher Marie of JumpCloud also had some great insights in their sessions. Rich Mogull’s “KickaaS Security” session was a great look at the top things you need in terms of security. Another very popular track was Craftsy VP of engineering, Matthew Boeckman’s using S3 and Glacier for backup. There were some other great sessions but I can mention them all here. You can check out the Camp DevOps website for the full agenda.

We will be conducting more Camp DevOps in the near future in cities throughout the US. Some will be in conjunction with larger events or conferences within conferences, others will stand alone events. Stay tuned for more details.

I was asked the question of whether Camp DevOps competes with DevOps Days. Short answer, no. We support DevOps Days and the culture they represent. Camp DevOps shares with DevOps Days the desire to advance DevOps, but takes a slightly different tack. We will have both highly technical, as well as business orientated tracks. Camp DevOps will feature both learning on DevOps culture, as well as tools. We will also be adding more exclusive Camp DevOps activities to the events in the future.

2. Gluecon 2014 – Camp DevOps Boulder was held in conjunction with Gluecon in nearby Broomfield. Gluecon was fantastic this year and also featured a full DevOps lineup. I was the moderator of the DevOps tracks on day one. Again some real quality presentations on Ansible, Saltstack and more. We will be posting video here soon.

Look for more announcements regarding Gluecon and Camp DevOps soon.

Webinars:

Compuware APM – I was invited as a guest on a webinar by CompuwareAPM in an intro to DevOps. The webinar was hosted by Steve Wilson. It was a good conversation about several interesting areas of DevOps. The recorded version of the webinar will be available shortly and we will post a link on our events page.

SecDevOps – I am joining Andrew Storms of CloudPassage to discuss SecDevOps, the new black. You can register for this here. Andrew is a really bright fellow that is very well known in the security space and this promises to be a great webinar!

devopsy.kinsta.cloud Media Sponsored events

devopsy.kinsta.cloud is working with several organizations to promote events for DevOps learning. If you would like to have devopsy.kinsta.cloud media sponsor your event contact sponsor@devops.com

May 30, 2014
Dev, Ops and Security Collaboration: Bring the body and the mind will follow
Complexity has a way of muddying even the clearest of waters, and this has certainly been the case with IT Operations. While Dev, Ops and Security teams share a common purpose, the silos between them are so deeply entrenched, it’s easy to see how they have forgotten that they are working towards the same end. Fortunately, the rise of DevOps has provided the opportunity to break down those silos and leverage automation to increase agility, efficiency AND security. But accomplishing that requires an alignment that is only possible through a sustained, collaborative effort. So, I wanted to dig into more detail into the stakes Security, Dev and Ops all share, as I am certain the benefits of working together will become startlingly apparent.

First, let’s take a look at where each group is coming from:
- Developers want fast, automated application deployments. They only care about infrastructure as it relates to their ability to roll out applications.
- Operations folks (network managers) live, eat and breathe infrastructure. When it comes to application deployment, they need clear technical requirements to reduce “redos.”
- Security folks need to make sure policy & process are enforced with auditable security controls that also can ensure compliance.
A big part of the problem is that until now, security has been introduced at the tail end of the development lifecycle, after risky practices have been introduced into application delivery architecture. Security comes in after the fact, implementing fixes and controls the best they can. Obviously this slows things down, and creates a dynamic in which security is perceived as an obstacle, and security teams are pigeonholed as “the folks who are always saying no.”

The good news is that automation can ensure that security is woven into Dev and Ops processes from the get go, and to great benefit. But technology alone won’t change the underlying problem. Breaking down silos requires cultural shifts that don’t happen overnight. The first step to changing these dynamics is to better understand the relationship that exists between applications and infrastructure. This does not mean security folks need to become domain experts in agile development, or that developers need to become network security experts. In fact, even a basic understanding of the collective impact of these trends should create the common ground needed to move towards a more collaborative model.

As the DevOps movement reaches critical mass, the increased agility, greater efficiency and substantial security improvements it can deliver are being talked, written and Tweeted about in depth, and with increasing frequency. And most importantly, these benefits are not just marketing buzzwords – they are tangible and multifaceted, as is illustrated in Steve Hall’s Jan 2014 blog post:

“Business people completely understand ‘release my product faster’, ‘time to market’ and ‘make more money’ which are some of the outcomes that DevOps pontificates on. This is why DevOps as a movement has a higher probability of succeeding than other investment choices because there is a direct correlation between it and top/bottom line revenue. So if you’re an InfoSec leader, a good bet is to align yourself to the DevOps initiative (or spearhead it yourself for that matter) and help the business understand the value of security in a way that doesn’t measure things by # of incidents, time lapse from vulnerability to patch, or compliance score.”

As for the shared stakes between Dev and Ops, check out John Allspaw and Paul Hammond’s Velocity 2009 talk on how cooperation between Dev and Ops enabled 10+ deploys per day at Flicker. If that doesn’t demonstrate what “increased agility” looks like, I don’t know what does.

These are just a sampling of the myriad ways Security, Dev and Ops can reap greater benefits by working together. But…. it takes time and effort to get the ball rolling. Perhaps the best way to get started is to make sure Dev, Ops and Security start talking, literally. Once a week. Every week. No matter what! Get the bodies there, and I promise you, their minds will follow.

Based on our customers’ experience, a few quick wins is all that is needed to get the ball rolling. Once Dev, Ops and Security folks experience the upside for themselves, those silos will start to crumble. In my next post, I’ll provide some examples where automation can enable Dev, Ops, and Security to gain those quick wins and build momentum for further cultural change.
April 4, 2014