Dan's Take

The DevOps Problem

The challenges are often not technical, but rather the result of the "silo" mentality.

• By Dan Kusnetzky
• 12/10/2015

Wel Caldwell, CTO of Intelligent Software Solutions (ISS), and I had an interesting discussion about DevOps, what that term really means, and both the challenges and benefits the concept has to offer. ISS, by the way, offers tools, processes and procedures allowing its customers to deploy the concepts behind the term "DevOps." The company identifies the problem it solves this way: "The amount of data being generated and shared is growing exponentially, producing information overload and cluttering vision, mission or enterprise goals."

What Exactly is DevOps?
The first portion of our discussion focused on what the concept of "DevOps" really is. It seems that there are as many definitions as there are industry players, all declaring their approach to be the solution to every problem. Most definitions bandied about are vague and quite difficult to pin down.

Most of the definitions appear to center on setting up procedures, processes and using tools that can help developers, operations staff and facilities staff work together quickly and effectively to address enterprise issues as they arise. Caldwell pointed out that this requires three elements to be put together in balance: people, technology and process. In his opinion, this often means addressing a cultural change, adopting the proper tools and to putting them to work in a systematic, effective way.

Cultural Change
Enterprises typically have a culture centered on silos of expertise and a business-unit focus. Business units are each allowed to acquire technology, stand up workloads that address their own unique needs, and little is done to really understand the needs of the enterprise.

Early in the history of IT, it became clear that dealing with all enterprise IT requirements was a task that might just be too big and complex for a single group of people to address effectively. So the problem was segmented and different people focused on a much smaller set of issues.

The Emergence of Silos
Although there are many variations on the theme, for enterprise IT infrastructure is segmented along lines of technical expertise rather than along the lines of business requirements.

• Network people own the network and make sure the network is reliable, manageable and provides sufficient capacity. Often these people only understand how much capacity is being used, not how it's being used.
• Facilities people take responsibility for the datacenter buildings themselves, physical security, negotiating with suppliers for the best access to communications, power, cooling and other services required; and in some enteprises, negotiating with suppliers of systems, storage, networking equipment, as well as software licenses.
• Storage people own the storage configuration, its provisioning and mangaement. Often they don't have a full understanding of what workloads are using what storage.
• Systems folks stand up and provision systems and virtual systems.
• Application folks develop and acquire applications.
• Data management folks provision and manage databases.
• Few know or understand -- or care to understand, for that mater -- the whole bundle of technology that addresses the enterprise's business needs.

Caldwell points out that, at the very heart, DevOps means having all these people communicating and working together, rather than staying focused on their own segment or silo.

Breaking Through the Silos
Caldwell says that while the concept of deploying DevOps is enticing, it can be very difficult to get an enterprise's silos to understand one another, work with one another; or even just to agree that what everyone does should be valued equally. Until a number of successes have been observed, some silos will fight the process in the hopes of maintaining its influence within the organization.

Dan's Take: More a Political Problem Than a Technical One
Although technology plays a critical role in the move toward using DevOps as a lifestyle, politics can be seen as a major inhibitor. Management in each of the silos often doesn't want to relinquish their hold on power, money and staff. Integrating teams along business lines rather than technological lines means, in their view, a loss of control and influence.

Another challenge is that many technical silos use the same words to mean different things. Just put experts from facilities, applications, systems, data management and networking in a room and ask them to each define what a "cluster" is and what it does.  An outside observer would be amazed to learn that simple term means so many different things to different people. This shows that communications is a big challenge.

Teams may speak the same words and believe that they've come to a unifying agreement with one another, only to be disappointed when future events don't live up to their expectations of cooperation and mutual support.

If ISS's experiences are to be believed, this approach can be made to work if the teams are dedicated and management is focused on results, rather than who gets the credit.