Within Gartner, there’s a lot of talk about Bi-Modal IT. Bi-Modal IT was borne out of a business need to increase IT agility and innovation, while simultaneously meeting performance and availability requirements of the business. Thus, a bimodal capability is the marriage of two distinct, but coherent approaches to creating and delivering business change:
- Mode 1 is a linear approach to change, emphasizing predictability, accuracy, reliability and stability (aka Samurai mode).
- Mode 2 is a nonlinear approach that involves learning through iteration, emphasizing agility and speed and, above all, the ability to manage uncertainty (aka Ninja mode).
Most mainstream enterprise networking teams are optimized to operate in mode 1 (think change windows, maintenance windows, and NCCM tools). But what about mode 2, does this even matter to network infrastructure (aka the digital plumbing)? Yes, because as stated in the research, the unplanned nature of Mode 2 projects challenges existing network staff skill sets and sourcing methodologies.
Given that SDN creates programmatic access to the network, which could land in the hands of application owners – that must be the best fit for Bi-Modal IT, right? Well…not quite, well at least not today (always good to remember that despite what you hear, SDN doesn’t fix everything).
Right now, from a technological standpoint, the best way to support a Bi-Modal IT capability is (in many senses) to get the network out of the way. Getting out of the way lets the DevOps teams go crazy with their code and the tooling/management framework de jour (Mesos, Kubernetes, Docker, OpenStack, VMware, etc.). That said, there are several things that need to be done to the network:
- Build self-service capability into your network infrastructure which allows the lean/fast/agile teams to serve themselves (without waiting for the corporate IT and change windows). This includes base network concepts (VLANs), DNS/DHCP and L4-7 services (app delivery, security).
- Similarly, invest in networking solutions that are highly automated and include hooks that the DevOpsians want like Ansible, Chef, and Puppet.
The combination of the above two gets your closer to that Developer panacea: They can get all the stuff they need via API (how very Amazonian of you) and/or pull down reference templates from Github.
However, transport bandwidth and latency still matter, especially when the WAN is involved. Thus, you want to create a WAN solution that enables ubiquitous connectivity to public cloud services, and overprovision WAN access for Internet and WAN services at key sites and data centers. Ensure the provider can provide network capacity on-demand (so you don’t have to tell the business to wait ~60 days while we upgrade the Internet headend).
Lastly, as with most things, the technology is nice – but staffing and culture require investment also, which includes (among several other things) evolving existing staffing skill sets towards APIs and programmability. More details in the full research note written by my colleague Bjarne Munch:
Network Planners Need to Prepare for the Impacts of Bimodal IT
Summary: Existing network planning will be broken apart by the impacts of digital transformation and bimodal IT. Network planners need the ability to adapt network solutions to unplanned business projects.
Read Complimentary Relevant Research
Top Strategic Predictions for 2018 and Beyond: Pace Yourself, for Sanity's Sake
Technology-based innovation arrives faster than most organizations can keep up with. Before one innovation is implemented, two others...
View Relevant Webinars
Channel Trends 2017: Three Activities to Focus on
Widespread digital transformation and shifting buyer expectations are placing demands on technology provider channel leaders to enhance...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.