DOES Europe 2016: Courage is Not Optional (cont'd)

In my previous post I talked about re-defining what legacy means in organizations that have been around for centuries, and the courage required to empower teams to adopt DevOps without forcing practices on them.

I ended that post talking about the challenge that enterprises face when they try to extend DevOps success beyond self-contained initiatives/applications: backend systems that are slow to change and are thus at odds with the fast-paced applications that depend on them.

But that is not the only “clash” organizations presenting at the DevOps Enterprise Summit 2016 in London are facing. In this post I will be expanding on that.

Clash of Civilizations – Part II

Another kind of clash that is becoming evident happens when organizations trying to leverage DevOps across the board hit the “wall” of vendors/suppliers used to red tape ways of working (often dictated by the contracts or KPIs put in place by those very organizations – valuing MTBF over MTTR still being a common example).

Just as a “one size fits all” approach does not work well when scaling DevOps across large, distributed organizations (Barclays deliberately avoids being too prescriptive), approaches for dealing with external suppliers also vary.

For example, Unilever, a conglomerate of popular consumer brands, recently embarked on a DevOps where the first steps included replacing consultants from large vendors by boutique consultants whose DNA they aim to mimic. Investing in configurable tooling to increase their teams’ autonomy and letting go of proprietary technology whose lifecycle is owned by large vendors was another step. Immediate net results are in the order of 90% reduction in run cost.

On the other hand, you have the example of Zurich Insurance who quickly understood that depending on a major infrastructure services supplier for the entire business was impacting their DevOps strategy. Integrating suppliers in the delivery lifecycle (and amending contracts to allow them to share same incentives as internal teams) was fundamental to accelerate delivery.

HMRC and Ingenico ePayments took yet another route by creating multi-consultancy cross-functional teams, bringing in external expertise and mixed backgrounds to help kickstart their DevOps journeys.

Collaboration-as-a-Service?

It’s no surprise that many of these organizations are going the PaaS way after initial grassroots explorations of DevOps by groups of like-minded individuals or teams. As companies realize the potential gains through internal initiatives as well as clear external signals (such as State of DevOps reports or DOES presentations), they start showing FOMO (fear of missing out) on DevOps for the rest of their IT. As Tom Clark from ITV put it “now it’s time for the settlers.”

But platform teams are not a new idea. Most organizations larger than two pizzas have surely seen their share of tooling teams or their Ops team taking responsibility for a common “platform.” So what’s different now? Ownership. Application teams owning delivery, monitoring and support of their service is crucial. Platform teams no longer own part of the applications lifecycle but instead they offer (and own) standard services to the other teams (monitoring, deployment, security, etc).

But ownership boundaries between application and platform are neither clear-cut now nor set in stone for the future (what changes will the next breed of tools bring about, after containers and continuous delivery toolchains have become standard?). That’s why strong and on-going collaboration between teams is key for the PaaS model to work, instead of leading into new knowledge silos. At ITV for example, each Scrum team has one embedded platform engineer and new hires are “incubated” in the core platform team before moving to the Scrum teams.

The question is, as Simon Parkes from Ordnance Survey put it, “How do we prevent DevOps from becoming its own industry?”

- About The Authors

Manuel Pais

Manuel Pais is co-author of "Team Topologies: Organizing Business and Technology Teams for Fast Flow". Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Continuous Delivery.

Follow Manuel on Social Media

• 
•