 As Simon already said, my presentation from last week was really walking people through the different features of Archimedes today. It's much more focused on practical examples, although I will start with the highlights of what's new. So introducing Archimedes itself as a language, for those of you who are not familiar with it, Archimedes is intended for enterprise architects to provide more rigorous specifications of architecture. The main idea is basically shown in the cartoon on the right. You might have all kinds of nice diagrams, but if you always have to ask the architect what they actually mean, if they have no fixed meaning, then you're in trouble. Then you have to do a lot of work, say the typical PowerPoint architecture. It doesn't really work out in practice. And I think the cartoon is sort of a worst case scenario when it doesn't do anything in these rectangles, but if you have clear models, you can do a lot more with them. It's not just a picture to hang on the wall. It's actually a structure that you can analyze that creates transparency and traceability across the entire enterprise from high-level strategic goals to the implementation in systems to the project that realize these systems to the processes, the people involved, et cetera. So it's really much more than just pretty pictures. It also helps you in creating alignment in the organization across these different areas. By providing these links, it becomes much easier to see where there's misalignment, where you should work on that, where you can help the organization become more coherent. And finally, models also inform decision-making because you can use them in various ways to perform all kinds of calculations, cost calculations, for example. You can create, say, cost distribution models, how do the costs of your infrastructure add up and how are they going to be distributed to the business units making use of your systems. You can use them for portfolio management, risk assessment, all kinds of dependency analyses, impact of change analysis, et cetera. So models are really a very powerful means to support change. So what does ARCIME provide then as a language? Well, it is a language with concepts to describe architectures. It's not a detailed design language. It's really intended for this architecture level of abstraction, so it doesn't replace languages like UML or BPMM or others that are really more detailed. It's a framework. It has its own framework for organizing these concepts, and I'll walk you through the changes in that over the iterations of the language. It has its own graphical notation, but it also has a vision on how to visualize architecture for different stakeholders. The main point is that the notation itself is not completely tightly coupled to the underlying models. You could visualize models in various ways. Of course, it's useful to have a standard notation to avoid the problem that I mentioned before that the architects don't understand each other, but it's equally important that you can visualize these models in different ways and make that stakeholder dependent. Of course, there's no fixed way of doing that because it really depends on the kind of stakeholders you have, but the idea is that the visualization itself should be decoupled in a way from the model structure. So you have your models in a repository and visualize them in various ways. But today, of course, I will focus on argument and standard notation as well, so you will see mostly argument pictures. But it's really important to keep in mind that, for example, when you address a management audience, the argument pictures, the graphical notation might not be the best way to do that, but the argument models provide you with a lot of rigor and analysis power that you can use to provide these decision makers with the right information. Well, finally, of course, Archimade is an open standard maintainer. The open group, we don't have to go into that because you're attending an open group webinar. So positioning the Archimade language in between strategy and design, this is what you typically would do. Archimade has a modeling language and Archimade models bridge this gap between high-level strategic approaches like this in model canvas or a balanced four-car, the SWAT analysis or what have you. And detailed design models in languages like BP, MN, or UML, or others. Archimade is less detailed, it's less formalized than the lower level models, but it's more concrete than the higher-level strategy models that you find in the upper layer. So Archimade bridges that gap, and it also bridges the gap between different models like BP, MN, and UML, because if you want to model your business processes and your applications and show the relationships between them, Archimade helps you with that, but you couldn't do that within just BP, MN, or just UML. You need to bridge between them to have this overview. One graph that's maybe interesting to you, I read a poll last year on the Archimade LinkedIn group to see where Archimade typically is used. And as you can see, government and finance and information technology as well, those are the biggest sectors where you see usage of Archimade. But we also see an increasing usage in, for example, manufacturing and retail and telecommunications in other areas. So enterprise architecture is a discipline that Archimade, as a language in particular, is increasingly used in the less traditional sectors where it grew up. It really started out in government and finance. But today it's less than half of Archimade users that are in these two sectors. So we do see an increased usage in other areas, and that was also one of the motivating factors behind the development of the next version of the language. So that's my next slide. Why do we need a new version of Archimade? Well, of course, the discipline of enterprise architecture is evolving. It's used in other areas, in other domains, and that requires new concepts to relate enterprise architecture to other areas. Especially over the last years, we saw an increasing demand for design relating architecture to business strategy. It's really increasingly seen as a means for implementing strategy, for making sure that this strategy can really work. And also to provide feedback to strategy, to see what your strategic options are, to deal with technology innovations, etc. A second important addition is in the physical world. Archimade, until now, didn't have any concepts for modeling physical technology. So you could, well, later on I'll give an example of a steel factory. That's really physical. But also the internet of things, and those kinds of technology innovations. We could model the internet, but we could model the things. Now we have concepts to do that, now we'll show examples of that as well. Like I showed on the previous slide, we see increased usage of Archimade in other domains than the traditional government and finance. So new domains require new kinds of concepts like, well, manufacturing with its physical equipment. We need to have the concepts for modeling those. And then of course there are various other reasons for improving the language, increased consistency, comprehensibility, improvement in the notation, etc. And improvements in the alignment with other standards. I won't go into all the details of the improvements. We have seen most of that last week, but I will show some of the areas where we have added concepts and where we have improved. So I'll just walk you through some of the highlights. But first of all, a little more about the structure of Archimade. Archimade's framework initially started out with these three columns of active structure, behavior, and passive structure, which resemble the structure of human language. All human languages have subject, verb, and object. The order depends on the grammar of the language, but they all have subject, verb, and object. And that was the inspiration behind the structure of the Archimade's framework initially. So in this example we have John, who's the subject of the sentence. He is an actor in this model. He reads a book, so his process is reading and the thing he reads is a book of business objects. This structure is replicated across the layers that we have in Archimade, and initially those were the business application and technology layers that are very common in many architecture approaches. So that's what was the first version of the Archimade language, Archimade Version 1. That was what was developed in this R&D project with the Telematica Institute, I spoke about. Then, in version 2 of the language, we added two different areas that were not yet covered. And those were the motivation world. So what's the reason behind your architecture? Why do you want to have something? What are your goals, your requirements, your principles, etc.? And the implementation and migration world. How do you realize the architecture in practice? So what are your project programs, work packages, as we call them in Archimade, what are the deliverables they provide? How do you sequence this, etc.? So this is the second version of Archimade, version 2 that came out in around 2012. Now we've added two new areas. We've added some concepts for modeling strategies. We'll get to that later on, things like capability, for example. And we've added concepts for modeling the physical world. So technology, that's not IT, but technology in the physical realm. And as you can see from this picture, it's closely linked to the technology layer that we already have. So I will show you how this works. It's really integrated because increasingly physical technology is, of course, computerized, is driven by IT systems, and it's inseparable. The Internet of Things is just one example of that, but most technology nowadays has some sort of IT inside it. So that's now version 3 of the language. This is the coverage of Archimade at the moment. For those of you who are really into the details of Archimade, we no longer talk about extensions. We used to call it the Motivation Extension, for example, but we see this really as an integral whole set of concepts that belong together. So it's not just a core and some extensions, but we still sometimes address the original part of Archimade as the core of the language because that's where it all started. So a few more highlights of this new version of the language. We've got a few more examples. We added concepts for modeling strategic issues, capability-based planning, as one important way of implementing strategy. So we will see those. This really helps you in strategy execution. And these are also in line with other approaches. Toga, of course, is a prominent one, but also you might be familiar with the Bishbok from the Business Architecture Guild. Their capability concepts, just to name one, will be closely aligned with the one in Archimade. For the Business Motivation Model, which has a concept called course of action for modeling strategies and tactics, we also have that now in Archimade. So those were really approaches that we looked closely at. We didn't want to reinvent the wheel. We took concepts from existing methods approaches, languages, and linked them to what we have in Archimade. There's also a white paper on capability-based planning forthcoming, so we will provide more detail on how this works in practice. Then we have these new physical elements. So this technology layer was extended with elements for the physical world, things like manufacturing or logistics, but also computer-controlled machinery, the internal things, et cetera. And I will provide examples of that later on as well. Then there were some other improvements, one that's probably quite popular with the more experienced Archimade modelers, is that you can now relate things to relationships. For example, on the left, you see that you can relate an insurance policy to a so-called flow relationship between policy creation and policy management. So you can actually model what is flowing there. Or on the right, you can link relationships to plateaus, and we didn't have that, and you couldn't model that in a certain plateau in the development of your architecture. A relationship was added that there was a new link between two applications. You could model the applications as part of the plateau without the relationships. So now we have added that. You can do that. Another improvement is that we now have actual semantics for the grouping concept. Grouping used to be just a graphical thing. It didn't mean anything. It didn't bind the stuff inside it. It was just a graphical notation. But now you can really use it much more extensively. You can put things inside it that are really aggregated by the group, and you can draw relationships to and from the grouping. So in this case, you see that this grouping really aggregates a number of processes in an object, and these together realize a service. So this provides a lot more flexibility, for example, in modeling architecture building blocks. If you're a Togaf user, you know about the prominence of ABBs and SBBs while the grouping concept is really useful for modeling those. But of course you can use it in various other ways as well. And finally, another highlight is that we've added a specific notation that helps you identify in which layer a certain concept lives, especially in larger diagrams, larger views on your architecture where you combine multiple layers because we have kept the notation quite simple, you see that, for example, a service is denoted in the same way across the different layers. But it's useful to have a notation that makes a difference, especially if you, for example, print them black and white and really want to make clear in which layer you live. And if you look at this example here, you see the little b in the corner for business layer, the a for application layer, and the t for the technology layer. So this is just one example of how to use that. Of course in this example it would be pretty clear what layer things are in, but this might be helpful as well. It's an optional notation, you're not obliged to use this, but it might help you. And then we have done some updates to increase the consistency of the language. So it's more regular, we align the definitions within the language across the different layers, rename the elements in the technology layer which were called infrastructure something. So that was quite inconsistent because the layer was called technology, so we renamed them technology something. And we also have consistency across the layers in the behavioral concepts. For example, we have process interaction and event at all layers, an extra function that we already had. We have collaboration, et cetera. So it's a more regular language in that way.