 Welcome, everyone, to today's webinar from the Open Group. Today we're talking about the combined use of the TOGA framework with the Arcimate Language. And we have three members of the Project Harmony team here to give us some presentations. So Bill, if you're ready, can I ask you to start today's presentation? Thank you, Simon. Yeah, this is Bill Estrum. And I welcome you to our webinar on Practitioners Guide to Using the TOGA Framework in the Arcimate Language. With me today, I've got two of my colleagues that have really been the major writers and contributors to the Project Harmony activity, Sonja Gonzales, who originally was working as a member of Duke Diligence in Costa Rica. And today she has taken on position as the Architecture Forum Director at the Open Group. And so that's kind of exciting. And Serge Tharn, when he originally was doing this work, he was with Architect and the Enterprise, the CIO. And today he's working with us at Metaplexi. Today's agenda, we're just going to basically do some brief introductions and then talk about some of the issues related to architecture modeling and the TOGA framework, especially using the Arcimate Language. And we'll talk about some of the activities that are going on with it in Project Harmony, which is an activity at the Open Group on the Architecture Forum and the Arcimate Forum. And talk about especially what we've just completed recently in our phase one efforts to really take a look at what we need to make it easier for practitioners to use these two standards together. So we'll start by looking at the glossary of terms, which you might not appreciate how important having a common language is. But I think that one of the strengths of both these frameworks is they try and impose a standard language that we can use when we're discussing things so that we get consistency and understanding. So we'll start out with that. Then we'll go ahead and take a look at the deep down relationships that exist in each of the frameworks between how we do the modeling, the content that we're modeling or using to model. So we'll take a look at the entities that we're using as modeling objects and also the relationships between those entities. And then finally, Serge will come back in and talk about viewpoints, which is another area where we really need to be able to have a common perspective. And so we'll talk about some of the issues there. At the end, we'll do our conclusion. And then we really want to open it up and provide about 10 minutes or so of Q&A. So basically, some of the issues that we have as we try and do architecture modeling today is there was a lot of different modeling tools out there. And many of them use things like UML and other standards. But the open group has recently, in the past five or six years, introduced the Archimage language. And they've been working to develop Togap for almost 20 years now. And so these standards are basically meant to work together. They've been designed that way, but they do have different origins. Togap traces backwards heritage all the way back to the early TAPM framework of the US Department of Defense. And Archimate is much more recent, having been originally developed in the Netherlands by the Informatica Institute and other participants and then turned over to the open group in 2009. So because of that, they do have some differences. They're designed to work together, but they are separate, distinct standards. They are pretty compatible, but there are differences. And that's what Project Harmony is trying to focus on, is how can we identify these things and talk about ways of working around them. So EA practitioners want to be able to use the Togap standards in their enterprise architecture practices, and they want to be able to develop and migrate models for those practices based on the Togap architecture content framework and its minimal, but also to the Archimate language. And again, the Togap is a framework and I think we'll point out several times that Archimate is a specific notation for developing views with some language that really gives us a very precise way of expressing our models. So integrating Togap and Archimate is a really key objective here. If you take a look at this, this is one of the standard pictures that we use to really describe the differences. So Togap is a framework with a lot of strength in the area of process. It also has a content framework and viewpoints and repositories and those kind of things. Archimate, on the other hand, is a language. It does not itself have a procedure for doing architecture, but it's a language for describing it. So it's pretty much all about content and we need to be able to store and manage that content in our repository in a way that's interoperable with the Togap standard and with other standards as well. So that's where we got started with Project Harmony. We've been at it for a little bit over two years and the result has been in phase one activity on the production of three major white papers describing the different areas that we're looking at and then also these practitioners guide that we'll be focusing on. So again, the goal here is to enhance the ability and use the framework together. But it is not the goal that we're trying to like consolidate the standards into a unified standard. That is not, we want to keep them in separate entities that people can decide to use independently. So we're basically looking at a way of comparing certain aspects of the two standards and then seeing if we can recommend ways of working around some of the differences that we discover. So yeah, these are the four areas I've already mentioned and the glossaries and terms, the content and the models that are provided in Togap and ArchMete. And in particular we'll focus on the entities and the relationships most. And then the viewpoints, the architecture viewpoints that are really linked to the stakeholders and how we express the model to the stakeholders. So the Togap standard is a standard for enterprise architecture. Three major areas that we have is the architecture model method, which is certainly one of its core strengths. The architecture content framework, which has been greatly improved in the Togap nine time period. And then the architecture capability, which is something really added in Togap nine that really gives us the ability to establish and operate an architecture capability. So it is important to note that the architecture content framework, even though it's very powerful and very significant contribution to Togap, we have designed it so that it is an optional framework. So if you wish to use Togap with other frameworks, like for example, Dodab for Zachman, then you can do that. In the same way the ArchMete language is an enterprise architecture modeling language standard. And it gives us the ability to model and using active objects that perform behavior, passive objects that have behaviors performed on them. And then it also allows us to connect these together with relationships in a much more fine-grained approach than Togap does. And again, just like Togap, we do have the ability to extend the framework. The ArchMate standard provides some extensions straight up. So yeah, here's a picture of the Togap content framework. Well, those of you that are Togap certified probably are quite familiar with this. And again, we start out by trying to create deliverables that basically describe architectures. As part of that, we're basically using artifacts like catalogs, makesh, season diagrams, which together describe these building blocks and how they're related to each other in architecture definitions. And then some of those models and some of those artifacts will be considered reusable objects. And after certain governance procedures, they'll be placed into the repository as reusable objects, reusable building blocks. We also have this kind of underlying grammar, if you will, for the content framework, which is the MetaModel. And this particular view of the MetaModel basically shows by ADM phase, the different content elements and entities that are in the MetaModel. So I'm not gonna go too deeply into this right now. But again, this is a standard view in Togap. And then we have the more logical model that really shows you the representation of the entities and the relationships between the entities and also a description of the relationships. You know, like who owns the business service and things like that or name the relationships. Content MetaModel basically is a way of giving you traceability between the stakeholders' concerns and constraints back to the actual model itself. And so Togap has this core MetaModel, which gives you really the basic stuff for traceability. And then for certain types of activities, we have an extended extensions that we had, which I'll explain a little bit. And so these extensions give you finer grain of detail. So basically one of the things about Togap is it's really always been designed to really interoperate with other frameworks and languages and things like that. And I think in the same way, Arcimate is designed that way as well. So it's not uncommon to see people using a mix of different languages to describe their models or using different models for different domains and things like that. And then again, as I mentioned, we can substitute our content framework with other frameworks like Dota app and Zackman. So then the Arcimate standard basically provides this ability to describe entities and the relationships between those entities. And then you can basically move down through the stack here and you can get more specific about things like applications and processes and functions. And then you go down all the way to the metamodel level where you really talk about the relationships between these things and domain specific ways. So to look at the picture here, you'll see that Togap basically in its traditional view of the enterprise architecture, the architecture development method, you can see that as we progress through the ADM in the early stages, we see that we have the motivation metamodel, which is really all about why are we doing architecture? Why are we doing this particular business? And then as we move through the rest of the ADM, basically we start going through the actual core modeling. So the architecture vision, we still are working at the motivation level. And then as we get into the actual modeling in the architecture definition phases of the Togap ADM, you can see that that's also basically linking the Archimade core where we talk about the business layers, the application layers and the technology layers. And then as we move into the phases E and F and on into G, we're doing the implementation migration and things related to that. So yeah, here you can see that the Archimade language has a generic metamodel, which is what's displayed here. And then it also has a separate related metamodel for every layer and extension that's provided in the Archimade language. Togap, on the other hand, provides basically this core and extended metamodel. And it also gives you the ability to define your own model if you wish, okay? So I think when you're customizing, for example, your repositories to do certain types of modeling, then you might create a custom extension. But for basic Togap definition, we just have the core and extended metamodel. So that's it. Basically our key findings is that as we went through the project harmony activities, we certainly discovered that there were differences to be had between the different areas, the major areas that we'll look at today are glossary. The major points, the metamodel entities and the metamodel relationships. So without any further ado, I'm gonna go ahead and introduce Serge Thorne and let Serge take it over and talk a little bit about some of the work that he's been doing, not only with the project harmony work, but he's also been one of the leaders, he's been one of the leaders of the localization committee which basically is trying to create country-specific translation glossaries for Togap and also for Archemy. So Serge, go ahead and tell us about that. Thank you, Bill. Go on, Serge. So the subject now is going to compare obviously the different glossaries between Togap and Archymate. The two standard have two sets of glossaries. As you may see on that slide, there is also a glossary for Togap 91, which is represented on the right side of the slide that you can download, obviously, from either the link that you find here or directly into the book. So that's going to be shown in the next slide where you see that the start-ups contain certain number of terms, which comes from different parts from the Togap start-ups. Those different glossaries have been translated these last years in different languages. So you may also want to download those glossaries. As you may see, we have actually more than 10 or 15 different glossaries and it's always the same format. So you'll see that you have one column with the terms from the standard specification written in English and on the right side, you will have the translation. So if you click on that link, you will find also those ones available for download. Here is an example of how the glossaries looks like. So you see you have the title of the term like applications architecture. Then you have the descriptions. It's classified alphabetically. Then obviously, depending on the type of language, you may have different translations and then the reference to the Togap 91 specifications. The reference is coming from the chapter three and there's also an appendix A. There is also glossaries for Archimate 2.1. Another link is provided there. And the same thing happens. You also will see that you have one column with the terms from Archimate and then different possibility of translation. So here again, on the next slide, you'll see different links to the different existing glossaries which have been translated. Both standard arts, both Togap and Archimate will have new translations in the future. So here you see two different levels in the Archimate glossary. The part which is on the top and the 2.2 is obviously specific to Archimate. And the definitions below, as you may see, the reference is different because it comes from the Togap specifications. This means that sometimes we have terms derived from Togap and some of them we have terms which are specific to the Archimate standard. Here again, we do have, obviously, created the first document. This document is also downloadable. It's called the glossaries comparisons which is going to compare the two glossaries between Archimate and Togap. So obviously what we try to do in this document is obviously to try to understand what are the different elements coming from Togap and the one which were specific to Togap. So the idea was to say, okay, do we have the same meanings? Do we have different meanings? And we came up with some documents which would compare the two. So the glossaries comparison as a standard was to identify the different terms which were not totally perfectly aligned between the two standard arts. Sometimes we have a perfect consistency between the two standard arts. They had to be some differences but the idea was not obviously to substitute one term with the others but simply to identify when the terms are different and when the terms are the same or sometimes the terms exist in one glossary and do not exist on the other one. So the outputs of this document, as you see, they are different columns. The first column will be the term which represents the name of the elements from the specification. Then we have the description. So one column will represent the description specific to Togap 91. The third column will be the term specific to the argument 2.1 glossary. So that would help us to obviously do the comparison. So as an output of the study what we had was three different possibilities called the mapping status. So in white, that means there is no correspondence. So it means that the term exists either in one standard and not the other one. If it's orange, that means there are different definitions and if it's green, it's the same one. It means that it's being just replicated from the Togap 91 specifications. Then some comments if there was something to refer to to justify the difference or maybe some suggestions to improve eventually in the future of the mapping. And the last column will be related to not the terms from the chapter three, but from the appendix A. So the appendix A is at the end and these have been added also in the glossary. Here's an example. You see that we have the term business functions. The business function has a specific descriptions in the Togap 91 specification, but it has a different one when you look at the archimage specification. So I'm not going to read the two, but you see that sometimes you have to think, okay, which one is the right one? So you will have to decide in all your organizations which one makes much more sense. Here's another one, product as you see in Togap 91, it has a meaning which is the output generated by the business and in Archimate, we have different definitions. So again, when you will have to align the different glossaries for your organizations, you have to change eventually the way you have defined one of the other to support the needs of the business. So which one makes much more sense for your different stakeholders? Here is a few examples. So you see the first line, access. So this is a term which is part of the Archimate to the 21 Prime National Glaciery. There is no mapping with Togap. Obviously, term access makes it somewhere, but it's not a term coming from chapter three or from the appendix A. There is no command and there is no supplementary definitions. However, you see the second one, actor and business actor, we do have two different definitions. The one on the left side, which is coming from Togap, the second one, which is inside Archimate. And we just decided that there was a correspondence but a difference that's the reason why the box is in orange. And the third case, which is architecture, as you may have thought, this is exactly the same definitions in both start-up. That's the reason why you have the green color in the mapping status. And here is the last example where you see that we have put a command for a data object. The command could be like here, a relationship with Togap, data entity and data element. And the last column, which is the supplementary definitions, is coming from the appendix A. So it's not really part of the glossary, but it's what you may find in the appendix. So it's all documented in something like 40 pages. So now the findings are that sometimes you will have to identify what does mean, for example, for your organizations, an actual business actor, because the actor on the business actor exists in both specifications, but it may have different meanings. As you may see, we also have in Togap something called an auction unit, but the unit does not exist as such into our commit. So you may also have to find a way of aligning those and you will see that with the viewpoints. Or for the role, you have a perfect mapping like the business service, but there's nothing in terms of business subject inside the Togap specification. So the conclusions for the glossary, sometimes there are different meanings and you will have to define within your organizations which definitions is much more appropriate, which one would obviously create more value for the stakeholders, which one will not create confusion or misunderstanding by your stakeholders. And basically it depends on each situation. So we are not recommending to use one or the other, but you'll have to identify that there are differences and find the best definition for your organization. So we're gonna talk here about the MetaModels. And as I mentioned earlier, the Togap framework gives you a core MetaModel, which gives you the basic stuff that you need for traceability when you're doing your modeling. And then if you have a special needs, you can go ahead and add in the extension MetaModels. And so we get the motivation model that kind of talks about why we do things from a business perspective. Governance is basically measuring how well we're doing against our goals. Process modeling gives us the ability to do more fine-grained processing, process design and process modeling. Data extension basically gives us more fine-grained information about the data. And then services extension, in the current version of Togap, the only services extension is there is the information service extension, which gives you a mapping between the business service and the underlying application components and logical application components. So in the Togap document in the chapter on MetaModels, there are three tables. There's one table on entities, which basically has a list of all the entities. There's a second table that talks about the relationships between the entities, and that's what Sonya will be talking about next. And then there's a final table that talks about the attributes that can be assigned from the Togap standard right to the entities. And again, you can change these things if you need to for your own organization, and you probably will want to when you're coming up with your organizational specific framework. So here you can see an entity and its definition, a couple of them. And so that's pretty much the way that table looks. So in our activities with Project Harmony, we did a pretty detailed comparison of all the terminology that are used for modeling, all the entities, and basically then compared them to Archimate. And largely, there's very good compatibility between the two, so many of these things were green, meaning a strong fit. And for some things, there was a weak fit. For example, here, the business interaction, which is a level of detail that's appropriate for the Archimate language, is not something that is done in Togap architecture modeling typically. But if you need to, there's ways of dealing with that. You can create various techniques to specialize the description of the process or function to give you that indication of how you're gonna do your business interaction. And the same thing is true with business objects. In Togap, we have a separate data layer. And in Archimate, the data is basically embedded in the different layers. So we have a business layer, an application layer, and a technology layer, and there's different types of entities in each one. So that can be somewhat troublesome, but not too, because the data is still there, just that it's located in different layers. So our key findings basically were that the Togap on the left-hand side here, we talk about things that are unique to the Togap content framework, structured according to the content metamals. And the metamals give you a single view that encompasses all four domains. And they are defined at a level of detail that is typically very useful for enterprise architecture modeling. But then when you're actually starting to do more detailed modeling to address specific stakeholder concerns and things like that, then the Archimate modeling language gives you a more detailed set of metamal entities and relationships in particular. It does not really give you specifically out of the box a lot of information about the attributes, or as Togap does, but the attributes can be added. You can specialize the entities to create attributes. The Archimate metamals are derived from a common metamal, which is almost like a metamal, it's an underlying grammar that all of the other metamals conform to. And then for each of the different areas like the business layer, the applications layer, the technology layer, or the specialization of the extensions, there's a metamodel for each of those then. Again, we have the four domains and Togap uses modeling whereas Archimate only uses the three layers plus the extensions. Archimate also goes further into defining an entity in terms of whether or not it's an active element, a passive element, or a behavior problem. So that's a pretty good summary of the things that we found. And again, reading the papers that we have on their website and the open group publication website, you'll get a lot more information, but it's all very similar to what I've just described. So now I'd like to turn it over to Sonia and have her talk a little bit about entity and their relationships. Okay, thanks, Bill. Hi everybody, thanks for being here in this webinar. The next one, please, Bill. What comes to relationship, I think like the difference are similar in nature that the ones that we have seen in glossaries and also in the entities, because like I said at the beginning, both as standards, but Togap is a standard framework for making enterprise architecture while Archimate is a modeling and specification made for modeling enterprise architecture. So that's why they are different. For example, we have like a high-level key find that we will have, for example, the interactions in Togap are not classified. They don't have a specific notation. They are just, they are lines that are like put in together and connected to different entities that belongs to the content model and they don't have specific rules. Like for example, for in the right relationship, that the one that we have in Archimate, they don't have like a specific direction and they are not specifically read from left to right with the same connotation that we have in Archimate. For example, in Archimate we have the use-by or use-relationship and that one could be mapped with several different relationships in Togap and could be, for example, performed, only performed by. So we will see this difference during the presentation and like Bill said and also search. If you can move forward, you will find in the white papers a very detailed mapping between the every relationship going from Togap to Archimate and vice versa. Okay, here for example, here we have one example, the aggregation relationship. We have a very specific notation and concept on centralization in Archimate for aggregation, which may basically be the temporary grouping of some elements, for example, roles that could be together and perform some kind of behavior. It would be like the behavior made but that's specific aggregation elements. We don't have that specific relation in Togap, in Togap we only have the decomposed relationship. So that would mean that we're using it in a specific modeling, a real case, we should see the context and see, for example, we have two specific roles that are like forming a teamwork that will be like other composition in Togap that it will belongs to the aggregation because it's just some people that are gathering together to perform a behavior. And so it will depend, next one Bill, it will depend on the particular context. They have to be used depending on the context of the modeling. In the next one, the same thing will happen with the specialization. We don't have that specific concept for relationship in Togap. However, Togap can allow defined taxonomies or additional attributes to the different elements to the pickback. For example, we have in the left side, we have Archimate model, which is showing like a node or a system software or the specialization device or system software or the specialization of a node. And also we can find some time of assignment between a node and a system software and a device. And that this composition could also be fine in Togap. And the other hand on the right side, we have, for example, that we can also define or make this mapping. For example, a node can be mapped with the logical technology component in Togap. And a device and a system software can be mapped to a physical technology component. And both of them can be related in a taxon of the definition or with the realization relationship in Togap like you will see on the right side of this particular slide. Again, it would depend on the conceptualization or the particular situation. Also, we have difference with dynamic relationship. Another big difference is like Togap is not making a classification relationship. And we have, for example, in Archimate, we have like the relationship that are more like for structure and it was the right dynamic. And for example, for dynamic, we have the flow relationship and the trigger relationship. Or we also have the ones that are like, they can be like a node and or a junction relationship. How we can map this with Autogap, we can also use the Togap control elements which is part of the process extension in Togap content metamode to depict that. And also, we can use the event element that is also present in the Togap content metamode to depict, for example, that one process is triggering another one or is having some kind of controlling them. We can either represent a Togap control element in there or an event that is actually triggering the other behavior. So in that sense, we can see like we can do this mapping. Also, the use and use by this relationship that we have several mappings. If you go into the detailed document, you will see that one single relationship in Archimate could be count three or four in Togap. Again, how we can use this, it will depend on the proper context when we are making the modeling. And in real cases, we do that. Like we said at the beginning, we have some specific needs in our business and organization to model. And so you choose using Togap as a general framework. We can take the content metamode or it can take another one. And also, we can pick Archimate like a modeling language. And at the end, we'll come up with our version of Archimate and Togap and we can also make some changes or specialization in the elements. That's the way that Archimate can be extensible. You either using specialization or you either using profiling. For example, in this particular case, we have in Togap with a process and a service, one of the relationships that can fit in there is support on orchestrates. This can be also represented in Archimate using the use or use by relationship and the realization relationship between a business process and a business service. And this can also apply to the different layers in Archimate that are used in that relationship, use and use by. So you can, again, you can go into the mapping that we have in the white paper that you can download in the open group site. And you will see there how we have made a very specific and detailed mapping with these differences that we are making here. But the main thing here to have clear is like the, how are we going to use a particular relation that will depend on the needs that the stakeholder are asking about a particular model. Also, the access relationship. We have a very specific access relationship that is mostly between active and passive elements or entities in Archimate. We don't have a specific access relationship into Agaca Web, or if we see the relation between, for example, a business service in the data entity, we see that the relation can be there either consumed or provided or accessed by. And at the end, it's similar because you will see that, for example, a particular business service is accessing or having an access to the particular business object in order to consume some of the information that is inside the data entity or provide some information to this particular data entity either for consultant or for update or for access. So we can see that could also be a very good map. And again, we can have the access, the particular needs that we are having for making the model. Having, of course, in mind that the main goal here is to address specific stakeholder concerns and needs. For implementation, I'm a written extension. I think that's interesting because if you see talk of content metamode, you will see that we have, like in the upper part of the model, the content metamode, you will see different entities like, for instance, the work package, the deliverables, the requirement, the principles, and all of them are related with the rest of the elements or entities in the core metamode. A archimage handle is different because archimage has a very specific extension for implementation and migration. So like we are seeing here in the example, we have the gap, which is relating to different plateaus. Plateaus is also an element that does not exist like that in Toga. This is a difference that is also the picture in the entities mapping. Also, we can see like always with the app, we have to relate the particular work package and the work package will be delivered or realization or providing some specific core elements like in this example, application components. So since we have more specific notation in the entities and relationship in the implementation and migration extension in archimage, I think that that can really be used to leverage Toga for phase A and F are the phases in which are actually making the solution building blocks models and the actual implementation model. So in this way, I think that this difference that there are between the two standards are really telling us that archimage is made to deliver more specific notation modeling and just Toga is just providing the general rules. So some key financing here, for example, we have here another example, some of the relationships that we have in archimage, they have not like so clearly the governance meaning like that we have in Toga, like the govern and measure by relationship that you will find between a service and a product. But we do have, for example, in archimage definition of a product that approaches a collection or an aggregation of business services and a contract. So we can put additional elements or governance and measure in a contract and in that way, you're also fulfilling the need that Togafis is talking about regarding governance, how a particular business service, how to be in govern and measure by a contract. So that can also be depict and use applying different entities and different relationships that we also have in archimage. Okay, well, thank you very much, Sonia. Okay. We're now getting to our final topic, which is putting all these things together into a set of viewpoints that the stakeholders can basically look at to see that their concerns are being addressed. Serge? Okay, so the next subject, first, there is a few findings about the mapping between the viewpoints between Togaf and Archimage. So the first thing you need to know that there is a document that you can obviously download with the link, which will give you, I think, five different examples. So I'm just going to present one of the five. The other four will obviously be described in that document that you can download. So a few observations. You need to also to realize that that document is obviously done to explain how you can take one viewpoint from Togaf and transform it into an Archimate one. It's working quite well together. Sometimes there is some modification which requires to be done. Sometimes you need to adapt, but sometimes you may also find that the viewpoints that are different are very different. So when you will look at that document, you will see that we don't use scholars, but we use a shading approach when there is no real match. So you'll see in that document at the least of the different existing viewpoints from Archimate to one from Togaf and when there is a correspondence. So the structure of the document is the following. You have the name of the Archimate 2.1 viewpoints, which is obviously related to one of the sections of the specification. Then the description of that viewpoint from Archimate. And then we map the different Togaf 91 artifacts. When I say we map the different one because you can have, for example, one viewpoint from Archimate and several Togaf 91 artifacts. Sometimes it's one, sometimes it could be several. Then the description, which obviously maps to the definition of the artifact, and also, finally, the phase where you're supposed to document that artifact, the phase of the ADM. So here's an example. On the first column, you see introductory viewpoint. Then you have the description of the viewpoint. Then there is the mapping on the right side where we say that an introductory viewpoint may be quite similar to either a solution concept diagram or a business footprint diagram. Then you'll see that the descriptions on the right side obviously relate to the Togaf 91 artifact. And the last column is referring to the ADM phase. In this case, the phase A. Here in these situations, we have also one example, the first line where we have a business process cooperation viewpoint, the descriptions. We say that we have a correspondence with an even diagram part of the phase B. But as you may have said, the second one, the product viewpoint doesn't have something equivalent in the Togaf 91 artifacts. So this is why it's shitted out. And the last one is the same one. There is no Archime 2.1 viewpoint referring to a benefits diagrams within the specific. So that will help you to see how you can eventually automate from one standard to the other one. So here's an example. This one is based on one of the Togaf artifacts. Obviously, every company had different ways of muddling the different artifacts because there is not a standard as we have in Archime 8. You're free to have different sort of shapes. But when you look at the specifications, you're supposed in an organization the compression diagram and viewpoints to describe the auction units, the locations which are in red. Here we also see actors in green and the roles in yellow. You have probably seen before that there is no correspondence or there is no auction unit in Archime 8. So you have to identify how am I going to transform that artifact from Togaf inside Archime 8. So you may say that also an organization is a type of actor. So then you can end up with different ways of doing the muddling within an Archime 8 diagram. So the first one, which is on the next slide. Oh, sorry. I just forget to add the description here which refers to what means, obviously, an organization within the Archime 8 specifications. So as you see on the right side, here we have a viewpoint called Archime Viewpoint on the Archive Viewpoints with definitions where we say it's focused on the organizations of a company, a department, a network, and so on. And what I've done here is just to recreate the name of Archie Enterprise, HQ, Division A, Division B, and then the different links to the different locations on the right side and on the left side, the relationship between actors and roles. As you see, I've transformed the auction units and subunits into actors in Archime 8. And I've added collaborations between the two business roles. So you see, you will have to interpret and see how it works for your organizations. So that's one possibility of transforming the Togaf artifacts into the Archime Viewpoints. And the second possibility would be that you define everything as actors. So here, I've added a third level. So I see my Archie Enterprise, which is an actor. Then I see HQ and Division A and B, and then the different actors like C, O, V, B, and so on. So that's two ways, in fact, of representing the same Togaf artifacts. So that's going to be the tricky part of the exercise. So the mapping clearly shows that there may be interpretations between auction actors and roles. But at the end, when you present the two different viewpoints, they may look slightly different, but they can read the same message. So the conclusions is that you should first really understand the meaning of all the different elements from both specifications to do the right level of mapping. You also may need to adapt that terminology to fit with the organization, something you will address while you do the primary phase. And sometimes those viewpoints may have to customize, adapt it, or they may be to be changed to address the stakeholder needs. So that's the way you will have to do it. Also remember that when you develop your Togaf artifact, there's not a standard or predefined shape, as we do have inside Archimate. But the idea is that you try really to align the essence and the message that you try to pass to the different stakeholders. Well, thank you, sir. So just to sum up, before we go into our questions and answer sessions, I think the two frameworks are very compatible and complementary to each other. But not surprisingly, there are differences. And I think we've addressed some of those differences. Our papers, obviously, get into much more detail. And so you can take a look at those. So we're identifying, Project Harmony is trying to identify the differences and proposed ways of resolving them. So I think as far as the practitioners go, our papers that we published basically have that information. And now as we move on to other activities with Project Harmony, we're looking at ways that we can improve the standards in the future and some things that we might be able to do to kind of maybe resolve some of these differences that we see, things like that. So anyway, just to sum up here, we have the documents that have now been published all for and out on the Open Group website. There is a zip file somewhere. I don't know exactly. It should be right there that has all four documents that you can download in one zip file. I didn't see it this afternoon when we were looking around for it. So I might have moved someplace. But if you go to the Open Group Publications Library, there's just a whole bunch of really good information in there about TOGAP and ARCMAID and other standards from the Open Group. But the four documents that we've got are listed here, along with their publication number, like W14C for the Practitioners Guide and A for the Harmonization of Glossaries and et cetera. So I hope that you'll get a chance to take a look at those. I certainly would start with the Practitioners Guide and then if you need more information, I would recommend that you take a look at the other more detailed documents. So with that, Simon, I'm ready to field some questions. Question from Kevin. Can you just elect to adopt ARCMAID as the meta model to represent a TOGAP model? And he says, that is use ARCMAID instead of using that part of the TOGAP meta model. Yeah, I think that that's exactly what we designed, the content framework in TOGAP so that it could be replaced with another content framework. And so I don't see any reason why you couldn't do that. So let's just say, for example, that the TOGAP viewpoints are not consistent with the way that you want to present things, then you could go ahead and just switch totally over to an ARCMAID content framework. Or you could try and adapt the two and try to get some of the models that are in TOGAP and create viewpoints in your modeling tool that would do those things. And within certain limits, I think you can do that. I think I agree with Bill's response. I think like we said at the beginning, you can use TOGAP with other framework. Or you can use the content meta model and use another modeling language with BPMN if you're modeling, for example, processes or UML. Or you can choose ARCMAID. Or you can take also the decision and say, OK, I have my interpreter to frame. What is the language with TOGAP? But for modeling or for content framework, a rather use ARCMAID is also a very valid decision. And at the end, I think it would depend of our stakeholder concerns and needs, even for the viewpoints. Because even though ARCMAID and also TOGAP has a list of suggested viewpoints, that doesn't mean they are written in stone. I mean, my point is like, for example, if you need a new viewpoint, for example, depicting some kind of product lifecycle, for example, or product categories, you can take a viewpoint, a system viewpoint, and make some modifications on that or create your new point and a viewpoint for that. And for that, you will use different elements and entities. And also, if you see the difference that we have pointed out today, they are all related. Because if you have differences in terms and terminologies, then that will lead to having also some differences in the entities, because the different metamosas have different levels of detail. And at the end, that will lead to difference also in the relationship and in the viewpoints. So all of them are related. And the core thing here is to choose whichever option will fit better for your organizational needs. Great, thanks, Sonia. This is a question from Paul, asking, what will be the next steps in terms of truly harmonizing TOGAP and ARCMAID and making ARCMAID the language of TOGAP? I may take that one, Bill. I'm currently working on the phase two, which started just before Christmas. So what I've been doing right now, for those interested, you may obviously join that project. The idea is to compare obviously all the different terms from the glossaries, from both standouts, then come with recommendations, try to come with a single definition when it's possible. It's not always possible. Sometimes the definition doesn't make much sense to be added to TOGAP or the other way around. Doesn't make much sense to put in ARCMAID. But sometimes we try to find a solution. A good example would be an actor. So we have two definitions between the two standouts. Or for example, an organization does not exist within ARCMAID. So maybe the answer could be something like, well, we want to create the specializations of an actor, which could be an organization. So this is work in progress. At this moment, I've been working on more or less under terms, more to come. There's a team of people who are going to review and come with a list of subjects that request for changes for both framework. Obviously subject to approval. But I was really interested in not fusing the two standards together, certainly having a high degree of interoperability between them is not a bad thing at all. It's just we don't want to create a single standard. We want to keep them, if some people just want a modeling tool, they should be able to use that without TOGAP. If they want to use TOGAP or some other modeling language, they should be able to do that as well. Okay, yes, I wanted to support also that response from Bill and also from Serge. I think our idea with this project, in fact, part one was the main goal was to deliver the white papers. And phrase two is just beginning, like Serge said. And the goal here is to come up with some change requests for both the specifications in order to get them work better together. However, it's not always a tension to merge them. So you will continue, for example, your decision is to use TOGAP with another modeling language or you start to make with another framework like SACMAN or TOGAP, you can also do that. Our idea here is to try to harmonize both standards so it can, if a practitioner decides to use TOGAP with ARCHIMED, it would be easier than the way that it is right now. But it's still equipping the boundaries in what happened if we need to use TOGAP with another modeling language or ARCHIMED with another framework. So that's like two different levels of harmonization in here, okay. Excellent, well, I'm just keeping on the time but I think we've got just a matter of the time. So one last question, this question is from Chad. They asked, which one of the publications would you consider the master data model or ERD for the entity crosswalk between the TOGAP 9.1 framework and ARCHIMED elements? Wow, that's a great question. Hard to answer, really, because I think it's very context-dependent on your enterprise and your modeling too. Yeah, I'd say the TOGAP framework is pretty grand in scope, but it doesn't go as detailed as the ARCHIMED language does. So could you create a common library of entities and relationships that would achieve both objectives? I don't know. I think you would have to make that decision yourself. And it could be that somebody would publish a white paper that might suggest how to do that. That would be a great thing to think about. I think that if it comes to the white paper, so I will start with the practitioner guide, which is like the master document. And then if you need more detail, like Bill said, because you need more detail for your particular situation, I'll go with the glossaries and then the meta model. I mean, the order in the white paper I showed in the slide, because when we go into the meta model and then in the relationship harmonization, you will see a very detailed tables in there that will show item by item, the mapping between the two of them, and that can be useful. But again, it will depend on your needs. For example, if you're trying to harmonize your information or architecture, you will look for specific elements into both standards that can be harmonized. And if you're trying to look for harmonization in your business architecture, then you will take the elements and the entities that will belong to that particular domain. So I guess it would depend on the particular need that you have. Okay, well, I think this is a good time to close today's event. I'd like to thank Phil, Serge, and Sonia for today's presentations. And I'd like to thank you all for attending today's event. Please do keep an eye on the open group website for future webinars, which we will be scheduling in the near time. So once again, thank you, everyone. And I'd like to say goodbye. Bye-bye. Thank you. Thank you. Thank you for being here. Bye.