Bringing Web Scale and Velocity to the Enterprise
Bringing Web Scale and Velocity to the Enterprise
Why are things so much harder at your company than high-flying internet startups? and what can you do about it? Find out here.
Join the DZone community and get the full member experience.Join For Free
The DevOps Zone is brought to you in partnership with xMatters. xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read this best practices guide and learn 4 steps that are critical to DevSecOps success.
At last week’s Delivery of Things World conference, we heard a remarkable diversity of DevOps success stories, as well as various ‘in progress’ accounts. Perhaps most interesting, however, was the diversity of presenters.
First off were web scale companies: Spotify and Netflix. Then we heard from Microsoft about their internal development. And we also got the inside scoop from a number of enterprise representatives.
The overall pattern was a familiar one: web scale companies have figured out both how to leverage the vast scalability of the cloud as well as the remarkable business velocity that DevOps can deliver. Netflix, for example, pushes code to production 4,000 times per day.
Enterprises, in contrast, struggle with the nuts and bolts. How to deal with bureaucracy, the struggle of build vs. buy for both apps and tools, and how to get all the various bits of the DevOps story to work properly to get results that the web scale guys can achieve are just a couple of the issues that arise.
The fellow from Spotify, for example, displayed his company’s organizational model, a highly matrixed, employee-focused approach to organization. He cautioned the audience, however, that what works for Spotify doesn’t necessarily – and in fact, most likely wouldn’t – work for them.
Therein lies the enterprise challenge: what works for the companies that have demonstrated success with web scale and business velocity is unlikely to translate well to the enterprise context. You can’t simply layer on Netflix’s architecture or Spotify’s organizational model onto an existing bank, manufacturer, or brick-and-mortar retailer.
How, then, should enterprises learn the lessons of web scale companies? What bits of the Netflixes and Spotifies of the world can an enterprise CIO bring to their own shop?
The answer is that which bits to import is the wrong question. The solution isn’t to take lessons from the web-scale companies and add them to the enterprise. Rather, the proper question is what to subtract.
Subtracting Legacy: Even Trickier Than It Sounds
The most obvious place to start is with legacy technology – those ancient systems and applications that serve as proverbial boat anchors, keeping enterprises from keeping up with the Amazons of the world.
Not so fast. If you’ve been following my writing for the last few years, legacy technology has gotten a mostly undeserved bad rap. Many such systems – especially mainframes – are the engines that drive digital efforts for the shrewder enterprises that own them.
In fact, legacy technology has become more of a scapegoat than a boat anchor, something executives can easily point at as the cause of their digital woes, when in reality, they’re missing the larger legacy picture.
Instead, look no further than the proverbial people-process-technology triad to identify the legacy areas we must reduce – and furthermore, to people and process I’ll add policies and ways of thinking to the mix.
Even more so than legacy technology, people are the primary roadblocks to achieving the scale and velocity enterprises crave – both individually and organizationally.
Atari Founder Nolan Bushnell
No one likes to point their finger at individuals as the problem, of course – well, almost no one. One notable exception: Atari and Chuck E. Cheese founder Nolan Bushnell, who keynoted the Delivery of Things World conference. Bushnell consults with many businesses and he finds that after a few days, he can identify the “just say no” individuals that are blocking progress and innovation in their organizations.
The larger the organization, the more risk-adverse its members tend to be, but there is usually a small subset of individuals whose risk aversion is so narrow and pervasive that they are unable or unwilling to see how counterproductive it is for themselves and the companies they work for. Can’t fire them? Then make their lives so uncomfortable they move on by themselves.
Also on the removal list: extra layers of management. It’s no coincidence that the companies that are most successful with DevOps have flattened organizational models. The more layers you have, the more people can say no to any kind of change – in particular, the innovation that drives competitiveness.
Speakers singled out middle management in particular as a primary culprit. At the top, executives are more likely to see the value in placing ostensibly risky bets on transformative initiatives, and the rank-and-file at the bottom are mostly willing to try new things.
Middle management, in contrast, faces little upside and massive downside for any risky endeavor, and thus frequently serves as a roadblock. Time to flatten that org chart.
Lose the Legacy Processes and Policies
The conference was also rife with stories of earnest attempts at implementing DevOps, only to fall victim to one legacy process or policy that ended up slowing down the whole shebang. In fact, one of the most important lessons of DevOps is that business velocity depends on eliminating all such bottlenecks, as it only takes one hiccup to scuttle the entire effort.
For example, a few speakers lamented the insistence on a final, externally mandated testing pass sandwiched between development and deployment, even when the organization had merged their Dev and Ops folks as part of an organizational shift to DevOps.
It’s clear how management was thinking: this DevOps approach is risky, as it increases the chance that problems will make their way into production, so we’d better double-check, just to make sure. And in any case, we’ve been doing acceptance testing for years, so what’s the big deal?
Only, it was a big deal. The message the DevOps teams heard was that management expected them to fail – not the "fail fast" Lean approach to innovation, but rather the "you’re not competent" and "we don’t trust you" messages that quickly discourage all of your good people.
Other processes and associated policies that should make their way to the chopping block: tech refresh cycles. If you own your own infrastructure, then every three years or so it’s time to replace old with new – which means capital expense and all the planning, budgeting, purchasing, installing, and maintaining that goes with it.
Web-scale companies have a mere fraction of these tech-refresh activities that enterprises do because they’re primarily in the public cloud. Why go through all that trouble when your cloud provider will do it for you?
One item on this tech refresh list worth calling out: maintenance. If your apps are in the cloud, then you still essentially have a maintenance bill to pay as part of the subscription fee you’re already paying. But you’ve removed the hassle of maintenance, from dealing with vendors to downloading, testing, and installing patches.
In fact, patch management is one of the primary enterprise roadblocks to business velocity while also being one of the most serious cybersecurity risks in the organization. Bottom line: the less maintenance you have to do, the better.
The Intellyx Take
In order to achieve web-scale business velocity, perhaps the most important targets on your remove list are legacy ways of thinking – especially among management. The sad truth is that such archaic thought patterns are all too easy to find.
Go into any large enterprise, spot an occupied conference room, and sit in on a meeting, and what are you likely to see?
PowerPoint presentations. Planning sessions. Budget discussions. Lots of graphs and charts consisting of boxes connected by lines. And along with all that folderol, plenty of management-speak to go around.
Scratch the surface and what’s really going on? Risk avoidance. Passing the buck. Coming up with one reason or another not to make decisions. Analyses. Justifications. Explanations. Prevarications. The list goes on and on.
Don’t get me wrong. Some of this activity is necessary and you’ll find a judicious measure within the fastest of the web-scale companies, as well as every other organization on this planet. But a lot of it – perhaps even most of it – is mere legacy busywork, intended more to keep people’s butts out of some fire than to further the strategic goals of the organization.
The good news: every enterprise, no matter how set in its ways, can benefit from removing some of its legacy processes, policies, and ways of thinking. Digital transformation success depends on it – as well as your competitiveness overall.
Remember, web-scale and business velocity aren’t simply characteristics of the web scale companies. They’re essential for the very survival of your organization.
Published at DZone with permission of Jason Bloomberg , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.