carloscastilla - Fotolia
The bimodal IT model dictates that IT delivery is split into two separate modes -- so will it cost twice as much?
Mode 1 is structured to maintain legacy hardware and core back-end software stacks that demand stability and reliability, typically achieved via traditional IT operations. Mode 2 embraces fast, agile, nonlinear practices, typically to enable new opportunities for the business. Two independent teams work simultaneously to optimize these two sets of systems. While IT experts debate the long-term value of a bimodal IT strategy, the concept acknowledges a core premise of systems development: One size does not necessarily fit all.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this age of erasing silos and optimizing the use of talent and technology, bimodal IT institutionalizes a barrier between the old and the new, imposing costs that organizations do not anticipate or adequately fund. These overlooked costs can jeopardize a bimodal IT initiative.
1. The skills to pay the bills
Organizations overlook the investment needed to cultivate or acquire hardware and software skill sets for bimodal IT environments. New IT professionals rarely possess expertise in traditional hardware platforms, such as mainframes. Similarly, new developers know C++, Java, HTML, Python or PHP, and cannot replace the aging population of programmers that service COBOL and job control language (JCL) scripting used on the mainframe OSes. Mode 1 is a tough sell for hires looking for opportunities on emerging languages such as Go and Swift.
A company can pay a premium to attract or retain skilled employees, though money only motivates staff for so long. Cross training will get existing staff skilled in handling both modes, but training is an unpredictable and recurring cost as employees change roles and leave the company. Outsourcing, at least for some low-level tasks, is another option, but it moves some project control and intellectual property outside of the company.
2. Help wanted
Even where an adequate scope of skills exists, bimodal IT may not be practical with the existing staff composition: There are simply not enough people with the right skills to support the two distinct IT delivery groups in a bimodal IT model. The company must increase staff count for either mode -- or for both.
The additional cost of salaries and benefits is compounded by the complexities that bimodal brings to staff motivation and career objectives. One of the principal complaints about bimodal IT is the intentional separation between legacy and innovative systems leaves mode 1 staff just keeping the lights on, while mode 2 staff gets to work with the interesting stuff that adds more value to the business. Ask any IT professional which team they'd rather be on.
Business leaders adopting a bimodal IT strategy must make a concerted effort to underscore value in mode 1 projects, and reward mode 1 staff accordingly. Some organizations rotate staff periodically between teams; it helps to cross-train skills, and improves communication and cooperation between teams to reduce any barrier or silo between them.
3. A mechanic's shop of tools
Different modes of IT delivery inevitably require some different tool sets. Mainframe management platforms and software development tools are unlikely to suit DevOps-style continuous development and deployment on cloud resources.
For example, a given mainframe requires COBOL, TSO I/O spoolers, the z/OS operating system, Interactive System Productivity Facility source code and text editor and scripting with JCL. A distributed server cluster at the same company runs Windows Server 2012 OS instances with VMware ESXi virtualization and Microsoft System Center and Chef management tools, among other point tools for monitoring and management. The services it hosts rely on .NET and an array of development platforms.
Enterprise IT tools use is hardly free, making multiple tool sets particularly challenging to a budget. For every tool, consider the cost of acquisition, deployment to host the tool, maintenance over its lifetime -- configuration, patches and updates -- and ongoing user training. Many tools carry vendor support costs. Even open source tools take time and expertise from the team.
Disparate IT tool sets also pose potential communication gaps between bimodal IT teams.
4. Keep that old clunker running
Traditional software is inexorably tied to its hardware -- directly addressing specific memory locations, buffers, ports and other physical elements. The software is incompatible with later hardware, without an extensive and potentially disruptive translation. The result is an insidious form of lock-in, where developers must maintain aging code to run on even older hardware. This is the challenge of some mode 1 operations in a bimodal IT model.
Aging hardware poses an ever-greater cost and risk to the business in terms of support. Vendors are motivated to retire aging systems in favor of selling new tools and services. As aging parts become rarer, prices escalate on even the most mundane components. In some cases, parts are no longer available from the vendor, only to be found on the resale/used gear market.
As described above, the skills base to support the hardware also dwindles over time. Vendors typically provide training and technical support for systems through warranties and service contracts. As systems reach the end of their product lifecycle, OEM vendors will discontinue service contracts, sending IT organizations in search of third-party support organizations.
Ultimately, the company pays for legacy hardware without expecting a return on the investment. Eventually, mode 1 systems and software must go.
5. Time is money
Business leaders must expect overlooked costs from policies and procedures. Modern IT delivery translates policies into workflows and then streamlines them through orchestration and automation. Bimodal IT requires mode 1 and mode 2 policies and procedures. Teams will spend time and may need to purchase tools to draft, implement and maintain two sets of processes. There are also unforeseeable costs of complexity and confusion for staff that run multiple processes in a bimodal IT model: oversights, mistakes and compliance breaches could occur when someone accustomed to one mode moves to the other.
Bimodal IT processes are often interrelated and intersect in places. For example, an innovative new applet released by the mode 2 team queries a complex database that resides on a mode 1 system. The slowest piece (mode 1) could constrain development on the fastest piece (mode 2). In the example, the applet must wait for an update to the underlying database to support its complex new queries. Process delays potentially mean lost revenue or competitive advantage in the marketplace.
Another tenet of the bimodal IT model is that mode 1 legacy applications are modernized into more nimble systems; and mode 2 innovative systems become hardened, stable, predictable workloads over time. If the team institutionalizes static mode 1 and mode 2 operations, it will prevent this evolution on both sides. Whether you plan to build a business around bimodal IT or simply see it as a transition to more dynamic IT delivery paradigms like DevOps, step back and recognize some of the potential pitfalls and costs. While both modes may operate quite differently, they must ultimately provide measurable value to the business.
The bimodal IT strategy is not without controversy
Gartner redefined "bimodal IT" two years after its debut
The bimodal model may an incomplete and short-term solution to a long-term problem