 Thank you very much to all the attendees that we have today. Our subject today is Promoting Interpreter Technical Mobiles, Knowledge, Interchange, and Business Miley Using Archimedes, and for that we are going to have a group of speakers and it's me, I'm Sonia Gonzalez from the Open Group, I'm the Archimedes Forum Director and it's a pleasure for me to be here today to share this information with you. We're also having Phil Vivier from Archie, our Maker for Business Design, Alain Brunette from Corso, who we're part of the team that work in the standard, and also Andrew G.S.C., which is our Director of Standard for the Open Group. So all of us want to welcome you to this event. A little bit about the agenda for today. First, we're going to explain why we consider having this exchange file format is important for the community and for Archimedes. Then a little bit about business value perspective, why is this standard delivery in value and who are the main stakeholders that will receive these values? Then we want to talk about a brief technical overview on the format and for that, the technical experts that are actually the ones that have worked in this standard development with the liberal explanation and that. Also, we have the current tools that are supporting the exchange file format that in this case are Corso, Business Design, and Archie. So the three representatives will be sharing their experience with us about this. Then we're going to have a demo about how the exchange works from the different into different tools, future plans for the format and the actual state of the standard, and some final conclusions. And at the end, we are having a questions and answers session. So first question, why it is important to have an exchange file format for the Archimedes standard? And for that, it is important to go a little bit background in here. First, before having this format, this standard, Archimedes models were creating in different tools and in different formats, even though all of them were compatible and compliant with Archimedes, they were made in different formats languages, so that's why they were locked in just one tool. And it was not easy to share all that comment and that content. The existence of different formats was an issue for consultants and vendors is their custom of how difficult sharing information through the different models and also in some cases migrating from one tool to another, it was a real issue for the end users if they have to redraw that again with the lack of consistency on the information and also having to spend more money, time and effort and having to order reviewing everything again. So that's why the relevance about having this standard is because it preserves user investment in the development of the Archimedes models. And on the other hand, it frees the model from being just locked in one tool. So now we can be sure that even though the different models are compliant with Archimedes, now they can also be shared in a consistent way and between the different tools that are actually using this standard and like we said at the beginning, it's saving money and effort and also it's delivering the confidence that the information that we are sharing is really being representative and being accurate. About the business value perspective, I think like the business value is not only for modelers or technical people because at the end what we do when we do enterprise architecture is to deliver a landscape of our organization in order to the leaders to take the final key decisions that are related with business and strategies. So one of the main advantages is that we are supporting interoperability and information exchange between organization, organizational areas, vendor, different sectors, different vertical, etc. in a very consistent way and making sure that they'll be in conformance with the standard. If we go into end users and decision makers, for example, the CAOs and other key stakeholders, interorganizations, for them having the possibility of inter-exchange model will allow them to have better information provided for strategic and business stakeholder decisions. So for example, in this moment, we know that the pressures on the market are forcing us to have everything together. We have our businesses now surrendered by another one, so we have a whole value change in which we have to be interactive with our customers, with other business partners, with alliances, with another organizational body. So for this, it's really key to have the way to interchange these different architectural descriptions and being able to have a unified view about all this. For monitors, architects and designers, they are also able now to interchange with colleges, another related organization, and share the knowledge. And that way, we are also supporting having a real networking of information and a real knowledge base of models, a real model repository that is now more global. And like we said also at the beginning, this issue has also operational advantage in the sense that now we are able to migrate between different tools with the corresponding tape and money savings. For vendors, now they share information with business partners and other alliances easier so they can build this value change for the final customer. And for example, if you have a large project in which there are three or four vendors involved, so it's not an issue anymore if every vendor or every part of the team will deliver a specific part of the model because at the end, all the information will go into a common repository. It's also easier for customers to migrate from one tool to the other and to also perform some benchmarking between tools and also to test for conformance. For consultants, they are actually working with final users and one of the key issues is how to define and compose a repository in which they will have different models mixed together. So this is also being consultants work easier with end users and explaining them that even though they will have, for example, one tool and then use another one for another part of the organization, it shouldn't be an issue anymore because at the end everything will go into a single repository. And this is also very good for trainers because it's a good way to explain and teach about interoperability and cooperation and also to explain to their students how the different tools that are argument certified are working together and collaborating in this new interchange standard. The session now we're going to give the control to Field and it's going to deliver a brief technical overview about the format. Okay, thank you, Sonya. And hello to everyone who's listening in. Yeah, I'm Phil Beauvoir and I work on Archie, the open source Archimate tool. And I've just been asked to represent the other people on the project who have worked at the technical level bringing the Archimate Exchange format out. So we've been working for a little while together between various vendors and the open group to work on the Archimate Exchange file format. As Sonya says, there's something that's really quite important to add value to and users and tool vendors and customers. The design features that we decided on at the early stages were the bullet points that you see in the slide here. We decided that portability was an important issue for importing and exporting a model file. It should be software and hardware platform independent and then there's completeness. So it should be possible to represent a model file accurately when moving between tools and to represent the concepts and relationships as defined in the Archimate 2.1 specification and any graphical representations, i.e. the diagrams. It should have robustness to errors. So it should be possible to detect errors at an early stage when importing and exporting between tools. And obviously there should be interchangeability so that any tool conforming to the standard will be capable of reading and writing all conforming model files. And flexibility in that future extensions to the Archimate language and any possible vendor-specific additions should be accommodated for without compromising the robustness portability of the exchange of the standard model files. So the exchange file format should at the very least be able to convey from one tool to another the basic Archimate concepts, relationships, attributes, objects, and diagrammatic information. So we have all of the Archimate concepts, things like business actor, application concepts, and technology concepts. Those need to be exchanged obviously at the semantic level. We need the relationships, the Archimate relationships between those objects. That information needs to be exchanged as well as diagrammatic information. Now some of these things are going to be more optional than others and some things are going to be extremely mandatory in what we exchange. So we do need at the very least to exchange model information relating to the concepts, the relationships. And if we can get diagrams as well, which I'll come to in a minute, then we're on to a win-win situation. I must say what the file format is not at this stage. The exchange file format is not intended as a native file format in the same way that you might find that XMI is used to represent UML. We are not using that kind of notation, that kind of representation for Archimate because there are too many problems around defining the Archimate specification. There are a lot of loose ends. There are a lot of fuzzy areas with Archimate. And in order to use, sorry, in order to create a native file format for Archimate, then we would have to, for example, look at things like XMI and MOF and all of that kind of stuff. So we made the task for ourselves to concentrate on exchanging file format information between tools, and the tools therefore have to be Archimate aware so that there's no implicit metamodel in the exchange file. When you receive a file as a tool, you must know what those Archimate concepts are already. You must know what those Archimate relationships are in order to make sense of the file, the Archimate exchange file that you're receiving. Okay, kind of the next slide, please, thank you. So going back to the requirements for the exchange file format, as I said earlier, it should be extensible to allow for possible bend or specific things. Obviously the language is going to change. There will obviously be future versions of Archimate. We need to keep that in mind. And we obviously need to contain enough information to exchange a model usefully between tools and diagrams. Next slide, please. Okay, so carrying on with the requirements, the first requirement started off with simple things like shall include an identifier for the version of the Archimate language supported. Okay, so this in our case is 2.1. And then once we've established that, we know that there are a finite number of Archimate concepts and relations that we can exchange. And also shall include metadata about the instance of the model being exchanged, metadata being things like purpose of the author of the Archimate model, those kind of things. And a model without additional textual value is not much use. So we need to support exchange of documentation. And documentation applies to the model itself and also to the aggregate parts of the concepts and relationship. And also to support optionally localization, because not everyone's speaking one language. So when we see diagrams with labels and documentations and properties and attributes, those need to be in more than one international language. So we decided that we needed to support that as well. Next slide, please. Okay, so we've established that we're not going to come up with an XMI type of definitive representation of an Archimate model because of various problems inherent in that. So we're actually conveying information from A to B. We're packaging the model information to get it out from one tool to another tool or from that tool to yet another tool. And so the easiest way to do this is to express the model or represent the model rather in XML backed by a schema, an XSD schema to validate the well-formedness of the XML. So there's no representation of a meta-model, of an Archimate meta-model per se in the XML, other than one that's implicit in the structure of the XML document. So we chose XML after trying a few other things. One thing that we did try was OWL, which is the web ontology language that proved somewhat problematic in representing things like diagrams and colors and that. And also some of us were finding problems in actually implementing it in our tools with the availability of OWL libraries. So we went with XML and it was something that we could work with quickly and it's well documented. There are many plugins and tools available for vendors to use and it's proven for other exchange and interoperability file formats and allows quicker progress all around. And you can incorporate other XML standards such as Dublin Core metadata, something that you could add onto your model to use it to describe it so that you could add additional information about the model so that if you had models in the repository you might search on tags or authors or rights, that kind of stuff. Next slide please. Okay. So this is what we're looking at here is actually, I suppose it's a kind of UML model of the implementation that we put in place. You can see that we've got the white box at the top, which is the Archimate model. Obviously that is the container for other things like metadata for elements, relationships, properties and attributes. That's another thing that we wanted to include in the file format so that you can add things like cost, other metrics, other attributes in Archimate language or properties to all of the concepts. These are additional things that we can add to the XML. Thank you, Phil. All right, this is Andrew Joseph here from the Open Group. Just to give you a little bit of an update on where we are with where you can get hold of the standard. The standard was approved by the Open Group in July and published in August. You can download it from the URL shown here. You will need to register for an Open Group Web ID if you haven't already got one. As well as the standard itself, there are a number of supporting items such as schema documentation and a number of example models. There's also an online resource site which we're seeing here so you can go to www.OpenGroup.org.xsd.archimate. As well as containing links to the standard, that contains a link to an implementer's guide and the FAQ. We've actually put together a guide to actually help other tools suppliers who might be thinking of implementing the format to explain some of the best ways to do that. Next slide, please. The other thing the Open Group has now started doing is adding models to its publications where applicable. Here you will see for this white paper, which is about the TOGA framework with the Archimate, using the TOGA framework with the Archimate modeling language. We have some Archimate examples within the white paper. Now we actually also publish the XML Archimate Model Exchange file with that and there's a couple of different models and case studies that we've published using that. You can download the Arch assurance and the Archimental case study. Lastly, we're actually starting to see that there are other uses of the XML format. Here's an example that was contributed to us by Diffie in Norway. They've actually been able to generate information about models using an XSLT style sheet. This is actually something that's very simple to do. We're actually starting to see these spin-off ideas about how you can use the Exchange file format. I think we've also seen another paper written by a Dutch company about how they're importing the XML models into a database and being able to do searches about relations and so on. So it's a very flexible format and it's very easy to understand and use. Okay, back to Sonja at this point. Okay, thank you, Andrew. Now we have delivered an overview about the standard and about the advantages of using this standard and the different resources that we can have in the Open Group page. We are going to also go about the current tools that are supported in the Exchange file format. And for that, we are going to ask the three representatives of the companies to talk a little bit about their experiences while delivering this standard format. Okay, Sonja, thank you. My name is Arn Baccar from BizDesign. Together with my colleague, Franz Pazer, we worked on defining the ArcMate Exchange file format. And we have implemented it in BizDesign Architect in release 4.7, which was released this summer, summer 2015. And we have implemented it using our BizDesign scripting language, which makes it easy to extend later on. Should use versions of the ArcMate language, here for example, that can be catered for quite easily by extending export and import script. So there are two scripts, one for importing models and one for exporting models. And the benefit of using the Exchange file format is, of course, that our users can rely on one well-defined format for importing and exporting models, irrespective of which tool they come from. And of course, as one of the leading artisans defining the Open Group's ArcMate standard, we adhere to the open exchange of architectural models between tools. And as a plus for us as a tool vendor, it's also good that we don't have to write that many import scripts for each tool we know of. So we can simply rely on that other tool vendors also implement the same Exchange format. And as a plus also, BizDesign Architect supports multiple modeling languages such as English, Dutch, French and German and Spanish. And these can also be exchanged using the Exchange format. Back to you, or back to... Yeah, hi, everybody. My name's Alan Burnett, of course, hey. Just briefly about us. We provide tooling, hosting and services to support EA and more specifically ArcMate. About four years ago, we built a plug-in to System ArcMate to support ArcMate, and actually now we've got an additional web platform that does that as well. Back in the summer, we implemented the Exchange mechanism to that plug-in. You can access that by a simple menu item for both export and import. You can also choose which elements you want to bring in or export at that point as well. I mean, for us, the key drivers to enable the exchange of models has been described in this presentation because we do recognize that they're on the site of an engagement. There could be multiple tools and partners involved. So if the tool of choice is cool or there are multiple tools on site, then we can focus more on business outcomes rather than get hung up on tooling degradations. We're very happy to support this exchange program. If you want to know any more about us, then obviously you can contact us. Thanks. Yeah, hi. As far as Archie's concerned, Archie's built on a plug-able framework, the Eclipse framework. So it was relatively easy to implement the exchange format within Archie to import model representations in XML using a JDOM plug-in and some handcrafted code. So Archie 3.3, which is the current version of Archie, supports the open groups, Archime Exchange file format. If you download Archie, it's there in the file menu. You can work with a model. You can select the export to the Open Group Exchange format option to export a model in the XML file format, or you can import one as well. Under the hood, there's some validation going on against the schema. So Archie will validate any XML instance against the XSD schema and tell you if there's something wrong with, which there isn't something wrong with it, between the tools that we've been testing, but should a tool incorrectly implement the exchange format and create an error, an erroneous exchange file format, then Archie will shout at you and tell you that there's something wrong and go back to the person to fix it. So yeah, it's all there. In Archie, it's a plug-in, and it was thanks to the Open Group, they sponsored the development of the Archie plug-in and my work on the exchange format. So a big shout out to them. Thank you for that. And that's what we've done. Okay. Thank you, Phil. Thank you, Ellen. Thank you. So we are going a little bit about the demo of the model exchange and for that, we have a set of slides in which, again, the different vendors will go over the different steps and we'll deliver an explanation about how the interchange works in real time with the tools. Yeah. So this is the file as it is being exported from Bitisan Architect. In this case, we started with Bitisan Architect doing the first export. And what you see here, after you have run the script from within Bitisan Architect, you see here the results, the XML results. What you can't see is that all of the methods, all of the objects and relations and the graphical information is within the XML file. What you see on this screen is also that international information, the languages we support, like English, Dutch, French, et cetera, are also being exported in this XML format. And we have run the demo by means of a set of slides that show you how the export that started with Bitisan Architect shown on this screen. When you want to export a file, you just select the model in the model browser on the left-hand side of the screen, and then you will run the export script, which is quite easy. And in this view, you see some details that we changed in this model. So we made one object a red color, one object with some thick lines, and one object with some grayed-out text, and these are all there to illustrate that all this kind of graphical information also gets exported and imported in the tools, in the other tools. So let's continue to the following tool. Yeah, okay, thanks, Ham. So as Ham said, yeah, in Bitisan Architect, you can export the model to the exchange format, which Harman-France did, and then I took that XML file and imported it straight away into Archie. And looking at it, I think it looks pretty much the same as what we were seeing in Bitisan Architect, except for a few things which I should point out. Not every tool implements every graphical feature. So I think there's a thick line missing, maybe, because one tool does not implement line thicknesses, or another tool might not implement things like alpha or shading, that kind of thing. One thing I had to do when I imported it was I had to make some slight adjustments to the connections, and this is because Archie implements connections differently to how Bitisan Architect implements it. So it's something to be aware of, that when it comes to diagrams, there is going to be a loss. There could possibly be a loss, I should say, somewhere along the line, simply because of the way that the tool might implement its graphical representation. Okay, so now I hand over to Corsa. Hi, so we did a similar exercise here where we took the model from Bitisan. So from an imported perspective, we can select an import file. It's very simple. We actually can choose all of part of that model that we wish to be imported, so we don't have to take anything. So that's one advantage. In terms of the views, they're mapped to the relevant diagram in the tool, and all the objects are mapped to their relevant definitions with their associations. What we can see here graphically is that we've managed to maintain the colors the bolding and the lighter text. So we've replicated most of this. As Phil said earlier, you do have to get around the fact that different tools handle different things in different ways. Some of the line-routing will be from system architect because we can manage the bend points, but actually starting end points do depend on the tools they come from. And so we've made an adjustment for that. But as you can see here, there's pretty much replication of that. I think I've also got the next slide as well. So that's the next slide. So now we've come through the process of how to do this design into Archive and then into system architect. So pretty much held on to all the information again. You'll see that the bolding of one of the boxes has not been brought through. So I guess that's the hop that we saw through one earlier. And we can see some of the indirect relationships we have in these red lines and the tools. So that's maintained. So maybe there's a little bit of time to develop, but effectively we've got the same structure. So all of the model information is maintained. There might be some symbol. There seems to be something similar here that's pretty close as you can see. Okay. Back to Archie. And so what we're seeing is a bit like Chinese whispers. We're seeing the business design import from Corsair imported back into... No, is this... I'm looking at the wrong one. Let me take this still. Yeah. Sorry. You see what happened? It looks... Chinese whispers here. Yeah. It looks so close to Archie. I thought it was Archie. See? And this is especially exchange format. Yeah. This is a good example. What we see here is the causal import of Archie and re-imported into business design architect again. And what you see here is some things to note, of course, is that the graphical information is not imported all as such. You see the grader text and the red symbol. That's okay. But the attachment points of the lines, they are not well transferred now. So you need some post-processing to make this model look like it did when it was exported. And another missing thing here is the labels, the names on the relation lines. They are missing as well here. So that's just an illustration of the point that not all of the graphical information gets transferred, but most of it is transferred quite good. Sorry about that. I genuinely thought that was Archie there for a moment. I put my glasses back on now. And yes, back to Archie. So resuming our program, this is imported from Corso, who had previously imported from business design. Okay. Lost a little bit there. Lost some, as Arm said, lost some of the labels on the connections. But fundamentally, what we have exchanged, we always exchange the semantic elements, the model itself, the elements and relationships. Of course, something to remember, this is version 1.0. And there are some improvements we could possibly make. And this is probably something that could be looked at in future versions. But as you can see, between the three tools, between business design architect, between Corso's tool and between the Archie tool, we're getting a very good 95% integrity of exchange here. I just want to talk a little bit about our future plans. So a couple of areas we're looking at as we move towards the future. Firstly, we're looking at mandating the support for the exchange file format as part of the certification program. So what that would mean would be that all ArchieMate certified tools would be required to support the format. So we're looking at when we can bring that in. Obviously, there'll be some testing that we want to introduce to assure that. We're also investigating exchange of incremental updates for a model. So instead of importing a whole model, it might be that you could send changes across to another tool. Obviously, that's slightly more complicated than something we'll have to think about. We'll obviously be also supporting future versions of the ArchieMate standard as they arise. And the other thing is we're looking to have more tool suppliers supporting the standard. So those are our sort of future plans that we're currently thinking of. Back to Sonia at this point for the wrapper. Okay, thank you very much, Andrea. And thank you also our three-year vendor representative for the demo. And making a little bit of wrapping up, just we can go to questions and answers. As we know, right now we have to face a lot of competitive markets that are demanding for the real and truly boundary-less information flow between organizations. So in this sense, information exchange becomes a key issue for different organizations no matter in which sector or vertical they are. And also related with that, we have now architectural descriptions that can deliver and should deliver organizational overview and value and improve decision-making. Both for that, it's important to deliver a holistic assessment on that. And we can only accomplish that if we integrate all these different models through the whole value change. In this context, we see that the EA model interchange become critical to deliver this integrated view through different organizations, different vertical sectors, and different types of organizations between different tools. And for that, the Archimade exchange for our format, it's delivering this, it's supporting this, and it's a very efficient and a good way, a precise way to make the interchange like we could observe in the demo. Basically, the model was looking exactly the same with a few differences within the different tools, which is saving a lot of money and efforts between different organizations and vendors. Also, we know that the industry has a hole. It can obtain a huge benefit through the application of this Archimade and model exchange for our format because now knowledge can be shared. Benders can work better together, can cooperate, and can improve the workforce to the market, to better alliances, and deliver better services to the final users or end users that can actually start sharing information in a more efficient way. We also know that EA is a growing discipline, and then standards of Archimade can support it better if we know how vendors and implementers and consultants that can't talk to each other in a more consistent and easier way. And we can facilitate, for example, as we saw in the demo, a model being migrated from this design and then to Corso and then to Archie in a continuously way and keeping the key information and also keeping all the conformance with the standard, which is delivering a lot of value to the industry as a whole. And finally, we know that we as Open Group we support Open Standards that will deliver value to the community, and for that, the Archimade exchange file format, is supporting all these key issues, and it's also promoting a better networking among the different communities and users, vendors, consultants, and trainers. So that's the wrapping up that we are making about the standard. And we really hope that this content has been valuable. And now we have come to the point of some questions and answers, like Simon explained at the beginning. The process was to write down your questions in the chat dialogue, and then we will ask Simon again to start reading some of those questions, and we will try to deliver the proper answers as a group. That's great, Sonja, and thank you, panel, for that presentation, explanation. Yes, we do have a few questions in. First of all, question from Anne is asking, does Aris also support the exchange file format? This is Andrew. I'll take that one if you want. I think the answer is we don't know at this time. The only tools that we are aware of are the three that have been involved from the start. Obviously, we've got the information out there to help implementers, and we're more than happy to work with other tools suppliers to get them to support the format. And we'd invite them to come and participate with us in doing. We have sort of an interoperability testing area that we have where we do this exchange of models. That's where we are right now. That's great. Andrew, thank you for that. Question from Rafi asking, how about security in model exchange? I think you did just to clarify a little bit more about the security. Who would like to take the question about security in models exchange? Well, I'm not an expert on it, but the thing that occurs to me when thinking of that question depends on the context. I come from an open source background. So for me, it's not an issue. People want to share models to learn, but in-house I suppose it depends what you're doing. I think it may be an issue for the end user. An end user might work with more than one tool. An end user might in one scenario simply want to let's take the scenario of getting a model out from Archie and into course of system architect, for example. I don't know whether security lies in that. I suppose it's like anything else in the issue of sharing data around security issues. Thank you, Phil. Can we start somewhere or is somewhere already available and he's saying some site where an Archimate template or Archimate templates are stored, but he also says also ERP delivered business models are stored. Are there such templates and if so are they available or freely available at the moment? Okay, so I think Phil, would take that and perhaps the rest of the families can also help me out. I think in terms of Archimate templates, if you go into the open group site, you will see several Archimate and Togo publications and some of them are actually case studies and ways to start using Archimate. If we are talking specifically about the standards in terms of starting using the tools, we also have the register of the different tools provider that are actually Archimate certified, so you can also find the information to reach the different vendors and ask if you are looking for a specific implementation on the standard. Okay, thank you, Sonia. Just picking up on the security issue, we have another supplementary question that asking are these exchange formats password protected? Phil? Yeah, I was just waiting in case you wanted to answer that. Very simple answer to that. No. There isn't any password protection or encryption in the exchange format. It is just an open XML format. It makes me think about, I mean, if you are using one of the tools in-house, in your organization, do they support password protection already? I'm not sure. I suppose it comes back to that issue of securing data internally and in-house. Yeah, I think, I'm afraid, just to add to that, I mean, I do get involved in quite a lot of security, especially dealing on the cloud. I think if you have the internal processes that allow you to make sure that anything you handle is, if you handle customer data or internal data with passwords and protection, then I think it's more about the processes you put around it, as opposed to something inherent in the exchange exchange. And if you're on the cloud, you obviously have to be more careful about how you handle data. So for me, it's more about an internal process, I think. Okay, thank you, Alan. A question here from Henry Kay, asking, does the Archie version for Mac support integration with Corso and this design? If you mean by integration, does it support the exchange format, then yes, the Archie version for Mac has exactly the same features as the Archie version for Windows and Linux. Okay, thank you. Moving on a bit, also the version of the architect that can run on the Mac can run in parallels or doesn't run native on Mac, but when running so, of course it will support the exchange of data from either Archie or from Corso. Okay, thank you. A question from Sandy, how is this different or better from EDI data model exchange? Maybe to add a bit on this EDI model exchange role, as I can recall, just exchange the semantic part, like the objects in the relations, but not necessarily the graphical information, which is quite a big plus of this exchange format, I think, because the graphical models, the views that you make are quite some work and it's good that you can exchange them in an open way between the tools. Okay, thank you. I've got a question here from Zolt, but it looks like it may have already been answered within the Q&A, but I'll ask it anyway to the Q&A and do it to create an entry standard for EH change format, or have you already done this? Sonia? Okay, like Andrew just explained, we are open to how more vendors participation, and actually MEDA, it's also a certified tool as one of our members, so we have been continually working with them. So at this moment, like Andrew just said, we are not aware and there's all the resources space that we just showed about how to use the standard and if MEDA or any other vendor can be interested, we are more than happy to work in collaboration and also to start working not only in the usage of the standard, but also in the improvement and in the growing because, for example, facing new versions of the standards or having like Andrew just explaining the possibility to do the model, not the whole model, there are things like we are in the future plans and if we have more vendors involved then it would be even better for us. Okay, thank you Sonia. This is the last question we have on the Q&A and I think this is just a more detailed question about involvement. This is from Frederick, he's asking, does the open group maintain and publish the contractual agreements for certification of the conformant archimage specification? Sonia. Okay, we have a conformance requirement and a whole process and program for being archimage certified for tools. So if you go into our site and you go into certification program and services and you go over archimage certified tools, you will find all the process in there or the program follow in order to be archimage compliant but there are different things in here. If you go into the process, you are a tool vendor and you want to have your tool certified, you should follow the process and be compliant with the conformance requirement and then the tool will be archimage certified. Having implemented the exchange file format is another step because then if you are doing the two of them, even though Andrew explained it in future plans, it's also to use the exchange file format to test some conformance for being a certified tool. That's great, Sonia. Thank you for that. That's the last question on the QA. We're getting close to the end of our hour so this is probably a good moment to end today's webinar. Sonia, do you have any final comments? First of all, thank you very much for all the attendees for delivering this timing for us. I think like we explained at the beginning, using open standards and exchanging information, it's really delivering value to the industry as a whole and this group of people, they have made an outstanding job putting together all this and delivering this standard. For example, the issue of our security, it could be a good improvement in future versions and also to invite again vendors to get involved with us in this effort. That's great. Thank you, Sonia. Thank you, panel and thank you everyone for joining us today and I will now end today's event. Thanks very much. Thank you, everybody.