Today, it's everything "Ops". You may have heard and seen the term "Ops" many times. Most likely, every vendor has an "Ops" product for you already. Can you live without it? Yes. Should you? Our answer is no. Let's talk about it.In our previous article, we mentioned 4xOps:
- DevOps
- SecOps
- DataOps
- FinOps
Let's get into a bit more detail on the most mature one: DevOps.You've heard this term by now hundreds, if not thousands of times. It is being used in every possible form by every vendor out there. Fun fact: did you know that the term DevOps was coined for a dedicated talk about it, only because there was no other name? Yet it has stuck for over 10 years now. DevOps. The holy grail of IT. But is it only an IT tool?
What is DevOps?
Have you started implementing it? What does it mean to put DevOps in place? What does it mean for your organisation? Have you asked yourself these questions? The evidence is out there. DevOps as a practice (because it is a practice, not a tool) helps organisations to be more efficient. You can see it from the State of DevOps report or this article and report from Google. Those are the reports, but here is our observation based on the projects we run with customers. At the majority of organisations, when people say DevOps, what they refer to is automation. And sure, DevOps is IT-driven and focused on deployment automation. The idea isn't wrong, but it's just a piece of the truth.So, let's dissect it.
Where to begin with DevOps?
First, we need to have a repository of things we want to deploy. This would mostly be Azure DevOps or GitHub in the Microsoft products world. That's a pre-requisite. Team(s) have to have a single place to work together. When we have it, we can start thinking about the next step, Continuous Integration.
What is Continuous Integration (CI)?
It is a process of putting pieces from the repository together into release. Anyone who went through the release of IT projects into production will understand the benefit. Nothing will get missed from the notes. No files forgotten to be included.It is automated. Repeatable.It's a process. Then, it's time for the next stage.
What is Continuous Delivery (CD)?
Imagine this: what if your application could be deployed not just over weekends? What if you could push it to production at any time? And if something goes wrong, go back to the previous version just like that? This is Continuous Delivery. Changing the pain of deployment into a repeatable, observable, and measurable process. Here is where most organisations stop. CI/CD. Hurray! We have DevOps!Unfortunately, no, you do not.
The next step in completing your DevOps implementation
So far you have addressed only the technical side of your pains, and not all of them. To have full control, you need to make your applications:
- observable: to be able to say if they work and do what they should do
- measurable: to be able to answer the question about their health and business process using numbers.
Now it is time to start adopting DevOps as a process. First: it is a communication tool. All work put into making your deployment process smooth will not do much if people will not see the benefit of it. And we mean people outside of IT. How can they see it? Here it comes... the backlog! Don't be scared. We will not preach the agile way of working to you.
What is a backlog?
A backlog is a shared view of what you want to achieve. What needs to be done to deliver the product.What you need to do is to connect all people involved in the product in this single space called the backlog. Your product team will be able to say what they want to do and what are the priorities for them. Your development team will not have to figure out what to work on. They will pick it up from the backlog. They will also communicate what was delivered. Through the backlog.Issues, comments, bugs. All gathered in one place, with clear visibility for everyone involved.
Backlog brings teams together
With process transparency comes the next part – responsibility. It is not "IT" who handles success and operations. There are no "business" and "IT" teams. You all work on the same backlog. You plan it together, and you sign up for delivery together. If there is a problem and something stops working, one look into your DevOps space shows it:
- metrics from the app, to show problems in performance or business process execution
- the state of deployment and signs of problems there
- who is responsible for fixing it and who is the best person to work on it.
Let's see some results!
Does it sound like a dream? Something that can't be implemented? Many organisations did it. We did it.
This is DevOps
A communication tool and process to deliver the product. Not deployment automation. Not a code repository.It is a culture of working and delivering a product together across teams.
Want to learn more?
We want to recommend some good books for you to read in this area:
- If you haven't read it yet, get The Phoenix Project for a weekend. You are going to like it. It tells the story of DevOps as a practice being applied at a company
- If you want more structured and data-driven evidence, Accelerate is the book for you
- And finally, to connect the need for DevOps with business, read War and Peace and IT.
Those three are a must-read for every CIO, CISO, Team Lead, Development Lead, but also Product Owners of marketing managers.Your product teams want from you what is described in those books. They don't know how to name it.
Why is DevOps so important?
Do you want to know what the number one problem in having IT as an active part of a business is? It is not the cost of it. Nor is it a lack of skills.It is the lack of a common language to talk across the entire business value chain, which includes IT projects. Give your business team a language to talk to your IT team. One that both sides will like and understand.Give them a tool for communicating and understanding the bigger picture.Give them DevOps.
Author
