Often, organizations assume that a new organizational design will be required in order to have a successful DevOps transformation. There's a really great free document from the DevOps Enterprise Forum called Thinking Environments, evaluating organizational models for DevOps to accelerate businesses and empower workers. I'm going to share some of the content from that document and also encourage downloading it to get more details. After this video lesson, you should be able to describe a traditional functional silo organizational structure as well as some key considerations when choosing organizational models for a DevOps minded organization. While the traditional IT organization is structured into functional silos, DevOps relies on empowered cross-functional teams. Is it possible to blend the two approaches and work within the traditional structure? Or, do you need to restructure your organization to support DevOps? In a traditional organization, typically there will be a chief information officer or chief technology officer and functional teams such as development, QA, security, and operations. Now, DevOps practices do help organizations speed up development, innovate, and deliver high-quality products and solutions. But DevOps in and of itself is not an organizational structure. Rather it defines; one, away to organize independent teams cross-functional or full stack. Two, a culture humane and outcome-based. Three, a set of lean principles. Four, fast feedback including feedback from production. Five, a set of practices highly-automated with continuous delivery. It remains for us to find the best way to fit these DevOps principles I've just mentioned into an organizational structure for technology and for the enterprise as a whole. There will not be a single solution that works for every organization. In fact, since DevOps is still relatively new to a lot of organizations, we really cannot be sure what works and what does not all the time. In my experience, it is not a one-size-fits-all. Nor do we believe that organizational design is the only or even the most important factor in obtaining the value of the DevOps approach. As Mark Schwartz suggests in The Art of Business Value, each organization has embedded in its corporate culture and in its rules and processes, its own understanding of business value and how best to create it. Each organization will need to take its own experimental Agile approach to finding which organizational structure works best. As with all other Agile approaches, Deming's Plan Do Check Act, the PDCA loop, can be used to continuously refine the model. There are pros and cons with different organizational models. What's important though is to know what attributes need to exist in your organization to be successful at adopting DevOps practices. Traditional functional silo organizations are often optimized for cost and efficiency. Functions are optimized within these silos as opposed to across functions. Often, understanding how applications are delivered is very challenging because work is dispersed within and across multiple functions. A positive aspect to this model though is that accountability is quite clear. If there's an issue with infrastructure, for example, it's clear who the CIO needs to engage. Lean theory teaches us that there is waste anytime there's a handoff between resources, and the functional silo organization essentially guarantees that projects will need to be handed off a number of times before they are released to customers. DevOps, like other Agile Lean approaches to technology delivery, relies on cross-functional delivery teams. It goes beyond other Agile and Lean approaches. However, in the breadth and depth, it requires of its teams. To be high-performing, teams must have skills in development, testing, operations, and security at the very least. Working in such cross-functional teams avoids handoffs and increases the possibilities for rapid feedback, not only from testers and users of the product but also from the actual usage of the system in production. There is clearly a tension between the DevOps cross-functional approach and the traditional functional silo-based approach. Rather than asking whether DevOps can be made to fit within traditional organizational structures, it might be better to ask, what characteristics an organizational structure would need to have in order to align with the DevOps model? It's also important to know what outcomes the organization is trying to achieve. If optimizing for speed is a focus, then that can help drive the conversation. If the organization is more focused on cost, then it could drive a very different conversation. We can then use these characteristics to evaluate proposed organizational structures to see how closely they fit. In effect, these characteristics are acceptance criteria for an organizational design, and companies can innovate and experiment with different models that might deliver on these requirements. There are seven of them, and we're going to go over each of them in the next video.
