Splunk Vice President of IT Markets and Chief Technology Advocate Andi Mann sees DevOps moving from an artisanal approach to an IT factory.
This represents a reversal: Historically, developers operated in a factory-like environment, passing chunks of work down the line, but that caused problems because “different managers owned different sections of the production line.”
Agile and DevOps were a response to that issue, he said, resulting in “the artisan developer … the full-stack developer.”‘
The trend is now flowing in the opposite direction, with Splunk customers wanting to see “the whole flow.” Furthermore, enterprise DevOps is too big for an artisanal approach.
“I worry about that [reversal],” he said, but technology can help artisanal quality within an IT factory. Collaboration tools such as permanent video links between different locations enable specialists to work together and understand each others’ work.
“That’s a different kind of factory,” said Mann, in which development, security, QA, operations and other staff do not need physical proximity to work closely together. This is particularly important for large enterprises, he observed, as you cannot pack 1,500 developers into a small space.
One example he cites to show this approach can work is a telco with its developers spread across multiple locations in Sydney and Singapore using DevOps practices to achieve continuous delivery. Another is one of the largest UK retailers getting weekly releases from developers in London and Mumbai, with QA work done at another location in India.
“Executives I talk to are very heavily committed to improving cycle time,” said Mann. But they are also concerned with quality (e.g., problems should be detected and fixed before they reach the user, and the percentage of changes sent for rework should be minimized) and business impact. Executives want to link DevOps to their own KPIs: “Are they moving the needle on my business requirements” such as shareholder value and reputation?
“You get the changes you drive by your measures,” he said, so it is up to managers to make sure their measures make sense in the broader context. It may be time for a balanced scorecard to be applied to DevOps, with metrics in all three areas, he suggested.
These metrics could include code coverage, error rates, customer complaints or trouble tickets raised, plus business impact measures such as click-through rates, cart abandonment, subscriptions cancelled, open rates (for mobile apps) and customer sentiment.
Mann noted executive demand for the adoption of DevOps, even where “they don’t even know what they’re talking about.” He feels it is really about a desire for visibility into the development pipeline, and “that’s really challenging.”
Part of the problem seems to come from the tension between traditional IT (especially “ITIL-owned shops”) and new-generation executives with titles such as head of digital.
Slavish adherence to ITIL practices won’t allow the required speed, may not achieve the expected level of compliance and business goals probably won’t be met, he suggested.
“ITIL came out of a fear of failure,” but failure is no longer catastrophic. “If you’re not failing, you’re not trying, you’re not innovating.” What’s important is to fail fast, fail small, and fail cheap—and DevOps allows IT to fail in low-impact ways. Even when an organization is making significant changes to software, the effects of failure can be contained through measures such as canary releases (where the new versions are initially made available to a small subset of users).
Furthermore, customers are getting used to the idea that technology isn’t and doesn’t need to be perfect, largely because of their experiences with speech recognition services such as Siri, he said.