Blab: How do NZ organisations maximise the opportunities from DevOps and Bimodal IT?

We know that DevOps is about combining development and operations into shared multi-disciplinary teams to help organisations become more Agile as software can be built, tested and released in highly iterative and rapid ways.

We also know that Bimodal IT is a Gartner term describing the organisational practice of running a traditional, stable IT mode (mode 1) in parallel with a separate Agile, change-oriented IT mode (mode 2).

In this Blab we explore how these approaches can be used by addressing the question 'How do New Zealand organisations maximise the opportunities from DevOps and Bimodal IT?'.

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? 
• 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? (covered in this post)

This post covers the final 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: So we'll move on to the final question then. How do New Zealand organisations maximise the opportunities from DevOps and Bimodal IT?

Herman: I'd say come and talk to us, we can help.

Bill: Putting that blatant plug aside.

Peter: Cut to the chase Herman, as always.

Bill: I think the key thing is the 'mode 1', 'mode 2' model is useful in recognising maybe helping people understand the IT department and setting 'mode 2' as a desired state to move to, and as part of that having a robust DevOps capability to be able to move from 'mode 1' to 'mode 2'. So I think it gives people a framework, and to say "okay in three years time or whatever their objective is, can we be essential a totally a 'mode 2' operation?". And set that as an aspirational place to be, because I think the advantages of being able to operate in that Agile capability, and be optimised, globally optimised, to deliver the most values as quickly as you can for the whole organisation is an admirable objective as opposed to just trying to be the most efficient IT department or to just be the most... keep the cost-down, which often is an emphasis. Because so many organisations have to spend so much every year to keep their 'mode 1' systems running. And just like going tramping and putting rocks in you pack, it slows you down, it slows down. You got less and less money available to do the 'mode 2' type stuff.

Peter: My feeling is that I definitely see some organisations that are doing what you just said Bill. They are essentially transitioning everything towards the responsive and fast turn-around end of the spectrum, to the 'mode 2' stuff if you like, but making that the system of record, doing that end to end thing.

But that's an ongoing journey for an organisation, and they've got to stay sharp around... they've got to address technical debt and the types of things, the fluff that builds up in systems, and they've got to do that actively. Whereas, again, not naming any names or anything, but my experience is that there are a lot of organisations that are going the other direction. Essentially it's an accretive effect around the 'mode 1' systems. Something comes in, at one point it's fast and responsive, but then at some point it gets added and stabilised, or becomes..., people move on, stuff changes and then it becomes brittle, and you put a wrapper around it, you don't touch it and it stops being able to be responsive or it just become an overhead and adds to the dog pile.

Herman: It's almost like it seems like a comfort zone, isn't it?

Peter: Yeah, and then as Bill says, the resources spent on standing still just keep going up.

Herman: And somehow, and I think Bill is right, as a framework it would be great to have that as plotted journey from today til tomorrow that says we want to move from a 'mode 1' to a 'mode 2' and in three years we'll be there and here are the things we need to do to get there. And that would be ideal, but I don't think there's many that would be actually really thinking that way just yet.

Peter: Well for some commercial outfits, it's just an imperative.

Herman: Sure.

Peter: And depending on their market and their positioning and so on. There are commercial organisations where that's probably not a big deal quite yet, but there are some that have already died because they haven't competed, as you said. And there are many others for whom where they've got to make that shift sooner rather than later, but there are organisations where there is no commercial imperative and where the benefits of going to moving to a core level to a 'mode 2' are quite different, maybe yeah...they're not do or die.

Herman: No, the motivational factors for those organisations need to be cranked up and something that makes worthwhile doing, whether it's publicity or whether it is some other driver that...who knows. Is it a relevant technology? Yeah, absolutely. Is something that we should be involved in? Absolutely. Is there something we could help these people wake up, these organisations wake up? I think everyone should, and as I said at the beginning in this final question, we can help with those discussions by bringing out the Gartner material and showing them the modes that exist and maybe waking people up and saying, "Hey, you should really move from here to here, because of these reasons." Go ahead.

Bill: The thing is, I don't think they're sleep. I think it's recognised, actually, and the problem is known. It's not an easy problem because you've got these legacy systems that are becoming very, very old, very complex, people don't understand them, but you can't take the risk of them going down sometimes for an hour because they could be 24/7 systems or whatever. It's a very, very tough problem.

Peter: I think it's...I agree, Bill, and I would just say that there are clearly a lot of the examples that we've picked around the 'mode 2' organisations, the Facebooks etc. They're brand new organisations, they started that way. It's a completely different prospect for an organisation that's got IT systems 30 years or whatever it is. That's a much harder proposition.

Bill: And it's almost an natural entropy problem whereby systems, even if you don't touch them, suffer entropy just because there aren't skills available to maintain it or whatever. And it is a recognised problem, and it's...if we talk about moving systems from 'mode 1' to 'mode 2', but the architecture of those systems have to support that to be able to do that stuff needs to be a built with testability in mind. And to retrofit, it's almost impossible to actually retrofit automated unit testing and stuff onto an application that wasn't built to easily support it.

Peter: Well, that's if you've even got access to the source code.

Bill: That's even more scary.

Peter: Lots and lots of systems out there are off the shelf in one form or another, and you're not able to do anything to fix them at that level.

