There are several questions to consider:  The answer is to consider the architecture role. In the SOA model, the architecture team  makes decisions in isolation. In agility integration, the architects are role-practicing architects.  An example is shown in Figure 2-11 on page 26.  You have many teams and some of the members have a dual role. On one side, they are  expected to be an individual contributor on the team, and on the other side they sit on a  committee (or guild) that rationalizes what everyone is working on. They are creating common  best practices from their work. They are creating shared frameworks, and sharing their  experiences so that other teams do not blunder into traps they already encountered. In the  SOA world, it was the goal to stop duplication and enforce standards before development  started. In this model, the teams are empowered and the committee or guild’s responsibility is  to raise, address, and fix cross-cutting concerns during application development. If there is a downside to decentralization, it is how to govern the multitude of different ways  that each application team might use the technology. You encourage standard patterns of use  and best practices, but autonomy can lead to divergence anyway. 26  Accelerating Modernization with Agile Integration Figure 2-11 Guilds for governance GLYPH<SM590000> If you broke your teams into business domains and they are enabled and focused on  delivery, how do you get some level of consistency across all the teams?  GLYPH<SM590000> How do you prevent duplicated effort?  GLYPH<SM590000> How do you gain some semblance of consistency and control while still enabling speed to  production?  2.5.5 Evolving the role of the architect P L F U R V H U Y L F H D S S O L F D W L R Q P L F U R V H U Y L F H F R P S R Q H Q W P L F U R V H U Y L F H F R P S R Q H Q W P L F U R V H U Y L F H F R P S R Q H Q W * X L O G V