The problem is allocating the time for developers and testers to work on it. The project  managers must get involved to figure out who on their teams have the capacity to add the  new element and how to schedule the push into the various environments. If you scale out,  you also have competing priorities. Each project and new element must be vetted and  prioritized, and this takes time. So, you are in a situation where there is much impact in terms  of time for a simple and straightforward change. The question is whether the benefits that you get by doing governance and creating common  interfaces is worth the price you pay for the operational challenges. In the modern digital  world of fast-paced innovation, you must think of a new way to enforce standards while  allowing teams to reduce their time to market. 2.5.1 Moving to a decentralized and business-focused team structure You are trying to reduce the time between the business “ask” and production implementation,  knowing that you may rethink and reconsider how you implement the governance processes  that were in place. Let’s now consider the concept of microservices, where you have broken  down your technical assets into smaller pieces. If you do not consider reorganizing, you might  make it worse. You introduce even more handoffs as the lines of what is an application and  who owns what blur. You need to rethink how you align people to technical assets. Figure 2-9  on page 23 gives you a preview of what that new alignment might look like. Figure 2-9 Decentralized teams Instead of people being centrally aligned to the area of the architecture they work on, they are  decentralized and aligned to business domains. In the past, you had a front-end team,  services teams, back-end teams and so on. Now, you have many business teams, for  example, an account team that works on anything that is related to accounts regardless of  whether or the accounts involve a REST API, a microservice, or a user interface. The teams must have cross-cutting skills because their goal is to deliver business results, not  technology. To create that diverse skill set, it is natural to start by picking one person from the  old ESB team, one person from the old front-end team, and another from the back-end team. Chapter 2. Agile integration  23