Blab: What does DevOps mean in a New Zealand context?

DevOps is currently a popular topic in IT and software development and no doubt you have heard people talking about it. The name comes from combining the words Development and Operations and its intent is to expand the boundary of multi-disciplinary Agile development teams to incorporate IT operations activities. Such an approach helps organisations become more Agile as software can be built, tested and released in highly iterative and rapid ways. In this Blab we address the question 'What does DevOps mean in a New Zealand context?'.

Blab topic: Exploring DevOps and Bimodal IT in a New Zealand IT context

We recently ran a Blab session (find out more about Blab) discussing DevOps and Bimodal IT in a New Zealand context, where we worked through these questions:

• What does DevOps mean in a New Zealand context? (covered in this post)
• What does Bimodal IT mean in a New Zealand context? 
• How do DevOps and Bimodal IT play together? 
• How do New Zealand organisations maximise the opportunities from DevOps and Bimodal IT?

This post covers the first question. The recorded Blab is ~12 minutes long and there is also a transcript of the discussion below.

Blab presenters

Our presenters during the Blab presentation were:

• Blue polo: Bill Ross, Principal Consultant, Equinox IT Wellington office
• Grey shirt: Herman van Krieken, Principal Consultant, Equinox IT Wellington office
• Green shirt: Peter Smeaton, Senior Consultant, Equinox IT Wellington office
• Green polo with window blinds behind: Brendon Livingstone, Marketing and Communications Manager, Equinox IT Wellington office.

Transcript of conversation

Brendon: My name is Brendon Livingstone. I'm joined today by Bill Ross, Herman van Krieken and Peter Smeaton and we all work at Equinox IT providing IT consulting, software development, and IT training services in New Zealand. On the Blab today we're going to be talking about exploring DevOps and Bimodal IT in a New Zealand IT context, and the first question is what does DevOps mean in a New Zealand context and I'll hand it over to you.

Bill: Right, okay I think actually for smaller companies in New Zealand, DevOps is almost a natural way of operating because haven't got any choice. They haven't got separated development and operations teams. Small startups, small companies, they operate in their way and probably have for a long time, but maybe didn't even have the name, you didn't associate the name DevOps with it. Yeah, I don't know what you guys think of that situation?

Herman: Well, actually I disagree. There are plenty of large organisations that do have very separate organisation structures that do operate in a more traditional way, and it would be very good for them to move into this DevOps principle to remove all the waste that goes on between development, operations, and all the unwritten expectations that happen when they throw things over the fence to all of the sudden become productionised.

Bill: Yeah, I think my comment was to do with small companies, but you're right I agree the larger ones adopt this traditional separation of development and operations, and where that comes from originally, I don't know, thinking about textbooks I used when I was doing my degree. IT textbooks on IT management they said "this is the way you structure an IT department - these separate areas called development and operations." Everyone said "oh yes okay that's the way it's done, that's always the way it's been done" and so be it. It's interesting that it's being challenged now, what's driving that challenge to that traditional structure?

Herman: Yeah, and it's all underpinned by a whole bunch of technology development that makes it possible to all of the sudden sit side by side, and do seamless handovers and do continuous development and create a pipeline of delivery. That's all the outcomes that organisations will get from there. And as a result, quality goes up. As a result, the reduction in frustration of users is greatly reduced.

Bill: Yeah, but only if it's done well.

Herman: Oh sure.

Bill: And I'm not sure actually, it's not necessarily the technology that's driving it. It's probably that separation, I think, used to exist because of complexity. It couldn't be trusted that you could easily deploy something without a lot of configuration and the complexity of configuring, and deployment, and data migration, and set-up and all that stuff that goes on. I agree that some of the automation technologies made that easier, but setting up that automation in your organisation is a considerable effort, and it's not something you can just move to. It's something I think you migrate to as you move that deployment pipeline, you move it closer and closer to the actual live system and add the automation over time. It's quite a journey I think for any organisation that's going from the traditional structure to move to a real true DevOps operation.

Herman: Yeah, no I agree. It's not a trivial thing to do, but it's got to be driven by the need to reduce waste in the organisation, and it has to be supported fully by the management team and the executives to be able to get there, because it also requires investment, and the investment will take time to return the value back to the organisation. But once it's done, it becomes a very valuable tool to fend off any competitive activities if they are in that sort of game, and although the government is obviously not, so public sector is not in a competitive game, but they could gain significantly from doing something like this and investing in returning better quality services to the public at large.

