 recording of the webinar. Second of all, let me share some formal organizational information with you before we go to the contents itself. I think it won't last longer than five minutes. So the name of the webinar is RCDA, risk and cost driven architecture agile architecture making big engineering decisions with agile teams. The presenter of today's webinar, Dr. L. T. Port from CGI will introduce himself as well. Here's a slide about himself. First thing I would like to say is thanks to Lockheed Martin, the sponsor of Incosy 2021 webinar series. Another one thing I would like to let you know that in case you are a certified systems engineer, you can use or you can receive credits for certification renewal because you attend to a webinar. That is relevant as well for both Incosy certifications and German chapter We have pretty much different but aligned programs and these joined webinars are relevant for both cases. So if you like to use that, use that. There are links with more information about how to get these credits for certification renewal. Another one thing what we do in the German chapter that might be pretty much obvious to any one of you, but we have to from the legislative point of view to point out that during our meetings we do not have or are not allowed to discuss prices or pricing elements, exchange sensitive company data, or competition behavior coordination and stuff like that. That's a European law but sounds pretty much obvious to all of you from all around the world. Just have to note that. If you didn't see the video teaser on the on the YouTube channel of the German chapter of Incosy I think I'm not going to introduce L2 again in detail because he has a slide about himself as well. The interesting thing is about this webinar that it was organized by the German chapter by the Incosy central and the L2 is from the Netherlands. So that's a truly international cooperation for this webinar and I really like the fact that it is happening right now. Before we start I would like to let you know how we are going to do that. We're not going to interrupt our presenter because we have a lot of information to give you. If you have questions please ask them in the questions and answers section. I will gladly if that really fits and it is a short question I will let the presenter know that there is such a question but normally we will answer them at the end of the presentation. I think we will have like 10-15 minutes at the end of the presentation for that. So that's pretty much it. L2 I'm done. You can take the stage. Excellent. Thank you very much, Alexander. And I will share the screen. Let's see. How does this work? Yep, we can see your screen. Yeah, excellent. Great. So thanks for inviting me to get this webinar. We met at an RCDA training course about six months ago and we got to talking about the links to systems engineering. And I have to admit that I am not an expert at systems engineering. I have sort of run into some systems engineering concepts during various more technical engagements as an architect but I'm not really an expert or even I'm sort of certified engineer in that sense. So what I'm going to do is I'm just going to explain to you what we have been doing in terms of what I call architecture in the digital world and how to get a better alignment with agile working. And then I think maybe in the questions and answers or after which we will have a little bit of time to see how that all of that relates to the systems engineering. All right. So this is the announced slide about myself. You can see some of my clients, some of my hobbies here. And I spent the last 20 years working as an architect but lately I'm mostly doing three things. I give an opinion about other people's architectures. So I do second opinions, help trouble projects, do assessments, etc. And I lead the architecture practice in CGI in the Netherlands. For those of you who do not know CGI, CGI is one of the bigger global IT service providers. We have about 75,000 people worldwide and about 30 countries, I think. And the third thing I do is help organizations modernize the way of working when it comes to doing architecture. And the basis for that is the RCDA approach, which you saw in the title as well. So this is RCDA. Depending on who you talk to it, it either means risk and cost rate architecture, that was its original name 10 years ago, or responsive and collaborative digital architecture, which is a more modern name. It comes down to exactly the same four letters. So that is a fortunate coincidence. And we have been, well, not silently, but we have been developing this for our internal use to get better at doing architecture in agile projects. And we have been publishing about it and also helping clients to modernize their architecture function using this approach. And so of what I know about the systems engineering processes, architecture is seen as a phase in the engineering process, right? It is something that you do after you understand what needs to be done. And during the architecture phase in systems engineering, what you do is you make a high level decomposition and you assign responsibilities to the various subsystems or components that you decompose your system into. And this is actually very much also how we used to look at architecture in the software world 20 years ago. However, then something happened. The thing that happened was called the agile manifesto. And the agile manifesto basically is a, you can call it the revolution, that happens once people realize that the type of engineering that you do with hard stuff, with buildings, with airplanes, et cetera, is not the constraints that you have there do not really apply to the software world. Actually, in the software world, there is a much longer period after you have started to take the system into operation where you can change stuff. And to embrace that change, that is the basic tenet of the agile of the agile manifesto. And once you look at that, they have to rethink what architecture is, because if you can change things, and you have to design things throughout the whole life cycle, then the evolution, sorry, the architecture of that system is not something that you have to sort of mostly design a prompt with maybe a few changes or modifications afterwards. No, it becomes something that evolves, where you have to be very smart about how much you sort of lay down and design upfront, and how much of that you will have to change later on, or you will evolve later on. And that means that architecture is not a phase or a particular activity, but it then becomes a set of responsibilities. And that is what this slide tries to say, architecture in the digital world is a set of five responsibilities. And these responsibilities are, first of all, understanding context, because architecture is context. It's all about understanding what needs to be done, what the constraints are, what is realistic, et cetera, et cetera. And then making models, blueprints, designs, actually that decomposition of the system, that you can also consider to be a first model of the system that you're designing. And that is the more traditional way of looking at architecture. You can see some references here, architecture is a set of structures as an abstraction. And these come from books from the late 90s. But then also there is a responsibility of making decisions, because once you decide, or once you design a system and you decompose it, you basically decide how to decompose it. And then there's other decisions to make, like which responsibilities to assign to specific subsystems or components. So this is a slightly later realization that happens in the zeros, or the noughties, as an architect colleague of mine, you like to call it, that architecture can also be seen as a set of design decisions. So that's the third responsibility. And then there is a responsibility to validate that design. If it's an upfront design or the upfront part of the design, then that has to be validated based on the models, of course, or maybe on some product typing. But if it's evolutionary design, then there are other possibilities of validating that architecture. And then finally, there is the responsibility of supporting the realization of that design. And we have called that responsibility delivery here. Of course, architects are not responsible, not fully responsible in the end for the delivery of their solutions that they have designed. But they are certainly responsible for supporting that realization, that delivery. And that is a responsibility that may not have been so obvious or a little bit understated in the classic view of architecture. But in the view of architecture as something that evolves, then that means that there is a much longer interaction between the people doing the architecture and the people doing the delivery. It's not a hand over moment, but it's a continuous back and forth between those two responsibilities. So this is why delivery in an agile context is a much more important responsibility of the architecture function. So what we did basically was we based a maturity model on these responsibilities. As I said, one of the things I do is I help organizations get better at doing architecture, improve or modernize their way of working. And one of the things that one of the tools that you need for that is some way to assess how good they already are and where they need to improve. And you traditionally do that with a maturity model. And our maturity model is based on these five responsibilities. And what we realized after a while was that actually there are many organizations in the digital world, software companies, but also banks who don't even have architects anymore. And they have found a different way of fulfilling these five responsibilities. And at first, of course, that is a bit scary if you are an architect. But after a while, you start to realize that actually, you know, you have that freedom. So the maturity model doesn't say that you have to have architects. And this is what they have to do. No, they have that. But basically, what the maturity model says is that you have to look at how well the organization as a whole fulfills these five responsibilities. They have to be balanced. And they have to also be in touch with each other, of course. So once we had that maturity model, of course, what we started to do was we started to look at organizations and we started to pilot the model and refine it. And this is definitely not the first version. But up till now, we have had quite a number of assessment workshops in about 10 organizations. And we also did these workshops in a number of conferences. Actually, these numbers are a little bit outdated. And we started to gather results. And of course, what we saw was a wide range of maturity levels. And we also saw some very interesting patterns or maybe I should say anti patterns. And these are what we have started calling the waterfall wasteland, the agile outback, and the headless chicken. So what is the waterfall wasteland? Well, this is the name that we started to use for teams or departments where the left the right hand side of this model was ignored. Basically, what we saw was there were teams that had a lot of attention and put a lot of energy in modeling after they understood the context. And then also into validating these models and getting these models approved. But once they had a an approved architecture document, they moved on to the next project. They also didn't think that they were making decisions, they were putting the decision in front of management and making sure that management had the information, right? So they considered themselves advisors rather than decision makers. And they, they had very little involvement in delivery, right? So this, the icon of this, this caricature is, is the ivory tower, right? These are the architects that have kept on working in the classical way. And of course, you know, this is a caricature, as I say, this is not the real world. We didn't meet this extreme, as I'm explaining here in the real world. But there were certainly, there are a lot of teams that are sort of tending towards the left hand side of this model. The opposite, of course, also happens, which is, which is the, the antipattern that we call the agile outback. And here, what we saw were teams that made decisions, they made design decisions. And then they immediately started building. They did not first model it out. And the reason for that was that the agile manifesto actually has something to say about how to make architectures. And it uses the word emerge. There's a principle in the agile manifesto that says that the best architectures emerge from self-organizing teams. And a bit later during this presentation, I'll get back to the principle. But they saw it, you know, as telling them not to model, they were sort of afraid that they would interfere with that magical emerging process, if they would do too much modeling. And validating, that's also something they did not pay too much attention to. And the reason was that they said, well, you know, it's better to fail early and fail often, right? It's you learn quicker from making mistakes than from doing a lot of thinking. And of course, there is a point in that. But it is a little bit one sided. And certainly in very business critical or safety critical systems, failing early and failing often is not an option at all. So that's the other extreme, the agile outback and the icon for the agile back is the crocodile, which emerges from the swamp. Just to symbolize that the emerging architecture is not something that just happens magically from a crystal clear pool. Your beautiful architecture emerges. No, actually, emerging architecture is a lot of hard work. And if you're not careful, it will bite you. So once we establish this, the question, of course, is how do you find that balance? It's all about the balance between five responsibilities. And what we found out after a lot of trial and error and talking to a lot of people is that there's a number of principles that really work quite nicely if you try to balance these extremes and find the right balance between the waterfall and the agile way of working. And the first of those principles is that you have to see architecture no longer as a blueprint that you create, but you have to actually see it as a streaming of decisions. It's not a one thing, you know, not one big thing, one big document or model that you create at one point in time and then handle. No, it is something more continuous. Some people call this continuous architecture. And I'll go into a little bit more detail for each of those principles in the coming minutes. The second principle is about focus. What should architects worry about? Well, that should, of course, be what the business needs, right? So business impacts should determine your focus. And what does that mean for architecture? The third principle is about how far into the future you should be planning or designing, right? Classical architects tend to want to have everything as future proof as possible. Basically, they're designing for eternity extreme agilists. They refuse to see further ahead than one sprint or two maybe. And of course, the truth is somewhere in between. And that's what we call just enough anticipation. But how do you calculate what is just enough? We have some tips for that. And then the fourth principle is about who is doing the architecture. And I already said a little bit about that, but architecture in an agile context is teamwork. It is not something that's done by one person with one goal. So just to go into a little bit more elaboration for each of those principles. So this is the traditional involvement of architects in the software world in the digital world, enterprise architects. I tend to talk about architects in the digital world because there's this big continuum of infrastructure architects, software architects, enterprise solution architects, domain architects. Well, I think there's about 50 of those. And I sort of gather them all into this one denominator, talking about architects in the digital world. And this is how what they used to do. They used to be in their own department. And at the beginning of a project, they would deliver architecture guidance, usually in the form of an architecture description document. And that architecture description document, sometimes, by the way, was called an SSDD, which of course is a term out of the systems engineering methodology. But mostly in the Netherlands, what's called the PSA, the project start architecture. And then in other countries, it's mostly the SAD or the systems architecture document or the software architecture document. And that was delivered. And then after a while, then the architects, of course, needed to make sure that the team, the project, was still compliant with the architecture. So I showed it at these checkpoints. Well, this model does not work in an agile context. Agile teams do not accept this type of architecture. They call the architecture guidance, big upfront design, which is a square word in an agile. And then the checkpoints, they call mind your own business, right? We're a self organizing team. So the best architectures emerge from us, right? So we don't need your interference with your checkpoints. So we need to find a different way to involve architects. So basically in the traditional context, architecture used to be a phase, right? A design phase in a project. In an agile context, what you see is architecture is more continuous. And basically, there are little bursts of design and decision making and validation, et cetera, you know, all of the architecture responsibilities that I mentioned. And these bursts are driven by the backlog that the agile organization or team is running. This is a Kanban, which uses, in this case, the swim lanes of shape of the skilled agile framework, but basically an epic goes through a number of swim lanes. It starts in the funnel, then it becomes the backlog. And then there's this analysis, swim lane. And when an epic is in that swim lane, that is where most of the refinement is done, right? And refinement means you're figuring out how to build it, what it's going to cost, what is the best way to do it, basically architecture work, right? That's where the design decisions are made. But because there is this stream of epics, you might wonder what an epic is. You may have heard the term user story. An epic is basically a collection of user stories or, well, it's not really that. It's something that the business needs, basically. And the business keeps on wanting things. And there's this stream of needs that are these yellow sticky notes here. And as the stream is sort of being digested by the team, that's when the epics or the stories or the speeches go through these phases, these swim lanes, I have to say. So basically an epic sometimes behaves as a little project with its own specification, design, build, and test phase. But if you digest them like this, then architecture becomes a continuous discipline. So one of the key things that you need for evolutionary architecture is you need to have short feedback loops. Because when an architecture evolves, when it needs to respond to changing needs, then you cannot afford to have long feedback loops. That will mean that the architecture will lag behind the needs of the business. You actually need to be able to have, you know, to quickly validate, to quickly design, et cetera. And this is one of the reasons, by the way, that we are sort of looking at these decisions rather than at the whole architecture documents, which are too big to have a very quick feedback loop on. So there's basically two feedback loops in architectural design. The first feedback loop is between the design and the stakeholders. And this consists of communication and analysis. And better understanding of the context leads to better design. And then the better understanding of the design by the stakeholders will need to better formulate the needs. So this becomes a virtuous circle if you do it well. And if you can do this in a manner of days, or maybe even hours, rather than weeks or months, which you would need for a big architecture document to be approved and reviewed, et cetera, then that will lead to a quicker feedback loop and then a more agile and higher quality system. And the other feedback loop is between the design and the working system itself. And there the feedback loop consists of, you know, basically trying stuff out or building stuff and then seeing how it works out. So experimenting is allowed there, of course, but you should also analyze the system in production, you know, because there is one, because this is evolutionary architecture. So you should use that knowledge to also improve your design. So in order to speed up that first feedback loop, what we need to do is we need to get away from these big architecture documents. And this is why we focus on the slower entities of the individual architectural decision as your primary deliverable. I'm not saying that there should no longer be architecture descriptions, or SSDDDs or whatever you want to call them, but they are no longer, you know, considered the primary reason or the primary end product of the architecture responsibilities. And that's the decisions. Of course, from time to time, you need to be able to reason about the design and to communicate the design. And for that, you still create documents. But the individual decisions become the primary entity that you work with. And because they're smaller, they allow for a quicker feedback loop. But also you get something else. And that is individual decision time. Now, this is a very important aspect. The timing of an architectural decision is very tricky. Agilists tend to say you need to delay especially the important decisions to the last responsible moment. Or how do you calculate that? Well, this is an attempt to have a formula for that. But basically, the time to make your architectural decision, your big design decision, is at the moment when the risk of making the wrong decision becomes lower than the cost of delaying the decisions. And of course, the risk of the wrong decision becomes smaller and smaller over time because you get more knowledge, right? And the cost of delay, you know, that depends very much on what else depends on that decision or the dependencies on my decision. Like, okay, I need to order hardware. And, you know, if we don't order the hardware now, then in six months, we'll have nothing to run our system on. So you have to decide now because that basically means the cost of delays sharply going up at that point in time. And it's not just ordering hardware, but it's also teams basically not being able to continue if the architectural decisions are not being made. So, and if we go back to that big architecture document, basically what happened was that we were forcing the timing of all the design decisions in that document to be synchronized at the moment of approval of the document. And I don't know if you have, you know, been involved in this kind of stuff. But if we, you know, I certainly have noticed that usually in those documents, there were a lot of decisions that I would rather have delayed by a month or so. You know, it's not that important. There's no real cost of delay for that decision. And a month from now, I can make a better decision. But it still needed to be made because it has to be in the document. Otherwise, the architecture is said to be incomplete. And the business approver says, I don't know what I'm getting. And likewise, there would be decisions that you had already taken two months ago. But nobody acted on it yet because the document had not yet been approved. Right. So that is the cost of sort of synchronizing all of these design decisions in one document. And that's something else that you gain by timing, by looking at these decisions as your primary output rather than the document. Okay. So what does that mean for your architecture documentation? Well, in an evolutionary architecture setting, basically what you get is you get this cycle of making architectural decisions, and I'll say a bit more about that in a minute, which is driven, of course, by what the stakeholders meet. And this architecture work that is done in that cycle leads to two things. It leads to an architectural decision, which is register, which starts empty, oops, and then grows over time. And it leads to architecture knowledge models and other knowledge that you gather during your architecture work. And what you basically need to do is from time to time, these decisions are your primary deliverable, your models are what you use to validate and to communicate your architecture. But from time to time, you need to have a snapshot of your architecture. And this is what you used to use the big architecture documents for to show your stakeholders evidence that their concerns are being addressed. But in evolutionary architecture, that is not the end product, but it's just a snapshot of the situation of the evolution of the architecture at a point in time where they need to make their decisions. And that creates the baseline on which you do change management. And basically, when you say that, you know, the primary output of architecture is decisions, then it becomes this, what we call architecting microcycle, this becomes your workflow, you start by identifying and prioritizing architectural concerns, which is the problems you need to solve, they become your backlog. And then you research possible strategies or tactics, you know, the tools you can use, and you decide on the best fitting one. And that becomes your primary output. But this is a very simple decision making cycle that that is used to make architect decisions. Okay, Alexander, are there any questions up till now? Well, there is a command. Oh, there are many of them, actually, I missed a lot of them. There is a command, if you like, you can react on that. From Hisham Ozafar, in the mechanical field, there is another loop related to procuring prototype, which can be longest lead time. This can greatly influence learning between architectural iterations. Okay, yeah, that's an interesting point. Thanks. Yeah. Yeah, there is actually a discussion in a chat. So I think, yeah, I just opened the chat and I had a look at it. Yeah, if you have further slides, let's just go further. So there are no direct questions. There are no direct questions. Okay. Oh, and now I see the Q&A actually has something. Elaborate on the headless chicken architecture maturity level. Okay. Okay. Well, that is well spotted that I did not mention that. And, okay, I'll, because I have no slide about that, but basically what we noticed is that there's apart from these two, sorry for this Alexander, I'm going back, but apart from these two anti patterns, this is the waterfall waste, and this is the agile Alpec, we also started to see something else, which is organizations that were very mature in the four lowest responsibilities, but we're very poor in understanding context. And this we saw also occurring more and more over, you know, the two or three years that we have been doing this, we have. And what that means is that there is a lack of connection between the architecture function and the stakeholders, you know, that have to tell the architects or tell the teams what they need. And that means that, you know, even though you can be very good at making decisions and modeling and validating in the delivery, if you do not understand context, basically, what you have is a lot of execution power, but little sense of direction. And this seems to be a worsening problem in organizations and, you know, something that can run very fast, but doesn't know where it's going. And it's the headless chicken. Thanks to John Goodwin, one of my colleagues who came up with that name. All right. Okay, let's continue. Let's go to the business impact. So what is the business impact of architecture? Well, it turns out if you really look into that, and there are some people like Mr. Raymond Slott, who wrote his PhD thesis about this. The real business impact of good architecture practices is in risk and cost control. He investigated a large number of projects and he looked at how they applied architecture practices and what the resulting project success factors were. And he noticed quite strong correlations between, you know, applying architecture practices and risk and cost control. So, for example, the projects that did apply architecture practices had an average budget overrun of 3% and the projects that did not apply architecture practices or did them in a worse way had an average budget overrun of 23%. So that's quite a big difference. So basically, you know, architecture is to improve risk and cost control. Those are the main business reasons to do architecture. To put it another way, it's perfectly feasible to do stuff without architecture. You just win a little bit more risks and it's probably going to cost you more. And if you talk about risk and cost control, then you'll quickly get into this visualization of how the risk and cost uncertainty decreases over time. This is called the corner of uncertainty. It is quite an old diagram and it's used to visualize that. And the job of the architecture function basically is to reduce the uncertainty by doing research and by making decisions. And if you shorten your architecture feedback loop, I try to visualize this with these cycles here. You see the shorter cycles allow you to make quicker decisions, better decisions, and then that will be used to have basically a shorter or a quicker reduction in uncertainty. And that's what we're trying to achieve here. One of the main points there is that, you know, it's especially the big decisions that are most helpful in reducing that uncertainty. And you also, there's another reason to make them in the beginning, the big decisions is because every decision you make constrains the decision you have to make later on. And you do not want the low impact decisions to constrain the high impact decisions. And this is why, you know, that's the ordering which you have to make your decisions. I'll quickly move, I see that I'm going through my time quite quickly. So I'll go to the just enough anticipation bit. So how far ahead should we look if we're doing continuous architecture? Well, in order to calculate that, once again, we have to look at business value. And for this, we use this interesting coloring scheme by a guy called Philippe Grusen, he is one of the real heroes in the software architecture world. And basically, what he says is that the stories in your backlog or the features or the epics, they are in two categories, they are, there are visible stories visible to the end users. And these can, these contribute direct business value. But there are also invisible stories. You can call them under the hoot improvements. And the skilled agile framework calls them enablers. Because they, they are, they don't have any business value by themselves. But their business value is indirect by enabling these green stories to be created more quickly, higher quality or whatever. And so this model allows us to reason about the, the business value of these architectural stories. And that's actually quite important. Actually, both of these stories also have a negative counterpart, which is, you know, red for defect. So if there's a visible thing wrong with your system, you have to repair it. And that repair work is a red story. And then there's also stuff in your system, which we call technical debt. And our definition of technical debt is it's work that needs to be done in your system. But it doesn't directly increase the business value. It's an enabler. But as long as you do not do that work, you are paying interest. That's why we call it technical debt. And the interest usually is that you run higher risk, or the team runs is less productive. You know, seemingly very simple green stories take a lot of time because if there's too much technical debt in the system. So by using this framework of colors, so yellow is architecture, architectural components, architectural improvements, green is a new business features, red is bugs, and black is a technical debt. Then that will allow you to in a continuous architecture setting to be very smart about how you want to develop that business value. And what is the right order to do things. And I'll explain that to you, starting with this simple picture, which most of you probably have seen before. This is actually a picture that is associated with the scrum methodology of agile working, right? We have a solution increment basically what, you know, in agile, of course, you almost never create a new solution, but you always create improvements on existing solutions. Those are the solution increments. And these are created by doing work that is in backlogs. Every sprint, this is a sprint cycle, you do work that is in your sprint backlog, and the sprint backlog at the end of every sprint is populated by stories from your bigger solution or product backlog. So what I have done here is I have used these four colors to indicate the type of business value that is in these stories. You also see this strange little curl on top here that symbolizes the daily stand-up meeting and basically the short feedback cycles that you encounter in the scrum team. So where do these stories come from? Well, the black and the yellow stories, the enablers, are usually the result of architectural decisions. And you see here, there is, of course, the architectural decisions, remember the architecture microcycle, they are there to address architectural concerns. Now, where do these architectural concerns come from? Well, they come from the stakeholders that need new user features. And they sort of supply the green and the red stories. And all of that comes together here. And of course, the main problem now is how to prioritize all of these stories in such a way that the yellow and the black stories, even though they do not create direct business value, still get sufficient attention that they are not left behind. Because what happens if you leave all of the black and the yellow stories in here? Well, there are enablers. So that means that some of the green stories will become much harder to build or maybe even impossible to build if the architecture is not there. For example, let me give you one example. A good example of a yellow story in an enterprise architecture setting is an API gateway. So an API gateway is something that no end user will ever see. It is a way to make the data inside your organization's landscape available outside of that organization. That's what an API gateway is for. But by itself, it doesn't have any business value. However, the business value is indirect because it enables, for example, mobile apps and websites that are outside your organization to use the information that is inside your organization. So it's very hard to write a mobile app without an API gateway. So if there's a green story here for a mobile app, it can be done, but it will be a clunky solution and it will be very, very hard to manage in terms of security, information flow, etc., responsibilities, etc., etc. So I hope that example clarifies this a little bit. Okay, so you will have gathered by now that this is mostly about dependencies, right? There are dependencies between the yellow and the green stories. And there's also dependencies with the outside world and the events happening there. So for example, if we hear that a competitor will release a shiny new next generation product, we need to have our product updated with a shiny new feature as well. Otherwise, they will get more market share from us. But maybe that new feature cannot be built if that piece of architecture runway here, that yellow thing is not built first. So this allows us to reason about how this business value comes into being and to basically pay sufficient attention to architecture and to technical debt in our continuous architecture work. So I realize it's a lot of information, but maybe if there are some specific questions, we can talk about that. I only have one principle left, which is architecture's teamwork. That of course is not so hard to explain. In a traditional setting, a waterfall-like setting, it was mostly architecture work that was done by a particular person. In an agile setting, it's less defined than that. Let me explain. So this is a screenshot from the agile manifesto website. If you want to check it, agilemanifesto.org. The best architecture's requirements and designs emerge from self-organizing teams. I've already mentioned this principle. I think this is, well, from my perspective, certainly one of the sentences on that website that has caused most damage. Not because it's wrong, but because it was misunderstood. So people saw the word emerge and they thought that it meant that it magically would happen. As long as we abide with the agile bible, then we don't have to think even about architecture because it will emerge magically. Of course, it doesn't say that at all. This sentence is about responsibilities, about ownership, self-organizing teams. Basically, it already says a little bit that in order to deal with architecture and requirements and designs, you need to spread that responsibility and you need to create ownership with more than one role. Basically, if you look at the classic architecture, a way of doing architecture, you used to produce an architecture document which had hard rules. It basically gave the constraints within which the developers were then allowed to make their own smaller decisions as long as they do not violate the constraints that were set by these red hard rules. Now, in evolutionary architecture, it works differently because if you have this big red piece here which basically puts your architecture in, sets your architecture in stone, then there is no room for evolution. What you need to do is you need to have a more lightweight upfront architecture. That's the red part. Then there should be a lot of gray stuff here which you can say are suggestions, but these are left open and have to evolve. People call this design intent. You are certainly allowed to give the teams multiple options, for example, for making a particular decision. Filling in this gray area here is the joint responsibility of the delivery team and the people doing the architecture. This is the key to the architecture's teamwork thing. It means that in evolutionary architecture, architecture becomes much more a vertical function. What I mean by that is referring to the metaphor of architecture as an elevator. Architecture, just like an elevator in a skyscraper, connects levels. This is an example of connecting levels, the architecture level with the realization level and all the levels in between. How do you do that? I won't go into detail for this slide. There are various styles here. You have the classic architecture, you have the completely crowdsourced architecture where there is no named architect, but there are some useful models in between like architecture marshals and architecture owners that you can use to base your way of working in doing architecture's teamwork on. Here are some references that might be interesting to you. That's basically all the slides I have for now. Let's open the mic for questions. Thank you very much for the presentation. I will start with one hand raised. Matias, thank you for that. There are some questions in the chat room. I will start with a comment on this slide with updated scrum cycle. If you can open it when I read the comment. Tom McDermott writes, that was an excellent slide. Neil Harrison agrees with him, writes, really pulled out a hidden dynamic at work that often makes prioritization feel like a challenging conversation. That's just a comment on that topic. The question which we have is, do you have these green ones, the user features above and the defect below is just a coincidence or that means something? From your point of view, user features are more important than defects or it is not the saying of this slide? No, the position of the colors here is due to this matrix. This is a Boston matrix and basically what is on top here means that it is positive value and the stories at the bottom of this matrix, they represent work to remove negative value. The green is work to add positive value. Red is work to remove negative value, but all of those are visible. This is direct value. On the invisible side, once again, positive indirect value is yellow and the removing indirect negative value is black. Okay, thanks for an answer. We have two options. Dear colleagues, you can send questions and the questions and answers section by text or you can raise your hand. Matthias, I see your hand and now I give you, I think, the opportunity to say something. You can turn your mic on and you can ask the question if you like. You might even turn on your camera if you had one. Yep, so you're technically allowed to turn your mic on, but I cannot do that for you. Okay, meanwhile, when you prepare yourself, just interrupt me when I'm asking for the question. Oh, no, there are no more questions in the queue. There is another one question from an anonymous viewer. Hello, I have a curiosity about how to represent the architecture in the most effective way, but also avoiding excessive documentation. My company, Mechanical Engineering, chose to deliver the architecture of each department only in a graphical form, block diagrams. Afterwards, on the top level, the diagrams are joined and this method actually simplifies the process. How other companies do that? Which are the most common tools representations use it? Yeah, so excellent question. So it depends a little bit on what you mean with architecture. So if you say architecture is decisions, then, you know, but that's not what this refers to. This is very clearly about the modeling, right? Block diagrams are models, right? And if you constrain yourself to only a graphical form using either a tool or some or Visio, you know, you can have more intelligent tools that there are, of course, software architecture modeling languages like UML or Archimate. Then, you know, you can, if you constrain yourself to those models, it becomes harder for your stakeholders to understand the impact. So you need to basically separate this documentation based on the value that's in it. So the model, let me go back to the relevant slide here. It's this one. The block diagrams are in the architecture knowledge repository. But they are probably not fit for consumption by business stakeholders. So you need to make that translation there. And that means that you probably won't get away with just having one style of modeling or one style of communication. You know, just referring back to the architect elevator, you need to translate. You need to speak the language of each level in your organization. And of course, in the engine room, they may be perfectly happy with these block diagrams. But if you go a few levels up towards middle management or even towards the penthouse where the board sits, then you need to make that translation in these views. Does that answer the question? Anonymous attendee, are you happy with that answer? Okay, we'll never know. I do hope I will get a feedback. But meanwhile, yes, thanks. That isn't so good. Another one question. Do architecture models play a role in the workflow presented in the slide 23? If so, which one? It is an important one. Sorry, do what was the architecture models play a role in the workflow presented in slide 23? Yes. But it's hidden. So the models are used to, for example, to help make the bed make the right decisions, right? So the models are, they give input because they help us to validate the decisions that we make, right? And then very often, the models that we make in some form accompany the stories, the architecture runway and the technical death stories, but specifically the architecture runway stories are quite often accompanied by models that will help the team to realize that story. Because they, you know, because they have the model, it makes it easier for them to understand how it should be, should be created. That is the most important place of the models in this, but it's hidden. What's the difference between solution backlog and sprint backlog? Yeah, so the sprint backlog, the solution backlog basically contains all the work that all the stories that stakeholders have asked for. And so that's, and the sprint backlog can never contain more stories than you can do in one sprint. So one, one, let's say two weeks, two week cycle, the sprint is a cycle and it depends on your organization, whether that's one week or two weeks or maybe even six weeks in some organizations, but sprint backlog basically is filled up with stuff that can be done in that one sprint. And the process of picking the right stories, prioritizing the stories in your solution or product backlog and filling up the sprint backlog for the next sprint, that is a very important process because if you do it very naively, you will forget the enablers, you will forget the yellow and the black stories because the role that is usually responsible for this arrow or this gate here is called the product owner role. And you know, one of the first things they learn is whatever you do prioritized by business value. And then lots and lots later, they learn the difference between direct and indirect business value. But by that time, many have already lost interest and then they tell you only do green stories. This actually happened in a lot of organization and can be really harmful. Okay. We have one minute left. Alexander, do you think we can answer one more question? I think, I think we're pretty much done though. There are no questions more. The Matthias, he just wrote the message that he got the answer from I think the another one attendee. Okay. And I think it's the perfect time to retake, make a recap. So I will say thank you again. We have a lot of comments, like people say that that was a great presentation. They say thank you and so on. That is important thing. I say the same thing again. What I will do is, dear colleagues, the recording of this presentation will be available for INCOSE members on INCOSE Connect and for GFSE members on GFSE Internet. Definitely. Some of the webinars are being published for some reason on YouTube channels of both chapters or organizations. I will send you a link in the chat room. We do not have any decision on this specific webinar, but who knows. You can meanwhile subscribe to the YouTube channels of INCOSE and GFSE. And what I will do before we say goodbye to all of you, again, we have further webinars. There is another one next join GFSE INCOSE webinar. You can take a look at that. It could be interesting for you as well. CISML hashtag architected description. And the next INCOSE webinar from the HL systems engineering working group we have, by the way, at INCOSE, the HL systems engineering working group. And I would be really curious if somebody from the working group took part at this webinar because I see a clear interesting collaboration opportunities here. That is really, really interesting stuff. So, nevertheless, I think that was pretty much it. I think you all will be notified by an email about how you will get the recording of that as a member. And I say thank you again. And that was pretty much it from our side. It's I think just in time because I hear the ambulance coming to get you. No, no, no, I think I deny it's always that way here. But thank you. That was about we were about like 130 people at the peak. And that was really great to have you all day. Thank you very much. Thank you, LTV. Thanks for your questions, guys. Okay, bye bye. We see you definitely. Bye.