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? My answer is no.
Let’s talk about it.
In my previous article, I mentioned 4xOps:
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?
Have you started implementing it? What does it mean to put DevOps in place? What does it mean for your organization?
Have you asked yourself these questions?
The evidence is out there. DevOps as a practice (because it is a practice, not a tool) helps organizations 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 my observation based on the projects we run with customers.
At the majority of organizations, 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.
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.
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.
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 organizations stop. CI/CD. Hurray! We have DevOps!
Unfortunately, no, you do not.
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:
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 I mean people outside of IT.
How can they see it? Here it comes… the backlog!
Don’t be scared. I will not preach the agile way of working to you.
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.
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:
Does it sound like a dream? Something that can’t be implemented?
Many organizations did it. We did it. We did it for Damco:
You can read more about this project here.
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.
I want to recommend some good books for you to read in this area:
Those three are a must-read for every CIO, CISO, Team Lead, Development Lead, but also Product Owners of marketing managers.
Believe me. Your product teams want from you what is described in those books. They don’t know how to name it.
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.
If you want to try it, we have a DevOps Kickstarter workshop to quickly show you how it looks. Check it out!
And let’s talk security next time with SecOps. It is a hell of a topic.
We talk a lot about perimeter security, zero trust, etc. And there’s a good reason for it. Malware attacks don’t jus...
One vendor, two services. Which one will prevail? Where to invest? These are the questions raised by myself and many ...