With DevOps, IT can still be vigilant and responsible while delivering faster and accepting a manageable level of additional risk.

DevOps transformation: Is your IT organization the tortoise or the hare?

Remember the fable of the tortoise and the hare? We were always taught to be the tortoise: vigilant and methodical, as opposed to the hare, who relied on speed and greater risk taking and achieved the expected outcomes. Today, successful IT leaders enable their organizations to be both—to operate with the fiduciary responsibility, governance, and security stewardship of the tortoise, and the swiftness, agility, and (managed) risk taking of the hare.

Traditional IT requires trade-offs

Traditional IT focuses on cost reduction, long-term technology investments, and command- and control-oriented security. The model is effective at managing cost and traditional cyber or delivery risks but requires IT leaders and project managers to continually make trade-offs between speed and effectiveness:

  • Time: Sacrifice speed to affect broad change—initiate major programs that take too long to deliver meaningful results
  • Resources: Work within narrow parameters to achieve velocity—limit the systems or processes a program can impact to minimize security and compliance risks
  • Scope: Limit scope to achieve agility—launching broad and ambitious projects and then cutting away the pieces that slow delivery, meaning the finished product often doesn't address the stated goals

IT will always be tasked with minimizing risk, maximizing operational efficiency, and controlling costs. But today businesses face an unprecedented pace of change, and competition comes in the form of digital disruption from startups or businesses entering new industries. The demands from business on IT aren't just high, they're different.

The good news is that IT has a richer-than-ever tool set from which to draw and a tech-fluent user community that is more tolerant than ever of change. We no longer have the option of being either the tortoise or the hare; we have to be both and more.

Not "either/or," but "both, and..."

DevOps offers IT an opportunity to eliminate some of the trade-offs involved in traditional IT. It's currently a trending topic in tech circles, with a plethora of companies in the container, microservices, and infrastructure-as-code space seeing unprecedented market valuations.

But DevOps isn't just the latest shiny object garnering IT and venture capital attention—it truly presents a departure from traditional thinking and an opportunity to solve some long-standing problems.

In a legacy environment, updating a fully integrated, tier-1 enterprise application is a considerable undertaking. In a large enterprise like HP, such an effort could involve 100 or more people: developers, testers, and security and infrastructure personnel, plus business stakeholders and users distributed across the globe. With a model like this, up to half the project lifecycle can be consumed in project overhead (governance and coordination meetings, authoring and reviewing functional specs, code inspections, phase gate reviews, and sign offs).

Using a DevOps approach means we can deliver value faster and assign a larger portion of resources to the outcome rather than the overhead. We can move faster but also build in protection. For example, if I divide those 100 people into 10 discrete teams, each owning a few more granular parts of the service (microservices) and loosely couple these services, as opposed to the prior approach of tight, end-to-end integration, I can make changes quickly by evolving a few services at a time. I can use a hybrid cloud environment to enable infrastructure as code, so solutions can be quickly provisioned based on established security and performance guidelines without the need to use human "butlers" or buffers to intervene at so many stages of the process.

This can significantly improve time to value and allow IT to incrementally deliver new user and customer experiences and then scale to meet demand. And IT can still closely manage cyber and delivery policies through an informed blend of risk taking and risk management.

Collaborative IT requires cultural evolution

Frost & Sullivan says, "...agility tops business leaders' list of priorities, as they prepare for the fast-paced, hypercompetitive future." IT can offer leaders a clear path to agility through DevOps in exchange for leaders' support of the cultural and process changes necessary to make DevOps a reality.

The continuous integration and delivery model that DevOps enables requires continuous business stakeholder engagement. IT must be plugged in to business strategy and understand what's keeping business leaders up at night, then design IT capabilities to address those issues or drive key initiatives. In return, rather than spending time with IT only during the annual or quarterly planning cycle when IT gathers business requirements and agrees on release delivery plans, the business will be more closely involved in IT planning, testing, and implementation. This model requires the business to spend more time with IT, but it recalls the old adage, "measure twice, cut once"—closer engagement and time spent up front and throughout yields faster time to value and less need for rework.

The build cycle also evolves with DevOps. Traditionally, IT plans a major initiative, procures hardware to meet the demand, and then installs, configures, and tests software for the workload over a period of several quarters or years. With a hybrid cloud model, we have a true on-demand compute infrastructure. We still need the hardware, but it can be provisioned on a "build to stock" basis rather than an "assemble to order" model. We can assess a need and provision solutions on demand, based on pre-assigned design and security parameters.

With DevOps, enterprise IT groups can truly be the tortoise and the hare, realizing the security and vigilance of the tortoise by enabling infrastructure as code and the speed of the hare by creating a microservices model for rapid delivery. As I said in Frost & Sullivan's May 2015 DevOps white paper, to start a DevOps fire "...You start with a few sparks [passionate developers] and some dry tinder [well chosen projects]. Be careful not to add too much additional fuel to the fire too soon or to leave it exposed to the elements of corporate governance before the flame catches and is strong enough to survive."

Note: A similar version of this article was originally published at HP Infrastructure Insights.

Topics: DevOps