Digital Transformation Anti-Patterns
Takeaways from SpringOne Platform 2017
Day 2 at SpringOne platform was a whirlwind of keynotes and more user-led breakouts than one can physically attend. I’m always on the look out for patterns in how users are adopting technologies. This time, I looked for the behaviors to avoid: the anti-patterns.
Anti-pattern #1: Assemble “The Avengers” of a Team
When the rubber meets the road for kicking off a change to your software practices, you need people. This could be for standing up your PCF platform ops team, or just building a DevOps team in general. Assembling that team might feel like you’ve got to assemble The Avengers.
But modeling your DevOps team on The Avengers is an anti-pattern. Why? Three reasons came up during day 2.
First, you’re not looking for heroes. When asked about changing job roles, Dean Parke of Discover noted a shift in emphasis. The “maturity model” titles still existed, but the focus is on equality as a team over seniority. This harbors the teamwork over heroism.
Second, you want to normalize the new. Jon Osborn of Great American Insurance Group, had a session packed with great tips. One that stood out was to not pack your team with “rock stars” because it lets others dismiss their work. If your team starts, say, releasing software twice as often, you want everyone to feel like they could do that too.
Third, you want diversity. Okay, okay, so The Avengers are sort-of diverse… Thor’s from another world, Captain America is from another era, and Black Widow is… female… But more importantly, they bring different skills to the table. That’s the kind of diversity that both Matt Curry of Allstate and Jon Osborn highlighted. Different career stages bring important diversity of perspectives.
Anti-pattern #2: Skip the Testing and Release Automation
Back at Cloud Foundry Summit in June, I spoke with a customer running PCF at scale who told me he didn’t care if his developers paired. He only cared that they had automated their tests. That was my first clue at how important this was. Here at SpringOne Platform, Ford, Scotiabank, and others all highlighted the importance of automating CI/CD.
From the platform ops perspective, automating platform updates has life-changing implications. Brian Kirkland at Verizon can watch Monday Night Football again, despite “Maintenance Mondays.” And this is taking patching frequency from every 6 months to weekly for twelve foundations.
Meanwhile, Bryan Kelly of Cerner was visibly excited as he described a recent automated platform update. In twelve hours to move 220 virtual machines across sandbox, non-production, and finally production. But zero humans were involved. Cerner is using PCF Pipelines, a collection of Concourse pipelines for installing and updating PCF.
While the endgame of pipeline automation becomes obvious, getting there isn’t. It’s daunting to imaging writing all the tests needed to automate all your application deployments. But, like anything, it starts with small steps. Or, as Matt Curry from Allstate put it, as incremental deposits into an interest-earning account.
You may not need all the tests and release automation on Day 1, but begin investing early.
Anti-pattern #3: Go Slow, Stay Small
There’s a natural tendency to take small, cautious first steps when doing something new. But PCF users who were reaping major benefits from the platform didn’t stay small. Liberty Mutual and Comcast were all explicit about making bold moves.
In his keynote, John Heveran reiterated the big goals that Liberty Mutual set for itself. Then he described how the company converted ten applications into microservices running on PCF in ten weeks. They next tackled an application that supports $4bn of their $10bn in commercial insurance revenue. That progressively bolder approach has yielded 10% of workloads on PCF, deploying at least weekly if not daily.
Neville George of Comcast distilled a number of lessons from scaling PCF to 9k apps and 2100 developers. Second on the list was to “Be Ambitious” and bring big apps onto the platform. Bigger apps bring more developers with them, force more standardization in the process, and create strong endorsers. Landing a big app is the antidote to getting stuck in “science project-land.”
Everything usually starts as a pilot project, but when it goes well, you want to scale. To scale you need to think bigger.
