There’s something magical about credit cards — and I don’t just mean the illusion of buying something without paying real money for it.
What’s magical is the almost unspoken way in which consumers and retailers use credit cards to facilitate a transaction. Apart from instructing them when to slide their card into a reader, there’s not much more conversation required. Imagine if, instead, a consumer had to explain to a cashier each time how their credit card worked, and the cashier needed to go over in detail the way in which the amount on the bill would be added to their account statement afterward? Sadly, this is the kind of disconnect within organizations that is leading more of them to pursue DevOps today.
This analogy came to mind when I saw a mention on Twitter a while back about a presentation from executives at MasterCard at a Forrester Research event on software development. The tweet showed a slide from the presentation deck which suggested a key indicator that DevOps is working is the common language both sides of the house are beginning to speak:
MasterCard says that emerging language like this in DevOps indicates you're staying competitive. #FORRForum pic.twitter.com/LAUfyAkC1O
— Alexandra Behringer (@ESourceAlex) October 17, 2014
I didn’t get to see this particular talk, but even the session description suggests Mastercard is being really intentional about the way its DevOps mission is articulated to the collective team: “To support more agile and higher-quality service delivery, MasterCard has made the DevOps method a priority, empowering technology team members to make the transition from ‘being the machine’ to ‘engineering the machine.’”
The importance of language was reflected in a recent Vanson Bourne study on DevOps commissioned by CA Technologies, where the top obstacles included organizational complexity around people and departments (35%) and lack of alignment around roles and responsibilities (28%).
Although the research also suggested that “improved collaboration” was among the internal factors by which 38% of those surveyed will measure the success of DevOps, it’s only one among many. I’d argue that improved collaboration is often under-examined as a metric, and that organizations would benefit greatly by more deeply imagining not only what it looks like, but what it sounds like.
Does DevOps success mean that both both developers and those in operations know terms like “blue/green deployments,” or is it about innately understanding the business needs so well that they act in concert in everything they do? Is it vague goals around better customer experiences, or is it fostering a way of working together that means whatever the organization offers is as easy to create (or use) as swiping a credit card?
DevOps probably prompts some uncomfortable conversations within organizations, but they should ultimately lead to a shared vocabulary that provides the foundation for innovation. And if you can use that vocabulary to create tangible value more quickly? Now we’re talking.
