Is Bimodal IT a Realistic Approach?
Is Bimodal IT a Realistic Approach?
Zone Leader, John Vester, asks if implementing Bimodal IT is a realistic approach, based upon the staff who are left to support the decision.
Join the DZone community and get the full member experience.Join For Free
Buckled up and all set to kick-start your Agile transformation journey? 10 Road Signs to watch out for in your Agile journey. Brought to you in partnership with Jile.
The topic of bimodal IT has been around for several years and I have a couple clients who are actually considering implementing a bimodal approach to meet the needs of a wide customer base. Upon hearing one particular client talk, with enthusiasm, about implementing bimodal for his team, I wondered if the expectations being set are truly realistic.
According to IT research firm Gartner, bimodal IT is "a collection of principles, capabilities, methods, behaviors, and approaches that enable an organization to differentiate the normal from the abnormal, the evolution from the revolution, the continual improvement from the disruptive innovation — and manage them differently but coherently. It's about the business, not IT, even if in some cases bimodal starts within IT." (Source: Gartner - Deliver on the Promise of Bimodal)
Two modes have been established, to define bimodal IT:
Mode 1 focuses on predictability and has a goal of stability.
Mode 2 is exploratory and is best-suited for areas where an organization cannot make an accurate plan because of too many unknowns.
In essence, Mode 1 operations are basically "keeping the lights on" from an IT perspective, while Mode 2 is where innovation work is performed for future design.
A Similar Example
The bimodal approach outlined by Gartner matches an experience I ran into while working as a full-time employee a few years ago. This scenario was driven by two recently promoted individuals who both reported to the CIO. In an effort to figure out how to allocate staff across these two senior vice-presidents (SVPs), the decision was made that one-half of the development team would be in charge of new application development (Mode 2), while the other half would be in charge of production support for applications that were fully deployed (Mode 1).
Perhaps, on a whiteboard or an organization chart, this sounded like a logical breakdown. One SVP handled everything in production, which included the Data Center and associated support staff, plus a development team to handle break/fix needs and minor feature requests. The other SVP would be focused on meeting the emerging needs of the business, agile and exploratory in nature, to provide solutions that were flexible and not confined by legacy decisions.
The Mode 2 team would provide innovative solutions and, once ready, they would pass the solution to a Mode 1 team, before starting work on the next innovation.
The resulting challenge for this approach is that, more often than not, the solutions designed by the Mode 2 team were not completely thought through from a production support perspective. It was like the team put on blinders and developed a solution that met the business need with a laser-focused approach. While meeting the requested need, the solution often did not fit in well with the larger IT application infrastructure. In some cases, competing frameworks and languages were selected, which had an adverse effort on the Mode 1 team attempting to support the application once it was transferred to their control. In several cases, the Mode 2 design approach was not complete, exposing a backlog of technical debt that had to be corrected as part of the first production support Sprint implemented by the Mode 1 team.
Attempts to resolve these design issues were not successful because the Mode 2 innovators always focused on the next innovation and failed to consider how their decisions impacted production support of the application. As one might imagine, this caused discord between the two modes and cultivated an environment that, though once enjoyable to work in, became challenging at best.
The core of this issue was the need to split up staff in order to accommodate two individuals who were recently promoted. As a result, changing the model wasn't a possibility. The better approach would have been to maintain one development group. Instead of fully dedicating the staff to a given mode, rotating the roles periodically would have been a much better approach. Meaning, the team introducing a new innovation would continue to support/maintain the application, while the other team would be assigned the next new project. I have found that if the Mode 2 innovators go into the process knowing they will need to support their solutions, they are more likely to be responsible with the decisions that are made.
Alternative views of Gartner's Bimodal IT have been published. While some critics recommend staying clear of Gartner's Bimodal IT, others are supporting Simon Wardley's Value Chain Mapping (VCM) concept. The approach behind VCM is almost trimodal in nature, where a value chain exists to meet the ever-changing needs of the business. As part of this chain there are three groups:
Pioneers - truly innovators, like Mode 2 teams in Gartner's Bimodal IT.
Settlers - the missing layer - a team dedicated to refining, maturing, and stabilizing products before they are considered production-ready.
Town Planners - truly production support, like Mode 1 teams in Gartner's Bimodal IT.
The following diagram, courtesy of Simon Wardley, demonstrates how Value Chain Mapping fits into meeting the needs of the business:
Keep in mind, the chart above is simply one step (out of ten) in Simon Wardley's "How to get to Strategy" publication, which I recommend reading when time allows.
In my experience, larger corporations have placed the pioneer need into the hands of enterprise architecture (EA) staff. The EA team maintains the responsibility to innovate, making sure their innovations have the ability to work within existing IT infrastructures. A challenge to this approach is that the burden can be too much to place on the settlers - since they are not always approaching the solution with the same mindset as the pioneer. The pioneer's vision is one of enterprise scale, while the settler has a focus on meeting the current need of the business. So, even in a trimodal (or VCM) approach, challenges should be expected.
I understand there are individuals who thrive as innovators and there are individuals who enjoy their focus on providing production support. However, for a majority of those in Information Technology, there is a desire to participate across both ends of the spectrum. It is important to understand the background, goals, and traits of your staff before trying to place them into positions which are not a solid fit, based on their skills, abilities, and ambitions.
Since an IT department's greatest investment is the human resource expenditure, the decision to implement bimodal, trimodal or nonmodal (I just made that up) should be driven by the people who will actively live in that mode. Making the incorrect decision and hoping for a positive result is no different than trying to place a round peg in a square hole.
Have a really great day!
Opinions expressed by DZone contributors are their own.