Rule #1 for your Digital Transformation is to Fail, and Fail Fast!

Christopher Harrold

Subscribe to Christopher Harrold: eMailAlertsEmail Alerts
Get Christopher Harrold via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: DevOps for Business Application Services, Application Performance Management (APM)

DevOps: Blog Post

Taking Back IT - DevOps: Bimodal IT By @CHarrold303 | @DevOpsSummit #DevOps

Or how I learned to stop worrying and tolerate my legacy software

In my previous posts I have been talking about the issues with DevOps as seen from the Operations side; the cultural changes needed and the reality of the challenges that are faced getting there. As a firm believer in the idea that you "never present a challenge without a possible solution" it's time we talked about one of the ways to start building towards true Operationalized DevOps.

Bimodal IT is a concept that was revealed by Gartner in 2014 as a possible model to address the reality of the IT Operations landscape. My first reaction was much like this article. To sum it up, "If you cannot do everything in an agile way, your company is dumb, and you should go work somewhere else". To be fair, as a long-time, real world practitioner with no love for analysts and the ads in CIO magazines designed to make your boss's boss buy some new shiny widget, it did sting a little that this idea comes from Gartner and probably made me less likely to trust it initially. As I have worked with Gartner and understand more about their business and what they do, and looked at the reality of what they were saying through the lens of my colleagues still in the IT trenches, I realized that like so much of my legacy IT ways, that bias had to go. I am glad it did, because what they released was truly an informed (if not quite fully articulated) means to bridge the chasm between legacy IT and DevOps and can provide the foundation for what Operations actually wants: a way out of the wasteland.

The premise of Bimodal IT, grossly oversimplified, is that you have a "fast" and "slow" infrastructure/operations platform running in your environment - a "fast" platform for the new stuff that needs a fully engaged agile DevOps platform and a "slow" platform that allows the legacy systems to coexist on the consolidated infrastructure. The underlying implication is that, like many other areas of innovation, you have to start somewhere to get where you want to go and this offers a path to support the current platform while enabling a more realistic migration to the "fast" way of supporting infrastructure and operations.

The reality is that everyone wants to move to the hyper-agile, DevOps model where new cool tools and exciting discoveries with data and apps will happen immediately and continuously. Unfortunately the vast majority of what drives our businesses is not ready for this. You are not going to run your existing Oracle/SAP/MS SQL as a micro-service anytime soon, and this reality is why most organizations older than a couple of years cannot move existing platforms to something new even if they would like to. They run on them day-to-day, the cost and level of effort is astronomical, and the payoff really isn't there unless you look WAAAAAAYYYY down the road. As anyone with more than a 5 minute IT career will tell you, no one looks that far down the road in IT. The ROI for something has to be measured in weeks and months, not years, and the impact of changes measured in seconds or minutes and not months. I think that this has led to a lot of the anti-Bimodal rhetoric that is out there. The fact is that most of the rhetoric misses the mark, because it is too bogged-down in the minutiae of what problems Bimodal "could" create and the "because (insert internet-age buzz-word company here) does it, everyone should" syndrome.

The simple fact is that no matter how much we all want to be crazy agile and do amazing innovations, the reality of our legacy IT world prevents this on a wholesale level. Bimodal isn't "the answer" - always remember, you cannot buy DevOps! - it is just a path to take. While I do not agree with all of it's tenets (such as leaving legacy applications alone in their own bubble and not trying to improve or innovate against them) I do think the core concept is sound. I humbly offer then, my opinion on what it should enable if managed properly.

Bimodal offers a way for the smart IT innovator to provide a path to move from slow to fast where it makes sense and still enable functional Operations responsiveness to the overall IT landscape, without a wholesale rip-and-replace of everything. It does not prevent innovation as the article I cited above would seem to imply, it enables it by allowing the platform for innovation to exist in the first place; a major roadblock to adopting the full DevOps stack at most organizations. The premise and even the execution is highly possible if one follows the conversation I spoke of in my previous posts and maintains the mindset that the only constant is CHANGE. Simply put, the real Bimodal IT execution path is parallel execution on a consolidated platform wherever possible, and leaving those applications and tools that cannot coexist or modernize, in their bubble so as not to slow the rapid innovation of the newer platform.

Bimodal starts small and removes the primary barriers:

1. Split the stuff that for whatever reason, cannot be virtualized or otherwise commoditized into it's own bubble. This is not an overnight process, it can take many weeks and months, but it can happen in small increments with minimal disruption. One example here is letting the AS/400 have their own bubble of operations space/time. The AS/400 isn't going away, so don't force it, just operationalize it into its dedicated operating space and give it room to do what it needs to. (Most companies already have this, but it bears mentioning as a simple example - replace "AS/400" with "DOS-based legacy app requiring hardware dongle to work" and you have the same picture. Yes, they still exist. You would be shocked.)

It then splits operations into the two tracks:

2. Bimodal done right implements a parallel platform inside/alongside the legacy one. Everyone has virtualization or at least knows about it. It is a requirement for the on-demand, ___  as a Service world we want to get to. (How you virtualize is your personal preference, but when choosing, remember that you are building your house on this foundation. I am a big fan of being able to call tech support if something breaks at the base levels.) Inside this virtual world you need to have the platform for rapid and continuous delivery that is in its own domain, subject to the basic controls and policies of the whole of IT, but free from the legacy constraints that cause IT to be a roadblock instead of an enabler.

There are lots of tools for this and I will not give any endorsement, because all of them fill specific needs and solve problems that you may or may not have. You choose tools to support outcomes, you don't build outcomes around a tool. As an example, any of the CloudFoundry environments come to mind here (BlueMix, PivotalCF, and others) as one way to enable a continuous, service delivery architecture inside your existing platform. You are now operating two modes of IT delivery for very different applications and outcomes.

It moves tools and services to the new model where appropriate, over time:

3. The final chapter of Bimodal is a whole story in itself. You build new on the new, and you migrate legacy onto it as you can. The "old" never goes away most likely; it is maintained, on the same platform and in the same realm, using the types of tools that allow you to do both types of IT, and yes they exist. The end goal is to optimize and enhance wherever you can as you grow and change, not to completely remove the legacy world.

It is overly pedantic to say "if your organization can't do everything agile, they suck". There is no real way any established organization can transition everything all at once because except for a true technology company, it isn't their business; they make/sell/service in a different way from a tech giant. It is also not about "separate but equal" IT; the fact is the legacy environment ISN'T the equal of the new DevOps world because IT CAN'T BE. So how do we find the right way to balance these worlds? Bimodal IT can be an answer if you see it for what it is, a pragmatic and realistic view of a shift that is already in place from static to dynamic IT delivery, and a path to walk in between them.

Missing the mark? Want more? Flame on? Comments are encouraged and welcomed here or on twitter @charrold303

More Stories By Christopher Harrold

As an Agent of IT Transformation, I have over 20 years experience in the field. Started off as the IT Ops guy and followed the trends of the DevOps movement wherever I went. I want to shake up accepted ways of thinking and develop new models and designs that push the boundaries of technology and of the accepted status quo. There is no greater reward for me than seeing something that was once dismissed as "impossible" become the new normal, and I have been richly rewarded throughout my career with this result. In my last role as CTO at EMC Corporation, I was working tirelessly with a small group of engineers and product managers to build a market leading, innovative platform for data analytics. Combining best of breed storage, analytics and visualization solutions that enables the Data as a Service model for enterprise and mid sized companies globally.