Today’s business world necessitates that IT organisations deliver to an agenda of agility and flexibility. The business demands that the IT function adopts and embraces new technologies, with a speed that makes the process challenging for all but the most effective CIOs.

One approach to meeting these demanding business requirements is that of bimodal IT.  The term was coined by Gartner and is used to describe a two-track approach to delivering IT services.

On the one hand there is the traditional method taken by IT organisations, which can be called IT operations or IT ops. This is exemplified by the focus on delivering infrastructure, both physical and virtual.

IT ops is core to delivering mission-critical applications, those that form the core or the backbone of the business. These processes are very structured, with well-documented procedures around the deployment, maintenance, upgrade and decommissioning of technology.

Typically the infrastructure deployed is provided to the business, onto which applications are developed and implemented. The application development process is dependent on up-front planning to scope out the infrastructure requirements.

DevOps represents a new approach to application deployment that provides the development teams with the ability to deploy and manage infrastructure (typically virtual) in an on-demand fashion, to meet the requirements of a specific project.

>See also: What is bimodal IT and what does it mean for the CIO?

The ability to provision resources on-demand allows DevOps teams to be more experimental (and less structured) in their approach, which is aimed at providing a level of agility that can’t be achieved with IT ops.

DevOps requires high levels of automation and orchestration, in order to remove the manual human aspect to provisioning, which would otherwise impede on the agility objectives.

Highlighting the benefits

There are clear benefits to using both methods of deployment. IT ops provides a stable and structured framework for delivering business-critical applications, with known and measured outcomes (such as the time to deliver project resources), albeit with a more elongated timeline. Gartner describes this as traditional, sequential, with an emphasis on safety and accuracy.

In contrast, DevOps provides agility to change approach as a project develops, allowing the application development teams to take advantages of an evolving project. In Gartner terms this is exploratory and non-linear, with a focus on speed and agility.

The benefit of both modes of operation for the delivery of IT is clear. In some circumstances, it’s appropriate to deliver using a fast and agile methodology and in others a more controlled and considered approach is required. How should organisations go about adopting the right methodology for their development work?

Evolution

Introducing DevOps into existing processes needs a strategy that balances both the benefits and the issues the methodology delivers. The use of DevOps is therefore more an evolutionary rather than revolutionary approach.

First of all, it’s important to realise that both styles of deployments bring their own benefits and neither one nor the other suits all requirements. That means team members have to be accepting of both strategies and leave their egos at the door – there’s no room for taking sides with one process or the other.

There’s a need for a balanced approach that requires application teams to have information that allows them to make the right decisions and choose the appropriate direction for developing the application.  This means speaking the same technical language where possible.

Secondly, flexibility is key. Some application development may benefit from an initial DevOps approach in order to scope out ideas, produce multiple choices of direction or design and answer some of the more ethereal questions around the practicalities of the application requirements themselves.

A good example of this could be the development of a mobile app, where the interface isn’t fully specified. A DevOps approach could enable multiple teams to produce a range of ideas that are then narrowed down into a smaller number of candidate designs to be taken forward into the final production release.

Flexibility also means having the ability to change the deployment method as the evolution of a project demands. As an application moves to be mission critical to the business, then the controls placed around it will through necessity become more stringent, implement greater testing and be more controlled to minimize the impact of any failed modification.

Managing risk

At this point it’s clear that both styles of IT application delivery deal with risk in a different way. DevOps embraces risk as an acceptable part of the development cycle. 

An application may be changed and introduce new features but also create bugs (witness how many mobile apps issue a point release not long after a new update that corrects one or two minor corner case problems experienced by customers).

IT ops is more risk averse – changes have greater impact and so have to be carefully managed. Imagine, for example, the controlled process around changing a core banking app or one that runs an air-traffic control system.

Any system or infrastructure change has to be as fully load tested in a pre-production environment and fully monitored once deployed into production.

Infrastructure and tools

Implementing bimodal IT has both an affect on and is affected by the infrastructure and tools used to develop applications. IT ops works well with traditional (and some might call legacy) infrastructure built around single “monolithic” applications that are curated and managed for availability.

Examples here are anything developed around traditional database platforms like Oracle. The creation of test environments is typically very static, with the up-front creation of long-term test/dev and UAT environments that mimic the production environment both in functionality and performance.

DevOps application development uses both a new approach to application deployment and a set of tools to match. Applications are typically “web native” or at least web-friendly, capable of being deployed and scaled out across multiple virtual servers or using container-based technology.

Application development tools like Chef and Puppet allow environments to be built and maintained on-demand from configuration files and rebuilt in an automated fashion.

>See also: Technology service providers must go 'bimodal' or go home, says Gartner

DevOps tools also work at the platform level, with environments that build frameworks for developers to take preconfigured designs and spin up test applications within their own “sandpit”.

While DevOps provides a more flexible and agile development process, it couldn’t be implemented without a strong IT ops basis and this re-emphasises the need to have both methodologies in place. IT ops is the basis for providing a safe, consistent and reliable infrastructure, onto which a DevOps methodology can be placed.

The ability to spin up application development environments on demand places a large burden on IT infrastructure. This means it is more critical than ever to ensure that comprehensive, precise instrumentation and performance management is in place that monitors, manages and maintains the environment that allows DevOps to flourish.

The right infrastructure performance analytic tools provide the capability to allow environments to scale on demand, to highlight potential anomalies and to perform root-cause analysis to correct the problems.

DevOps provides a level of agility that can’t be delivered in a traditional application development process. However, as we’ve seen, there’s a balance between using the right process at the right time.

IT ops still provides the foundation for both mission critical application support, and the framework around which DevOps can be used as a strategic tool to gain real business advantage.

Sourced from John Gentry, CTO, Virtual Instruments