Peter: I'd like to separate DevOps from speed of deployment. If I go back to my early experience in IT, then partly to do with the scale of the organisations that I worked for, but I think it was also more common at the time. DevOps was a thing. It's what you did. You analysed a business area, you often wrote the code or had a high level of involvement in the code and you saw it into production and you were the one on the end of the cell phone when the batch failed at 11:00 or whatever. But that didn't correlate with a particularly fast change cycle. But nevertheless, there was no formal separation between build and run, if you like. There was still advantages from that because it meant that the people on the operation side had a deep knowledge of the software and so on, so I think there were advantages without the fast cycle times, which is something else, which was the continuous deployment and the agile aspect that's relatively new at least in my experience.

Bill: Good point Peter.

Peter: I think these are all separate things and they can be considered separately, but they then can play together.

Brendon: So we have...the question talks about the New Zealand context. Do you think there's a difference between what we are looking at here in New Zealand with DevOps, and with other locations maybe?

Bill: Yeah, I think with organisations that their business is technology, like the Googles and the Amazons of the world, they experiment essentially in real time through AB tests and other approaches. It's intrinsic to what they do. Other organisations, techniques like that just aren't necessarily useful. And Herman mentioned government departments, they're probably not in that situation of wanting to run experiments on their client base to see what they favour, although they potentially could, but it's more delivering effective value to the stakeholders.

And I think the key thing is quick feedback cycles and being able to deliver value quicker, but it's probably much more incremental as opposed to big bang deliveries as major releases. You're able to do more frequent but smaller value that's deployed. And I guess there's certain bottlenecks that have always existed. Testing is a classic example, a regression test of a system. In a big complex system, that could be many weeks of work, and that's a transaction cost, if you like, especially if it is done manually. It's a transaction cost of putting out a new release, but some of these technologies allow you to reduce those transaction costs in automated testing etc. to much smaller levels, and that's probably the key to it, the reduction of the release transaction cost activities. It can be tested overnight automatically, and a lot of things come together from unit testing at the lowest level, integration testing, automated performance testing and so on and so forth, that the underpinnings of the ability to do this stuff.

Herman: Yeah, no, I totally agree. I tried mention and probably didn't do so well in my first comment is that the application of tools to underpin DevOps have made it possible to do some of the individual steps in the whole DevOps definition in a much more automated way, which make it more reliable, more repeatable, more automated if you like, end to end, and as such the speed of delivery gets greatly enhanced. It means in work packages the changes can happen more frequently. That means risk is reduced as a result also. So all that together makes this whole DevOps principle pretty much more worthwhile to look into, I would suggest.

Bill: And I think an important aspect to it is the project approach to new software, because a project that's releasing a new system, especially if it's a big bang release of a new system, they're not necessarily... the way you judge projects through 'do they deliver on time and scope and budget etc.' often doesn't mean that the project gets an advantage by making the investment in that sort of automation. Because once it leaves the project, then it's in another world, the operations business-as-usual world, and that's often where the pain occurs. And the general wisdom is that the most money spent on any application is actually spent on it after it goes live, but there's so much emphasis on the project that maybe you're better off thinking of almost dropping the project concept and thinking of the whole thing as a factory in all the early iterations or the early part of business as usual. You want to build assets that those sort of things we spoke about earlier, that are basically going to give you a payback over the complete life of the application.

Herman: I agree with that. I think the project approach, historically, needs to change to smaller increments. The minimum viable product concepts that you see in the Lean architecture world is probably a much better way to it, and using DevOps to deploy that is a much better way of looking at the minimal parts and then following on then all the features, all the changes that you may want to make going forward. So DevOps on its own is probably not so wonderful, but if you take it into context with other Lean principles, it becomes a very, very powerful tool to help technology departments deliver value.

Peter: Just going back to what Bill said, I agree, Herman, but Bill you talked about almost not wanting projects or looked at the destructive or the negative elements of projects around scope. So there's that whole thing that the project de-scopes or does things to get over the line, and then it's over the line and then it's ops problem. If you take up a more holistic view from an organisational total lifetime cost, it's disadvantageous probably. And so you either change that...either move to a way which gets rid of projects and replace them with some other construct, as per Herman was saying, a more incremental approach, or maybe change the scope of a project so that it fundamentally must be not just delivered, as in posted through the slot, but actually in production with a fully operational environment. You change that scope so that it's in the project's interest to deliver a complete thing.

Bill: Yeah I couldn't agree more.

We'll be doing more Blab-based content in the future covering other common Agile and IT questions. Please let us know if you have any IT questions that you would like us to address.