Close

How DevOps Can Crush Application Release Cycles

We were recently joined for a Webinar by Jay Lyman of 451 Research. Our purpose was to highlight results from a 451 Research project and share some specific insights about enterprise DevOps and cloud adoption. I also presented an overview of how Actifio helps streamline and automate DevOps. I’ll summarize Jay’s key points here but I encourage anyone interested in the topic to view the entire webinar which includes the Actifio DevOps capabilities overview. Link.

To start, the research clearly shows that enterprises are aggressively moving to DevOps models of application development across a spectrum of industries as well as in the public sector. From Financial Services and Insurance to Telecommunications and Retail, the objective is speed. Every enterprise is looking for an edge that helps gain better readiness and faster response. Speed is a powerful means to distinguish from competitors. Improving DevOps capabilities helps gain faster updates, execute rapid response to security threats, deploy new services and add to profitable revenue. Organizations clearly realize the dangers of not moving faster, evolving more quickly. And the promise of DevOps is just that speed – and the faster release cycles that will deliver more and better business.

However, a major challenge for traditional IT organizations comes in their difficulty moving and evolving fast enough. That frequently leads to unsanctioned use of public cloud resources – what Jay calls “shadowy IT.” The internal IT orgs know it’s going on, and in some cases even encourage it, because they don’t want to slow innovation. It gives them one more compelling impetus for pushing ahead with cloud deployments and integrated DevOps.

Organizations realize that they need to untangle existing applications and decouple them from physical infrastructure. So, many are in the process of modernizing these apps and moving (sometimes very slowly) to cloud or SaaS deployment. But while they’re doing that they’ve also been developing cloud-native apps. Cloud native allows them to do things and add functionality they couldn’t have before cloud was an option.

With all of their DevOps interest, organizations are also encountering new challenges. What is the best way to start? What are the standards? Who’s on the team? What are the best technologies? How can we do this without a major disruption to IT operations and established culture? What are the big-picture consequences of moving too quickly? Too methodically? We know that traditional IT doesn’t like to take chances. Doesn’t like the unknown, the untested. So, these are unsettling questions.

Even though it sometimes seems that DevOps is all about developers, it’s really about the business. It’s about gaining advantage. Yes, there will be a change in culture and a shift away from command and control. Some Fortune 500 companies have even seen the old guard resign before they will move to “cloud first.”

Change is hard, but Jay also had some advice on that front:

  • Start small. DevOps is like a workshop filled with tools. Best not to start with the big power saw.
  • Try it with a net-new application and broaden out from there.
  • Assemble a/some cross functional teams to spread the work, share the glory, contribute expertise.
  • Pull in the shadowy IT users to help. They’re early adopters and likely have lessons already learned.
  • Make self-service capabilities a center point.

The key here is to take away the infrastructure management and log-in headaches for the developers, for the entire team, so they can focus on making better software, improving functionality. That’s why self-service is a priority component of any successful DevOps structure. And, as they tackle the technology and tools, the first teams will also discover the best way to set who-does-what responsibilities and establish new boundaries – or do away with boundaries altogether.

If you’re interested in seeing the webinar in its entirety, you can view it on-demand here.