DevOps: The missing link in your IT organization

 

How DevOps culture could be the engine upgrade your Organization needs

You probably have heard of DevOps. Heck, you probably have implemented it until some point. 

And if you didn’t, what are you waiting for? 

DevOps is a culture – a cooperative culture between development and IT operations. The better the cooperation between these teams, the faster will be your response to market demands and the better and reliable your software will be.

But all of these intangibles should, and do, flow down to the bottom line. Which means that any well-designed program should include a healthy perspective on how it creates business value ROI.

These are perfectly valid statements that should be made not only for DevOps, but any implementation on scope. In this short handbook, we hope to give a brief overview of what is a real value of it and why you should have adopt it sooner.

What should I expect by Investing on DevOps?

“I’ve got this idea, it’s a philosophy and a movement and a cultural change and it’s going to make our company better.”

I suggest we take advantage of AWS ECS Capabilities and the new Capacity Provider functionality, (…)

I’ll lose your attention span if we start like this. Not because you don’t care, it’s just because it’s not your usual vocabulary. In any project, idea, improvement you make you should adapt your pitch according to the Audience, and DevOps is no different.

Besides having a strategy, and I mean a phased e clear plan, with timelines and clear objectives, it’s important to know what is the business’ impact, how it will create value what are the costs and how will recoup the investment.

So which are some of the symptoms that you need some kind of rework on how your processes?

  • All (or majority) of your tests are manual and require large QA teams or low test coverage
  • You don’t have any CI/CD pipelines or they’re meaningless and only use for deployment purposes by manually triggering it
  • You don’t use any kind of container technology 
  • You don’t have any automatic code review tool who gives meaningful tips and finds common errors
  • You have to schedule deployments for off-business hours or weekend. 
  • You have downtime when doing a production deployment
  • You don’t have any security policies on Application/Container/Orchestrator levels 
  • Your developers have very limited perception of the deployment process 
  • You have limited monitoring & analysis on your infrastructure
  • You have a low # of environments, with a lot of people relying on these environments
  • You have a release team or someone responsible to deploy, handle git merges, etc
  • You have a fair share of homegrown scripts crucial to the day-to-day operations

You may think that you already have a solution to circumvent these problems or that you are already so used to it that you don’t see value on changing what is working, but if you’re able to visualize your savings in scale by updating any of these pain points, you might change your views.

Measuring DevOps Value

This is kind hard to tell, but DevOps value isn’t measured because it can’t be. You should be wondering “You just told be it’s important to know every ins and outs of any implementation”. And you’re right.

While it can’t be measured as itself, all your other projects can be. The difference between the value before and after of all the products and projects you develop and release is the value of DevOps.

It’s kind of utopian to measure DevOps value before & after, basically because it’s not some kind of plug & play tool. But we can split DevOps into smaller problems: For example, if you’re implementing a new centralized Log system to aid developers find & fix bugs, measure how much faster issues are found. And there you have a subset of the value created by DevOps.

And a DevOps mindset has a strong impact on a widely spoken concept that is IT performance. But How?

IT Performance 

There are many “IT Performance” definitions, but since we’re talking DevOps, I would like to focus in two concepts that you should be aware:

  • Throughput 
  • Stability 

These two concepts are the main drivers of your IT performance. And we can break it down into 4 main KPIs:

  • Deployment Frequency – Number of times that your code is deployed in production. 
  • Lead Time for Changes – How fast we can incorporate changes – from conception until production
  • Mean Time to Restore –  How fast can we restore when a system fails
  • Change Failure Rate – How often these failures happen

There are many more KPIs that we can keep in check (Deployment time, # customer tickets, error rates, etc) but we control these 4 main metrics  and try to constantly improve them, we are on the correct track! But how can we do it? As I said before, DevOps is not a plug & play product, and as you may know, every business is very unique in it’s own way and it should be aligned with the organization objectives and limitations.

There is a plethora of tools & concepts that would make this endless, but I’ll leave an overview of the concepts that DevOps aims to fix:

There are many more concepts, such if limits on Work In Progress are set, how many homegrown scripts you have, If training developers on Ops and the other way around is set, etc. Again let me warn you: You can use all of these tools and not have a DevOps culture in place, or don’t use any of these and be DevOps proficient. The most important thing is communication, processes and people.

DevOps ROI

One other thing is if you’re going to invest, you also need how will you recoup the investment and profit on top of that. 

The following equation explains itself:

You can expect direct savings on developer time and indirect savings on many other fronts, depending on the subject of your business. Let me frame it on five main points:

  1. Cash
    1. Through speed. Faster to release, addressing customer issues, having less errors.
  2. Growth
    1. Through iteration. Iterating faster through customer needs, leading to increased sales and brand recognition.
  3. Reduce Expenses
    1. Through automation. Do more with less by automating manual, repetitive work, enabling teams to focus on producing value 
  4. Long-term stability
    1. Through reliability. Having no unexpected downtime & scaling your infrastructure with demand, increases customer loyalty and steadier revenue streams.
  5. Costs
    1. Through investment. This isn’t possible without it. Investing in people, processes & technology will be beneficial in the long-term 

Implementation

There’s many ways to setup your “DevOps Team”, but there’s not better explanation than these guys over at devopstopologies, where they talk about the do’s and don’ts of how to setup your team. There are some topologies that we can highlight as the more frequent:

Type 1 – Dev and Ops Collaboration

Smooth collaboration between Dev teams and Ops teams, each specialising where needed, but also sharing where needed. Needs quite substantial organisational change to establish it, and a good degree of competence higher up in the technical management team.

Type 3 – Ops as Infrastructure-as-a-Service

Organisations with a fairly traditional IT Operations department which cannot change rapidly and for organisations who run all their applications in the public cloud. A virtual team acts as a source of expertise and acts as a does most of the communication with the IaaS team

Type 4 – DevOps as an External Service

Some organisations, particularly smaller ones, might not have the finances, experience, or staff to take a lead on the operational aspects of the software they produce. Dev team might then reach out to a service provider to help build test environments, automate the infrastructure and advise on operational issues.

Type 5 – DevOps Team with an Expiry Date

This temporary team has a mission to bring Dev and Ops closer together, ideally towards a Type 1. The members of this team ‘translate’ between Dev-speak and Ops-speak. Long-term responsibility should not be given to the temporary team, otherwise it may become a silo itself.

Bibliography

https://web.devopstopologies.com

https://logdna.com/how-to-determine-log-management-roi/

https://devops.com/real-cost-downtime/

https://devops.com/the-roi-of-enterprise-devops/

https://medium.com/dm03514-tech-blog/devops-decision-making-applying-roi-based-analysis-6f6301ca6123

https://stackify.com/15-metrics-for-devops-success/#post-14669-_qwuwyxibzmrj

https://devops.com/talk-cfo-devops/

https://calebfornari.com/2019/07/11/devops-decision-making/

45503dd4-d78f-4acf-81ca-117e93140e6c_200x200
This website uses cookies to ensure you get the best experience on our website.