Defining DevOps from the Customer’s Perspective

There has been much discussion lately on the topic of “what is DevOps?” I sense a bit of a struggle to define the basic value proposition. If we view things from the customer’s perspective, though, the value becomes easy to see: Cloud computing turns software products into services. It used to be that software companies designed and developed software, then distributed it to customers, who took responsibility for deploying and operating it. Software-as-a-Service means that the same company that builds the software also operates it on the customer’s behalf. In the cloud, operational excellence is a fundamental part of what the software vendor is selling. Operational excellence implies more than just scalability, availability, and security. Part of the benefit of having vendor-operated software is immediate access to software updates. Operational excellence thus includes the rapidity, and quality, of the software release process.

Software-as-a-service means that sales and marketing need to care about operational excellence. The agile development process needs to incorporate non-functional requirements. The software release lifecycle needs to be optimized just like the design/development process. In a sense, Agile has always been incomplete, even before SaaS: no matter how great the development process, it has no benefit unless functionality can be delivered to the customer.

It’s important to remember that customer delivery includes non-technical components such as documentation and training. By the same token, integrating operational excellence into the product means that operations needs to think about the customer. Ops is no longer about managing servers and networks (assuming it ever really was). Instead, it’s about managing the customer experience. If development introduces code that makes the application slow, operations cares. Ops also need to care (and in order to care, they first need to know) if they accidentally turn off previously released functionality. The fact that the infrastructure still works is of no solace to users.

Much is made lately about continuous delivery. DevOps groups are very proud of how many times per day they can release new code. But what is the impact on the customer? If they are continually surprised by the change, will they consider it good? I know that if I log into a site, and the navigational mechanisms have changed without warning, and I don’t know where to click, I feel like something is broken. Again, ops need to think in terms of the customer experience. Perhaps, rather than “continuous delivery,” we should call it “frictionless delivery.”

I don’t think DevOps is really about dissolving boundaries between operations and development. I believe it’s about dissolving boundaries between all the groups involved in delivering software services, from marketing and design, through development and QA, to operations and support. Beyond adopting specific agile development techniques, such as scrums and continuous integration, DevOps needs to adopt Agile’s underlying philosophy of delivering customer value. It may be that DevOps is unfortunately named. The name focuses us on a single part (dissolving boundaries between dev and ops) of the whole need. What we’re ultimately striving for is a unified software service delivery organization that aligns all teams with each other and with the customer. This unified organization needs to integrate design, marketing, development, QA, operations, and support. Together they can practice what we might call “User-Centered IT.”

Post Comment