DevOps really does speed things up, study shows

DevOps really does speed things up, study shows

Summary: New study suggests a real impact on the business when developers and operations people put their heads together.

SHARE:

The practice of DevOps -- in which developers and operations people collaborate on applications as they are designed, built and tested -- is increasing the speed of software deployments by 20 percent. 

US Census National Processing Center photo from US Department of Commerce
Photo credit: US Census Bureau, US Department of Commerce

That's the takeaway from a study of 1,300 IT executives and managers, just released by CA Technologies. Respondents with DevOps practices report they have experienced anywhere from a 17 to 23 percent improvement in business in the form of increased revenue, faster time-to-market, improved competitive positioning and enhanced customer experience.  Nearly all respondents recognize a greater need for DevOps strategies now than before.

Organizations with DevOps approaches say they have seen a 22 percent increase in customers and 19 percent increase in revenue as a result of putting the methodology in place.

Two-thirds of the organizations in the survey say they have or are developing DevOps strategies. DevOps isn't as straightforward as it sounds. Developers like to work in unstructured ways with bursts of productivity, while IT operations people are schedule and process-driven.

However, what really matters in the end is the customer, be it an internal group or external consumers. In fact, the need to improve the end-customer experience is the number-one driver of DevOps (cited by 68 percent), followed by the need for greater collaboration between development and operations teams (61 percent). The rise of mobile and cloud -- with their lightening-fast requirements, also are major reasons for DevOps, cited by 52 percent and 43 percent respectively.

IT optimization factors, such as solving for the complexity of IT systems and cost-cutting, are at the bottom of the list (seven percent two percent, respectively).

How do organizations get to DevOps?  IT automation is seen by most as the best route (52 percent), followed by adoption of Agile methodologies (47 percent).

Topics: Software Development, IT Priorities

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • What do you folks do here?

    I still say the biggest challenge in business software development is getting the end users to precisely articulate their business processes. It amazes me how difficult it is to find out exactly what happens at each step in an organization. Without that, you can't automate it properly, and if you try the users won't relate to the system when it's done. Yet in most places, you have to get at least 50 people in a room to figure out, for example, what happens to an "order" from the time it arrives from the customer at the mail room until the product gets on the truck. Unfortunately, there's never a shortage of people who =claim= they understand every step in the process, and if you let them, they will help you develop something that the users will hate.
    Robert Hahn
    • Re: getting the end users to precisely articulate their business processes

      Rapid prototyping works well here. Nothing like showing the users actual (if incomplete) working code and seeing them immediately say "no, that's not what I meant" or "it should be more like this" or "that's it".

      If you insist on getting all the specs hammered out up front, the system will be obsolete before it can be deployed.
      ldo17
  • I use a few methods...

    for the existing applications, on the most critical and highly used screens i put one of our developers running those screens for real every day. This helps us find every bit of optimisation we can squeeze in and we very quickly find if anything is not as fast as the developer thinks it should be. This is brilliant for some of the work we do.

    the second method I use is that I, as the head of dev or another senior dev, actually sits down and shadow an employee for a few hours at a time. This helps tremendously in finding the easy changes or requirements that bring immediate benefits to the company. it also gives the opportunity to remember to those employees when something could be done faster if they were using screens they forgot about...

    for new project I just go general planning, designing and only go Agile after i have built a first beta version. most often Agile from day 1 is useless. first we need to guide the other people with something concrete since as soon as you put an non developer in front of a non working 'version 1' screen they just cannot get their head around the fact this is just a mock up. But from the beta, agile, agile, agile!
    Drakkhen