 Warm welcome, please, for Mark Lancoste. Welcome, Mike. Yes, thank you, Steve. Somehow this started with the father of Archimete, and then it became the godfather and then the grandfather. I don't know what that is, but it goes from bad to worse, I think. So, yeah. In the program, you might not have seen the exact title I have on screen right now, because we were not allowed to mention Archimate 3.1 until a few weeks ago. But now that the release is official, you can see. This is about Archimate 3.1. My presentation will not be about the details of the changes in the new version. Tomorrow, in the Archimate User Group, I will be speaking more about that. But I will demonstrate the use of one particular addition to the language, the value stream concept, but you will see that in my presentation. But the main body of the presentation is about the use of Archimate for business architecture, which is one of the reasons we did put out this new version 3.1. It was also the reason already behind 3.0 adding concepts for business architecture. But it's mostly about the practical use of the language for that purpose. Right. Well, I think Steve already introduced me, so this is me if you want to send me an email or call me, you can find me there. About business design, click, click. So, business design software company. We provide a platform that helps organizations design and change their business. Enterprise architecture is a big part of that. And I think we have a lot of architects in the room, other kinds of models we do as well. Then the one slide we're most proud of, that's this one, Gartner's Magic Quadrants that recently came out. We are way up there. So that's for the commercial break into the content of the presentation itself. So, let's start with a bit of motivation for business architecture. Why do we want to have this? Why is this important? Actually, if you look at enterprise architecture, it should already do business architecture. If you look at the scope of that, business architecture should be a big part of that. But if you look at how enterprise architecture is done in practice, often you see that it is still rather IT focused. It's rather enterprise IT architecture. And the business comes kind of second. It's the parts of the organization that influence IT that many architects find most important. And you even see that in Togav. I think Togav 9.2 is already better than 9.1. But you see that it is centered around IT development. But what's the business of the business? How do you design that? That's where business architecture comes in as kind of an adjacent discipline to enterprise architecture. It has some overlaps. But depending on where you stand, it's an addition or it's a part of enterprise architecture. That discusses how the business operates independent from the details of the implementation. So it's really about what the business does. And you really need this to translate your business strategy into action. You need this line of sight from where do we want to go and how are we going to do that? What I also see is a shift in focus in the enterprise architecture discipline. Partially because IT architecture is more and more something that's done for you as an enterprise architect. Commercial of the shelf software has its own architecture. You don't influence that. Agile teams do the software architecture part. You're not in charge of that as an enterprise or a solution architect often. Infrastructure increasingly runs in the cloud. You don't own that. Well, if you do an ER platform stuff, you still need to do some work there. But things are moving. So I see EA shifting on the one hand towards business architecture, sort of up in the stack, and on the other hand towards integration. Well, this presentation is not really that much about integration, but I think that's the other bit that is increasingly important for architects, integrating stuff. You no longer design all your own software, but you have to integrate everything. But today's more about business architecture. And then you get the discussion of how do we implement our strategy? How do my business and IT solutions support that? How can I improve my capabilities to be prepared for the future? What do my customers need? So all sorts of reasons why you have to have this business focus on your architecture. So then into the argument language and where we stand today and what it can do for supporting you with business architecture. It doesn't... Okay, argument, the language. I mocked up the cover of the standard, by the way. I don't know if it really looks that way, but I just changed the number. I haven't seen the physical copy yet. Andrew, do you know, does it look like this? Because all the others did look like this. No. Oh, well, I need a new picture then. So what does argument offer? What is it? Well, it's a language. It's a way of expressing architectures. It's like natural language. You talk argument. Well, sometimes I joke that a colleague of mine, Henk Jonkers, and I are the only native speakers of argument, because we are the only two left from the original project that are still working on the language. But it is a language. And it has a framework to organize the concept of language. So the argument framework is just there to organize that. It has its own graphical notation, but it's also important to create your own visualizations of models for different stakeholder groups. We'll see more about that when we discuss actual examples. But of course, we need a standard way of describing it for, let's say, our peers, the other architects, other stakeholder groups might need different visualizations there, but that's what argument also talks about. You can't standardize all these different visualizations, but the standard does discuss this notion of having views of two points and how you could create those based on the same underlying models. And it's, of course, an open standard maintained by the open group. So how do we position argument? And first, let's position business architecture. And here, I've drawn some sort of range from design and implementation really at the bottom. Does it point? No? So we've got this range of design and implementation at the bottom to high-level strategy at the top. Solution architecture sits, let's say, above design and implementation. On top of that is enterprise architecture, and at the very top, we have the strategic direction of the enterprise. And you have all kinds of models in this world. At the top, we talk about financial models and risk models and maybe your business model expressed in, say, your business model canvas or balance scorecards, swath analysis, et cetera. At the bottom, you have all these implementation-oriented models, say, UML for software or BPMM for your processes. Now, Archimade has a language that covers parts of that. But first, let's position business architecture in here if it wants to zap. Yeah, there we are. So, like I said, it is part of enterprise architecture. On top of enterprise architecture, it's partially into this strategy domain. I don't know what it's doing, but somehow it gets stuck. Now, we have business architecture. Archimade covers that and more somewhat towards solution architecture, somewhat into the strategy domain. You cannot really draw a fixed boundary. Of course, whether something is still enterprise architecture or solution architecture is somewhat arbitrary. Whether something is business architecture or strategy is somewhat arbitrary. So Archimade covers that middle ground, helps you bridge between that high-level strategy and the lower-level solution and implementation. Now, let's discuss some of the concepts for business architecture. There are lots of concepts in Archimade, but not all are equally relevant. So I want to highlight a few concepts that are particularly useful and important in modeling your business architecture. And then I would specifically think of the motivation elements in Archimade, and some of them, not all of them, but some of them, and I'll show more of that later. So the reasons behind your architecture. Why do you want to have it like this? Why do you want to go in that direction? What's the need of the stakeholders? What are the drivers of the enterprise? Why do you want to take it? The strategy elements, those were added in Archimade version three, and those of you who know Archimade will probably use the so-called capability concept, but there are a few others. Now we have the implementation and migration elements that tell you how to get from A to B. So how do you plan your changes? What's the work that's needed to implement them? And, of course, you also have all these core elements that sit in between, let's say, the strategy and the implementation and migration, all the central parts of the architecture. That's, well, you could say traditional enterprise architecture, the core bits of it, which is actually the oldest part of the Archimade language. I don't want to go into that too much today. I want to focus on these other elements. But, of course, if you do a full stack of architecture from strategy to implementation, you will need these core elements as well. We will see some of them, but I want to focus on these other bits. So first, which of the motivation elements would be most relevant for modeling your business architecture? And these are not all of them, but I would say these are the highlights. These are the things that you really need as a business architect. Of course, starting with your stakeholders. Who are you doing this for? Who are your customers? Who are the internal stakeholders? Your management? Your employees? Maybe external parties like regulators? Very important. Anybody who has an interest in the effects of your architecture can be a stakeholder. Then we have what motivates change in the organization, the drivers behind change. And that can be the concerns of your stakeholders. There might also be other drivers that are more generic, say, the economic situation or new regulation. It's not always tied to one specific stakeholder. But drivers are very important. Now, a driver in itself doesn't say anything about whether you're doing well or not, whether change needs to happen. It just says, this is what I find important. So say for a CFO, profitability is an important driver for the organization. It doesn't say profit is high or low or should be improved or whatever. It just says profitability is important. Then we have the assessment concept with this little looking glass as its symbol. And that says looking at the enterprise from the perspective of a driver, how are we doing? So is profit good or bad? Are we, say, compliant with regulation or not? That's the assessment. Then based on an assessment, you can start formulating your goals. Well, if everything's fine, of course you don't need to change anything, sell them the case. That's why we architects are always very busy. There are lots of goals that we need to achieve. That gives you direction. Where do we need to go? What do we want to have? And of course you can do that at all kinds of detail. You can have your high-level strategic goals and then drill down into more detailed goals. Now next to goals, you might also want to model the actual outcomes you get or expect to get. Or maybe you want to prevent some outcomes from happening. That's why we have the outcome concept. It shows this dart stuck in the bullseye. That's, of course, what you'd like to have, an outcome that really is in line with the goals you've set yourself, but that's not always the case. So it is important that you can also model the outcomes and see the difference between your goals, with your goals. And finally, and we will see that later on when I introduce the one new concept in Archive 3.1, the concept of value. The value produced by the enterprise for different stakeholders. And that can be monetary value. It can just be about money, but it can be about all kinds of things. It can be about, say, efficiency, or it can be about usability, or all sorts of things that different stakeholders might find important, the value you produce. Now next to these motivation elements, we have the strategy elements. If the thing wants to zap, yeah, there we are. And here we have this one new concept, and I'll get to that. The course of action. That gives you the strategic direction and the plan of the enterprise. Where do you want to go? What are you going to do to achieve your goals? So basically how am I going to use my capabilities and resources to get to where I want to be? Then we have the concept of capability. That's probably the most popular addition we did in Archive 3.0. Capability maps. Who in the room is using capability maps? Yeah, that's quite a large number. I just recently did some statistics. Actually, yesterday I did some statistics on a number of large clients of ours just counting which concepts they use the most. Well, of course, application component was number one, business process was number two, but capability was in the top 10. It is a very popular concept. Capability maps can be useful for all kinds of reasons, and I'll show more of that later. Now we have the concept of resource. The capabilities, which represent what you're able to do, you can say the resources are the assets you have. Just looking at capabilities is not enough. Unfortunately, some of the business architecture methods out there, some of you might know the Bishbok, don't really recognize this as a perspective. Just focus on capabilities. But take, for example, say you're in a mining company and you have excellent mining capabilities, but you don't have a mine problem. So resources are quite important. And then there is this one new addition in Archiment 3.1 called Value Stream. And a Value Stream represents the sequence of activities that an organization does at a high level of abstraction to produce value. What are the steps, the stages in the value production of the enterprise, where capabilities are kind of the organization at rest, the Value Streams model the organization in motion. And of course, for the different stages in your Value Stream, you will need different capabilities, and we will see that later. And Value Streams are not to be confused with business processes because they are not about the individual tasks that you execute to produce a specific product. This is about the higher level overall value creation, but they will be realized by business processes. Tomorrow in the Archimate User Group, I will discuss this in more detail. And also the other changes in the Archimates to 3.1 release. Today, this is the one new thing that I will show. Then I mentioned the implementation and migration elements. And specifically out of that set of elements, I think two are most important. Work package has a concept for representing the work you do to change something. That could be, say, a project or program, or the work of agile teams, or whatever you do to create something new. And plateaus that help you model things like roadmaps, the stable stages of your architecture, the stages in which it evolves for planning purposes. So those two concepts out of the implementation and migration elements, those are the ones that are most relevant for business architecture in my perspective. We have a few more, but these are the things that I typically use and I see others use as well. So if we add up these concepts, that gives you this line of sight from your high level goals that comes via the courses of action you've planned to change the world through your capabilities, resources, the core of the architecture and the change initiatives. That is this line of sight from strategy to realization. That helps organizations really focus on what's important. Now one caveat in using Archimade, of course, if you have seen Archimade as a language, it's similar to what we see in other languages like UML or BPMN. It looks similar in boxes and lines. That might not be the best way to show business architecture to non-architects. In practice, I encounter basically three types of people in management, and it has more to do with their personal background than with their formal position. But let's say the first type is people with a technical background. It could be in software, it could also be something else. They are pretty adept at reading these kinds of diagrams. I once was in a discussion with somebody at Philips Electronics in the Netherlands about how they communicated with their management, and he said, well, we just showed them UML diagrams, and I said, management doesn't really understand that, but my experience is more in government and in finance, and they wouldn't want to look at UML diagrams at all. But he said, yes, that's not a problem. All our management are electronics engineers, and they are used to very complicated diagrams. We can easily teach them that. So that works for them. So that's one group. The second group I see are people with a financial background. You find lots of them in management, and they often like to see tables, charts, matrices, cross-references. That's the kind of information you can easily generate out of a model. It might not be the way the model itself looks if you put it in an argument, but the information is there. So that's a different representation with something that looks like what you get out of Excel, typically. The third group I find the most difficult, and that's people with a legal background, also prevalent in management. Steve, you've got a legal background, right? What do you think of argument? Well, people with a legal background are really focused on text, and there's even some scientific research into that. If you show some, say, article with text and images to a person with a technical background, they look really closely at the images, looking at the individual arrows, and asking themselves if they shouldn't be the other way around. And literally, in about half of the presentations I do on Archimage, there is somebody in the room asking me, what does that arrow mean, and the same question is, shouldn't it be the other way around? And they just skim through the text diagonally. People with a legal background are the exact opposite. They read the text very, very closely down to the individual comma because that might have legal significance, and they just skip through the pictures. So that's a very difficult group to address with architecture. Architecture in general, Archimate models in particular. I haven't found an easy solution. I've just tried an experiment to generate text out of models, just verbalizing the model, and it can be done, but that is really, really boring prose. That's worse than legalese. So I don't have an easy solution. But you have to adapt to your audience. You have to find a way to represent that. So I will use some alternative notations here and there in the examples I give, just to give you an idea of what could be done. Now, let's start with an example that some of you might know. Arch-Assurance. The example case we've used over the years, ever since the start of the Archive Project, actually, a fictitious but pretty realistic insurance company, the result of a number of mergers, well, some of you might have even been in those kinds of companies, insurance companies are in difficult circumstances. The interest rate is crazy low, so it's very difficult for them to fulfill their long-term obligations, especially life insurance, really problematic nowadays. And, of course, you have this whole digital disruption, all kinds of new entrants, fintechs, and all sorts of other companies entering their market. So our example company, Arch-Assurance, needs to do two things. Become more efficient in its current operations to lower its costs. And they need a new business model to counter these digital competitors. And in my example, I will focus mostly on the second part. The first part, reducing your application landscape, for example, I've got examples of that as well, but not in this slide deck, but you can see what you can do there easily. So we need a new business model. We'll see that in the storyline. But let's start with the ecosystem of Arch-Assurance. And it's a somewhat simplified picture, but what you see here is the insurance company itself, its customers at the bottom, and the insurance intermediaries. It sells its insurances also through intermediaries. And this doesn't look like an Archimate picture, but actually behind this are Archimate concepts. It's just visualized in different ways. And you can do different kinds of mappings if you want to. But this is to show an ecosystem to some non-technical experts to show how these different flows between these parties can be described, who is sending what to whom. So we've got these product offerings and we've got the product itself and there's money flowing, et cetera. Just an alternative representation. I think we need a new clicker. Oh, there we go. Capability maps. I mentioned them already, and I will show more of them, several of them later. Structured overviews of the capabilities of your organization. And very useful to project all kinds of information on top of, because people start to recognize this after a while. Typically, a capability map is in the terms of the business owned by the business, designed by the business with the help of the business architects. But it's really a business thing. And because it's this common background, you can project all kinds of information on top of it. And that's starting to become the standard way of looking at your enterprise from any organizations. So say your strategic importance of certain capabilities for your goals, all sorts of KPIs you can put on there, the resources you need for them, the evolution of the capabilities, which project impact there is on capabilities, et cetera, et cetera. And our insurance, of course, has a capability map. Yeah, there we are. Oh, that's... And this is inspired by an existing reference model for the insurance industry. Simplified a bit for demonstration purposes, but you get the idea. You see the core of the organization, the operational capabilities in the middle, strategic capabilities at the top that give direction and supporting capabilities at the bottom. By the way, does anyone want to guess what the one capability is that I've removed from the strategic layer here? Which capability was there, but I've removed it because it gave me too much discussion? Come on. Enterprise architecture, of course. But there were people, when I presented that at some companies, they say, oh, no, enterprise architecture is just part of our IT department. It should be a sub capability of IT management. I disagree. It should be up there. But I didn't want to go into that discussion, so I just removed it. But capability map. Now, like I said, you can project all kinds of information on there, and the typical way of doing that is using heat maps. And this is one example, a heat map of efficiency of these capabilities, but you can do this for all kinds of purposes. And I have a few more to show later. So that's our insurance and what it does today, the capabilities it has today. Now, perhaps, for this new business model, they will need something else, but we will see that. They've made this strategic analysis, starting with this, the board of the company, as stakeholders, they look into the profitability. And they see that there are some issues there. First of all, they see that customers defect to competitors that have a better digital experience. And on the other hand, some other customers defect to competitors that are cheaper. So they need to counter these two effects. And the basic goal they have is increase in revenue. They want to improve their income. This is not about the efficiency part, so lowering costs could be another way of improving profitability, but that was the second bit. I don't want to go there now. This is really about new business. And then they see they need to have two sub-goals. One is the customer retention that needs to be improved, and the other is they need to increase their market share by having an financially attractive offer to their customers. That lower layer we'll see in one of the next pictures again. But they've done more. They've created a SWOT analysis. And this is, again, not an archimage picture, but actually all these things are, again, archimage elements. What you see in the strengths and weaknesses, et cetera, those are assessments. And the bits in the middle, that's in course of action concepts like that. So here we see how, for example, a strength of the company, like broad product coverage and an opportunity, these affluent millennials that they want to sell their insurances to, could be exploited using this strategy of digital customer intimacy. And what that is, I'll show you in a minute. But this is a way of depicting an argument model. Again, not in archimage concepts, but something that the business could easily understand. It's not complicated technical notation. So this strategy, what does it entail? Well, first of all, they want to engage more closely with customers via social media to improve the customer experience. And on the other hand, they want to harvest more data on customers so that they can improve their premium setting. So, for example, in the Netherlands, we have some car insurance companies that put a black box in your car in this OBD port under your dashboard that monitors your driving behavior. And if you don't take corners too quickly, don't accelerate too quickly, they give you a discount. That's the idea there. But they will need new capabilities and resources for this. Their current capabilities are not good enough for that. They don't have this social media capability. They don't have the data part. So that's where we get back to our strategic analysis. But first, we did a bit of stakeholder analysis, and this is on the goal of improving customer satisfaction by the social media part. Again, a picture that is not in archimage notation, but actually these things are stakeholders with influence relationships. Let's say something about how they can influence each other. And this is the typical Togaf power grid. If you know Togaf, you know about this. The interest versus the power of these stakeholders. So, again, you can express it in archimage without showing an archimage diagram. But back to our strategic analysis. This was the bottom part of the previous one. We can then define some specific goals based on what we wanted to achieve, and then we can define the outcomes we're planning for, like this best-in-class online customer experience and these detailed insights and customer behavior. And together, those are the outcomes from our digital customer intimacy strategy. Now, we do need a few new capabilities for that, because this is not something you can easily implement without having the right digital customer management capability, part of our overall customer management, and this data-driven insurance capability, part of our overall insurance capabilities. We'll see more about that. Two new capabilities we need. Then another picture that doesn't look like Archimage, but represents the business model of the company. Again, Archimage Concepts. A business model canvas, probably something many of you will be familiar with. I don't want to go into the details of what's expressed here, but it's about the value proposition, the key activities and resources that are mapped to Archimage Concepts again. So we see capabilities, for example, for these key activities. We see the value concept in the middle. So that's the business model they envisaged. For these millennials, we see the customer segments over there. We see what they want to offer. Now we get to how we create that value, this value proposition in the middle, and here is this one new concept in Archimage 3.1, the Value Stream Concept. And this is the high-level overall value stream for developing products, marketing and selling them, managing policies and claims, and then serving their customers. That's how they create value. That value itself can be modeled with Archimage's existing value concept. We already have that. I've also modeled the outcome of the overall value stream and the stakeholder it is for. This is the customer. You could link these different value elements also to that stakeholder. I didn't want to make the picture too cluttered, but it was also irrelevant. Now this value stream is supported by the capabilities of the organization. So below this, we need the different capabilities from that capability map I showed you before. So this shows how these things intersect. And way down at the bottom, we see this data-driven insurance and digital customer management. Those are the two new capabilities that I introduced previously that we need to add. This is a different representation of that. A business outcome journey map. Terminology invented by Gardner. They have these usually forward terms nowadays. A business outcome-driven enterprise architecture that's even five. This is a different representation of that same picture before, but still capturing the same data, the same information. This is a different representation of that same picture before, but still capturing the same data, the same information. Now drilling down from these capabilities, we can go to our resources below these, and here we have a refinement of the initial capabilities. So we need data analysis and data acquisition as part of this data-driven insurance, for example. And then we need specific resources for that, like data analysis competency and data analysis automation. That's really giving up. Yeah, right. We can use these resources also to express kind of high-level what the solution is about. Well, you can read that. So the data analysis automation, for example, that captures data on customers from these data sources and that goes into the integrated back-office automation that I didn't show here, but that's part of this second part of the strategy, improving their application landscape, for example. We see the outcomes we plan for this and some other areas, some requirements. We're focused mostly on the business part of this. So we need the realization of these resources in our core architecture and we can realize our value streams by business processes. So we can drill down from this high-level into the details of the architecture by adding these kinds of concepts. So you can really trace from high-level strategy to the details. Similarly, for capabilities, they will be realized by the business functions of the enterprise, which are, in turn, performed by the different departments of the organization. So here we see the assignment of that. You also see that it's often not a one-to-one mapping between capabilities, functions and departments because your capability might stretch across multiple parts of that. And then finally we can plan and realize those changes using these concepts from the implementation migration layer. This is a high-level plan when to achieve these capabilities. We want to model the exact changes, but for this presentation, that was a bit too much. So that gives this full line of sight. This shows how these things would fit together. Now let me show you some real-life cases. One is the capability management at a major bank and we use the BIAN standard for this, which is now in this latest incarnation expressed in Archimate as well. There was a collaboration between the Open Group and the BIAN consortium. If you go to that link, you'll see the full Archimate model, but let me just show you a bit of that. This is the full high-level picture. You can't read any of that, right? So let's zoom in a bit. Here we see the upper left-hand corner of that. We see what they call their service landscape and we see a number of areas and then we see some capabilities in there and they've even used the stereotype notation in Archimate to express that they have business domains and service domains as a kind of capability. This customer for which we did this implementation drilled down from these capabilities into their implementation and this BIAN standard really goes very deep into the communication between applications even, so that was also part of this whole story. So you can go quite deep into that, but my main point here is the business architecture bit. So standards for capability maps from some industry consortium are quite useful. This is another one. It's also about data. Data-driven data as a service from a government agency. A high-level capability map again. What do you need to have if you want to do data analytics and also a value stream for producing insights from that data and the relevant capabilities that support that. Another example is from a pharmaceutical. Again, somewhat simplified for demonstration purposes and anonymized, of course. Let's zoom in again. Here we see what they want. They want to be the leading provider of pharmaceutical services in the world, world domination. Then they have operational excellence and product leadership as goals and then we drill down from there into the more concrete change goals, requirements, capabilities, plateaus and work packages again. This is their capability map. I started from the other end. Again, simplified a bit for this presentation. They also use that to map, in this case, strategic goals to it. We see that operational excellence and product leadership map to different capabilities. Different impact on these different capabilities. They also map that to a value stream and they even mapped different metrics to that. Here we see two things visualized on the one hand, the cost of the application landscape and the IT cost, aggregated to these capabilities and eventually to the steps in the value stream. Also, the end of life IT risk also aggregated and shown with colors. We see, for example, that this sales value stream stage is at risk because there's this customer billing and collection management that apparently has some old IT somewhere down there, maybe some server or some system running Windows XP or whatever. You can see the business impact of that at this level without showing all the technical details. That's also an example of how to use your business visualizations to show the relationship to everything that's down there. Now, coming to some conclusions. Archimate is really intended to bridge this gap from high level strategic direction to implementation. As you have seen, this line of sight can easily be modeled using argument concepts, maybe represented in different ways. That really helps you make these analyses. It gives you that full traceability. Without that, a business architect sort of hangs in between these different worlds. If you can't link to the enterprise architecture details and you can't link upstream to the strategy as a business architecture kind of lost in the middle. That's quite important. What's also relevant is you do need to show this in different ways to different stakeholders. Given the huge world of stakeholders out there, this is not something any standard can pre-define for you. You might want to be creative or might want to ask your tool vendor to support you with that, but appropriate visualizations are important. With your colleagues, with other architects, you can easily use the Archimate language. With others, you might need something different. Finally, I would say, add Archimate to your business architect toolbox. I think it's a great tool for that. It covers the whole space of business architecture. All these concepts are in there. I think it's a really great help. Finally, I have some links for you. Yes, there we are. If you want to know more about the Archimate language itself, go to the website of the Open Group. The Archimate forum is over there. All the new stuff can be downloaded from there. By the way, I didn't download the original version of the standard yet. I guess it's on there, Andrew? It is. Okay, right. You can get it right there. There's an Archimate LinkedIn group. Interesting discussions. Over 11,000 members nowadays, grows with about a thousand a year. And a quick reference with the Archimate 3.1 concepts shown in action in small pictures showing some context. So it's not a simple list of all the definitions. You can get that from the standard, but it shows them in action. So that concludes my presentation. Thank you. Thanks, Mike. Please have a seat. We have some questions for you. I had one I've never really thought about, but how did it come to be called Archimate? There are two stories about that. At the same time, when we started with that project, one is that there were some ideas about animating architecture, creating something that was dynamic. So architecture animation, that's one. And the other one is that it was kind of the work mate for the architect, like this work bench. So those ideas came up at the same time. So we called it Archimate. Makes sense. Okay. First question. You showed the Panorama 360 reference model. Are there other reference models for other industries that are out there? The BN model was an example that I... But there are others. Some of them are expressed by the organizations themselves, sometimes using Archimate, but we should promote that. For others, it's often a question of just converting it to that. One example, whether it is fairly easy, is all these APQC models for processes that works, that we've done that ourselves. And another quite relevant example, it's newest NATO architecture framework that came out early last year, has now approved Archimate as one of the two approved metamodels for expressing defense architecture. Nice segue to the next question. Oh, metamodels. Are the metamodel and the metametamodel of what you showed based on industry standards, or are they invented by your team? It is an industry standard, right? Archimate. Actually, the metametamodel so the way we express the metamodel is based on a stripped down simplified version of the MOF metamodel. So we don't use the full MOF metamodel. If you're into the metamodel world, we might know about that. But we've created a very, very simple stripped down version. Like Archimate, it's much simpler than UML is. So it's inspired, I would say, by an industry standard metamodel. You're finding... You're guessing what the questions are before you even... So you gave a nice segue to the next question. You mentioned UML and other languages. What makes Archimate different or better than those? I didn't put that picture in that Archimate has a broader coverage but less detail. It doesn't force you into the details like UML does because it's more implementation oriented or BPMN with all its different kinds of events and gateways, etc. But Archimate connects these worlds. So you can create a single model that can be detailed out in these different languages. So you have a kind of higher level model covering the broader picture on top and from there you can drill down into the detailed models. Right. Okay, thank you. Would you link value streams to anything else? Like? Yeah, I don't know. Is there a thought for whoever submitted that as to what was behind it? Wishing to remain anonymous. Yes. All right. Well, whoever that was can maybe grab you afterwards and explain that one. I'm learning how to use Archimate and have heard people mention the exchange file format. What is it and how can it help me? It's a standardized way of changing Archimate models between tools. So if you have a certified tool that should support that format so you can easily give your model to another tool. Right. Okay, thank you. And that's the end of the questions, Mark. You mentioned the Archimate user group tomorrow. Do you want to give another plug for that? Yeah, come to the Archimate user group. You'll get more details about the changes in Archimate 3.1 and some other interesting presentations. It's tomorrow afternoon, the whole afternoon. I think it's a very interesting program. Okay. Well, thank you, Mark.