 Okay, now you have seen the UML component diagram, so you have seen one typical way of drawing, of depicting an architecture. Now we go into really what it means to architect a system. And there are essentially a number of questions that you ask yourself when you go out and try to figure out what's our structure, what's the high level view. And the first question you should maybe start with is, is there any kind of generic architecture that we can reuse? We'll look into this a bit later, but in very many cases businesses look similar and have similar requirements, so the applications also look similar. So why reinvent the wheel if you can reuse something that has been proven to work? So that's one thing. The next one is of course what will be the distribution. So if I have numerous components, they're all independent, where should I be deploying them? Should they be on different machines or all run on the same computer? Do they need different operating systems or do they have certain technical requirements, for example? Then, similar to the generic architecture, there are so-called architectural patterns and styles. So parts of the system that are structured in a certain way that has proven to have certain advantages and disadvantages. And you have seen a lot of them, we'll go into much more depth there. But these are just very common ways, proven solution for a part of a problem. So should you be using any of those? Which ones? What kind of properties do you need? Obviously on an organizational level, you might ask yourself, how do you document this? So it's often important that your developers know how the application is structured so that they can actually use it properly and that they understand it properly. And for that you need to understand, well, how do we write it down essentially? Do we not? Do we just have the architecture and we just by word of mouth tell the developers what to do? Or do we write pages and pages of diagrams and text that explain all of this? Then, of course, we get into the decomposition itself. How should we decompose? What are the components? What are the relevant parts? And that's maybe what most people would say is the most important aspect of architecture. We get into quality requirements. So you might ask yourself, why do we actually need to do this? Shouldn't we just go in and start implementing? And the answer is the architecture, the overall architecture of your system has a major influence on important quality requirements. So depending on how you structure, you might not be able to get the system above a certain performance limit or you might not be able to make the system more secure. So it's highly important really to have this planned structure in order to achieve certain qualities in your system. And this is always a trade-off. So the architecture, there is no perfect architecture. There is nothing that you can do to get all of them. But essentially, you always have questions about performance, for example, a very common one. Security, I would say, is very important. Sometimes you deal with safety in some systems. Availability is an issue. And for example, maintainability. So depending on how you structure your system, it's more or less performant. For example, it supports easy replication of components. You just, instead of one, you have two and suddenly the performance goes up because one component only needs to handle half the traffic. Security, if you have a certain architecture, it's easier to add or replace certain parts that, for example, handle authentication. Safety, if your system is safety critical, there are certain concerns to look at. Availability, well, again we go, for example, into replication. If you have two components and one breaks, the machine crashes, well, maybe the system still keeps running. And then more on a development aspect, if it's nicely decomposed, it's easier to maintain it. If everything is together in one component, it might be much, much harder to change things. So these are typical things we'll look at. And now in the following, we'll start by looking at these architectural patterns or architectural styles that often have a certain advantage in one or multiple of these areas. So that's where we'll now go into. We'll just look into a handful of these styles that exist out there.