Conference Coverage

Browse Sections
This content is part of the Conference Coverage: 2016 MIT Sloan CIO Symposium: The digital CIO has arrived
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Mendix CEO: Bimodal IT strategy is a means to an end

IT consultancy Gartner says a bimodal IT strategy is good for digital innovation; Forrester Research says the strategy doesn't go far enough. Derek Roos, co-founder and CEO at Mendix Inc., a Boston-based technology startup that offers a cloud platform to build business applications quickly, says it's a little more complicated than that.

A bimodal IT strategy breaks IT tasks into two speeds -- slow and fast. Slower tasks, what Roos refers to as "mode one," are often related to the traditional IT responsibilities of system uptime, efficiency and stability. (Think infrastructure.) Faster tasks, or what Roos refers to as "mode two," are experimental in nature. Agility and speed to market are important. (Think customer-facing applications.)

SearchCIO's senior news writer Nicole Laskowski caught up with Roos at the MIT Sloan CIO Symposium to probe further on how CIOs should be thinking about a bimodal IT strategy and on what needs to change to ensure "mode two" success.

You participated in this event last year and talked about bimodal IT as a strategy CIOs could use to better meet the demands of the business. Has your perspective on bimodal IT evolved in the last year? And, if so, how?

Derek Roos: My perspective on bimodal IT has not evolved. We're still a big believer in bimodal -- not as a goal, necessarily, but as a means to an end. Most organizations are organized in a certain way that isn't designed for speed and flexibility and innovation. Using the bimodal approach as a forcing function to establish a way to focus on new products, new experiences, and getting things out the door quickly is a great tool.

The bimodal IT concept is starting to attract backlash. Forrester recently put out a report stating it's not a good long-term strategy, that it can create additional complexity and silos within the IT organization. How do you respond to that backlash?

Roos: I agree with the statement that it is not the end state. At the same time, you cannot take a one-size-fits-all approach to innovation or to IT strategies or projects in general. So having an organization and a strategy that can deal with multiple modes or speeds, if you will, and focus on different business outcomes makes sense; that is a long-term situation. But starting with a bimodal approach just to force action and start that change process is one of the best ways to do it. As you scale and as you learn, it's important for the mode one and mode two teams to work together and create a way where the dependencies between the two -- and there always will be dependencies -- are managed consistently. I'm still a big fan of [bimodal], but it's a living thing and an evolving process. The goal should be not to create a silo for either team.

What are some bimodal IT pitfalls and how can CIOs avoid them?

Roos: One of the pitfalls with bimodal is that it isn't done right. In order to become truly Agile and benefit from the speed advantages you could have, you need to address all aspects of what we would call a "mode two success." It starts with what is the portfolio you're going to give to your mode two team; what projects are important; who should you put on the team. That relates to skillset, but, more importantly, to mindset. It relates to the process, and not just the process of how you're going to build applications or how you're going to collaborate with other stakeholders but how you're going to think about DevOps and release management. Lastly, what's the platform that you'll use to build applications?

The pitfall we see all of the time is that organizations create a separate team, but there are still too many dependencies on mode one infrastructure, mode one processes -- whether that's security-related or anything that may slow down the process of the mode two team. The key is if you're going to do it, go in all of the way.

Let us know what you think of the story; email Nicole Laskowski, senior news writer, or find her on Twitter @TT_Nicole.

View All Videos

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

If you're a proponent of bimodal IT, how do you divvy up tasks between the two speeds?
Tasks are fairly reasonably predisposed to one mode or the other. If the mode one backlog grows too large, some of those tasks can be broken down by the mode two areas of IT into smaller mode one tasks, which is also a good way to work with mode one areas and help them transition to mode two.
I’d have to agree that the bi-modal IT strategy is a means to an end. It allows those parts of IT that are further along the evolutionary path, and are therefore more capable of moving at a faster pace to do so, while accommodating those areas of IT that are not yet at that point. However, you do need to have a plan in place to move from a bi-modal system or your IT organization will get stuck there.
Actually, typical real world IT is bimodal or multimodal since a long time. Many large enterprises still have traditional mainframes somewhere, along with some client/server stuff from another era and now, some cloud stuff as well.
The terms "fast" and "slow" can cause misunderstandings, development people think about how quickly they can modify functionality while operations people do care about throughput and response times - occasionally they might be able to prove that old means fast and new means slow.
The real difference and discussion need is between "agile" and "stable".
Which one is more important? None, because we do need both more functional agility and more operational power and stability.
So we do need bimodal IT, with very agile mode 2 sandboxes where business analysts can develop and test their new ideas - and very powerful, stable and reliable mode 1 environments to run the business on, once those wonderful new business models are proven.
Bi-modal is a given for most organisations today but managing the 2 speeds requires a common approach, which most organisations don't fully understand. Most have the necessary potential but lack the means to exploit it.
This is where IT4IT can help. IT4IT allows organisations to address both speeds whilst utilizing an industry standard. My own organization, Hewlett Packard Enterprise, is a leading proponent of this approach.
Bi-modal is a fair label and approach as described for a top level strategy, but the question goes beyond that. The question assumes that the label and approach as described are a full story but queries us for greater completeness at lower level detail. I agree with the craigialexander post and would build on that, to point out the common approach or IT4IT needs to be at a higher level. Common architecture groups are addressing that and they are specialized by hardware, operating systems, DBMS, Security and application stack architecture specialists who support both modes.
To answer the question this widely used approach usually breaks off BI (enterprise if not also applications level) from a combined core business transaction systems, and subsystem support. The idea being the BI and report development efforts are more suited to Agile. But there is a missing part that sabotages the agile development. Epic management in agile really needs to be broken out and become the core of a newer architecture group a business data flow and linage group that proactively makes the full corporate taxonomy and ontology sets available in advance of the business requirements.

Not sure whether forming a new group that is supposed to make "the full corporate taxonomy and ontology sets available in advance of the business requirements" is such a good idea.

Rather, it might make sense to listen to the business people coming up with their new ideas, and help them in formulating their new requirements - with the practical background of what can work and how to best implement the required solution.