This excerpt from our podcast Beta & Beyond is all about speed to market, something not necessarily associated with software development until recently that is. What’s changed? DevOps. Get a crash course from one of our experts Saj Arachchillage with his insights into DevOps methodologies and maturity.
What is DevOps?
Saj : Good question. Traditionally, DevOps has been bringing the development teams and the operations teams together. So it used to be two functions back in the day: developers write software, manage services, and operations help them to run the software in production. But with technology transformation, it has all at once become one thing. And it's about bringing those two disciplines or two teams together and working together.
But I think the concept has evolved a lot. And now it's a cultural movement for me. So it's a culture of collaborating and working with the people around you. And it's a delivery process by itself. And it's a sort of a cutting edge, more agile way of delivering software and working together as a team. Altogether, it's a set of tools, processes, technology, and most importantly, the thing which applies for people just to create a high performing culture.
Why has DevOps become so necessary for teams to be able to build and maintain a competitive advantage?
Saj : Yeah, look, in modern days, any business would look for three things, from my point of view, one is speed to market. So essentially, it's important for you to compete in the market itself. The resiliency aspect of this, especially with recent things, and the lessons we have learnt in the world, is really, really important. And the last part is business agility, because change is the only constant coming along. So in order to actually achieve these three, what's underpinning is high performing teams, which is derived from DevOps and the DevOps principles. So that's why it has a direct impact into business competitiveness and how you compete in the market with the DevOps principle itself, creating a material impact when it comes to the competitive advantage.
So is DevOps just something that is just for IT teams? Or can it be something more?
Saj : It's not necessarily something for the IT teams, like some of these Lean principles actually started with Toyota and back in the day, right, it started with manufacturing. So there’s organizations I know who actually use these principles, outside technology with the business itself as well. But predominantly, it has become a technology thing, because technology has embraced that and created their own flavour on it. But that's, that's not a limit itself.
How many organisations are you hearing about or seeing in the market who have began their DevOps journey already?
Saj : Yeah, we try to get insights from the market all the time, right. And we talk to our customers, as well as our partners. And I think it's not necessarily the shiny thing anymore. Like, every day, everyone has started embracing it, and it's pretty much become a norm. But I think what we can say in the market is, it's not necessarily a big challenge if you've got a team of four or five people. But it is a challenge when it comes to the scale you're trying to run. If it's a business, you've got a team over 10 or more than that certainly is a a challenge. And then around that is the real challenge of articulating the value of DevOps back to the business folks and saying, ‘this is why we should do it.’ And here's how you measure it. That's where most people are struggling, not necessarily just understanding the value of their work from a technology point of view.
What scale do you use to compare those that are at a high or a low maturity in DevOps?
Saj : Yeah, I think my usual definition is...the best two things that look at Cost of change and cost of running. So essentially, if you look at cost of running, that means once your software is actually developed or any application is stable, what's the cost for you to actually keep the lights on and maintain it? So with things like cloud technology for using cloud first with modern technologies, that cost of running, it's really minimum. And then the cost of change means if you or anyone in your business gets a new idea, and you want to try that in the market, these days the best way to try is actually running it with the end user and, you know, running an experiment with the end users in production. So to do that, how much is it actually costing you, that's a good measurement to use. Because if you've got the right level of maturity, you should be able to ship software faster. That's a good way to measure it.
See what maturity level your DevOps practice is at
What would a high or a low maturity organisation look like?
Saj : Yeah, I think if you look at the low maturity end of the spectrum, the best way to look at it is like if you're shipping your software, not so frequently, you’re doing yearly releases, so somewhere like that. Plus, whenever you try to do a release to production, you come with a whole heap of problems in production as production issues. Or if you're having issues in production itself, and it takes you longer to restore your software in production, those are symptoms of low mature teams and how they work.
And when it comes to high performers, you can see that they're not scared of production, they could push software, frequently, they're confident they can, they’ve got the system and the plumbing and the technology behind it, to have that level of agility, to push software to production faster, and it comes with the level of confidence as well - you get less issues in production. And if on a worst-case scenario, they can breeze through the production and have that resiliency aspect built into them as well.
Are you seeing some organizations that may operate in more regulated environments being less sort of opened to DevOps methodologies? Or are they more open to it, because of the advantages as offers?
Saj : I think it certainly has changed. So essentially, to start with the five years or so ago, I feel like they were just bit scared to jump on it or jump on the curve. Because of the regulatory environment and the nature and the sensitivity of the data, they thought that's not quite their cup of tea. But I think with the cultural moment, now they're realising actually, that's providing that streamlining - the governance around it as well, with something like this it's really helping them. And they're sort of slowly adapting, I guess, but still, it got its own constraints with, you know, data majorities and legacy systems and so forth. So you can't really compare a regulatory environment with the gaming industry or something like that. Because the industry itself is you know, going on their own journey.
What does a typical journey look like going from a low DevOps maturity to high maturity?
Saj : Yeah, I think the key thing there is, it's not something you can do and see the results tomorrow, it takes time purely because it's a cultural change. It takes time for people to actually learn and start preaching that culture. I call it the safety culture, because it's a culture of actually not being afraid to fail. So it’s okay to fail in certain scenarios. As long as you get that learning and you fail in a low-end environment. It takes time. However, the best way to do that is certainly to try with a smaller subset or a catalyst itself and give these learnings and then really iterate and iterate.
What's your advice for an executive who is either considering a move to or doubling down on their investment into DevOps ways of working?
Saj : Yeah, I think three things. One is pick your battles and just pick your horizons. Say, it's a journey you had to go along. It's not something you can finish in a month or two months. So just like any other good thing, if you pick your horizon 1-2-3, and what you want to do in these horizons, and have a clear goal on where you want to go, then the next thing is pick a catalyst. So you pick a team who's really hungry for this, or a business unit or a technology, and then try the methodology - which will really help you for you to learn, as well as the organization to learn and get the learnings out of that catalyst. And then the last thing is, don't be afraid to fail. It's all about the safety culture. It's all about, hey, let's fail and learn and do it better, and get better ready. So start believing in yourself, and just just take the leap of faith.
To listen to the full interview with DevOps engineer Saj Arachchillage, including his learnings from observing DevOps failures, tune in to Episode 4 of our podcast Beta & Beyond.