Brendon: One of the things you said Bill, organisations building their capability in DevOps to help them move towards a 'mode 2' operation. What recommendations do you have for organisations that are looking to increase their capability in DevOps. Where do they start? What do they do?

Bill: Right, okay. I think that book 'Continuous Delivery' (Jez Humble and David Farley) describes it well. It talks basically the pipeline, and you essentially have to...they talk about from the time in the ideal world, in the ideal DevOps world, the time the code is checked in, you have this automation around...you're automatically running unit tests, automatically creating the deployment data, running test scripts, doing all the stuff to the point where it's actually the other end of the pipeline, it's actually deployed into production and it's ready to use.

Now you can't...The only way you can as I see it is you just have to essentially start at the beginning of that whole process and move the automation and the process, because there may be processes in there that are manual, or only some person knows. And even before you can automate anything you need to really understand it, because you've got...maybe it's documented, maybe it's not. But essentially you move the automation further and further along that pipeline, and it's gradually, it doesn't have to be overnight. But that's when you've got the true DevOps pipeline - what happens from the time code is checked in, as a developer that makes a change, to the time something is deployed into production, ready to go. And I guess that ties into to be able to move through that pipeline in smaller increments of business value, or functionality, or change, going through that pipeline at a very fast rate.

Peter: So time to value if you like, from a business idea which is validated, to it's out there realising value or not, it might be an experimental sort of thing. If it realises value, keep it, if doesn't, change it. But your cycle time for that changes from six months or a year or whatever it is, to days, or maybe at the higher end of the spectrum weeks, but not much more than that.

Brendon: So that covers off the process side of it. What about people, structure side, is there considerations there?

Bill: Well absolutely. In the 'mode 1' model, this pipeline isn't a pipeline, it's like stuff happening on one side of a wall.

Peter: It's a wall.

Bill: And the two sides may be optimised.

Peter: Like Pink Floyd's wall. Thick wall.

Bill: Yeah, so and what happens is that the development try to optimise around doing development. And even worse than that, well not worse than that, you get the disciplines within the project optimising. The BAs optimising what they do, architects, developers, designers optimising what they do. The testers optimising around doing good testing.

Then the operations people optimising around what operations do, and for them to optimise in terms of just operations...it's more optimal for them to get fewer bigger releases. If you only have to do a release once every six months as opposed to once every month, that optimises their resources but what it's not doing is optimising the flow of value through the whole thing, and that where the DevOps come in. So structurally, this structure change has to occur. Not development and operations, but DevOps.

Herman: Yeah, totally agree with that.

Peter: You're starting to talk... in lots of organisations you find them (development and operations) that they're completely separated physically, so there's a floor or an area of the building where ops is, or even a different building, whereas probably talking co-location and cross teaming and eventually blurring, completely blurring the distinction.

Herman: Yeah, the collaboration down the toilet, right?

Brendon: Well it could be even different organisations, couldn't it Peter?

Peter: Or sometimes, yeah it is. In the case of outsourcing and so on. With some of the arrangements that are in place around things like outsourcing, I don't know what the answer is there, because what we've put in place then is a whole set of legal structures or contractual structures between the change and run.

Bill: That's a difficult problem, but I think it comes down ultimately to trust. And if you could trust your vendor, your operations side. If they understand the way you want to operate and they buy into a DevOps type of operation, a member of that team could be on your site, and this really comes back to a lot of Agile principles around co-location, clear communication, the team-shared responsibility and self-managing team and all those sorts of things, and essentially trust.

But contracts are interesting because often contracts are structured around assuming you almost don't trust the other person.

Peter: Absolutely.

Brendon: All right, we're probably coming towards the end and trying to close out. Is there any last comments from anyone on the call that you'd like to mention before we finalise this?

Bill: Yeah, I don't know who had mentioned a book. There's a couple of reference books and places where there's a lot of information happening in this space and worth reading. I think you mentioned 'The Phoenix Project' Herman - that's an interesting thing to read. I think another one is 'The Lean Startup' (Eric Ries), which is another good thing to get a taste of this sort of leading edge in this space. I think I mentioned the 'Continuous Delivery' book (Jez Humble and David Farley) and it actually goes into quite a bit of detail, technical detail. There's a lot of interesting thinking going on, I don't know if you guys have other references. Oh yeah, 'The Lean Mindset' (Mary and Tom Poppendieck) there you go.

We've been reading up and researching and applying the stuff at a number of our projects and things we work on, but there's hundreds probably of books, but sifting through this and pulling out the gems and the key themes. Is there any other things you'd add Peter? Any around things you could read or resources that you think are important in this space?

Peter: No, not specifically. I think it's just got to be a good thing to shorten cycle times and to essentially iterate, and if that has to be in a small part of an organisation, so be it, but if the organisation as a whole is to be responsive, then you need that digitisation to the core, and the ability to iterate at a top level, an organisational level.

Bill: Sure. That's great.

Herman: It's a long journey.

Bill: And I like that phrase. Did you say, "digitisation to the core?" I think we should patent that. I like it.

Brendon: Anything more from you Herman before we close out?

Herman: No, thanks, I've already had my cheeky comment earlier.

Brendon: All right well then thank you everyone for participating. It was a good discussion.

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.