 Mark Lankhurst, he's managing consultant and business design evangelist at BizDesign, and Ivor Band is an enterprise architect at Cambia Health Solutions, and Ivor is also vice chair of the Open Group Archimage Forum. Mark is responsible for market development, consulting and coaching on digital business design and enterprise architecture, and basically for spreading the word on the archimage standard for enterprise architecture modeling. At Cambia, Ivor is now advising a consumer data initiative after guiding the development of healthcare provider network management systems and consumer web and email experiences. He's been working with the Archimate language for over five years as an architect, curriculum developer and contributor to the standard. So in this session, Mark and Ivor will introduce the new standard, Archimate 3.0, which extends the language with various concepts that help enterprise architects tackle challenges in digital transformation and business change. So I'm looking forward to this one. Mark and Ivor, very warm welcome. Thank you, Steve. Yes, so this is indeed the introduction of the Archimate 3.0 standard. This is just one presentation on Archimate this week, or today even. It'll be an overview presentation. It won't go into the details of the Archimate standard, but there will be several presentations later today. There's an extensive one in the Archimate 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 Archimate 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, I can just skip that. The contents of our presentation, we're going to briefly introduce Archimate to you. It's not going to give you an overview of what the language is. So if you're not familiar with Archimate, 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 Archimate in the first place. Archimate 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 Archimate 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 Archimate 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 Archimate 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 of Togaf, of course. The Zagman framework is a framework, Archimate 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 Archimate 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 Archimate itself. Things like your business model canvas, your balance scorecard, etc. 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. Archimate is in between. Archimate 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 Archimate 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 Archimate 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 Archimate can bridge that gap. So why did we develop this new version of Archimate, version three 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 Archimate has been extended in that area. There's another reason we extended Archimate, and 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 Archimate being used in other domains than the traditional world of large information intensive organizations where enterprise architecture grew up and Archimate as well. So that was also an important reason. And then we see that Archimate 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 Archimate. 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 Archimate, 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 Archimate, we started Archimate as a language mainly for, let's say, government and finance and 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 Archimate as well. So those are main reasons to extend Archimate with concepts like that. Okay, just to give you a bit of background on Archimate and Archimate structure, I'll talk you through the Archimate framework so that you understand what the different areas are that the language covers. And Archimate 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, human languages. And all human languages have subjects, verbs, and objects. The order might be different. The grammar of the language is side on that, but subjects, verbs, and objects are central to the structure of Archimate. You see that we have the active structure in Archimate 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. This is 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, the information systems layer, but it is aligned with what's in there. So this was Archimate 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 to describe how you get there. 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 when 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, Togaf, 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. The session this afternoon will 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 Archimade. What we see here is two existing concepts, driver and goal. This is already in Archimade 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 outcome is one new concept in Archimade. 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 with 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 ArchEssurance example that most of you who are familiar with Archimade 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 ArchEssurance'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. So we have one set of concepts for describing the whole technology world and the physical concepts are just going to be, 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 telematics appliances. And we see that there's an assembly line, a model as equipment in the new ArchEssurance concepts. We see various materials going in there like the pre-assembled circuit boards and others. We see that it's the assembly line that that is part of a manufacturing plant. And we see also that it's, well, the end product is then shipped via overseas shipping and local trucking using a distribution network concept, which is also new in ArchEssurance. 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 ArchEssurance, 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 these are 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 ArchEssurance was 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 have the same meaning. You use aggregation there to picture what's in the group. And you can indeed express that all the stuff inside the group now together realizes a certain service. You don't have to draw all 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 Archime Trek this afternoon. I'll give an extensive presentation on 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 Archime 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 Archime 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 can 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 Canvya 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 Canvya for Archime 3 are 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 Archime in modeling the service catalog that we're going to implement internally. Also we're very, 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 healthcare track, I will be giving a presentation modeling big data using Archime 3.0. And there I'm trying to introduce in my company some conventions for talking about big data solutions based both on Archimate and the NIST big data reference architecture. So come to my presentation tomorrow on the healthcare 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 Canvya health solutions, if you just Google it, you'll see videos of, you'll see videos of our plans for the future, which include quite a lot of technology in the delivering of healthcare 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 for, which include cloud services contracts and a claims processing contract with the form of subsidiary. You know, 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 a health insurance company's 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, it's fictional, of course, that integrates with two types of connected health devices, one of which is manufactured in Germany that comes in later. And, 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 things like everything from fitness trackers to the connected glucometers that people with challenge with diabetes are starting to use to connected scales, et cetera. And so, and what they're finding out is that they're large customers, they're 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. So, 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 SHIP-2 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 generators 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 intermodal 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 different networks here at the bottom. And also, 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 the 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 exchange between the digital health service platform provider and the health and wellness platform service layer. So 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, and 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 linked strategy to architecture, the enhanced groupings, which allow you to have many to one relationships. My previous diagrams, what I'm showing is, I'm showing relations, 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 now the notion of event has been extended to all three core layers, application, well actually to 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 Archime 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 we use, 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 it really, I think, encourages the most useful views of complex architectures. One thing that I thought of, the other thing that's good about Archime 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, which is used for big data, as an example. So again, it's just a much more complete and practical language today. So summarizing it, Archime 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. And 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. And 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. Can click one back. We created a quick reference with all the concepts of Archime. You can download it from the bottom link, but you can also get a paper version at the busy sign 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.