 So, welcome back to the Kaos Sony TV stage. The next talk is about software architectures and software architectures are one of the things young programmers should learn in their early years, maybe. I hope they do so. They are the solution for problems seen by more experienced programmers when they have to fix code, which in some shady path found its way from the first feasibility prototype by a tinkerer to production code in the field. Our speaker is Big Alex. He studied informatics in Dresden, took the usual way of dissertation apprenticeship industry job and from there came to be trainer and consultant. He gives seminars for project management and software architecture and he intends to talk about when and why software architecture is important for us as hackers and makers. He gave us very, very basic introduction and he condensed some weeks of details in the 40 minutes of video stream. He did his very best. And software architectures found in that case maybe a non-commented spaghetti code, I know, and one of the well-known big ball of mud. Maybe Big Alex can give us better examples and alternatives in the next 40 minutes and the stage is yours. Nice introduction and don't get me started out about prototypes and prototypes becoming production software and something like this. And I'm still a little bit scared about this call and I still wonder what came over me to think that anything even remotely resembling a meaningful introduction to software architecture could somehow be compressed into a 40-minute talk, but I try to do my best to have some meaningful talk for you and I really, really should have known better as Knob's already announced me. I talk on a regular basis about software architecture with others and once you really start to dive into the topics, you even can spend hours to cover the basic ideas and principles. But what made me do this talk is that there are some things that I wish that I would have known when I started taking on complex projects and more, more bigger long-term software projects and I want to give to you a short introduction what is software architecture really about and what you should consider it to be. The problem I have with this talk is a bit what makes me even more scared is the audience of this talk because every one of you for sure has his or her scar tissue and campfire horror stories about software architecture and software architects and usually as hackers or makers we have to deal with the results of bad software architecture, which plays in our hands a bit and some of us even consider architects to be people who do not or cannot code anymore or want not code anymore and everyone also have already met in his or her professional life those people that Joe Sposky called architecture astronauts. So he says there is a really, really great rant about those type of architects and he says they're so high up in abstraction and think on such a removed level that what they create is basically useless. They create high level abstractions, high level ideas about our system and but they're good and fine there well but they are not of any use to someone who wants to implement the system. We definitely want to avoid this and the other horror stories most of us possibly had what sometimes is called conference driven architecture that there are some big hype topics in your company or community where you have to go yes we have to use microservices and the customer wants blockchain and you know it's a big steaming pile of whatever garbage but this is what the customer wants or what others see as important and or what lead architect seem to be important. It comes from marketing slides and it really, really hurts developers if this is done without proper reasons and intention. I don't say that all of these technologies are bad or horrible. Microservices can totally make sense but there has to be a reason for this and not just because someone told your project manager while golfing that you need to do microservice architecture and you will become the next Netflix or Google have to do it that has to be a reason for this. So what I want to do in this talk we can only cover really, really the absolute basics of software architecture. So at first I want to start out with when might architecture, software architecture be relevant for you, be relevant for hackers or makers or this community? Why do I think this might be important for you? The next thing is what it is really about, what is meant by software architecture. This is the thing that I wished someone would have told me at the very beginning before diving into this topic and then why it matters and then I will give a very, very brief introduction what you can do to come out with what we call a good architecture or what can be a good architecture, whatever this we will talk about this later on. So let's start with some assumptions about you, why should architecture be relevant for you and why should you care about it. So what I have in mind about the people in my chaos community in Carl Stoner and C3D2, the hackers, why should they care about architecture? What they usually do is completely opposite to architecture. They just want to have fun with technology and find new creative uses. But if you really want to use a system in another way that is intended, it helps very much to know some common structures or design rules or typical limitations of the system that is under scrutiny by you. So typically every class of system has its trade-offs. It's dark alleys where someone did possibly cut corners to make life easy for the development team or to bring it faster to the market and something like this and software architecture possibly could tell you something about this. For the maker community, this is also not quite that obvious why we would want to use architecture. If you want just to think of a technology and play around and create new fans and stuff, that's totally fine. You might very well live without architecture. But the thing is, at the moment you want to create some sustainable software solutions, some projects, some library or framework or some Arduino application that you want to use for a longer amount of time or you want to build a community of developers or users around it. Then you simply can't live without knowledge of software architecture because it's an important success factor to make this thing fly. Without software architecture, you might run into trouble. The last people of our community, beside all the software professionals, they have to deal with architecture every day here. Social political actors, those people working in net politics, those people wanting to make sure that we get better software in our daily life from government projects and so on. The thing of software architecture is not only about technical decisions. When a project fails or a big government project runs astray, this is not necessarily because there are bad software developers and bad software architects at this project. There are a lot of other drivers for projects or for IT systems that have sometimes a much, much bigger impact than technology on the system. So there are political reasons. This is context of the systems. Why do people watch software projects fail and do nothing in big corporations or organizations? In this year, some cases of big software projects which had a great architecture and were not that hyped and successful, like commercial projects which had not so good architecture. So if you are a political actor, you might want to know what is behind of this. So before we continue, let's first clarify the terms of the architecture because we will use it a lot. Of course, when I talk about software architecture, one thing it could mean is engineering science. So the other uses of the terms of the architecture are usually what you want to end up with. There is also definition about this and this is quite to the point. This is software architecture is about the fundamental concepts or properties of the system which is embodied in its element, how it's decomposed into components and building blocks, how they relate to each other, how they relate to the environment. Then this is a prospective, still a programmer as well. But then the second part is important. That is the principle of its design and evolution. What are the rules? What are the constraints you use to decompose your building blocks? What are the rules you apply to communication and relationship to those building blocks? The other meaning of software architecture is of course what you really ended with. So on what's said, software architecture is a set of design decisions which have made incorrectly may cause your project to be canceled. So at the end of the day, when we talk about software architecture, software architecture is just a property of your IT system. Your system just has an architecture. It's not a description of its intended design and it's not, probably, should not be some treated that way but it should not be some upfront design by some enterprise architect or someone who tells you how to write code, how to write software. This is not what architecture is about, it's just a property of a system. So the problem is you can choose to ignore it. But that's totally fine. If you have reasons to ignore it, you can choose but you cannot have no architecture. You always have an architecture and if you don't care about the architecture of the system you create, it takes a course of it own. If you don't actively shape it, you have to deal with the results of just your design decisions. Then it takes just any form and you have to deal with it and this can become very, very nasty at the end. The longer the project goes, you all notice at the beginning of each project everything is easy, everything is beautiful. You have a green field to build things but the more releases you have, the more difficult becomes change and this is a real problem if you don't care about your architecture. Your architecture should help you with this. So let's take a super, super oversimplified examples for this. You want to make, light up your Hexpress. You want to have more more shining lights and so on. And if this is just a fun project, if this is something cheap you throw away after several months or after the party is over you, or if you just want to learn Arduino IDE and programming, architecture might not be that relevant for you. Just go loot the scrapbox, just take away, start your Arduino IDE or choose any of the existing open source projects that can light up LEDs and Bob's your uncle. You can be totally fine with this. But what happens if this project escalates into something bigger? Let's imagine you want to light up the whole building or you want to light up the assembly at the next camp or something like this where you have not one LED stripe but 100 or more or if it turns into something like an open source project that is for dealing with those LED stripes like VLED from air cookie or something like this which is a really, really nice project. So if you just want to have lights you don't have to hack it yourself anymore, you just can install it on your ESP here. If that what you do, that what you build turns into something like such a project which evolves over years, which is cared for by a community of developers and which should run with different kind of LEDs with different user extensions and so on, then it's time to think about architecture. So as we have already said, you just have an architecture, your system just exhibits an architecture, it is just there and what you want to do is you want to give it a shape, you give it a form, you want to give it tools, you want it to be a good architecture whatever this means now and also a good architecture in one year or in two years that helps you cope with change and so on. The problem you have at hand, each hacking project traces this right now when you develop stuff you have to make some design decisions and those design decisions can be very, very fundamental. For instance, programming paradigm or what programming language to choose, use the Arduino IDE or use a platform IO, what technology to use or should it run on a Raspberry Pi or on ESP or should it run on an older Arduino or something like this. And the next choices you have to make are even more difficult and complicated. You have to decompose your system into manageable isolated building blocks. You have to give it a structure, you have to find in which component to divide it and how those components should depend on each other. The thing is what you work with right now is a set of requirements that is far from complete. You only know some of the requirements, you for instance want to say yes, we have one tool have at least five different LED stripes and with each 100 LEDs and we should have nice fading effects and you know some of the quality requirements but not all of the system. This is what every take your own project, think about your own project. This is what every project starts off with. A very abstract, very malleable idea of requirements and constraints. There are some industries out there where all the requirements are there at the beginning but for most of our project usually not the case and it's definitely not the case if you do just a hacking project or a making project. So the next thing is you have to work with some assumptions about the future. You have to make decisions based on things you don't know yet and what it makes even more complicated when it is a long-term project. You do not only have to think about your IT system itself, those requirements but also about the process of developing it. This is something that can spend months or years and usually large IT projects and company develop over 10 or 15 years of lifespan. This is a lot of time and this development process puts additional constraints on the development of your IT system that are in many, many cases not technical. You are not allowed to choose the best engineering solution. You are a good engineer and you want to build the best LED light out there but you do not have any time to do it or you do not have the resources to do it or you do not have the skills. You just have to learn C++ or something like this. You just start learning to work with the Arduino IDE and your development team, the other people, hackers and makers that contribute to your project, you do not know what they are good at and how they are available and if they will commit to the project for the next coming months or years, especially an open source project, commitment is a difficult thing that requires to onboard people just because they like to do it. This is completely different from how a company works. The next problem is this is a moving target. All this changes over time. The time spent for your project over several years, a lot of things can change, people change, requirements and constraints change, the technologies change over time. All this changes independently and you somehow want to manage this and still want to come out with a good architecture and this is the real difficult part in such projects. This leads us to a major question, what really is a good architecture or at least the architecture that is good enough for your needs. The second question is how can we make design decisions that result in a good architecture for the project to build and doing this without big upfront design because you do not know the future. If you don't know the future and can foresee it, you just have to cope with change somehow. You have no major crystal balls that tells you what your requirements will be in several months or years. So let's go to the first question, what really is a good architecture? And then you hear the answer that every software architect will tell you and nobody really like it depends. It depends is always a good answer for software architect because it really depends and a really good software architect will tell you what it depends on and it depends on your goals and objectives. So is it just a fun project or do you want to really light up the next fusion with it and want to use it over the next years and so on. And there is no good or bad architecture without taking the context into account. And by context, I do not only mean the requirements on your system. By context also mean your development process. What skillset do you have? How much time do you have? How much money do you have? How skilled your developers is? What your experience with such systems is and so on. And only if you take this context into account, you can come up with an architecture that really fits your need. If you talk about a good architecture in general, they showed one thing what it should provide you is to help you minimize the resources to build your system and to maintain your system. The second part people often forget they only think about building the system as fast and cheap as possible. But if your system develops over several years, then maintenance of your system, keeping it up to date, keeping it up to changing requirements is the real difficult part. And this is also the part we don't know about. This is something that will happen in the future. We don't know if the certain libraries you choose to work with are still available in two years. Or if something bad happens like with log4j that it turns out to be a major issue and you have to update your system. So then the next thing a good architecture should do is help humans to understand the system. That is probably one of the biggest issue in systems design and systems engineering that our systems became increasingly complex. The Great Race Hopper once said before World War II everything was easy. After that we had systems. And the complexity of our IT systems are now so big that it's really a limiting factor for humans to understand how they work and how to change them or how to implement new features or how to adapt them to changing requirements. This is why your architecture should help you in this process. It means at least you have a meaningful division in separable components to contain complexity and you want to have some means of abstraction. You don't want to think about every and each detail of every and each subsystem if you want to change something. You want to decouple these things. And of course you want to do it because your architecture should help you to cope with changes which also happen in the future and provide your guidelines for your design decisions. And the problem we have with this design decisions is they are not necessarily rational design decisions. A rational decision is something where you can weigh all your options, find out everything you need and then choose the best options you have. And this does not happen very, very often with architecture design decisions. They are so-called bounded rational decisions because you have limited information available. You only know some of the things. There are a lot of what we call ikkivises. I know it when I see it. If you ask someone how the system should be, they say, I don't really know or just build it and I will tell you if it's right. I know it when I see it as the usual thing we have to do it. But you also have limited time to make this decision because if you do not make it within the next days or so on, you lose a lot of time in your project. And you have a limited cognitive capability to do this multi-dimensional optimization. So how do we come up? What is a good thing to come up with good design decisions that lead us to a good architecture? So how to come up with a good architecture? And step number one should always try to be sure about your requirements and your system context. If you don't know what drives you, what drives your decisions, what is important for you, then you cannot do really good design decisions because your design decisions are always a tradeoff where you have to sacrifice something for something else. And if you do not know your goals and constraints and what is the most valuable thing for you, your LED light should do. You cannot make a good design decision. And the other thing is about requirements and constraints and context as they often have the best buy date. If you do not fulfill the requirement of connecting all the maps in the RC3 world at least today, then your requirement becomes pointless. So you have to know how your requirements change and how stable it is. If you ask someone if you or she really needs it, then it can say, yeah, someone told me I really need this feature and I want to have it. But it turns out it's not a thing or she's really interested in or makes money with or it just he or she has just been told that everyone needs this. So you should know what are your goals, what are your influencing factors to your architecture, how important they are and how stable they are, how they will at least make an assumption about how they change over time. And one specially nest kind of requirements are quality requirements, because if functional requirements change, this is something we can cope with in our everyday life. This is normal somehow more or less. If a quality requirements of your system changes, for instance, your LEDs should now provide a PVM frequency of 1000 Hertz and not only of 200 Hertz for some reason, this can be a major problem because this might change the whole system and you might have to redesign your system completely. So you should really watch out that you have the most important quality requirements on your radar and find out how good your system should do things, how stable it should be, how maintainable, how changeable, because all the change in one of those quality requirements can mean that your system design becomes obsolete and you have to come up with a whole new architecture to cover for it. And to not let this happen one good thing is to work incrementally. Do not try to fix everything at once at the start of your project with a big upfront design, this usually doesn't work. You don't know everything in the beginning. Use iterations, use small steps to improve your architecture. So it's okay. You should have some course idea how your architecture should look like some guidance. If you don't have some guidance, you cannot do design decisions, but you have to prepare for it to change. And what your architecture should enable you is somehow to cope with those changes. And one important thing that you are able to do is that you know your tradeoffs. This is, I think Mark Richards coined the term everything in architecture is a tradeoff. So and also the corollary to this is if you as an architect have found something that is not a tradeoff, you just haven't discovered the tradeoff behind it. So to make good design decisions, you have to find out which components of your system are somehow connected, how they are coupled to each other. And if I change one component or the requirements for one component, how does it impact the other components, this component is coupled to it. Even if we take such a simple example like our LED lights, there are already such a lot of tradeoffs and real big project at this even worse. For instance, you could decide that you have to design this version to use software PVM to support a lot of LED stripes or to use hardware PVM, which has a lower load. The thing is if you so you cannot have some features, you have less stripes or you want to have a higher PWM frequency to don't have those Perl effect. Then you move your eyes, but the higher your PWM frequency, the more electronics problem you get and the lower is your dynamic range. You cannot have very, very low steps between the brightness of your stripes. And don't let's get started about such optimations between frame rates. And then you want to have a very high frame rate to have smooth animations. You have a very high load on the systems. You might have dropouts. You might not be able to synchronize it. For instance, if you want to light a stage with it and then switch the light and you want all the lights to switch at one. And this is sometimes this is absolutely a tradeoff to have a high frame rate to have it really synchronized. And don't let's get started about features and about quality attributes. For instance, do you want to have some nice over the air update to have it maintainable to not having to go to each of these lights to change your firmware? But this has a lot of security implications. Do you want to have something in your network like this? So it also you lose a lot of memory to enable over the air update and so on. And everything in your design decision is a tradeoff. And what you should do is identify what you traded against what are the quality of feature or attribute of your system. This is something you should bring out in the open, make them visible. And the good thing to do is, for instance, using architecture decision backwards. You should make your tradeoffs open because these tradeoffs are not visible in the code you write. They are just usually just in your documentation. So next thing is you have to cope with change and to be able to cope with change very well. You have to identify the things that are really, really hard to change. And those what those are depend on your specific project or system. But usually hard to change things like programming paradigms if you choose functional or imperative programming or your programming language, it's difficult to change it later in the project. You have to rewrite everything or the platform you choose or the middle there or some of the libraries you choose. Sometimes it's very, very difficult to change them. Or if your system provides a public API to others that a lot of other components, a lot of other users will use, then other systems will use then those things changing those things always comes quite at a cost. You can decouple from those changes. This is totally possible. But even decoupling brings to additional complexity in your system. And complexity is what really might kill your project because you must only have a small monkey brain and can only have so much complexity. So how would you do it? What do I do when things that are hard to change change anyway? Unix has a quite cool strategy for it. It basically has a set of small tools that do exactly one thing well. And they communicate with standard protocol. So they are very, very nice decoupled, which means every of your small Unix tools can be changed really bit by bit, no pun intended. So we already talked a bit about coupling and we use this a lot and it's an important concept to have. So what is this coupling? Coupling means there is some kind of dependency between your components. When you change one component, it might probably have implications to other components. So as a programmer, you know about coupling a lot. If I ask in trainings about coupling, usually people come up with coupling by call. If you want to call another component, a function or a method of an object, you are coupled to this. You are coupled by data structures and method signatures and so on. If you use a common database field, for instance, or common data type and one of this is changed, then you have to look out to other components who also use this if they can cope with the change. This is something most programming languages or a lot of modern programming languages take care for you with type safety and so on, but not all programming languages do. So you might want to watch out for this. You could hand over data as text or as JSON with all the JSON schema and then one component changes what's in this JSON file and suddenly your application crash. This is a sign that you are coupled via data. Also what programmers usually know they are coupled by inheritance. Inheritance between glasses is a very, very strong kind of coupling, but there are a lot of other modes of coupling and this list is by far not completely not complete, but of course we might be coupled by the fact that the components have to run on the same system or on the same virtual machines. Some components have to create other components. There's also some kind of coupling or you have a coupling via time that you rely on something happening before you can do something. And this is something that is usually not visible in your code. Modern programming languages provide constructs for this to make it easier to handle some of these things, but you cannot handle all of these things. And there might also be things you are coupled by which don't have any representation in your code at all. Like for instance, all your components need to be deployed at the same time because you are a layered monolith, you have strong dependencies and you have to implement fixed release dates so that everyone can merge his or her changes into your project so that you can make a new deployment. So and you can decouple or you short decouple as good as it gets. What you really want is not to have that much coupling between your components because it makes changing your system difficult and it makes thinking about your system difficult. And you have a lot of ripple effects when you change something, but even lose coupling as a trade-off. If you couple something loosely, it usually adds more complexity to your system, it adds overhead to your system. So and you should really know when to decouple. So and you have to have to have coupling in your system, you cannot get rid of, you have to structure it somehow. So what you want to do is that you want your design to be prepared for changes, but limit the impact of changes, limit the ripple effect and reduce unwanted complexity. And software architecture provides you with a lot of design principles that help you do this. Some of them, most of you already know, they are so common sense that you just grew up with them, like information hiding. Most modern programming languages provide one or the other means of information hiding or separation of concerns is something you should definitely choose. Those people from object-oriented programming know it as single responsibility principle, which is not quite the same, but basically the same. So if you separate your concerns, if you separate functionality, then you have a loser coupling between those things. You have less relationships between this component. There are a lot of other things, design principles, software architecture has on its leaf. I could make an own talk or own session about them. So if you want to have a follow up on this talk, the next thing will for sure only be about design principles, you should definitely look into them. But one thing you should notice is you do not strive for the perfect adherence to this design principle. You should strive, look if you can violate them because the thing is some of these design principles are really a trade-off in their own. For instance, every programmer knows they should adhere to the dry principle. Don't repeat yourself because the opposite of dry or sweat waste everyone's time. But not adhering to the dry principle, have duplicate code in your system can be very well for you because you can independently develop this code. You have decoupled the development. You can give it to different teams. So basically if you think about microservices, microservices violate dry all the time because you do not want to have inter-service communication because it's so expensive. That's why it's a good reason to violate dry because if you stick to dry, it may increase your coupling because if you do provide an abstraction for something you had when you used dry before and you provide an abstraction, you are suddenly coupled to this abstraction. So everything is a trade-off here. I think you get it. We are running a bit out of time. That's why I don't want to talk that much about pattern. Patterns are a very, very important concept of software architecture. You don't have to invent everything yourselves. Patterns provide you with reusable solutions for your problem that probably someone else already had. And also they provide something to talk about, to give you a structure and terminology. There are a lot of good sources for pattern. Don't invent your own pattern. Patterns are not invented. Patterns are discovered, but look out what patterns you might use. And there is also a lot more than just architectural design which we have covered now for software architecture. The most important thing is write stuff down. Nobody likes documentation. Everyone knows documentation saves time later on, but it might not be your time that is saved. This is a problem with documentation. But make it easy for others to provide documentation. For instance, use a template-based documentation. And if you do architecting, you are suddenly in marketing and politics. You have to train others. You have to convince others about your solutions, talk to other stakeholders, and make it work for them. So if it doesn't work, then you might have either a serious problem that what you design doesn't fit the needs of your stakeholders or your team or the people you work on this project with, in this case, for a hack space, then you should find out what their needs are and should find out if your design matches the requirement in context. But also a lot of non-technical things can go wrong. For instance, in companies, you have the problem that compliance with hierarchy is very often a big thing. You are not allowed to do architecture because you don't have a certificate or something like this. This inevitable leads to real conflicts. Or you have someone that has just got assigned a title architect and this person becomes a bottleneck because he doesn't do architecting. He doesn't reach a high enough level of abstraction. It's not that you should become an architecture astronaut, but you need some level of abstraction. If you do everything yourself, you cannot do architecture anymore. What usually works best if you want to make your architect fly in a company or in a group of hackers or makers, you should definitely avoid assigning architecture responsibility by hierarchy or title. I think this also will not happen in our community. Our community is quite immune to that. But if you watch it in your company, look out architecture responsibility very often and very well accessed without explicit titles of someone being an architect. Let just people grow into the role. Experienced programmers usually become architects themselves. I don't have to teach them anything anymore. They do it intuitively. This is the same thing that responsibility for architecture comes to those people who really care about the architecture and not who you assign to it. If you don't have an architecture role, it can be shared by a team. This is totally doable in development teams that you can share the role of the architecture between people according to their skills. Just go into a meeting and ask who can tell me something about how we did, for instance, over the air updates on our LED stripes. Look who comes up with answers, who cannot explain it. This is someone who might have an architect role in there. So our time is up. I'm sorry I'm forming late and didn't cover everything really well that I wanted to cover. What we covered so far is only the what about software architecture, why it matters, and a little bit of what is good architecture and very basics of architectural design. There are a lot of more things to talk about like how do I do a good decomposition and components? How do I separate concerns very well? What do I do with cross-cutting concerns, documentation? How do I find my influence and factors and so on? This is all the things that just didn't fit into those four demands. I'm very, very sorry about this, but anyway, we are at the end of this talk and thank you very, very much for your time. Big thank you for your patience and I'm really looking forward for your feedback and for your questions and maybe after the talk, we can also meet in the KAUS SORNER RC3 world, if you have any questions or discussed or if you have questions concerning just your project. I'm very fond of looking in the architectural problems you run into to talk about this to find out what you did or what your problems were there and how do you make it work because being a good architect means always to learn something from people who do architecture right. Thank you very much and I'm looking forward to your questions. So we have a little delay here in the stream, I think. No, I think we're online. Well, here I am. You hear me now? I can hear you now. Great. So we may not have the time for each and every question asked, but let's pick out some of the most important of those we'll get in the time. I will go through the chat later on and I'll give you all the answers after the talk. So software architectures are like knots in seafaring. They help the one who is responsible for opening the knot to be able to open it, as if they are well knotted, he knows how the one who threw the knot did it. So are software architectures known and present in standardization like DIN, SEN, ISO, IC, IEEE, RFC, and you name it? And which one is the standardization organization for software architecture? A standardization IEEE cares about software architecture, but IEEE cares about software architecture in a sense that it treats as a subset of system architecture. If you look at how the ISO and IEEE standard changed over the recent years, there was a few years back, there was still a definition of software architecture. Now there is only a definition of system architecture, which is completely okay because software architecture basically is system architecture for IT systems. So I can't talk about other standardization organizations, how architects are involved. There are organizations which care about the knowledge of software architecture. I don't want to make any recommendations here, but there is a very, very active software architecture community of, in my opinion, very, very clever and very, very excellent people here in Germany or Austria and Switzerland and Europe. And also there are a lot of outstanding individuals in other parts of the world who are good authors and who care about software architecture, but I cannot say anything about their involvement or the way they work together with standardization organizations, the trust, not the thing I know things about. That sounds somehow like the grassroots standardization done by RIPE in the beginnings of the internet, maybe. The problem here with the standardization is that for some terms, we don't even have a standardization. If people talk about the interface, they can talk about the contract between component, they can talk about the implementation artifact, they can talk about interface as a kind of abstraction. So yes, standardization like the Sway-Book or something like this for software engineering would be good. I completely agree with that. Optimal for the next answer, how does software architecture interact with systems architecture you mentioned right now? And how does software architecture reach into adjacent fields like hardware, firmware, licensing, and so on? And how do they communicate in the optimal case? So those are two questions, right? How does software architecture interact with systems architecture? Software architecture is a part of systems architecture. When your system has substantial software parts in it, then your software architecture is a part of the system architecture. It strongly interacts because you have a lot of dependency, because quality and capabilities of the systems you build influence, requirements, and constraints of your architecture. And it's not only interacts with system architecture, it interacts with other architectures as well, like information architecture or the business architecture of your enterprise. It can also interact with hardware architecture. Certain software doesn't work well on a single-credit processor, for instance. So you want to have some architectural separation here. So if you can think about software architecture, then you probably are really, really good about, can also think about system architecture and vice versa. The application domain is a bit different. You have to have more domain knowledge for systems architecture, because you might have to deal with hardware a lot or something like this. So what was the second part of the question, please? How are the involved people to communicate in the optimal case? In the optimal case? Like maybe in requirements, documents or whatever. The thing is, what is your optimal case? If your optimal case is, if everything works right in the end, what is what your optimal case is depends on the resources you have, the distribution of your team and so on. It's probably a good, or in the past, we had a separation of concerns by teams. You had teams that were responsible for hardware. You had teams that were responsible for front-end and people or front-end developers, back-end developers and so on. This usually doesn't work. It can work, but what works better is to have cross-functional. To involve other stakeholders in your decision-making to a certain point. You cannot have them all in your decision, but it also has a bit to do with Congress law, because the structure of the system you built, let's have a look here. The structure of the system you built is also defined by the structure of your development team. This happens inevitably. If you have a strong separation between those teams, then automatically your system develops an interface on the boundary of your team, which is hard to change, which causes a lot of effort to change. So if you want to have optimal communication between, let's say, systems architect and software architect, then point A, they should write a lot of documentation. But before they write a lot of documentation, they should talk with each other and find out what information the other stakeholders needs and what their trade-offs are. Explain their trade-offs to them. So one big Rosa Elephant in the room. Are there common architecture patterns that everybody should know? This is really a big elephant, and this is not a new discussion. Six minutes before that elephant. Humongous elephant. The thing is, what pattern you need depends on the system you build and on what level you operate. You should, as a developer, you should definitely now have the gang of forebook, the design patterns laying around, because it helps with a lot of implementation and design problems and coding. The thing is, architecture patterns really depend on what type of system you build. In the software architecture community, we had a lot of discussion which patterns to include in our curriculum, and what we ended up with was taking out most of the patterns, because every one, we came up with a list of 30 patterns or something, and most of these patterns didn't work for the other people training architecture. So what we captured were, I think, layers, microservices, pipes and filters, and some fourth one. This are the must-know patterns, but must-know only because they are relevant for the training, not because they are really relevant for the person using them in practice. So what I can offer the person who had this question is that we meet later on and find out what kind of systems he or she works on and what patterns might be relevant. The pose literature here is, for instance, distributed into different books, depending on what kind of software you build. For instance, if you have a distributed system, then you usually have other patterns than when you have a monolithic system or when you have a very, very system that is very close to your hardware. Well, maybe we answered that right now. Is there any literature that the developers should read? And I think that's almost our last question. The Internet asks for a next part, maybe next time. Recommending literature is always a bit difficult. If I should only recommend one book, there are a few good books on architecture. If it's a German-speaking person, I would recommend one book by Gernot Starke, for instance. If it's for the English community, the most modern and most comprehensive in the latest time is by Mark Richards and Neil Ford, the fundamentals of software architecture and engineering approach, which is from 2020, which is quite up to date. And if you see talks of Richards and Ford, they always work the time. They really do nice stuff. They also did a new book this year on modern trade-off analysis, which I didn't read, but I went to the workshop they had for this book before it went out. And this is more for those people who build distributed systems, who think about service-oriented architecture, so it might not apply to people coming from embedded systems and so on. But the fundamentals of software architecture book was quite good. Simon Brown has a good book, Software Architecture for Developers. There are Rosenski books, good authors. They are a bit older, like Bas Klemens and Kasman. They are also a bit older, those books, but this should get you covered in the most important one. Sorry to any good author, I didn't mention here. It's really difficult to recommend good books without stepping on anyone's toes.