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