 I'd like to see so many people and so many familiar faces now that I've been here several days. That's really great, good to be here. This talk is about business value over architecture. And I will, during the talk, also kind of tell you what's the history of that talk, really. Yeah, you see how my contact information slides are actually already up. And you should get them through the website and the app. And well, for the ones who have been here yesterday in the panel, they also know some stuff maybe about me. And I see these are not really good. But well, these are the books that I wrote. So one of my focus is on scaling, agile. So I actually wrote the very first book on that subject matter in 2004, so really long ago. Then also on distributed teams and then retrospectives for organizational change and cost of delay is another topic that I wrote on. However, this is all not really the topic for today. Well, the thing that probably relates most with are the ones on scaling and on distributed. So the thing is, if you are working on a system in an agile way, well, you have some architecture in place. And bear with me, it's a really simple architecture that I used here. It's more like a placeholder that it reminds you, well, there is an architecture for the products we are building for the systems. So it could be like this that we have some user interface, some business logic, and then there is a server part to that. Now, if you work in an agile way, the main difference is that you are not working like you start with the back end, then the business logic, and then the UI. And also, if the architecture would be more complicated, you wouldn't start layer-wise implementing what you want to do, right? I think that's what we all learned in whatever, scrum school or anywhere. So this means for a team to really create a product, it always focuses on slices through the whole system. We agree on that. OK, now one of the things might be, and it might already start with one team, but I think it gets even more difficult if you work with several teams. So given we have several teams now in place and those several teams want to work on the system, so what we are doing, because we all learned that, we slice our system through this way, right? So every team might focus on a specific area and they all have the slice through the whole architecture, which also means once we, when we start working on the system, we start with a very, very tiny slice, which is often very hard to find, right? So the stories also should go through and they should cover the whole architecture and create the architecture bit by bit, if you will. And the reason for that, I think, is also what we all learned. It's, well, we want to create business value. That's the focus of all we are doing. So we want to create the business value as early as possible and that's also how the product owner is steering the team in that direction that we have that business value soon enough. The other thing is that by having those slices, we also can get really good feedback on what we are doing. If we would focus, like, layer-wise, the feedback we are getting, well, is for a long, long time only technically. So we will never know really what the users are saying with that, what the stakeholders think about this. Also, integration is kind of an issue at that point when we go layer-wise, so it's really getting really good feedback that helps us to create a better product. The last thing, which is also very important, is by doing it this way, we want to create earlier return on investment. So even if we are not done with the whole product, we might be able to sell the product once we have, like, that slice done, right? So it might be the case that we can actually sell what we are having after three months or maybe even earlier, and we don't have to wait all the, whatever, say, five years if it's really a big product till we are done with everything. So that's also what we all hope that Agile really brings us. And maybe I also have to put it in the other way around because sometimes people think that Agile makes us faster and maybe it does, but I think the main thing it really does, it gives us that opportunity to go to the market faster. So building the whole stuff might take the same amount of time, but going to the market will be faster. Okay, so I think we all agreed on this kind of, at least I see some people kind of in agreement, or I take it for agreement. Now the thing is, what happens to me when I work with my clients that everyone's in a while, people ask me, okay, now, so these are my clients. So what about the architecture? And I give the typical consultant the answer, well, it depends, right? So this is the answer we all love the most because it's always true. And it really depends. And now this is kind of now the history of this talk in a short way. It, I thought I really wanna get a grip on what does it depend on? So I wanted to explain what are all those things that coming together that drive the architecture in a specific way, or that help us to support and maintain or build the architecture really. And not losing focus of things like conceptual integrity or so, just because we are focusing on business value only, because if we are only focusing on business value, well, maybe there comes a time where we are not able to do that anymore because the architecture is a complete mess. Yeah, and I guess some people have seen it and others might have feared it. So now coming to the point, what does it depend on really? The first access I wanna look, well, the one thing that I always say, well, it depends on the complexity. Now complexity is still something that's not really, you can't get your hands on really. So what does it really mean that something is complex? So the one thing that I look at when I look at complexity in that sense here is that's the y-axis. What is our rate of changes that we are seeing? So down here, in case you can't read it in the back, down here it's we have only a few changes in our system or we have many changes in our system. So this is one way of looking at it. And then on the x-axis, we have the uncertainty. So low uncertainty or high uncertainty, which means, well, are we creating something with the technology we have never seen and we are really uncertain about that and we don't really know what to do with it. So we also need to run some maybe proof of concept, experiments, whatever. Or we are using that for a long, long time so it's a no brainer for us working with that stuff because that's what we used to do. And similarly with the rate of changes, is this something where we will get and maybe also expect a lot of changes because maybe it could be from the architecture side but it could also be from the business side that the customer doesn't really know what they want. Well, this is how we know our customers anyway, right? And so they explore with us the possibility of the product and therefore with those changes, the product will evolve. And the more changes we see, that well, they will have an influence and what kind of influence I wanna look at this now. So remember, we had those teams that were focusing on the business value, right? So this is how we started with. And now when we look at now from the technical point of view or the systemic point of view of what we are building, the product, then we see that in this lower corner meaning we only have a few changes and we are quite certain about the technology we are using then we can talk about a system that's pretty stable. It's not really complex. Very often it's also a system that we are maintaining, right, so it's just we know most of it and there comes a change every once in a while and so that's fine. Then at the other extreme, so we don't really know what we are using here, we have to learn as we go and also the customer learns with us which means the system we are building is highly complex and pretty unstable because of the changes, because of our learning that's going on and so this is where we are. And then there's this big field in between which is called adapting. Now, again, my question was at the beginning, well, how do we support the architecture? Now we are getting really there. It depends in which area we are in. This leads us into how we can create, support, maintain the architecture and well, this picture will get over by more and more complex as well or maybe confusing. So if we stick with the lower corner, so we have a stable and complex area so we know what we are doing, few changes and so on. So there are typical two ways of, if we are working especially with more teams, two ways of how we create, maintain, well most often it's more maintaining thing, the architecture and the two ways are having a chief architect who's kind of knowing where we are heading and ensuring that whatever we are doing is not breaking stuff or we have a community of practice. So this can look like this. So the chief architect, we have our three teams that was the example how I started. The chief architect ensure that whatever those different feature teams are doing is not conflicting, not breaking the system that we are still coherent, conceptual integrity is still there in the system and all of that. So advising on what's going on. The other possibility as I mentioned is the community of practice. And the community of practice just means that from every business or feature team we have like one person and it must not be the same one all the time. It's just you could also say like in this friend it's whoever who has the head on that and one person responsible for architectural or technological issues. And so they kind of get together every once in a while when there is for example a change that we need to make or if there is some uncertainty in the technology that we are seeing here. And then they are getting together and figure out how to solve that and then it will be solved in the respective teams. Maybe all of them, maybe it's only one team that's impacted by that here so far. So these are two possibilities which I see in like stable and complex environments. And if you're working with one team only even then it could mean like you have one of the guys that would be the maybe the chief architect or you have like roles that are passed through that are rotating but you have like people having a head on it so that's a typical thing at least. Okay so then we are looking at the other extreme. Now we are looking at the extreme where it's absolutely unstable, highly complex meaning we have a lot of changes and we don't really understand the technology much. So the thing that I found especially in large and maybe also distributed settings is that it's most helpful to have something that I like to call a technical service team. And the thing that I find really important is service. And the thing how this works is basically like that. So we have still our three teams here and those three teams they formulate their, well you could also say stories or requests they are having towards the architecture. And those stories or requests are coming based on the features they are developing. So remember they were like looking at their slides through the system they are driven by the product owners creating product owner to create as high a business value as possible all of that. And then they figure well in order to create that business value we need X from the architecture because it doesn't support that. And so they are basically filling a product backlog or you could also say just a backlog without product more a technical backlog for that team that calls and that's the one up there the upper right corner for the team that I call a technical service team. And I mentioned already that I think the service is really the important thing because some people might have seen that before maybe also in the old world and that was what has been called an architectural team. Well the way I saw architectural teams in like the classic role they were more sitting on ivory tower and thinking about some kind of weird concepts and throwing it through the diverse teams and they had to adhere to those concepts and they wrote their eyes and were saying well this is not helping us we are not getting anywhere and it's those us down and all of that. So here it's on the one hand really the other way around because that technical service team provides a service to all the feature teams. So it's more the feature teams driving what that technical service team is doing and not as it was kind of in the old world where the architectural team drove what the like business features whatever teams were doing right. So it's upside down. And it's clearly that those feature teams are well filling the backlog and prioritizing that. And there are then again also a few things you can think of. So sometimes if it's more like a small setting like these three maybe it's good enough just the way I have scribbled it here that they get together and decide on the priorities but maybe you really wanna have also an equivalent as a product owner for the technical service team which would be somebody the feature teams trusting because that should be a person making the decisions on the backlog in the way they really need it the most, right. So they yeah they are actually if you put it that way the feature teams are actually the customer of that technical service team. Makes sense. Okay, time is passing really quickly. And then we have adapting. That's the last part. It's the technical consulting team where they call there and it really is something that sits in between and really just like that. So technical consulting team means well you have more or less a pool of people and yeah a pool of people and those people are supporting the respective feature team as needed. So if for example this team up there, well in this picture I use that team down there but you don't see it that good. So I'm still I'm using this team here. Figures that we really need support in terms of the architecture because we are like in an uncertain field where we don't really know what's going on. So then for a given spring somebody is working with the team on that issue. So they're also developing. So just like a regular whatever developer but they're also mentoring the whole team that they understand what's going on there and ensuring the coherence of that. So that's the intermediate state here. So the technical consulting team. And now I said this picture gets messier or more confusing maybe over time or more complex I said. So the thing that I'm seeing very often this is something that's related to time as well. Because when you are starting a new product very often things are fuzzy and you might really explore also a new technology and you are exploring the business together with the customer. So you are in this upper right corner and things are really complex chaotic and you are like constantly changing things. So there you might have the need of the technical service team. But then when things are moving forward and smoothing down well the uncertainty gets less the changes get fewer well and you know what kind of changes are coming you can handle it much better. Then sometimes it's the case that the technical service team or some of them turn into the technical consulting team so being that pool for the different team. And then times passing further then you are in the stable world and you might have well none of kind of the architects anymore because they all got into incorporated in those different feature teams until you have only a community of practice and that's wonderful. Or maybe you decide well in our case it would be good to have a chief architect because you have across different products you wanna have like a product line and so they are cooperating with other architects from other products whatever so that maybe again a depends thing right. So what's your decision on chief architect or the community of practice? So that's really the messy thing and it is my answer to this well what do I mean if I say well creating and supporting the architecture depends and well then it looks like that you have all those different options and there is not a one thing that's true there's just something where are we at with our system and sometimes what might be helpful is maybe you wanna do with the rate of changes and uncertainty I've done that also like putting it on the floor and people stand where they think they are with the system and that might tell you something how you should set up the way you are working here in order to still be able to deliver the business value because that's still the most important thing but if the architecture is not supporting it we can't do this anymore so it still has the same motivation as before but we need some support for the architecture and I think I'm out of time here and I'm done so thank you very much and yeah I have like of my two books over there I have a discount on Lean Part if you have that link with Agile India so maybe if you're interested so thank you I'm not sure I guess we don't have time for questions I guess well yeah it's lunch time but the people are hungry you have a question yeah so how do we insert them that the technical service team also tears to a timeline actually the way we are setting it up always it's they're running in the same rhythm so they also have a sprint they commit to what their clients are asking them which are the feature teams and they're really we are doing it just the same way it's only their clients are if you will more technical it's not like the end customer stakeholders anything like that but it's the feature team yeah so how do we in an unstable world how do we do what ah so okay so the thing is that feature teams request that they need this and that in order to implement their stories and so the technical service team has to figure out what to do in that case and so the thing is sometimes they can just start doing it sometimes it's more at least that again that's my favorite approach I then advise them more to look for a time box that they experiment with something then report back and if it's working maybe it's the right way and if not they run the next experiment but we time box how long we are experimenting with something it's actually in the good old I think XP world that was also something that has been called a spike so where we just well in the old world on the other hand waterfall you would call it probably more proof of concept or something so just like that but time box it because otherwise people will explore forever yeah right good question thank you okay thank you