What's with all the fuss about DevOps?


Bridging the Rift between Dev and Ops
As a member of the Product Marketing team at SAS, I spend a good part of my time researching – analyst reports, industry journals, blogs, social channels – and listening to what our customers are saying. Early last spring I began noticing the term “DevOps” showing up with more frequency. My background is in programming. I understand Dev, and I understand the role of Ops, or IT Operations. The oil and water act of bringing together Dev + Ops to form DevOps sounds interesting, but there’s more to it than simply removing the space between the two words. So what is DevOps all about?

The term DevOps is new - the concept isn’t
I began researching DevOps, and after just scraping the surface, I found myself redirected to topics such as The Deming Cycle, Just In Time, Total Quality Management and even Japanese terms like Kanban and Kaizen. For the most part, these topics explain processes for improving quality and efficiency of manufacturing environments - assembly lines, putting together cars.

Then the light bulb went off. Creating and delivering software applications is not all that different from assembling cars - a series of steps from beginning to end to create a product and deliver it to customers. So just like the assembly line for building a car, software goes through an assembly line process, of sorts, that includes Business, Development, and IT Operations. Since there are methodologies to increase efficiency and quality in end-to-end manufacturing of products, why isn’t there a methodology to drive end-to-end efficiency and quality of the creation and delivery of software?

He started it! Un-uh, he did!
While the two groups involved with creating and delivering software, Development and IT, are expected to successfully deliver quality software, their value is measured by different criteria. Development is asked to design and implement requirements to address business scenarios. The more features, creativity and innovation they pour into their software, the more they are praised.

IT Operations is valued for providing compute environments that support the business. They are praised for delivery of systems that are stable, highly available, and always secure. They install, maintain and support the hardware. They install, update and maintain the software running on the hardware. And when Development delivers new software or software updates, IT is responsible for installing and configuring the software, and possibly migrating data and custom user settings to make it available to customers.

These two groups kindly refer to one another as “the demanding trouble-makers” and "the Department of No.” And it was recently pointed out to me by an IT leader that Development often says “no” to IT requests as well. Sounds like two kids bickering, and I speak from experience on this topic.

The process of delivering software applications is expected to just work even though the two groups responsible for doing the work are measured by different standards that often put them at odds.

I am an important customer. You better remember me!
So why are we talking about DevOps now? What are the drivers? Your customers.

Customers form their opinion of your businesses based on their digital interactions. Customers interact with your business through web and mobile applications, and they expect their experience to be personalized and adapted to them: "I come here regularly, you should know who I am and remember my preferences."

Never has it been more important for businesses to thrill their customers. Customers unsatisfied with a company have always been able to walk away – whether the company is brick & mortar or online. The difference today is that unhappy customers can whip out their connected devices and share their experience with possibly millions of their closest friends.

Systems of record and systems of engagement
As a focus on the consumer increases, the focus of business applications often moves from systems of record to systems of engagement. Systems of Record are the traditional applications and systems that keep your business running. They are typically large systems with large amounts of data, possibly including transactional data. They are designed to be highly reliable and stable; they have been in service for a long time; and they do not require frequent changes.

Systems of engagement, on the other hand, are the applications that customers use to engage with companies, often by choice; and there are many choices out there. Customers, of course include consumers, but serving internal and partner customers are important as well - employees, suppliers, providers; essentially, anyone who interacts with your business is a customer of the systems of engagement you deliver. Since their use is increasing, they are also becoming a major focus for business applications. Customers expect their voices to be heard and for companies to act on their feedback. Businesses want to engage with customers, address their often shifting demands and use customer input to differentiate themselves from their competitors. To meet this demand, systems of engagement must be adaptable. They must support rapid and frequent changes in response to ever-changing customer needs and evolving market forces.

IT is comfortable and capable of delivering and supporting systems of record to meet customer demands. However, systems of record are not islands and are often tied to systems of engagement. This interaction means that rapid and frequent changes to systems of engagement may also result in changes to the systems of record, fueling a high-friction relationship between Dev and Ops that rarely solves itself. If left unaddressed, the rift can have severe negative impact the bottom line. To get everyone rowing in the same direction requires an organized, disciplined approach.

