Beware the Dangers of Bimodal IT

Many traditional IT executives, reinvigorated and rejuvenated after attending last week’s Gartner Symposium/ITxpo in Orlando, are now breathing a huge sigh of relief. They had been worried they’d have to revamp how they were running their IT shop and bring in a bunch of tattooed hipsters spouting talk of Agile and DevOps, preaching agility but bringing nothing but chaos. Perish the thought.

Instead, Gartner says, relax. Bimodal IT is the way to go. Split your technology efforts into two parts. Let the Agile cognoscenti take over the first part, doing the digital dance with the marketing folks. More power to ‘em.

fossilMeanwhile, leave the second part – slow, traditional IT – to keep doing things the way they always have. After all, traditional IT has forever been responsible for those stodgy old systems of record that have been running the business for decades. Legacy systems don’t like change, and now Gartner is saying that you don’t have to like it, either.

To which I say: balderdash!

The brilliant minds at Gartner – and any other consultant towing the Bimodal IT line, for that matter – are telling their clients what they want to hear, not what they need to hear. Bimodal IT is simply an excuse to keep doing IT poorly.

If the business world weren’t in a constant state of change, then perhaps leaving slow, traditional IT to its own devices would be the low risk option. Well, welcome to the 21st century, folks. The business world is in a perennial state of flux, and the ever-increasing sophistication of technology is only accelerating the velocity and diversity of such change. Transformation is all around us – even in the dusty old data centers filled with ancient legacy monoliths.

The fossil record is replete with species that didn’t adapt to change. Don’t be one of them.

Torching the Bimodal IT Straw Man

Central to the Bimodal IT canard is a false dichotomy between traditional/slow IT (what Gartner calls mode-1) and agile/innovative IT (predictably, mode-2). The false assumption here is that the only way to deal with traditional, slow IT is to transform it suddenly in some kind of big bang, high risk, expensive endeavor. Run everyone through a high intensity Agile/DevOps course and surprise! You’ve just switched from slow to Agile. And since we don’t want to do that, better to leave well enough alone.

However, the entire notion of big bang change actually contradicts the Agile way of thinking, which recommends iterative, customer-focused changes rather than pre-planned, all-or-nothing types of transformation.

Furthermore, there is no black and white distinction between the two modes of IT, simply because the business doesn’t require two distinct modes. Instead, when the business faces disruptive business agility drivers, those drivers lead both to the self-organizing, cross-organizational teams that characterize the agile/innovative mode-2 as well as the transformation of traditional IT – but in a step-by-step, business-driven fashion.

Fundamentally, Bimodal IT recommends maintaining your organizational silos, which is contrary to the entire notion of business transformation. True, I advise executives to know when to optimize, and know when to disrupt – but not in separate silos! There are roles both for optimization as well as disruption-driven innovation in both agile/innovative IT as well as slow/traditional IT, even though the specific optimization and innovation activities will largely be different across the larger organization.

Why Change at All?

I’m not recommending transformation for its own sake. Change only when the business requires change. After all, change is always difficult and often expensive. For traditional/slow IT, an important maxim is that if it ain’t broke, don’t fix it. After all, traditional and slow aren’t bad things in and of themselves if the system in question meets the business need.

But, for those organizations that face internal or external disruptions that necessitate business agility, then simply driving agility in the agile/innovative silo but not the slow/traditional silo is a recipe for brittleness, and when disruption is present, brittleness will most likely lead to failure – of technology to be sure, but also of the organization itself, as it will invariably find itself woefully unprepared to deal with anything new.

Bottom line, if your IT is traditional and slow and you face disruptive business agility drivers, then you must transform traditional IT – but some approaches to such transformation are better than others. Big bang transformations are rarely successful. The better way is to take an Agile Architecture approach that drives iterative, business-driven transformation.

The Agile Architecture approach I write about – Bloomberg Agile Architecture™ – is a business priority-driven enterprise architecture technique that advances the maturity of your organization, process, technology, and information – all iteratively. Furthermore, the agile/innovative digital teams are likely to be more in touch with that particular business priority, because they’re focused on the customer. As a result, disruptive change actually encourages collaboration between agile/innovative and slow/traditional, rather than separating the efforts as the Bimodal IT approach recommends.

Governance: The Tie that Binds

In addition, advancing the maturity of traditional IT means advancing governance to be more agile over time – which is every bit as important as advancing operations, infrastructure, and the IT organization and its processes. Governance, of course, is one of the most important, yet despised roles of traditional/slow IT. Someone has to hammer out the policies and procedures that keep the legacy lights on, maintain security throughout the organization, and ensure the IT shop is compliant with all relevant laws and regulations, after all, right?

Bimodal IT, however, encourages the traditional approach to IT governance to remain largely unchanged – every bit as paperwork-laden and productivity-killing as it has always been, the scar tissue that impedes progress. Yet, when governance lives in the dark ages, people in the organization simply find ways around it, leading to the whole BYOD/shadow IT phenomenon plaguing enterprise IT shops around the globe.

