Turning Silos into Success with DevOps

Silos within IT may be inevitable.

Silos are, after all, a natural reflection of the human tendency to specialize. It's not just that storage is different from networking is different from security; it's that the technology, tools, and skills required to implement, operate, and manage these disparate systems are different. Expertise in storage does not necessarily translate to expertise in networking.

Because of this basic truth, silos formed in which domain expertise aggregated and became akin to tribal knowledge. Very little is shared outside the domain because honestly, no one else understands it or has time to learn it. They've got their own domain to worry about.

This is why the introduction of cloud - and in particular, multiple clouds - can often result in more siloes. Each public - and private, to be fair - cloud has its own operational models, APIs, and methods of management. They each operate distinctly differently, which results in experts who are great at operating and managing one cloud but not so able to transfer that knowledge to another one.

You see, it isn't enough to understand how to interact using a REST API - or any API for that matter. The expertise is not in being able to use HTTP constructs and communication methods to exchange information, it's in the ability to understand what methods to call - and when - that makes someone an expert in an API. That extends to cloud, where the general operating model is based on the same principles, but implementation varies so widely as to render knowledge of one nearly useless in another. It's domain knowledge all over again.

That means that the 87% of organizations operating in multiple clouds are likely to mirror their cloud presence on-premises with specialized teams (silos) within IT. We see this in research, in which nearly half (46%) of organizations operate in "single function teams." Which is really a euphemism for "silos."

DevOps can help. Not because of its emphasis on agility or speed, but because of its emphasis on collaboration and sharing. It's not that DevOps are expected to become experts in other domains, it's that they're expected to share goals and collaborate on how to achieve them best – together.  

Cross-functional or combined operations teams aren't meant to replace expertise; they're designed to bring expertise to the same table and create an environment in which that team can collectively work toward a common goal - that of delivering and deploying a secure application at speed. Such teams often include a cloud expert, an app infra expert - an expert from every domain that's required.

But it takes more than a seat at a common table to achieve the speed expected in today's application-driven business. There is a very real danger of creating silos even in a DevOps-driven process through the tools and technology used to automate it.

That's because different teams bring different tools and technologies to the table. This often leads to more time spent on integration and hand-offs, negating the time savings that should be realized from leveraging technology to automate and orchestrate processes across data center and cloud properties. Integration has always been and continues to be a significant challenge for teams across IT - whether it's the tools and technologies used to deploy and operate apps and their supporting app services or those that manage the increasingly complex set of devices and services that form the enterprise infrastructure fabric. 

Enterprises have long understood the value of standardization, and when it comes to cloud and DevOps that value holds true. Being able to build a pipeline into which each domain expert can plug-in their piece of the delivery and deployment puzzle is a critical component to speeding up the process and realizing the value of cloud. Cloud-related expertise remains a requirement, but the languages and toolsets that execute on that knowledge should be shared across a team. 

If you're using separate toolchains, you're asking everyone to become experts in multiple technologies in addition to maintaining their domain expertise. It introduces more possibility for errors and misconfiguration and ultimately slows down the entire process. By standardizing, organizations can reduce the burden on domain experts and eliminate a source of frustration that is too often redirected from technology to people. That causes friction that slows down progress.

It isn't enough to bring people to the same table if their chairs are facing different directions. By standardizing on tools and technologies, organizations can better enable every member of the team to apply their expertise toward the goal of speeding up delivery and deployment.

By aligning seats at the table with common tools and technologies, organizations can increase the probability of success when adopting cloud and its cousin, DevOps.