5 Important Lessons about Bimodal IT and Innovation

Based on Episode 3 of the “Hybrid IT Files,” a monthly live, online series from CenturyLink dedicated to searching for the truth in the concept of Hybrid IT. 

I am a fan of a good talk show, and one of my new favorites is a live-streaming show, called The Hybrid IT Files, produced by a team here at CenturyLink. Episode 3, Bimodal IT and Innovation (embedded at the bottom of this post), featured a high-speed conversation between host David Shacochis, VP of Cloud Platform, CenturyLink, Jonathan Murray, founder of n.flex.n software and former CTO of Warner Music Group, and Odell Riley, VP of Corporate Services at CenturyLink IT.

For those who are learning the term, Bimodal IT is the business and process side of Hybrid IT. And while Hybrid IT refers to the fusing of public cloud, private cloud, and on-premises infrastructure, Bimodal IT is about simultaneous management of IT at two speeds:  Mode 1 is traditional, slower, mode of dealing with necessary, important legacy systems; and mode 2 is a fast, non-sequential, usually cloud-based mode for new applications. During the episode, guests opened up about important lessons they had learned from implementing a Bimodal IT strategy inside their large organizations. “Whether hitting you in the gut or hitting home” to quote Shacochis, here are the top 5 lessons you should know about:

Lesson #1 – Bimodal is driven by a combination of internal and external factors

Bimodal affects the internal workings of a business, but it is usually needed in response to a combination of internal and external factors. With business cycles accelerating, companies must react more quickly to changing market conditions. Industries are becoming digital causing barriers to entry to collapse, while we see new competitors emerge in established fields where innovation is set free across verticals and markets. Examples of such disrupted markets abound, and include book retailing, music, travel, and so forth. Companies that have older IT environments must develop the ability to move quickly to stay ahead, or even stay in place. In this evolve or die world, Bimodal IT enables the business to deploy newer technologies, while managing older systems, to meet new demands more quickly.

Bimodal IT can also benefit businesses by helping them to understand their consumers better by integrating previously disparate data sources to translate data into insight, insight into action, action into software, and beyond. Since mode 1 operation makes this exceptionally challenging due to organizations and architectures, which were set up with vertically integrated systems and data siloes, Bimodal IT begins to make the development of horizontal applications data management capabilities possible, with common transactions across multiple systems.

Lesson #2 – You still have “Technical Debt,” but in a different currency

Now in Monopoly if you draw the debt card , you do not pass go or collect $200 until you settle the debt. But in the IT game, technical debt is a term that describes the consequences of previous IT decisions that now make things sub-optimal. Technical debt does not mean that the earlier choices were mistakes – they were likely the best decisions that could be made at the time. However, as technology has inevitably evolved, they impede the ability to make changes quickly and easily. For example, if an IT department committed to UNIX for a certain system, that might be a costly decision to undo 10 years later. The IT department will live with that UNIX system until it can be retired with a minimum of stress and disruption.

Half of the Bimodal spectrum holds the promise of reducing technical debt. When development and deployment are done on an agile basis in the cloud, IT becomes less bogged down in long-lasting legacies. However, getting to that state is partly dependent on execution. Now it is definitely possible to make decisions that may cause problems later on while on mode 2 of the Bimodal track. The very nature of agile development and processes is one that guarantees that some decisions will be wrong and need to be remediated. It’s virtually impossible to move that quickly and avoid creating system elements that are not right. However, the agile nature of Bimodal IT enables rapid rebuilding if needed.

Line of Business (LOB) stakeholders need to understand the new technical debt conversation. There can be a tendency for business managers to think, “Well, the cloud is a totally green field effort. We’ll be forever done with any old IT delays and problems.” This is not the case, though the conditions are different. It’s best to have a constructive discussion with LOB that gets into detail about the kind of coexistence that will take place between legacy and newer applications as well as the new kinds of technical debt that will have to be “paid down.” In the future, technical debt vectors will take different forms, such as proprietary service lock-in and orchestration layer incompatibilities.

Lesson #3 – How you get started will depend on your organization’s culture

An IT organization that moves to Bimodal IT needs to choose how it will start the transition. Gartner makes a distinction between limited, project-based Bimodal and all-out company-wide approaches.  While most organizations will do some sort of pilot project to initiate the rethinking of IT, some will move a lot more quickly than others in taking it company-wide. Ultimately, how a business gets started on Bimodal depends a lot on culture and politics.

