\u00a02. You have five teams who start to work in parallel. The application integrates with ten different existing applications<\/strong><\/p>\n In the first case, you can usually start immediately. Only rarely have you to consider things like: increased performance in parts of the system or increased security that requires special coding guidelines. Experienced developers will take these into consideration naturally, without someone telling them. If developers pair, guidelines will emerge from this interaction. Components will emerge by extracting common parts of the code into separate libraries or services. Problem solved.<\/p>\n In the second case, you are facing different challenges. Every decision that involves more than two teams can take forever. Decisions made by one team might not be ideal for the whole system. Ideally, everyone will know the whole system and can decide for it, but we know that is not happening in reality. No matter if you structure your teams as feature teams or component team, you will have some long conversations for certain types of decisions. You have to answer more questions. How do you keep consistency in code? How do you ensure performance, security, availability, scalability? Some decisions need to be made that affect more than a sprint and more than a team.<\/p>\n There is more. Often during a longer project with multiple teams, you have to balance short term with long term needs. Should we spend one more day to extract one service now, or should we wait until we find that the user facing application has low availability due to that service? We knew we need high availability for the application for months, how comes we could not we see that extracting the service is important? Or is it more important to deliver? Can the Product Owners (we have multiple teams, so probably multiple POs) make this decision? How? Or should we leave this decision to one team? All the teams?<\/p>\n Depending who you ask these questions, you will get different answers. Some XP practitioners say that architecture will emerge. Scrum says you need to figure it out. Kanban builds upon an existing system, so it is again up to you to find solutions. None of these answers is satisfying.<\/p>\n If you ask experienced software architects, such as Rebecca Wirfs-Brock or Simon Brown, they will tell you that you need to think ahead. One of my<\/a> conversations with Rebecca<\/a> inspired her to write an excellent blog post<\/a> that you might find interesting in this debate.<\/p>\n My experience has shown that we need to think ahead. Like any plan, the initial architecture will change but it is important to have something to change. When I start developing a product for a customer, I believe my job is to make a few decisions that will help with three important things:<\/p>\n I go through an analysis process that lasts between two hours and two days<\/strong>:<\/p>\n It is worth repeating that you do not need to do these steps, except maybe identifying risks, if you are building a simple mobile or web app with a five people team. But if you have ever worked in an environment where 30 different teams build a product together using Scrum and the product has to work with existing services, protocols and devices, you will see the value in doing more upfront work. (By the way, I did work with four teams out of the 30 described above, and software architects were very important for the development).<\/p>\n Once we start coding, I always keep an eye on the architecture. I have learned from Marty Cagan’s book on product management (he is the former eBay product manager and has worked with agile teams),\u00a0 that three voices are important for the success of any product, before and during the development:<\/p>\n I did my best to expose developers to these ideas in the past month, by running three “Architectural Kata” sessions in UK, at SoCraTes UK<\/a>, at the Cambridge Software Craft Community<\/a> and at the London Software Craft Community<\/a>. The attendance and feedback was overwhelmingly good. I am waiting now to see what they took into their daily work and how it influenced their thinking. Agile and Lean Software Development need software architecture. We do not need ivory tower architects, but hands-on practitioners able to have meaningful conversations inside teams working in complex contexts. We have many more questions to answer, but we would not learn more unless developers understand what architecture is about, practice it and take ideas to their work.<\/p>\n If you want to learn more, here is other blog post about architectural kata<\/a>.<\/p>\n If you need improving your knowledge about Agile Architecture, we can help with:<\/em><\/p>\n\n
\n
![\"Architecture](\"https:\/\/mozaicworks.com\/wp-content\/uploads\/2013\/10\/2013-10-02-21.17.51-300x225.jpg\")
<\/a>\n
\n\n