 I'm looking forward to this one. Mark and Iva, very warm welcome. Thank you, Steve. Yes, so this is indeed the introduction of the Archimade 3.0 standard. This is just one presentation on Archimade this week, or today even. It'll be an overview presentation. It won't go into the details of the Archimade standard, but there will be several presentations later today. There's a extensive one in the Archimade track that really covers all the details of the new version of the standard, and there's also a specific presentation going to be on capability-based planning, which is also a hot topic, of course. So more on Archimade later on, but in this presentation we just want to introduce the new version of the standard to you and show you a practical use case from the healthcare world that shows you how to use some of these concepts. I think this was already introduced. Skip that. The contents of our presentation, we're going to briefly introduce Archimade to you. It's not going to give you an overview of what the language is, so if you're not familiar with Archimade, well, I wouldn't worry, but it's not going to give you a full overview of the language, but we're just going to zoom in on specific highlights and show a use case that shows you how to use these concepts in practice. But first, let's look at why we developed Archimade in the first place. Archimade as a language was really addressing the problem over here, that you have pictures that you only understand if you ask the architect what they mean, and I think this is a worst-case scenario where the picture doesn't mean anything, but you really need to have some kind of standard to understand what the architectures actually mean. But there's more to it than that. It's not just a picture. Architecture models are much more specific than just having a drawing. So Archimade as a standard provides more than just a notation for drawing up architecture diagrams. It's really a language. It's a language with concepts for expressing architectures, and that language can be denoted in a standardized notation, but Archimade also has a vision on how to visualize architectures for others. It doesn't provide you with all the different kinds of visualizations you might need for different stakeholder groups, but it does have this vision behind the language that you should be able to visualize the same concepts in different ways for different stakeholders. So that's one of the elements of Archimade as well. So it's not just its own graphical notation, but it's also really about visualization. The language has its own framework. It's structure, and the word framework is, of course, very ambiguous. Togaf is a framework, the F of Togaf, of course. The Zagman framework is a framework. Archimade has its own framework, but it's really intended to structure the language. And, of course, well, finally, it's an open standard by the open group. If we look at how you position Archimade as a standard, it's really in between different worlds. It's in between the higher-level strategic world of sort of informal models. They're less precise and less formalized at this level than what you find in Archimade itself. Things like your business model canvas, your balance scorecard, et cetera. Down below, you will see the detailed design and implementation models like UML or BPMN. Those are very detailed, very precise, intended to be executed or built in practice. Archimade is in between. Archimade is not as detailed and precise as what you find down below, but it is more concrete, more precise than what you find at the strategic level. And there's another aspect to Archimade where it bridges different areas of the organization because its scope is broader than, for example, just software or just business processes or just strategy, it ties together different areas. So there's also a horizontal connection between these different domains. So Archimade can connect between, say, the software implementation and the business process world, whereas BPMN and UML cannot do that because they don't have the concepts for that. You can't connect a UML model directly to a BPMN model, but Archimade can bridge that gap. So why did we develop this new version of Archimade, version 3 that we're now at? Well, first of all, we see an increasing demand to connect enterprise architecture to business strategy, and I think the previous two talks of this morning already addressed that. Business architecture is, I would say it's a sub-discipline of enterprise architecture. Others would argue that it's something different, but I would say it's really closely related, and it needs to connect to business strategy and we need the right concepts for doing that. So Archimade has been extended in that area. There's another reason we extended Archimade, and that's that we see an increasing connection between the IT world and the physical world. We see all kinds of technology innovations like the Internet of Things, the case that Ivor is going to present will really make use of those concepts. That connect these two worlds, but we also see Archimade being used in other domains than the traditional world of large information-intensive organizations where enterprise architecture grew up and Archimade as well. So that was also an important reason. And then we see that Archimade also had some issues of consistency, different definitions that were not really well aligned, some smaller stuff that we wanted to improve as well. And finally, the Open Group has a number of standards, and especially Togap is of course very important in this context. And over the last year, year and a half, there was a specific project called Harmony, looking at harmonization of the definitions in different standards, and the output of that project was also taken into account in developing this new version of Archimade. So various reasons to develop this new version. Much more detail about that later on today, but I will zoom in on a few examples of that in my talk. But first, a bit about the reason for developing Archimade, because it's really used in different domains nowadays. If you look at this, the industry usage, and this is a poll I did last year in the LinkedIn group on Archimade. We started Archimade as a language mainly for, let's say, government and finance in the typical organizations that have their primary process embedded in the IT. But we do see an increased usage in domains like healthcare and retail and manufacturing. And so those areas where they are really in the physical world and not just in the IT world, are really picking up, I think, enterprise architecture in general and Archimade as well. So those are main reasons to extend Archimade with concepts like that. Okay, just to give you a bit of background on Archimade and Archimade structure, I'll talk you through the Archimade framework so that you understand what the different areas are that the language covers. And Archimade started as a language when we developed it in a Dutch R&D project together with a number of user organizations like the ABN Ambro Bank and the Dutch Tax Administration, et cetera. And we started with a language that reflected the structure of natural language, and all human languages have subjects, verbs, and objects. The order might be different, the grammar of the language inside on that, but subjects, verbs, and objects are central to the structure of Archimade. You see that we have the active structure in Archimade, which are the subjects of the sentence, so in this case John, an actor if you recognize the symbol, a business actor. Then we have the behavior, the verbs. What is John doing? Well, John reads. And what is he reading? He reads a book, the object of the sentence. The central structure of the entire language. Of course, when you then look at architecture practice, you see that this is often applied at different areas, domains, layers of the organization. So the next addition we made was layering this according to what we saw in many architecture practices. And Togav is one of them. Togav has the same three layers, although they call the application layer, which is aligned with what's in there. So this was Archimade version one. This was the version developed initially, so that covered this core area of what the enterprise actually does. But this wasn't complete because if you look at Togav at the ADM, what's missing there is, first of all, the motivation behind the architecture. You can describe how it operates, but what were the reasons behind that? Your architecture principles, your goals, your stakeholders. So the motivation aspect is an important aspect that was added there as well. It's not layered like the rest because you apply this motivation across the entire architecture. You don't have specific motivation just for the business layer, for example. And the second addition was in the implementation and migration of the architecture. It's nice to describe how the world looks, so how it should look in the future, but you also need the right concepts that are concept-like plateau, the stable stage of the architecture development, or work package, the work that you need to do to implement a part of your architecture. This is subdivided in the same way that we saw in the other layers because we have the same kind of things there. A work package is typical behavior so that would be in the middle column. Passive structure, deliverable of a work package would typically be in the passive structure. So this was Archimade version two. This was where we started developing version three. And like I said at the beginning, we saw two main areas where we wanted to extend the language, and first of all, that's in strategy, so we have a few concepts added to describe strategic issues, and I'll talk you through some of those later on. And we added some concepts for the physical world. And if you look closely, you see that in this picture, the physical layer is really tied to the technology layer. We didn't put a separate layer in there. We linked it to the existing technology concepts because we saw that this integration between physical and IT technology is becoming more and more important. So describing that as an integrated whole is very central to the new additions. And I think Ivor will show examples of that as well. So that's Archimade version three. Of course, there are many other examples and many other improvements to the language and I will show some of those as well because it's not just adding a few concepts. There are other additions to the language, improvements, changes that help you apply it in practice. So I'll just walk you through some of the highlights. This afternoon, I will provide much more detail on what's new in the language. I will show many examples, but just to give you some impression of what's in there. So first of all, we added a number of strategy elements, a number of concepts for describing strategy, things like capability-based planning. They are really aligned with what we saw in other approaches like the BISBOK, which was already mentioned this morning, the business motivation model, TOGAP, of course, the new OBA standard. So that's an important addition at this strategic level. We are working on a white paper on capability-based planning. This afternoon, we'll tell you more about that. So this is an important addition and just to give you some feeling for what we have there, here we see a rather... Well, it's a simple picture, but it might look complicated if you're not familiar with ArchiMate. What we see here is two existing concepts, driver and goal. This is already in ArchiMate version two. So the driver of the organization is profitability, and to reach that, there are certain goals that have a positive influence on each other. But to realize these goals, you need outcomes. And outcomes is one new concept in ArchiMate, and an outcome is distinct from a goal because some outcomes might not be your goals, might not be desirable, might even be undesirable. So the outcome is the actual result, and the goal is what you want to achieve. So outcome is a really new concept. And if you look at the symbol, it looks a bit like a goal, but it's the same... Well, it's where the dart stuck in the bullseye. It's the same symbol as for a goal, this target, but with really the outcome achieved by having the dart in the bullseye. Next to that, we added some other concepts. First of all, we have the concept called course of action. And the course of action is really taken from the business motivation model, and it's used to express things like strategies and tactics. How are you going to employ your capabilities, your resources to achieve these outcomes? That's basically what a course of action does. And we already see a number of capabilities here. This is from a longer case story that I will use later today from our ArchiSurance example that most of you who are familiar with ArchiMate will know. We've extended that with this. This is part of their digital strategy, so they are developing new capabilities. And here we see that these capabilities together realize that strategy and realize these outcomes. Capabilities themselves, of course, have to be realized by what the organization is and does and has. So there are resources related to these capabilities, and these are just, well, simple examples. So we have social media competency as a resource needed for your digital channel management capability, and then you have your customer service team realizing that resource. So those are new concepts in the strategic world, and then you can draw things like capability maps. This is ArchiSurance's capability map, the typical insurance company, the typical capabilities you find in there. And so that's the work on the strategic level. Then we've added concepts for the physical world, and those are really closely integrated because we, for example, we didn't add any behavior concepts. So the work that's being done, we have a concept like technology process, but we don't have a physical process. It's just a technology process. We have one set of concepts for describing the whole technology world, and the physical concepts are just now part of that. So just to show you some examples, this is from a really physical world example, a really physical production example. Here we see the production of vehicle telemetics appliances, and we see that there's an assembly line, modeled as equipment in the new ArchiMet concepts. We see various materials going in there, like the pre-assembled circuit boards and others. We see that it's the assembly line, which is part of a manufacturing plant, and we see also that the end product is then shipped via overseas shipping and local trucking using a distribution network concept, which is also new in ArchiMet. So for physical distribution, you can now model that with a distribution network, not just communication networks, but really physical stuff. So this is a really physical example, the production of stuff, but we'll see a more Internet of Things-like example later on. Some other improvements to the language in a different area are that you can now draw some relationships to relationships, not just anywhere, of course, because that will become really messy, but take, for example, on the left-hand side, you can now model that a certain object is really related to a flow between two business functions. So you can model that this insurance policy is actually the thing that flows. On the right-hand side, you can now model that a relationship is part of an architecture plateau. You couldn't do that in the previous version of ArchiMet, which was rather awkward, because that's often something that changes between plateaus. You establish new relationships between application components in this case. So that was very important to add that as well. But like I said, this is not a generic feature that you can just use anywhere, because then people would start drawing relationships to relationships to relationships. That would be really messy, but that's one of the examples of where this is now permitted, which makes the language a lot more flexible and a lot more expressive. Another example is that the grouping concept in ArchiMet, which used to be just a graphical thing, now has an actual meaning. It has actual relationships with the stuff in the group. And you can draw relationships to and from a group. So the picture on the left and the picture on the right are really, I have the same meaning. You use aggregation there to picture what's in the group. And you can indeed express that all the stuff together realizes a certain service. You don't have to draw the individual relationships anymore. You can do it like this. So that's a lot more flexible, a lot more... But it saves you a lot of drawing as well. So those are some of the highlights of what's new in the language. If you want to know the details, please come to the ArchiMet track this afternoon. I'll give an extensive presentation of what's all new in there, and now I'll hand over to Ivor for the second half of our presentation. Thank you very much, Mark. So yes, so I'm Ivor Band, and I've been using the ArchiMet language almost every day, certainly every week, for the last five or six years. In late 2010, I was working for a diversified financial services company, and I was researching methodologies. And when I saw how Togaf and ArchiMet could work together, a light really went on for me. And I said, wow, this really solves a problem. I understand why it solves the problem. I really use this, and I can start using it right away. And since then, I've used it to model everything from office politics to salesforce.com implementations to complex stacks of cloud-based software. And I really find that it's extremely useful. So now I work for a company called Cambia Health Solutions. I've been there for a little over two and a half years, and it's basically, its roots are as a health insurer since 1917, and it really is moving to become sort of a health technology platform company. And so now I'm involved in big data and enabling, as we call it, everything as a service. And so some of my examples go from there. And so some opportunities we see at Cambia for Arcimate 3 or capability-based planning, enterprise service-oriented architecture. I've done a lot of work already. We have lots and lots of service teams developing things, and how does all that work fit together? And I've used Arcimate in modeling the service catalog that we're going to implement internally. Also, we have, like all insurance companies have been around for a long time, we have multiple generations of health insurance applications, and we have to do some rationalization to control our costs and complexity. And I'm very interested also in supporting consistent development and optimal reuse of big data solutions. In fact, tomorrow on the health care track I will be giving a presentation modeling big data using Arcimate 3.0. And there I'm trying to introduce in my company some conventions for talking about big data solutions based both on Arcimate and the NIST big data reference architecture. So come to my presentation tomorrow on the health care track. You'll hear more about that. And also, we're very interested in mobile health. If you go to YouTube and you look at Cambia Health Solutions, if you just Google it, you'll see videos of our plans for the future, which include quite a lot of technology in the delivering of health care in a personal and efficient fashion. So in this first picture, I talk about how a company can apply various resources to a particular course of action, which is offering claims processing as a service to other carriers. We see that the company has a claims capability that realizes it. And to that capability, we've assigned three essentially groups of resources and human resources. We have particular groups with particular skills. We have IT resources, a bunch of application collaborations or big solutions, groups of applications that work together, such as multi-tenant claims processing, all of which are based on a cloud-based infrastructure. And the company is also well positioned to do this through its partnerships which include cloud services contracts and a claims processing contract with the form of subsidiary. In this case, the company is already providing services to a company that used to be part of it, but is no longer. And so it has a basis to provide those services to other companies, especially when coupled with its existing cloud-based multi-tenant infrastructure and applications. So now I'm going to give a bit of a connected health case study here. And it's based on work and planning I've done integrating health insurance companies' web presence with health platform providers and ultimately digital platform service providers. So there are companies in the U.S. and I'm sure elsewhere that provide white-labeled personal health insurance, personal health and wellness websites, and they do that to... They do that, and a lot of insurers, health insurers now include them. Your group health insurer, if you have group health insurance, may include that on their website. And so here we have a situation. We have a company called WLPH, fictional, of course, that integrates with two types of connected health devices, one of which is manufactured in Germany. That comes in later. But they see that their competitors are integrating with a broad version of them. So consumers that use it don't have to use just one of the two. They can use any of them. And these connected health devices include everything from fitness trackers to the connected glucometers that people challenged with diabetes are starting to use to connected scales, etc. And what they're finding out is that they're large customers. The insurance companies, for instance, that use their platform for their groups and consumers are dissatisfied with this, and the sales staff report this as a key factor in cost deals. But fortunately, we have digital health platforms, and what they do is they aggregate it. They integrate with almost every conceivable device and provide an API and cloud-based services that let you get that information in a consistent stream. So first of all, here we're talking about, first of all, the consumers have to get a connected health device, and here shows an integration of the older parts of ARCHIMATE, which have to do with, basically, IT systems and solutions with the physical world. So you show a consumer at a SHIP2 location, perhaps as her home, who's using a website, which is an interface to place an order, and that order-placing service is realized by a fulfillment engine, which is on a hosting infrastructure, and that fulfillment engine sends the order data over to a pick-list generator at a distribution center. Of course, we're abstracting out probably some other stages that come here, but this is showing the concept. And then that pick-list generator takes the pick-list data and sends it to a printer, at which point we've already entered the physical world because we're showing that the pick-list generator is hosted in a server room at the distribution center, and then the printer is sending the pick-list print-out as a representation of that data to the packer, who takes the order from the shelf. And then that connected health device goes by overnight delivery to the mailbox of the consumer. And it's also, but it's gotten to the distribution center via an intramodal freight path from a factory in Germany where it was created on an assembly line. So here you have the whole thing, and I've also shown some... some networks... some different networks here at the bottom. And also... Now, here's another... Now, how are those devices managed? Here you have a health insurance website that includes a health and wellness sub-site and includes some health and fitness management pages provided by that platform. And there there are some services available to manage the health and fitness device, for example. And then through there, the health and fitness website accesses a digital health platform which uses a bunch of other services from the health platform provider that allows it to retrieve the supported connected health device types, register those, et cetera. So we're actually going down. The other thing that's important about this diagram is I'm using the flow relationship between groupings, which is a new Archimage 3 feature. First of all, I'm allowed to have a relationship between an object and a relationship. And I'm also allowed to have groupings that have relationships. And I'm showing that in order to preserve confidentiality, there's only an OP consumer ID exchanged between the digital health service platform provider and the health and wellness platform service layer. You can show that you can see some complexity here as well. And then if we move on, we can see the bottom of this where the digital health service platform layer is accessing a further set of services that allow it to manage the devices. And so there you see some of the infrastructure necessary to manage the devices, some of the applications. And finally, this is where I was actually trying to get to, it shows that there's a whole infrastructure that supports that, including that process, including data exchange with the connected health device. And then you see the entire infrastructure in this picture. And so now, moving on to the concluding remarks, one of the things as a almost daily user of ARCHIMATE, the advantages I see from ARCHIMATE 3, and besides having worked on the standards, I've been using it for about a month, is that it enhances the visualization of complex models. With the new strategy elements, as you can see, link strategy to architecture, the enhanced grouping, it allows you to have many to one relationships. My previous diagrams, what I'm showing is, I showed relationships between groupings. My diagrams would have been a spaghetti mess if I had to show those relationships between all of the elements of the grouping. But the relationships within the grouping are projected onto the individual relationships within the group. And the other thing is there's joint realization for multifaceted dependencies. Using the junction, I can show that many different components, many different more concrete components go into realizing something more abstract. So a whole set of servers can realize a whole set of services. For example, and the notion of event has been extended to all three core layers, actually into application, technology, and to the implementation and migration, so that you have those events, and as they've always been in the business layer. And I actually use those in my presentation on Tuesday. And another thing is good is in Archimage 2, we have business processes, now we have application and technology processes, which are really great. The application processes are particularly useful, I think, in the big data arena, where there's all this multi-stage processing, and I use that in my presentation tomorrow. And we have improved customization mechanisms, which ease support for different categories of standard entities and relationships. You'll see that I use stereotyping, for instance, extensively in my presentation tomorrow, and the whole notion of how to customize the language is better developed in the specification. And there's also the specification does a better job of documenting the viewpoint mechanism, and really I think encourages the most useful views of complex architectures. One thing that I thought of, the other thing that's good about Archimage 3 is it allows system software layers to realize each other. That may seem like a very technical point, but the idea is that we're always dealing with complex stacks of system software where you have an operating system realizing a database management system, and then you may have a middleware layer that uses both operating system services and database management services, and it goes on and on, especially as you go into the complex stacks to use for big data as an example. So again, it's just a much more complete and practical language today. So summarizing it, Archimage 3, all over, the business strategy is very important, the physical world is very important, and there's improved usability, consistency, and support for complex models. One of the things I didn't mention is that it also lets you clearly label what layer something is a part of, because some of the symbols are the same on each layer. So that was another important thing, and the definitions also are just better aligned with other standards. We did some work aligning it with Togaf, for instance, as part of the harmony project a few years ago now. So it offers better, even greater support in dealing with digital transformation and business change. So here's where you can find information on the standard, and there you go. Maybe to add to the final link over there. You can click one back. We created a quick reference with all the concepts of Archimage. You can download it from the bottom link, but you can also get a paper version of our booth. It shows you the different concepts in context, so with little symbols and how they're used together with other symbols. So if you want to learn the language, it might come in handy. So I think that concludes our talk.