Some companies can handle a radical, all-in path to Bimodal IT. In this scenario, the IT department makes a total commitment to Bimodal IT, gets buy in from the LOB, puts legacy systems on ice to keep the business running, and plunges right into creation of full-blown mode 2 – taking the business from 0–60 on this track and never turning back. This is not for faint of heart. There are multiple issues to contend with that will challenge embedded cultures and attitudes. Existing staff will need to be retrained and new staff with new skills will need to be hired.  Newer tools that focus on managing automation rather than caring individually for servers will need to be adopted .Most of all the organization will need to adopt newer, more modular philosophies of application development and deployment. Sound like an extreme makeover? It is, yet the business benefits might be worth the dramatic change.

Though the radical approach might not work for everyone, it has one advantage. Existing infrastructure can cause friction in getting new applications out to market or to internal users. This reality favors being aggressive and building the foundation of Bimodal IT rapidly to enable a quick transition when everyone is ready.

Lesson #4 – Bring “Shadow IT” into the IT department

“Shadow IT,” the practice of LOB freelancing its own IT with SaaS and public cloud, loses its traction in the context of Bimodal IT. The IT department can now compete to bring Shadow IT in-house, offering LOB the equivalent level of speed and economy but without violating security policies or abdicating control over corporate systems. A move of this kind can quiet the “IT is too slow” argument and restore confidence in the leadership and value of the CIO to the business.

Organizational realignment is needed to bring Shadow IT inside, though. Bimodal IT makes it possible for stakeholders to work together more closely and dynamically than before. However, this change won’t just happen. Managers in all affected departments need to work out a plan to make the new model a reality. One approach is to modify the IT department/business relationship so it looks more like that of an actual technology company, with product managers and rededicated development teams that work long-term on internal “products” that are used by the business.

With a product manager-business style relationship, the development teams can achieve a deeper understanding of business needs. Everyone can collaborate on a road map for getting to editions of the product that meets future business requirements. Adding in agile development, the entire software development process changes. Now, LOB people can sit down for a week of wireframing and white boarding and see an early build after a two week sprint. This is a big change from the traditional approach of spending a month working out a lengthy, complete design document for an application that gets delivered in entirety a year later.

Lesson #5 – Build a “Software Factory” out of loosely-coupled application elements

Success with Bimodal has a lot to do with taking the right approach to enterprise architecture. The best practice is to assume that anything that will be built will definitely need to be replaced within a foreseeable time frame. There is no such thing as a permanent application, operating system, message queue, and so forth. The way to solve this problem is by creating an architecture that is as loosely-coupled as possible while utilizing a flexible and standardized interface. Think Legos.

Any layer of the stack should be able to change without affecting other layers.  The ideal is that any workload can be moved to a different stack and still run. If a workload runs on Amazon, it should be then be able to port to OpenStack without recoding. This is the ideal, of course, seldom actually reached.  But, it provides a good goal to keep in sight.

When the IT department sets up an array of loosely coupled components for building applications, it’s like creating a “software factory” where development teams can assemble software quickly using pre-built or easily adaptable parts.  The developers don’t need to know about underlying component technology that enables fast delivery.


Bimodal IT is not a panacea to all issues IT is challenged with. Yet, the approach of separating old from new and slow from fast enables the dialing up of speed where it counts for a business. The challenge, of course, is getting all the details right, on both technology and organizational fronts. There are a lot of moving parts. Yet as we heard Murray say at the closing of the program, success comes when two or three IT and LOB leaders understand that “the world is going to change, needs to change, and they need a new way to deliver and so are willing to take the risk by placing an early bet, when they see it deliver 3x faster to market […]” that type of result makes going off the beaten path worth the risk.

If you’re planning to further your investments in mode 2, here is a helpful series that discusses the solutions to hybrid cloud challenges as you plan your road map off the beaten path.

Comment (1)

Leave a Reply

  1. Juan H. Stagg

    interesting view. The explosion of immediacy brought along by the Internet and social media coupled with all sorts of apps that promise to do things rapidly, has created a perception that IT is to slow. This happens when IT doe not or can not evolve due to personnel or company policy. The mission of what used to be IT, should be to transform itself into the enabler of innovation and process efficiency while driving real change whose results can be measured by previously agreed upon KPI’s.

    The Bimodal issue is dead on. We use this on several areas and it ha proven that no mattes if you use local resources or hire a good third party cloud and solution provider, the launch time is as good as the motivation of the business people involved. Change happens in direct proportion to the dependency of the people involved have on the person leading the implementation effort. When the CIO is very close to the CEO, things happen much more rapidly, since the first gets more authority to align process to company mission across all the boundaries of department heads and is able to avoid repeated tasks and assign accountability to the process lead and not the Department head. This method works and works well. It creates discomfort but in the long run, it is necessary to get process oriented change in conjunction with the measurable goals of the enterprise. The use of any technical means should be transparent to the end user but as efficient as can be afforded. The payback will chow in the short term KPI and in the aggregation of the multiple KPI complied with.