Consider the topic of Bimodal IT. Its merits are very controversial and have inspired a great deal of debate between competing analyst firms, industry thought leaders and the media. When we compare what Gartner prescribes versus two of our favorite technology thinkers—Martin Fowler and Jez Humble—we find ourselves formulating a balanced perspective based on what we hear from customers.

Starting with Gartner’s Definition

For those that aren’t subscribers, Gartner offers the following definition for BiModal IT: “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.”

A central piece in the BiModal debate comes down to the perception the definition creates—that is, companies must compromise safety/accuracy in order to attain agility and speed.

We are with Jez and Martin on this point–it’s just not true, when you really understand the principles of Agile and DevOps. If anything, the opposite effect – speed and high quality – are the results and this is well documented in The DevOps Handbook and Puppet’s State of DevOps Annual Report. (If you haven’t read these, it’s very worth the read. Links at the end of this post).

Agile and DevOps are the Path to Continuous Delivery

We believe BiModal IT was intended to apply to larger companies beginning to embark on the journey toward continuous delivery. They need to accelerate in order to compete in today’s highly connected world. And, conceptually the BiModal IT model makes sense when you consider how protective enterprises are about their legacy systems (“systems of record”) that are business data critical.

In many respects Mode 2 reminds us of the term “skunk works projects” (from days gone by—Pre-Agile & DevOps) when companies needed to change dramatically, but without impacting their current business. So separate groups would be created for true greenfield development and build the next “new” thing. It would help the company understand what their future could hold. However, whether you call it “greenfield or Mode 2,” some how that company still needs to figure out bridging the gap between legacy and new. On this point Gartner does explain that both Mode 1 and Mode 2 need to “synchronize,” but as Jez Humble points out in his (April 2016) blog, that process is fraught with complexity and problems. According to Jez, “The rate of evolution of any Mode 2 system will be constrained by the rate of change of the slowest system of record it talks to.”

So, here’s what it comes down to, for any organization to bridge legacy and new in today’s environment, holistically embracing Agile and DevOps leads to a sustainable model that achieves the business objectives, accelerates time-to-market and improves quality.

Is there proof? Yes there is. As Jez points out, “Market leaders such as Google and Amazon are managing each of their thousands of services according to its unique risk profile, with continuous delivery as the default approach.” So, there is substantial data supporting companies successfully using DevOps to transform.

There is a Gap Between Early Adopter Success and the Average Company

But, still there is a gap. And this is where we diverge slightly and try to bring our real-world experience to the table on the topic. As we have said in prior posts, we all know that many companies are still struggling to figure out how to adapt.

We think some of this gap comes from realizing that the early adopters—large enterprises— committed the resources, money and time to truly facilitate the change. And, from the top of the organization down to the individual employee, everyone understood the change was happening. It wasn’t optional. It wasn’t a side project, it was fully embraced and fully supported. In reality, every one of those DevOps success stories actually had challenges they had to work through. Much of that experience was presented at the recent DevOps Enterprise Summit in SF. But, the beauty of their stories is that they planned well, had company-wide support, persevered and as a result, achieved success.

What it Takes to Get There

For every company trying to figure out how to adapt, the key takeaway comes down to having a clear intention to achieve rapid service delivery (the first step toward continuous delivery), as well as really having the executive commitment and resources to make the transition happen. In our experience, there are two primary reasons DevOps projects fail, the negative cultural impact when executive commitment is vague, and resource skill sets unprepared for the work.

Being an Agent of Change

At Daitan, we live and breathe Agile and DevOps in our work. We understand what it takes to get there. We bring change about by taking sensible tactical steps to get the engineering teams on-board and actively driving the transformation throughout the company. For example, working with customers that need to renovate a monolithic application into a microservices-based architecture, we augment their teams to bring the technology forward, as well as, use Agile and DevOps best practices throughout. Their executive management actively participates along with Devs and Ops teams to transform their company, culture and products. So you see it’s not just a product transformation, it’s a company transformation that comes about once you get on-board with Agile and DevOps—and it’s well worth the effort.

In a future blog, we will elaborate on the scenario of monolith-to-modern architecture, and talk about the role of Mediated APIs as a key component and important stepping stone to get there.

As always, we invite you to read our latest paper, “Renovate to Innovate—How Mediated APIs and Microservices are Enabling Technology Companies to Expose IP, and Deliver Faster Innovation Cycles” which touches on much of what we talked about here today. No form, no email required, straight access to the paper. And of course, here are the links to The DevOps Handbook and Puppet’s 2016 State of DevOps Report.

How APIs and Microservices Enable Innovation