Disruptive changes occur much more frequently in the information technology sector than in most other industries. The velocities of these changes often illustrate the flaws in current IT organizational structures, skills and processes, which then yield unintended consequences. For example, the rise of shadow IT—business users circumventing internal IT resources because they believe it will cost less or get done faster—is an outgrowth of IT’s inability to respond to business demand in face of disruptive changes. This is pure Darwinism in practice; adapt or die.
Hierarchy defines most enterprises’ organizational structure. Executives, at the top define strategy, which then works its way down the hierarchy to become a series of tactical executions. Hierarchies do not fare well in the face of disruptive change. When the Web emerged in the 90’s, brick and mortar businesses had a difficult time reacting because they were not organized to respond to industry changes from non-traditional sources. As a result, smaller, more innovative businesses were able to seize the opportunity to sell products over the Web at lower costs due to much lower overhead. The impact of this event is still having an impact, such as the case with Borders bookstores and Blockbuster entertainment. Even if executives are adept, the time it takes for the hierarchy to convert strategy into tactical delivery limits the ability for large enterprises to move quickly.
Thus, it’s understandable why most IT organizations in mid- and large-sized enterprises have been created as a hierarchical organization. It’s part and parcel for participating in the larger enterprise. Moreover, until recently, IT was relegated to a support role speaking only when spoken to versus driving strategy. However, in the face of the emergence of consumerization of IT, mobile computing, big data, cloud computing, and a changing economic landscape, a traditional IT organizational structure is now an albatross around IT’s neck.
DevOps Culture
Prior to the 1980’s, auto manufacturing treated line workers like brainless monkeys. Line workers’ jobs were highly-repetitive and there was no opportunity to change the outcome of the final product. Then disruption occurred for the auto makers; Japan starting producing affordable, higher-quality automobiles for the American market. Suddenly, Detroit wasn’t the only game in town, and the emerging competition coupled with low quality products soon took its toll on the US automobile manufacturers. The result: recognition that the line worker was the key to producing a higher-quality product. Sure, there were other changes that were required, such as lowering the costs of raw materials and fixing the supply-chain, but enabling the line worker to stop the line to address quality issues ultimately led to a return of the US automobile manufacturing industry.
There’s a great parable here for IT. While executives have to recognize system administrators, application developers, data center operators, etc. for their training and specialized knowledge in computer systems, in the past, and maybe still to some degree, executives viewed these roles in much the same way auto manufacturing executives viewed line workers prior to the 1980’s. Forced to meet unreasonable timelines and a lack of voice in the delivery process has facilitated the introduction of unstable and unusable systems for the enterprise. All of this results in dissatisfied users, lower productivity and, eventually, missed opportunity.
With continued concerns regarding IT’s ability to meet the demands of the business in light of disruptive influences and a changing economic landscape, it’s odd that little change has occurred in how IT is organized. If IT is waiting for the business to address these issues, then the current stalemate we are witnessing makes sense. The answer needs to come from within IT itself. It’s time to stop expecting the business to enact change on IT and to drive change from within. It’s time to adopt a DevOps culture.
Of the many critical changes that come with DevOps, perhaps the most important and least often spoke of is the cultural aspects of this change. This culture is represented by dissolution of the internal hierarchy, a move to meritocracy, breaking down of the stove-pipes, service orientation, service lifecycle management and, most importantly, agility. DevOps cultures thrive in the face of disruption versus bottleneck and stall. They produce the highest quality output with limited human resources. There are no political barriers to sharing information and responding to the inevitable system failures. There is team, where once it was us and them.
DevOps Practices
In addition to the cultural changes, there are practical, operational changes that come along with adopting DevOps. These changes can be organized into the following categories: service lifecycle management, automation & orchestration, and governance. Let’s look at each of these individually starting with service lifecycle management.
Traditional IT organizations have a wide range of techniques for delivering IT services to the business. Typically, these services are organized around desktop management, business applications, and data center operations. It is not uncommon to find that the groups that manage each of these independent areas each follow their own processes and methods for building and supporting the service. Hopefully, there’s at least some common IT service infrastructure tools, such as help desk and ticketing, but even these have been implemented redundantly based on the size of the enterprise.
DevOps looks to normalize the common processes for building and supporting services across the enterprise. Large organizations sometime follow standardized methodologies for normalization, such as ITIL (IT Infrastructure Library), but these standards tend to be used as guidelines and compliance rather than actionable steps for delivering value. The key to service lifecycle management is that from design through operations the same team is involved and working together so that the system is understood from all involved in its delivery. Moreover, the involvement of the various stakeholders from the start allows for greater quality delivery with fewer outages since obvious problems are avoided.
Automation and orchestration is what allows DevOps to deliver greater quality faster with fewer human resources. All resources involved in the project have some role in automating the steps within the service lifecycle management. Examples of this include, patch management, continuous build, virtual machine provisioning, application deployment, identity management, backup and monitoring. The higher the degree of automation the more efficient the DevOps organization. Automation also is a key enabler for delivering self-service to the business. By allowing the business to do more, they feel more empowered and that IT is more responsive to their needs, while freeing up IT to build and automate other services; a win-win scenario.
Finally, the piece that makes all of this tick is governance, which is a key component of DevOps. As the walls come down between stove-piped departments within IT, there will be a natural desire to “own” something. Most IT professionals have not worked in these types of environments and it will be very disconcerting to be responsible at the service level versus the service component level. Those that controlled how storage was allocated in the Storage Area Network (SAN) yesterday, must now follow rigid processes for defining allocation that will be reviewed by other teams that share the SAN environment. Governance puts some rules in place for how this will all work so that it doesn’t degrade in the Wild West.
DevOps Resource Management
As alluded to in the prior section, there are human resources issues that arise when moving to a DevOps environment. The organization needs to realize that with different ways of delivering services that there will be a need for different skills, specializations that need to be aggregated by others and changes in compensation and career paths. To undertake DevOps without recognizing this is either a folly or destined to fail with blame focused on the concept of DevOps instead of the carelessness with which it was adopted.
Here is a brief summary of what to expect with regard to resource management changes:
- Differing skills – with a focus on customer service, IT is going to need leaders that communicate with the consumers and manage their expectations. As we move from being the landlord telling the tenant how they will live in your building to the concierge, we need individuals that understand customer satisfaction and can translate their business concerns into technological initiatives. Additionally, with a focus on automation and orchestration, some level of programming skills will be required by all operations and development staff.
- Aggregation – Specializations in networking, storage and server management are going to be difficult to incorporate into a DevOps world. Too many individual concerns without an understanding for how the infrastructure as a whole needs to operate in order to support the aspects of the service delivery. Infrastructure skills are going to have to follow the hardware trend in data center operations and converge into a single individual that understands the core infrastructure components.
- Compensation and Career – As mentioned earlier, DevOps is a meritocracy. This means pay and advancement relative to the strengths of the individual to contribute to the team. It also means finding ways to keep and advance talented engineers that may not necessarily do well in a management role. For some large enterprises, where larger salaries are given to management, this thinking can pose a real challenge.
It is imperative that Human Resources, Legal and Finance are included in the transformation to DevOps and that they understand these implications if the adoption of DevOps is to be successful.
Conclusion
They say the definition of insanity is doing the same thing in the same way continually while expecting a different outcome. IT has been supporting the enterprise’s need for applications and data management for forty plus years, mostly using the same organizational constructs as the rest of the organization. However, in the 21st century, where one out of every two people have a smartphone and one out of every four have an advanced mobile device, such as a laptop or tablet, the demands on IT are far exceeding capacity. Meanwhile, IT budgets are continually shrinking and upwards of 75% of the IT budget is being spent on “keeping the lights on”. Supporting this trend requires a different approach to delivering IT services.
IT is no longer an overhead expense, it’s a critical partner in running the business. An agile and responsive IT organization cannot operate in a traditional hierarchical command and control architecture; it takes too long to convert strategy into robust and reliable delivery. Perhaps the same could be said for the enterprise as a whole, but certainly the entire enterprise is not being forced by outside pressures to respond to changes as rapidly as IT must respond to technological innovations and acting as the engine to enable business to move faster. DevOps is the next incarnation of IT as an agile, cost-effective, and efficient engine for delivery of applications and data management in the 21st century.
About the Author
JP Morgenthal is one of the world's foremost experts in IT strategy and cloud computing. He has over twenty-five years of expertise applying technology solutions to complex business problems. JP has strong business acumen complemented by technical depth and breadth. He is a respected author on topics of integration, software development and cloud computing and is a contributor on the forthcoming "Cloud Computing:Assessing the Risks" as well as is the Lead Cloud Computing editor for InfoQ.