DevOps is not rocket science
DevOps is not a “stop everything you’re doing and do it this way solution. DevOps is not a person, or a team or a technology: It is all of them combined. DevOps is social science driven and supported by technology and fueled by executive support. The keys to DevOps are collaboration and communication, trust and transparency.

Implementing DevOps in an organization requires a complete understanding of all current processes. It requires recognizing how work flows through your systems, identifying constraints and elevating the importance of shared responsibility and accountability, not only for your job, but for the entire body of work being produced.

Layered on the mechanics of work flowing through systems is the need for tight feedback loops with alerts that receive high priority. By applying “lean thinking” through the entire system of software creation and delivery, problems are identified early and dealt with. Remediation processes must be followed to eliminate quick-and-dirty fixes that increase technical debt that leads to rework in the future. Quick engagement is critical for preventing issues from piling up and bogging down systems by increasing work-in-progress.

SAS is doing DevOps, and we want to hear from you
It takes effort and time to embrace, support and implement a DevOps culture, but when Dev and Ops are brought together, when collaboration and communication leads to trust and transparency, the results can be amazing. We are seeing it here at SAS, and we are interested in working with our partners to help you with your movement to DevOps. Let us know how SAS software is being used to support your DevOps, and let us know what we can do better.

Image provided by New River Gorge Bridge , Fighting Red Kangaroos // attribution by creative commons
Image provided by Rocket Ship Slide  // attribution by creative commons


About Author

Robby Powell


  1. Robby,

    I think the analysis and perspective you provided in your assessment of the value and challenges of finding a way for IT Development and IT Operations, "the demanding trouble-makers" to work together is spot on. Not only is there a need to find common metrics to measure their "collective contribution" but they also need to find a common vocabulary to work out their differences and how best to deliver the ultimate solution.

    I also like the way you connected your arguments to the systems of record to systems of engagement framework. As you know, I have used this transformative shift to help a number of companies see the need to resolve the issues you've identified. As part of that work, I have introduced a new "Collaborative IT" model which has been extremely helpful to this process. It allows all the key stakeholders to be at the table from the beginning, thereby aligning future technology investment priorities with mutually agreed upon business outcomes. It could be one way to help get Dev and Ops on the same page from the get go.

    • Robby Powell

      Peter, I agree completely with your concept of "Collaborative IT." At its core, DevOps is all about communication and collaboration, trust and transparency. Establishing, as early in the process as possible, a common framework for communicating and collaborating between all stakeholders is critical. The results of DevOps can be amazing, and mapping future technology investment to measureable business outcomes makes perfect sense and is a clear way of continuing to fuel the DevOps engine.

    • Good point Robby. The key from my perspective is thinking through potential scenarios, or the cascading consequences of actions - upfront. A 3 hour investment (exploring the ripple) can accelerate your time to value - yet few do it - they rush in to show progress.

      The other side of the coin is that it's not all about reducing risk - it's also about identifying opportunity - better methods and greater value.

      Kind regards, Jonathan

  2. The Devops approach for solving the IT challenge is a more confusing one as many would like.
    At this moment the common believe is you have 3 pillars for the ICT.
    1 - operations, running supporting existing IT environments
    2 - development inventing and building new IT environments
    3 - delivery/demand communication That is where the bussiness/customers may talk to.
    What is often being practized is heavy burocratic processes with al lot of control-points killing as much as possible of some engagement. With a strong segregation of responsabilities and personal/political goals (ivory towers) there is fall in effectiveness for all.
    The problem is that an Analytics environment does not even fit in this approach
    http://blogs.sas.com/content/sascom/2014/07/23/standard-etl-tools-are-not-designed-to-support-analytics/ . Instead of trying to solve that by some integration within those 3 pillars an new pillar is build (no 4) the devops one. The N-P-K problem of D T A P environments is already very challenging, in fact one hardly getting your feet on. There is a new (or old) playground.
    This devops could be not an improvement but back to the old days where analytics should be but away in some far corner isolated from all others. As they are difficult to understand not fitting into regular IT processed dictating the business processing. "Let they build their own datacenter".
    With more strict regulations coming in this will be a hardly to solve difficult path.

Back to Top