After watching this video, you will be able to identify how organizational structure impacts DevOps, explain Conway’s Law, and describe the optimal organization for DevOps teams. Let’s take a look at how your organizational structure affects your ability to become DevOps. Part of becoming a DevOps organization is to first become Agile because Agile is a fundamental tenet of DevOps. You must ask yourself, “Is the culture of my organization truly embracing the Agile mindset?” It’s important to remember that Agile teams must be small. If you have large teams and you want to be successful at implementing DevOps, you need to make your teams small. Agile teams should be dedicated. You can’t have people committed to several projects and expect all of those projects to move at the same speed, or for your people to remain focused on any one project for too long. Agile teams should be cross-functional. What we call the “development team” includes all of the people responsible for developing the product. This means software engineers, test engineers, operations engineers, business analysts, whatever it takes. These people need to be on the same team and not working in silos getting each other’s attention through ticketing systems. These teams need to be self-organized. They commit to work one sprint at a time. Let’s look at why organization is important, starting with Conway’s Law. Back in 1968, Melvin Conway stated, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” For example, if you ask four teams to build a compiler, you will get a four-pass compiler. You should not be surprised you got a four-pass compiler; you asked four teams to build it. If you have a user interface team, an application team, and a database team, you get a three-tier architecture. You should not be surprised you got a three-tier architecture; you asked three teams to build it. This is Conway’s Law in action. If you want to change the way you build software and adopt a microservice application architecture, you need to reorganize your people around the architecture you expect them to build. In a traditional organization that is organized around technology, you might have a separate user interface team that performs all of the user interface work. Regardless of what feature you are building; you need to get the attention and time of someone on this team to add a user interface element for your feature. This is sometimes called the front-end team. Then you have the application team, or the back-end team, and they add the application logic. They don’t deal with the front end or things like database schemas because you have a database administrators’ team to manage all of that. No one touches the database unless they open a ticket to get a database administrator (DBA) to do the work. When you organize this way, you get a three-tier architecture. Like I said, you shouldn’t be surprised you have a three-tier architecture; you asked three teams to build it. Conway’s Law tells us that an organization will produce a design whose structure reflects the organization's communication structure. No surprises here. We got what we organized for. This is why paying particular attention to how you are organized is so important. It’s better to organize your teams around business domains. You may have an account team that manages login, registration, and user data. They have user interface skills, application skills, and database skills on a cross-functional team. Then there is the personalization team. They create personalization algorithms using artificial intelligence (AI). They control their own user interface, their application logic, and their own database. Finally, you might have a warehouse team that is building capabilities around shipping, receiving, and inventory. Those are the microservices that they manage from front to back. The warehouse team doesn’t need to coordinate with any other teams to develop their features. They don’t need to open tickets to get the attention of other teams to complete their features. They work as a small, dedicated, cross-functional, self-organizing team. If you don’t organize around business domains, you are not going to get the full benefit of DevOps. You want to align your teams with the business. Each team should have its own mission aligned with a business domain. Make sure that they have the autonomy they need so that it feels like a “mini start-up.” They need to be self-organized and cross-functional with 5-7 engineers, but no more than 10. You then want to empower your teams by giving them end-to-end responsibility for what they produce. They commit, build, deploy, maintain, and operate their services. They control everything. And you want them to have a long-term mission usually around a single business domain. I can’t stress enough how important this is when creating high-performing teams. If you have people coming in and out of the team constantly, you will never get the benefits of having a dedicated team with a long-term mission that builds ownership and pride in their work. In this video, you learned that organizations must have small, dedicated, cross-functional, self-organizing teams to successfully implement DevOps. Conway’s Law implies that a company’s design results are a direct reflection of the company’s communication structures. Successful DevOps teams should be organized around business domains. Each team should have a mission that aligns with a business domain.
