As an IT professional you know you need to prioritize the enhancement of IT systems to meet business needs and not just focus on improving operating efficiency. But how do you progress on that DevOps journey, and how do you process that through the lens of Gartner’s Bimodal IT model?
Using the Bimodal IT model's Mode 2 IT has been discredited as strategy. But as with the much-criticized idea of forming DevOps teams, speeding up Mode 2 IT can be a valid tactic for organizations looking to start their transformation journeys. Ultimately, however, your success will only come through learning, and that will come only after a long succession of experiments.
Here are some key considerations for kick-starting Mode 2 IT in your organization.
Focus on strategy and tactics
If you are in a boat with a gaping hole in it, you need to fix the hole to save the boat—and yourself! Simply bailing out the water is no strategy for fixing the hole. As a tactic, however, bailing out water may yield a number of positive outcomes: It can buy you more time, give you better visibility of the hole, and help to stabilize the boat. Having deployed bailing as a tactic, your overall chances of achieving your strategy may significantly increase.
The leaky boat metaphor is an apt one for what it means to have a strategy versus just reacting with tactics. A strategy is a clear picture of what you want to achieve. Tactics are things you may do in an attempt to advance your strategy.
Jez Humble has made immense contributions to the software industry through books such as Lean Enterprise, and the 2016 State of DevOps survey. His advice is always clear and well argued, but sometimes he's a bit harsh on tactics. Back in 2012, just when DevOps and the importance of speeding up IT delivery was getting more attention, he famously renounced the tactic of creating DevOps teams.
This left many people conflicted. They heard great stories about the impressive release and operations performance of organizations such as Flickr but were being discouraged from dedicating a group of people to try to achieve it. My advice is not to worry too much about this. If you want to build a DevOps team, go ahead and do so. I would be surprised to hear of any organization that ended up worse off for creating a DevOps team as part of its tactical approach.
Bimodal IT: Making Mode 2 faster
Fast forward to 2016, and Gartner’s Bimodal IT model has received similar criticism. According to Gartner,
"Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.
I disagree with the notion Gartner put forward in Mode 1 IT that the rate of change must be traded for safety and that, given that, some systems should not be accelerated. As Gartner envisions it, the notion of Mode 1 IT is a destructive and regressive mindset. Mode 2 IT systems are also highly likely to be coupled to Mode 1, creating a bottleneck. Therefore, Bimodal IT is not a valid strategy.
But the creation of a faster Mode 2 is far less troubling to me as a tactic. If you want to make IT systems faster, starting with a few systems and trying to make those go faster is a sound starting point and a great way to combat some of the learned helplessness that we all experience. Many enterprises are struggling with how to successfully leverage Mode 2 IT, and I fully expect it to be a hot topic at DevOps Enterprise Summit 2016 in London 2016 when I meet with enterprise IT executives there later this month.
Experiment, fail, learn
Back in 2011, I had a particularly bad experience setting up a continuous delivery pipeline for a client. All we wanted to do was set up three servers using open-source software to automate the creation of a test environment, along with a build, test, and deployment pipeline. The organization already used virtualization and had spare capacity, so getting started should have been simply a matter of clicking a few buttons.
Despite this, we spent six months having wasteful conversations and creating PowerPoint slides that addressed concerns raised about things such as potential future costs from licensing and servers and whether our approach was "enterprise-relevant," strategic, and scalable. In hindsight, the tactic of making an argument to classify the CD pipeline as Mode 2 IT could have helped.
As an experiment, this was not a completely wasteful exercise. We proved conclusively that the organization's approach to assigning infrastructure was far too unresponsive and that its policies around open source needed a major overhaul.
When creating effective Mode 2 IT experiments, your team must have the freedom to remove as many constraints as necessary, to isolate those, and to speed up feedback. In this case, for example, the public cloud could have accelerated the project by six months. In terms of technology, open-source software has a huge potential to rapidly reduce the setup time for tooling, allowing you to go straight to understanding the impact on people and processes.
The key to responsibly using tactics is to measure the outcomes. Taking a scientific approach, as advocated in hypothesis-driven development, requires that you recognize the fallibility of each tactic and closely measure it for efficacy. Based on the feedback from each deployed tactic, you can learn, adapt, and continue to advance toward your strategy. All of this is good thinking and is depicted in the Deming plan-do-check-act loop. Deming's notion of learning by doing is a technique upon which the Toyota Way depends.
Perhaps Mode 1 should be called "leave as-is for now" and Mode 2 should be referred to as "currently in-scope for a lot of experiments to uncover ways to improve."
Get out there and get learning
There is a popular metaphor in agile that relates to the empowerment of teams. The idea is that if you want to get across a river, you shouldn't tell the team to build a bridge. Instead, empower them to determine a solution. By doing so you may end up with a much more elegant result, such as simply installing a sign that points to another local, pre-existing bridge.
Disparate organizations come together at DevOps conferences, and these present great opportunities to compare notes as you experiment. After a few open discussions with your colleagues about tactics, you'll go back armed with experiments that can really start to drive your organization's learning-driven transformation.
Finally, if you're going to DOES 16 London, be sure to listen to what HMRC's deputy director of digital delivery, Antony Collard, has to say about the success that the UK's HM Revenue & Customs is having with Digital Centers, and listen to what DevOps lead Gebrian Uit De Bulten has to say about what Ingenico ePayments has achieved in the fiercely high-stakes payments industry.
What experiments have you completed on your DevOps journey and what have you learned? Share your experiences below.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
