 Well hello to everybody. Thanks for the invitation. It's really a pleasure to be here and Okay, let's go to rock and roll and please I will make myself available In case that you have any type of questions follow-ups after this presentation. I have the intention to offer a short demo of the cartool. After that, this is the reason that I am using my my laptop because I have local the test cartography. I'm going to be really fast over the slides. You will get them later. And I would like just to put some additional grain of sand. The first thing is that I want you to know that the era is in the legal test of the era decision. So this is important because this reflects our commitment. And also you should expect from me some level of neutrality because I am an official of the European Commission only for the last three years. I have seen in the previous presentation of my colleague a comment when he made saying about the government saying if you need to change the legal test, just let me know. Well, in the European Commission to change, I would like to... How much time do you think that a text remains the legal test? What is the life cycle of a text? One year, please raise the hands, those of you that this one year. Okay, now one, two years. Okay, three years. Okay, four years. Finally, five years. Okay, it's five years, the average, okay, for your information. So if something is in the legal test of the European Commission and the Consulate and the European Commission and also approved by the Parliament, it stays there in the same way for at least average. Five years. So this has some good benefits, but also some you know, back sides. Okay, what is the context? The context is that we have an European interoperability strategy which gives insights about the governance and the basically what are the priorities, objectives, etc., the when, then we have an European interoperability framework which focuses on the principles and then we have ADA which focuses on the implementation guidelines and specifications. Okay, and to be frank, this nice slide, well, I think it's nice because I spent a hell of time producing it for you. I am not very nice guy producing slides with pictures. Gives you a context which looks structure. I would not say to you, dear colleagues, that it was pre-meditated in this way. Okay, so yes, it's a fact that we had the strategy and the framework, but we're more or less in parallel. Okay, I am presenting in this way to make, you know, a message as much as clear as possible. Okay, the European interoperability framework, which is now going to be concluded after the public review, public revision, public consultation, is basically the source where ADA goes and then ADA is fully aligned with the European interoperability framework. So everything that is set in the European interoperability framework, you can find in the European interoperability architecture. And why I am saying this thing? Because from the beginning, the definition of interoperability is defined in the European interoperability framework. And there you will find that the interoperability is considered a construct with multiple dimensions which are basically lost. I am lost, legal, organizational, semantical, and technology. So lost are the four dimensions so far of the construct interoperability. And ADA covers all of them. And for information, in the ASA decision we have spent most of our money, the public funds money, and addressing the semantic and the technology dimensions of interoperability. And my particular theory on why we have done that is because we couldn't understand whether the legal and the business interoperability, now we are understanding better and we are increasing our efforts addressing legal interoperability and business interoperability. Okay, ADA is basically an architectural content meta model which is defining the most salient architectural building blocks addressing interoperability needs in a government. And now I want as always to spend one minute addressing the construct because I think it's not a waste of your time. ADA, I'm going to focus on the R and in the A. ADA is a reference architecture so it's not like Togaf, an enterprise architecture framework. Any enterprise architecture framework that you can find in the literature, Togaf is one of them, probably the first one is Sackman. It has the ambition to provide solutions and approach end to end to design any type of solution. This is not ADA. ADA is a reference architecture which means a focus on a particular issue. In this case, the issue is the eye interoperability. So what is the meaning of reference architecture? In the reference architecture, in the literature, typically it's a marriage between a reference model and an architectural style. Okay, very quickly, the reference model of ADA is Archimate, period, which means the ontological properties are archimates. In this case, 2.1, we will migrate to 3.0. What is the architectural style? The architectural style is service oriented architecture, which means we care about the behavioral parts of a solution, but also about the code. In fact, one of our lessons learned deploying ADA in the member states is that member states, generally speaking, mainly central administrations, they care more about the services, the service part of their architecture. However, so far, we in the commission, there is more interest in the code. So in any case, the architectural style is okay. So this is ADA. It's a reference architecture, which means a reference model, which is Archimate, an architectural style, which is SOA, and focus on a particular aspect, which is interoperability. This is the reason that in the previous slide, I said the most salient. Why? Because we do not care about any other architectural building blocks that they do not focus on interoperability. For example, if you are using TOGAF to define a solution, you will define backup services, because it's part of your solution. We don't care in ADA. So we have defined, and when I say we means at the beginning, the European Commission, and then now member states, because now is basically the result of a collaborative effort, we have decided so far that backup services are not relevant to support interoperability. Well, ADA has been released. It was released version one in March. In the last month, we released a minor version, and typically it's released, and you can find our join up collaborative platform. You can freely download it as with release notes, and it's free for, according to the, and respecting the terms of open group. So there is a license, which is basically negotiated with the open group and respecting the terms and conditions. You can find it, it downloads. As I said, it's a result of a collaborative effort where we are basically producing new releases, and we have a roadmap. I'm going to basically highlight here some of the use cases of ADA, because it's going to be the reason of the demo that I'm going to offer. Basically, ADA has four clusters of use cases, designing, communicating, and sharing, discovering, reusing, and assessing. I am color blinded, so please do not ask me questions about the colors, because I cannot answer. But in each of those clusters, you will find different type of use cases. So for example, we will offer a very short demo on how to design basically a solution using ADA. But then you can, one of the benefits, one of the use cases, and is now being used literally in the commission is, for example, communicating and sharing. How? Because ADA provides a control vocabulary. On using this control vocabulary, you can use that as common terms of references in your public procurement, for example. But not only that, for example, now in the same way that in the legislation, now the European legislation is mandatory that you, for any type of new legislation, you need to provide a type of impact assessment on something. And this something, for example, is environmental, okay? You need to make an impact, environmental impact assessment of new regulation. The same happens with technology. You need to offer a technology impact assessment of new regulation, new legislation. And how to do that, but that's the problem. So now if we have, as I'm going to show to you in a minute, a cartography, now you can understand better what are the solutions that are supporting a given policy, public policy. Okay, one of the use cases, and I wanted to illustrate that in just one slide of the ADA, is the cartography. What is a cartography? Well, in the European Union terms, a cartography is basically a mapping of a structure, which is ADA, imagine Excel, where you have in the columns each of the architectural building blocks of ADA. And then in the rows, what you have are different solutions that you have in production. The effort of mapping each of those solutions in production against each of the architectural building blocks of ADA is a cartography. Okay? In the classical literature on IT, this would say like the inventory of the solutions in production. So we have done that. And we have done that to a small subset of the solutions of the commission. We chart the test system, which is another of the actions that I own. And action is the terminology we call programs. It's just to confuse you. But I mean, the world in the industry is program and portfolio. It's a portfolio. But it's just to confuse you. But we call actions internally. So there is one action that is called the European Enterprise Architecture that I am the owner. And another is the Trans-European Systems, which is basically the inventory of specific solutions that are Trans-Europeans that I also own. We have made the cartography of the test, partially, of the test systems, which are, for your information, 128. So in the commission, we have 128 solutions that are Trans-European. So those are the different specific use cases of the cartography. Basically, you can use the cartography, and this is the intention, to not reinvent the wheel. And I want to send this message here, because I guess that we have colleagues that are from the public administration, but also others from the business, private businesses. I am saying that with a sense of embarrassment, okay? But that's the reality. When you have a big government, there are typically a silo mentality developing things, which means that you can find applications and solutions that have been developing one site, one ministry, or one direct direction in general, which are basically redundant at some level of redundancy with another place, okay? So one of the areas, if you have a cartography, you will be able to identify those overlaps. And then basically, because you have, in one of the columns, you have more than one solution. So you can make rationalization recommendations on doing that. And I have done that two years now, basically based on the cartography. But another way is looking from the other side, which is basically where you have a hole, it means that you have nothing. And if you need something, this can be an input for your roadmap of development, establishing some priorities. Okay. I do not plan to spend time talking about solution architecture templates, which we have released so far for. You can download them if you want. And this is our roadmap. So far, we have released the cartography tool, version 1.0, which is supporting AIDA version 1.1. And this is based on Archimate 2.1. We planned then to, this is, you could replace the year by xx. So intentionally, we would like to have a major release around March and a minor release around September. And of course, as we get more mature and we understand typically, as in the industry, this, the distance between the releases will be longer. Okay. But so far, we expect that we will learn more. And this is one of our lessons learned. Now, I can say, and this is very particular, it's not a commission, it's Raul saying this thing, that I know what I do not know. Okay. Which means that I know, and I have a vision of the many things that we still need to do. Okay. And we plan to release a version 2.0 of the cartography supporting a major new version of AIDA around March. And then in September, it will be a minor, a minor version. And now I am going to change to the demo. And I have 19 minutes. Okay. Well, basically, this is a plugin that we have developed over Archim. And you can download. And we released that last month. Okay. So it's fresh. And we have had, you know, we, I think we have so far 129 or 13. I don't know. And we are not talking here about M&Ms. We are talking about, you know, the cartography tool. So far I am impressed. And we are deploying that slowly in the member states. Basically, the cartography tool is a request of the member states. And this is a lesson learned that I wanted to share with you. I mean, I work for the commission. And it means that my, my stamp here is to promote interoperability in the European Union, in the different public administrations, the central public administration, but also in the different administrations in Europe. And I, I, you know, I have a bias through cross border public services, the typical situation that you have a guy in one member state that requires a public service from another place. No. Okay. That's nice. But that's not the way that I think I will accelerate adoption. The value proposition, the selling pitch is to support member states. That's my experience and this is what they are asking. Basically, the message I got from them is, you give me the cartography tool. I will create my own cartography. And then later, we will talk about cross border services. Because member states, they have their own complexity. Depending on their own level of aggregation or process or decision making decentralization, they have their own complexity, some interoperability between the central, the, the, the regional and the local administrations. So what we have created here is a plug-in with Ada. And the first, the first basically use case is to have Ada. I am not any more demonstrating Ada with PowerPoints like the disaster of last year where I didn't have the right resolution in my slides and I was astonished and very embarrassed. So here we have basically a plug-in over, over our key where you have the entire Ada. Okay. And for each of the architectural building blocks, you, you have then documented and each, each, each and every architectural building block has a documentation, a formal documentation that for information in the next version, we are going to, to, to create a persistent link to each of the documentations of the architectural building blocks. And also they have some attributes which are particulars to the different architectural building blocks. This is for every architectural building block, not mentioning also a definition of the, the view in general. And here, sorry, I need to remind you on something. We intentionally use the word view. Ada is not a layered architecture. Okay. Sorry for this thing. I am consuming one minute of my remaining minutes. Many of the enterprise architectural frameworks are layered, layers, layered architectural frameworks. That's not Ada. A layered enterprise architectural framework typically has a layer where you have the most abstract constructs and then the next layer, you add additional details and then you add additional details and at the end you have the technology. Typically you have the strategy, then you have the, the business processes, then you have the application, then you have the design. This is not Ada. Ada is based on views and view is the concept which is borrowed from the database literature. So you have a partial view to, to the, the whole architecture which means that every single architectural building block in any view has the same level of abstraction that any other. Okay. So it's not that this one here is going to be implemented by others. No, no, no, no. This architectural building block in the legal view has the same level of abstraction that an architectural building block in the infrastructure technological view. So in this information window for each view, you have basically the definition on what are the essential characteristics that any architectural building block in this view should fulfill. So, so we can see all the views that we have in, in the, in the Ada and, and we could do the same thing. But what I'm going to do now is move to a use case which is I'm going to show you. Here is the library of so far the 73 solutions, test solutions out of the 126 that I mentioned that I have in the, in the carto, in the cartography. So we have documented 73 test solutions like in my Excel example and we have documented them against the Ada. So what I can do is basically query. Now I am a kind of portfolio manager and I want to know what do I have. So simple like that. So I can say that I want to basically know how many, or what are the inter-European solutions that I have. And then I want to know something so simple like I want to know which is the organization that is owning in another view. For example, what is the public service provider of these, of these at to the query. Okay. And I also want to know I am, I am basically doing the select of a SQL query. Okay. I am constructing dynamically and I also want to select now what is the public policy that those solutions are supporting if they are supporting a public policy which is one of the discoveries when you really don't know well what are the public, the solutions that you have. Sometimes you find that you have a solution that is supporting no public services. So this is an embarrassing discovery. So I am going to add that to my query. Then I am going to see build the query and I can say if I want explicitly the columns in the, in the, or I want to basically in the result or not, or if I want to filter by a specific value, I run and then I got basically my query in a tabular format where I have for each of those solutions that they have, the 73, what are the public service provider and what are the public policies that are they are supporting. So now I can make, I can go and ask in addition to that, I can add, I'm just demonstrating this thing. I want to know for example I will select for each of those solutions what is the, the identity management component that they have if they have one. So I'm going to add to the query and then I want to know basically if this identity management component is basically reusable and if it's reusable, if it has been actually reused. Okay, here. So I build the query, I run and basically I am interrogating my cartography and then what I have, I need to make some massage here to make the thing visible for you. Yes, the second. Public policy. Okay. And then identity management. I will move a little bit here. So here I have that they have those solutions that are provided by those directions general and that they have an identity management component. Okay, some of them by the way and then some of them are reusable and by the way in some cases they have been reused or not. Okay. So I can, I can and then of course I can ask where it has been reused. So these, excuse me, these helps to basically not reinvent the wheel and to understand what do I have. I am going to change now my use case. I have eight minutes and then I am going to completely change my use case to a kind of solution designer. So I am going now on in solution mode. Okay. In solution mode, one of the things that Ada supports me is to have a guideline on what are the key architectural building blocks. And the second question is let's not reinvent the wheel. And if I want to reinvent the wheel, it's my responsibility to do that. So for how, how do we do that? Basically the way of doing this thing is using the technique of stereotyping, which means that I am going to create a new solution, new solution. This is going to be test, open group. Then this is a basic information that they need to do to create a new solution. This is just information. Then I am going to start, for example, with the basically the technical infrastructure review, which I am going to open. And then I am going, what is the technique use? The technique use is basically dragging and dropping. So those are objects. And I am going to copy from my baseline, which is Ada, and I am going to leave this thing in my basically design desktop. So I am going to say, for example, identity management add to the model. I add here. And then the name. So I can say I want to create an identity management. And what I just did is very important. I can now type whatever I want, or I can select one of the identity management that I have in my cartography. And that's a key breakthrough for us, at least. Because in designing something, we can have a guidance on the things that are available. I can decide not to choose that and do another thing, or I can decide to use ECAS. So I have ECAS, basically, which is an stereotype of my architectural building block in Ada, which is identity management component. And in this case, I am using ECAS, which is inheriting all the properties that are in Ada. And I can do that with all the architectural building blocks. So I can now go to my legal view and select, for example, I go now to, I have five minutes. So I can move in my baseline to the legal view. Here I am my legal view. And then I want to say I can add here I am free, or I can open the legal view of the solution that I am designing. And then I want to say add to the model. I am dropping here. And then again, I can invent a new public policy, or I can select one of the ones that I have, which is very important because it means that they have a link to the legal text. Okay. And that's it. I just finished four minutes. Thank you. Thank you very much, Rool. Could we spend those four minutes with some questions? Yeah. We've generated quite a few from the audience. So please take a seat and we'll take them. And it's great to see something operating like that in real time and what it can do. It's great to see. So first question is, do you think this reference architecture could be used as a basis for a more general reference architecture for e-government? I think it shouldn't. And because then we are kind of forgetting the eye of interoperability. So I would argue, but this is a theory that we are covering, you know, like in aparato analysis, I think that with 20% of the, maybe just to say, architectural building blocks, we are covering 80% of the needs in any architectural design. So I think it's a good start in the sense that I would, yes, definitely recommend that if you want and you need to design an interoperable solution, you should start using EIDA and then potentially then using another tool. Okay. Thank you. Question about Archimate. Some people state that Archimate is only understandable by architects and it shouldn't be used in discussions with managers or business people and non-architects. What is your experience of this as a program manager? Yeah, my experience is talking with business users also, business analysts in member states, not all. I want you to know, I mean, I don't, I can say that we have deployed so far in five plus one because next week I need to fly to another member state, but very advanced member states in the European Union because that's what we decided. We decided to deploy starting in the most challenging and advanced member states in the European Union. That's what we thought that was the right approach. And I have been talking also to business analysts and business users. I think that the question may be, with all the respects for the requester, tricky because if you are a business analyst, you potentially you will be familiar with formalisms like Archimate. But if you are a business user, for example, a person developing legal text, a person developing legal tests in the administration, not necessarily a business analyst, it may be challenging. I agree. So I don't have the answer. I think that these business users will need a kind of intermediate stage with educated business analysts. Okay. Clearly you've at the moment chosen Archie as your Archimate tool. Was that because it's open source or other reasons? The selection of the anthology of Archimate was, I mean, the factor of being open, it was very important for us. In order to build up interoperability should be based among other things in openness. But there is also another thing which I celebrate, you know, that you are driving that and is adoption. I mean, Archimate is well, well, you know, considered a formalism, an anthology that is spread in the community. There are other unreferenced models which are proprietary. Okay. For example, I don't mind to say ARIS, BPM tools that they are proprietary, where this is basically, it's difficult being European Union to promote licenses. So the fact of openness for us is important. Very important. Thank you. But if I may, I would like to break a lens here. This does not mean that we should forget the proprietary world. So some type of interplace should be created. For example, your MDF format, which I support, and everything that has been deployed is in MDF format, not ARCHI, but MDF, to promote import and export should be, and that's my recommendation also, proprietary tools should be able to import MDF formats. That's something that we would like to recommend. You've made the modeling in Archimate. Have you been able to connect the models with implementation tools to make interoperability operational? Not so far. Not so far. Okay. And one last one. Is there an anthology defined for error? It will. So far, in the next release, we have a controlled vocabulary, which is already released in version 1.1. But the answer is yes, version 2.00 will have a formal ontology. So the question was, if the answer is yes, has the development of an ontology been used for interoperability and terminology use for architects? It will. On the way there. It will do. Okay. I think we're out of time. We'll leave it there. But thank you very much for a very enlightening presentation. Thank you.