Yes, shadow IT can be wonderful because it gives everyone the freedom to use whatever technology or cloud capability they want without stodgy old IT getting in their way, hurrah! That is, until there’s a security or compliance breach. Then you’ll wish traditional/slow IT had evolved their governance to better suit the changing needs of the organization.

The Intellyx Take: What will Transformed “Traditional IT” Look Like?

Taking an Agile Architecture approach that lets the IT shop optimize what it should optimize and disrupt what it must disrupt doesn’t mean that you’ll need to tear down all your cubes and throw away your ties and panty hose, replacing them with espresso bars and creative body piercings (well it might, but that’s up to you).

In fact, some aspects of transformed traditional/slow IT may not have changed much at all. For example, you’re still responsible for maintaining systems of record until their end of life. However, the way you decide how and when to modernize those systems depends more on business priorities than perhaps they did before, and you’ll favor a lighter weight, iterative approach to legacy modernization over high-risk, big bang projects.

You must also continue to maintain a broad focus on governance, especially compliance and security – but in an inherently agile, increasingly automated way, centering on dynamic constraint satisfaction. Governance becomes less about morale-killing policies, procedures, and endless meetings, and more about automation at the boundaries. In other words, most anything goes, but within the external constraints that IT must enforce.

You’re also responsible for providing access to all those systems of record, and for facilitating the sharing of any other technology resources that people want to share. As a result, transformed traditional IT will be responsible for the appropriate publication, governance, and evolution of microservices and dynamic APIs (I haven’t written about microservices yet, but stay tuned).

Perhaps the most dramatic change that transformed traditional IT will face is its organizational structure. Instead of a traditional hierarchical organization chart that fosters and reinforces siloed, “throw it over the wall” behavior, transformed IT will sport flat, loosely connected organizational structures that encourage self-organization into cross-organizational teams as needed. In other words, a DevOps culture.

The bottom line is that transformed traditional IT must act as the enterprise “traffic cop” – a good cop that keeps agile teams from crossing the compliance/security line, making sure that interactions among such teams play by a consistent, consistently evolving set of rules. Coordinate and facilitate sharing of IT resources where such coordination and sharing is desirable, but otherwise, get out of the way. What’s a good starting point? Stop listening to Gartner.

Image credit: Samantha Henneke, artwork by Bruce Gholson, Bulldog Pottery

SHARE THIS:

Comments

  1. Hello Jason,

    I am following your articles with delight and agreement.
    However today I just had the very strong urge to speak up to understand your concern.
    I think Gartner does very well in advising enterprises towards feasible and easy to understand approaches, while building a future which they (Gartner) can easily predict: If more and more enterprises follows Gartners recommendations, 5 years from now we will talk about the integration of the Bimodal IT model as both IT parts have grown to be separate.

    All in all I would say obviously not an efficient way to go, but it will achieve the target while enforcing Gartners visionary roadmaps. 🙁

    1. Thanks for your comment! Gartner obviously has some very smart people, and some of their advice is spot on. However, much of it is also misleading or incorrect. By taking potshots at them, I’m hoping people turn a more critical eye on their advice, rather than simply accepting it as gospel because it comes from Gartner. So if I encouraged to you think critically about their advice — even if you end up taking it — then I’ve been successful.

  2. Thanks for the article, it articulates well some feelings I had – and for the comment above speculating that in five years we’d all be trying to integrate the separate streams. I’m actually in the process of kicking of a bimodal split of sorts. Mainly due to our large legacy stack with (sadly necessary) huge corporate governance and our ever growing need to move fast at the sale channels. I do not see bimodality as I final, stable state, but part of the transition to a universally more agile future. As we finally decommission some of our legacy, we will redesign, rebuild, move and replace more of our applications and capabilities into mode 2. While we have old stacks not designed for agility, with no automated testing and high risk of change, they will remain in a mode 1 governance model. Gartner do seem to always speak of bimodal IT as a kind of final state, but there is, of course, no such thing. So the integration-in-five-years actually becomes part of the continuous improvement program.

  3. Jason,
    I like your clarity on your positioning and I share your dislike on a personal level.
    At same time I can easily understand why Gartner suggests such kind of approach.
    Even if I do not like it, I recognize it is a very clever way to handle the topic in term of positioning, from their point of view obviously.
    It seems to me that there is a genuine dose of skepticism factored in. The approach “just let them play in the sandbox” and let’s see if three years from now they will still be there, it’s a reasonable approach from this point view (the experiment in the glass lab room).
    Furthermore there is a non explicitly stated implication: you can stay “bi-modal” as long as you want.
    In my understanding they do not see this stage as a transient state in-between. There is no notion of moving the entire IT towards Agile-DevOps.
    This is the real “trap” and also the value proposition for many change resistant IT shops.

    Changing large IT depts. is a hell of work with tremendous risks. So like in any portfolio management with low risk propensity you just blend a bit the portfolio with a small share of risky funds but you hold the largest stake in the safe zone. Low risks, low benefits. This way you can always claim for having an exposure to the Agile/DevOps world but basically you do not need to be concerned and manage a complex transition.

    Just my two cents on where I stand: in our shop we have embraced Agile totally and now we are moving to DevOps. Benefits are much larger than whatever cost of change.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.