 Mark Langhorst is the managing consultant and chief technology evangelist at BizDesign. Mark is responsible for BizDesign's vision, market development, consulting and coaching on digital business design and enterprise architecture, and for spreading the word on the Archimate language for enterprise architecture modelling, something he does all over the world when he's allowed to travel there and virtually when he's not. The open group standard of which he has managed the development is of course Archimate. Mark's expertise and interests range from enterprise and business architecture to service orientation, agile methods and digital business design. Welcome from the open group or welcome back from the open group to Mark Langhorst. Right, so I'm going to speak about a new guide just published this week by the open group on agile architecture modelling using the Archimate language you need. This has been a joint effort from both the Archimate forum and the architecture forum. People from both forums have been involved in developing this. And since this day is about agile architecture, this is a fitting part of that. I'll just give you a brief introduction to that guide. It is also going to be an evolving document in the spirit of agile. We want to iterate and evolve this based on your feedback, of course. So please feel free to send us your input later on. So, well, this was basic, Steve introduced, no need to go into that in more detail. But this is the agenda of my talk for today. It's just a brief introduction to that guide. I want to start with why architecture modelling is relevant in the context of agile. Then I will show a number of ways in which you can use these models basically modelling the why, what and how that agile team or agile teams are involved in. Also using models to support communications collaboration between teams because that's one of the main reasons why architecture is so important in agile to make sure that you're all moving in the same direction. And we'll also talk about creating architecture models in an agile way itself since you don't want to do all your modelling up front, create huge big models and hand them over to your agile teams that's not the way to go. But I know I'll draw some conclusions. So let's dig in. Why did we develop this guide and why is agile modelling important? So we want to provide guidance to any architects involved in agile projects, agile software development or in a broader sense, on why these models are valuable and how you can use them. So this is the combination of these that we're going to address in this presentation and in this guide. And of course there's a lot to be said about architecture in general in an agile context and I'm not going to go in detail there. That has been addressed earlier today and in other open productions. At the end of the presentation I have a few links to those but probably you've seen some of those already. But in short, it is necessary to do architecture in an agile context as well to have this shared understanding of where you're moving as a group of collaborating teams as an enterprise. And one of the main things is that there's all the dependencies between the bits and pieces that have to move in the same direction. That could be in software, that could be in a broader sense, your business processes, your capabilities, all the bits and pieces that constitute that enterprise. How do you manage those dependencies? And the third area is balancing short and long term results. One of the criticisms against agile is often that it's focused on the short term only, what the user wants today. But of course you also have to have a longer term picture in mind and that's where architecture also comes in. And some define architecture as the stuff that is difficult and expensive to change later. The things that are very deep into the structure of your systems, the structure of your enterprise. The things that are not so easy to change later on when your focus changes, your direction changes, because you're agile and you need to change with external inputs. But if you make the wrong choice in your architecture, that could harm you later on. So you don't want to paint yourself into a corner. That's why good architecture is really important and why archimage as the language can help you there. Now the benefits of architecture models are numerous. And here I've specifically highlighted a number of things that are relevant from an agile perspective and in more general sense. But these are benefits that focus specifically on things that you see in agile companies. For example, you want to convey the vision and the business intent to agile teams so that they know where their bit fits into the grand scheme of things. You want to trace from your stakeholders to the implementation. How are certain requirements from these users from each other's stakeholders implemented? What's the prioritization of those, for instance? You want to make sure that your teams have a coherent view of what's around them. It's not just about what you're building as a team. It's also very much about how that connects to the broader world. And that relates to these dependencies as well. How do you manage these dependencies? I'll have more to say about that later on. Because that's often a large issue in agile teams. You have all these different teams building all their specific results. But then there's also spaghetti in between and you don't want that. Technical and architecture debt is also one of the things you can manage using these models. What you often see is that agile teams want to move fast. And they say, well, let's cut this corner because we need to deliver to the customer right now. And we'll fix that issue later. It might be an architecture choice that's not so great. It might be a technical problem there. But you need to keep track of that. You need to fix that later indeed. And you need to record somewhere that you did this. Well, you make this shortcut. Non-functional is also an important area that you need to address. And in agile, if you look at, for example, product owners in the natural context, they are often very much focused on the functional side of things. This application needs to do that and that for our users. But the non-functionals are equally important. And especially in agile context, the maintainability and flexibility of your solutions. So architects are very much focused on creating things that are agile. It's not just about the agile process. It's also about the agile end result. And that's part of those non-functionals. And then when you're going to deploy things in, say, the DevOps world, knowing how bits fit together and what could go wrong, how to create test scenarios above the level of unit testing that these individual agile teams do, but when you have to test a larger set of things that need to operate together and identifying root causes of issues is related to that, of course. If something goes wrong in operations, how are these things working together? So if a DevOps team needs to trace what the cause was of some problem, architecture models can also be very useful. Now moving on, I mentioned models to improve enterprise agility. The use of models to identify and reduce complexity. That's basically what that is about. Because complexity is the main enemy of agility. If things are really complicated, if everything is connected to everything else, then change is just really difficult. If you don't know what happens, if you change something, or if you have to make lots and lots of other changes because of non-local impacts of your change, then you are really not agile. Managing these dependencies, that's really what these enterprise architecture models can help with. So basically keeping the bits together, and this is not the solution. Often, if you look at larger organizations doing agile, often you see that they have more than just agile teams. They have a whole structure around that. Maybe they are using something like the scaled agile framework with their PI meetings, etc. PI planning is one of the main ceremonies there. But it's very difficult to keep track of the dependencies between what all these different agile teams are doing. For example, where you have all these sticky notes on the wall, you could say different springboards, and then using pieces of RedString to identify which user stories depend on each other. This is of course not really a good way to manage dependencies in a larger organization. Things fall down on the floor, you can't easily share this. It's just a mess and it's not the right way to do things. This is where models can really be very useful. Now, of course, you can talk about which concepts to use in an agile context, which argument concepts fit in there. I don't want to take you through the details of this picture. Actually, I have one that nicely builds. Now you see it all at once that might be a bit too much. But just to highlight a few areas, we have stakeholders that have certain needs. Strategic themes identify where the enterprise wants to go in terms of its courses of action. These strategic themes can be decomposed, elaborated in terms of ethics, features, and eventually stories, like user stories, that are put on the backlog at different levels of your agile development. You can be planned out in Archimedes. This is the plateau concept that plans things in time, and then actual stuff is going to be designed and built. This is just a small bit of some Archimedes core concepts that express what you're actually going to develop. You could even go as far as expressing who is going to do that and what's the work that you want to do. That might be taking it a bit too far, but you could even express the organization of your teams and the different roles in agile in an Archimedes model. Now, let's not go too deep, but you get the idea that you can map different areas of agile development on different terms in Archimedes and then use those concepts to model things like the stories or the features you're developing, the application services, the capability that you're improving, et cetera. So that's quite a nice fit, and you might want to look at the document itself to guide you to see more detail about how this is involved. Now, just to give you some concrete examples of that, here we start with a model of the architecture intent, the why, the reasoning behind the architecture. And this is from an example that some of you might know, the arch-insurance example model that we've used across many years in many different contexts to explain Archimedes. And here we see Arch-Insurance as a company where its profitability is the main driver of the board and they see that there are some concerns there. There are some issues. They see profitability go down for certain reasons and they want to do something about that, defining a strategy that they call their digital customer intimacy strategy that has two parts. They want to be in close contact with their customers via digital channels like social media, and they want to gain a better insight in the customer situation by harvesting all kinds of data from digital channels, from digital sources. Now, that's a high-level picture, but there's much more to it than that, of course. These new capabilities they envisage require certain resources. So that's trailing down from that why into the what. So here we see new capabilities in the context of the larger set of capabilities of Arch-Insurance. And we see some resources still at a very high level that are needed for this. So for instance, this digital channel management requires things like social media apps or staff with the right competencies to manage that. And you see that for that data-driven insurance part as well. So high-level picture of the resources needed. And then we can drill down a bit more. We see the same resources here, and we see some relationships between them. For example, that data sources provide insights in customer behavior, that there's data analysis automation needed then to come up with sensible customer profiles, that then goes into the integrated backup automation, and we see a number of requirements that are posed on these high-level resources. Of course, this is a demonstration model, so it's much more, well, it's much simplified compared to a real-life situation. But you get the idea. In Arch-Image, you can express things at a very high level without immediately going down into the details of the implementation. That's basically the responsibility of the agile teams. So we're still talking about the what, but it is a bit more detailed, more about what kind of requirements we need to satisfy. So these could be certain, well, if we drill down from here, these could be certain user stories that we need to support for that policy automation. So that would be a further elaboration of this part. Now, continuing, we can look how those resources are then going to be implemented. So for example, the staff with social media competency that has to come from our customer service team. And maybe the social media apps, well, Arch-Assurance is going to develop its own mobile app for that. I'm not saying that that's here, but it's going to develop their own app to communicate with customers. These data sources come from various connected devices. One example, I know several auto insurance companies that provide you with a black box in your car that monitors your driving behavior. And if you don't take too quickly, if you don't break too abruptly, etc., you get a discount on your insurance policy. So that's an example of such a device harvesting data that the insurance company needs. Now, those are still pretty high-level pictures we can drill down further. We can look at how this is then going to be implemented. So here we see the Arch-Assurance back office suite and the services it provides and some of the infrastructure it runs on. But still, this is not very detailed. It's still, in an agile context, the details are left to the individual teams. But this gives them the context of what they're doing. So if you're in an agile team developing certain services on the back office suite or if you're responsible for, say, the DevOps part, knowing how this is going to be deployed on the infrastructure, you can use these models to convey how the bits fit together. And it's all traced back to these requirements and from there back to the high-level pictures. So you have the full stack of models all connected. That's just an example. Of course, it's a toy example, but the ideas are there. There are some things you need to think about in supporting your collaborating teams and models. Conway's law is something that's quite relevant there. The structure of your organization is often something that determines the structure of the design. The structure of the architecture is often dependent on the structure of your teams because of the communication between these teams and if you have lots of communication between two teams, that's often inefficient. And then to avoid that, they split up the work so that they can work a bit more in isolation. So the influence of the structure of your teams on the structure of your architecture is very important. Now, Archime doesn't make a choice in that. You could have component teams and feature teams. Feature teams more aligned along these requirements. Component teams align more along the structure of what you're building. And you see common modeling approaches that work in both directions. So either can work. I don't want to go into too much detail here, but it is explained in the guide how you can use these different approaches. Now, using another example model, this is an anonymized model from a real customer case just to show you how you could also use these models. Here we see an application landscape with all kinds of flows between them, and you can see how you can use these models. One thing you can project on that is, if my slide will show, is what the impact of a certain feature might be. And in this case, it might be a bit difficult to see, but the feature was about adding smart forms to the website that would use certain information from the back office. So here we see insurance back office applications, and some flows are impacted. The website itself is impacted. So that's the feature. Then in the next slide, we will see which teams are responsible for which parts of the landscape. And in this case, they have a kind of component team like structure, basically DevOps teams responsible for keeping these systems in the air. And you see with color coding, which teams are responsible for which parts. And if we would combine both pictures in one, then we could easily see who needs to collaborate. The two teams responsible for these bits. Then we have this relationship to the financial system. So there might be some collaboration with that team as well. So to help identify where the dependencies are, these models are also very useful. This helps teams identify what their connections should be. Now there are other ways of using models in an agile context. There are all kinds of so-called agile ceremonies that you could support. For example, PI planning might be a useful ceremony where you want to do some high-level planning on what needs to be developed and who's going to do that, who's responsible. So on the left, we see an example actually from Robert East. He was also in the call showing how and what needs to be developed. On the right, we see a different kind of model. This is from an event storming workshop. So you see lots of business events and some remarks about that. Identifying relevant events and how they are going to be handled. Again, using models to log that information is much more practical than just putting things on sticky notes and sticking them on the wall and seeing them fall down again. This makes it more persistent and shareable. And certainly in the current times of COVID, with everybody working from home, physical sticky notes are not the way to go anymore. So we do have to have some support there anyway. So why not do it in a proper architecture model? Then I mentioned at the start that I also wanted to talk a bit about creating models in an agile way because it's not just about using models in an agile context for agile teams, but also the way in which you create them. And one of the things that's important here is that if you look further into the future, your models cannot be as detailed as when you model something that's going to be built tomorrow. So higher level models, maybe just using some motivation concepts are useful when you look at the logger term. And the closer you come, the more concrete your models will become. So for example, if you need to model an architectural runway, you will add more detail there. If you're focused on a specific solution that's going to be built in the coming weeks, well, you might need even more detail. And most importantly, you want to model just in time. You want to stay one step ahead of the teams that are going to use your models, but you don't want to model 10 steps ahead of the teams. The world will evolve faster than you can keep track of with all your models, so you don't want to model too much ahead of time. Then talking about what to model, one of the common questions is also, what's the right level of detail of my models? And I think the question supposes something that's actually not there. There is no single right level detail. You always need to identify where you need the most detail based on things like what's the risk associated? Say, if you're spending a lot of money, you might want to add more detail to make sure that you're not making the wrong choice in, say, buying a new system. Or if there are sensitive personal data involved, you might need more detail to know exactly what data is used where. Otherwise, you might, well, it might be a liability to certain findings or data breaches that harm your reputation. So risk is a good way of looking at where you need the details in your models. But at the front, you need to iterate like any agile practitioner. You need to iterate to find your right levels of detail, the right things to model. You don't always know that at the front, but you harvest the feedback and more detail where needed. Maybe take detail out if it wasn't needed in an agile manner. So in conclusion, the architecture models in Archimates are very useful also in an agile context. In general, of course, it's important in agile. Doing architecture in an agile way is important, but models really help to become more agile as an enterprise because they help you identify complexity, reduce that complexity, manage the architectural debt. They help in conveying the vision to the different people involved help prioritize what users find most important and then make sure that the agile teams are aligned and perhaps most importantly these models help these teams collaborate because they show how the connections are made what the dependencies are so it helps them in aligning their work making sure that they all are moving in the same direction. So architecture models are certainly very useful in an agile context can be used in all kinds of ways and of course the open group does a lot of work on agile in general so I've collected a number of links here the first link is to that new guide I've just published a few days ago this is the document I've just outlined but there's more to be had and these are just some examples of agile documents and also agile initiatives if you remember the open group of either the Archiment or the Architecture Forum you can join these working groups mentioned at the end. So that concludes my presentation and perhaps there are questions or maybe we want to move questions into the panel I don't know what to do with that Steve Yes Mark I think thank you very much for that it's a very fluent and comprehensive overview and we will I think take the questions in the panel but in the meantime a warm virtual round of applause for Mark Langhorst. Thank you Mark