 Okay, now we have covered architectural styles, we have covered generic application architectures and we sort of knew or we went into the direction saying planning the architecture helps you to achieve certain qualities because if we use certain styles we, for example, know that the performance is good. But there is another aspect of architecture that's very important and that's essentially the thought that the architecture is a blueprint for the development or the organization. So imagine, for instance, you are using a layered architecture. Let's do the classical three layer architecture, we have a database, we have the business logic and we have the user interface. Then very often you also have the team structure like that. So you might have a UI team, you might have a business logic team, you might have a database team or two. So there could of course be multiple teams but this is the way you structure the development of your software. Similarly, if you would have a repository architecture, you would have teams assigned to the repository and you would have teams assigned to the components accessing that repository. So this is very often also a way to structure the application and how you develop it. But in this context it's very important to look at one thing and this is called Convaze Law and Convaze Law says that the organization that develops a product sooner or later resembles or looks like the product. So imagine this is your product, you have a UI, a business logic layer, a database, sooner or later this is exactly how your organization will be structured. So you have teams here that do the UI, do the business logic, do the database. This might not be surprising because that's exactly what I just said but it's the same for example if you imagine you are building a car. So you have for example the teams that do the brakes, you have the teams that do the chassis, you have the teams that do the engine. So this is very commonly how automotive organizations are structured and that's the same for other manufacturing organizations. It's common that the organization looks like the product that develops it. And this is highly important in software engineering to understand because one thing that we have to consider is that if our organization looks like this this also says a lot about how the communication has to look like because if we have a team here and we have a number of teams here and there is an interface it also means that the communication needs to be between these teams. So whenever we plan our development we really need to take into account for instance how we place the teams, what kind of communication we have within the organization we need to consider how does the architecture look like. Because if this is how we structure our software product and the company looks more like this then you might run into trouble because these communication ways are not established and it might be very hard to get there. So it's not enough to just run and develop you have to take into account how your product looks like and that's where the architecture can help you as well. So it's not only a matter of layered architecture is better for security and repository architecture is good for having teams that are independent you also need to consider is the architecture suited for my organization because changing from one model to another might be extremely costly for an organization and might lead employees to actually resist this change and then even though the repository might be a much better solution for you it might be easier to just go with a different application architecture. So this is something that is really important to consider and that's also important to consider when we go into things like agile development if you think about can we actually be agile with the architecture we have for instance if there needs to be a lot of communication going on here the teams in the repository cannot really be that independent and just plan their sprints without talking to the others but there actually needs to be a lot of communication as long as the interfaces are not fixed. So this has a very important impact also on how you develop software. So keep in mind the architecture of a software very often resembles the product resembles the organization and that means you need to look at how do teams communicate within the company to actually build the product you would like them to build.