 So if I could ask everyone to join me with your, ideally with your videos on, certainly at least your microphone's on. So welcoming back Andrew Josie, welcoming live Chris Ford, welcoming back Sonya, Vishal, Chris Frost, welcoming live Jean-Baptiste I hope, and Mark you're already there. So this is the Ask the Experts panel. This has always been a popular session when we've done face to face events, live events. It really does give people an opportunity to share their questions or experiences with people who are very familiar with the standards and instrumental in creating them in some cases and evolving them in others. So that's quite a gallery I can see across my screen. Thank you all for joining and we'll kick off to keep a bit of flow going. Mark, I'm going to come to you first. Question came in. Mark, you talk about architectural debt. Can you explain that a bit more please? Yeah, it's derived from the notion of technical debt. The idea is that often if you're pressured as a developer or as an architect, because something needs to go live in the short term because there's an immediate business need, then it could be that you take some corners, you take shortcuts knowing that you don't have the ideal solution, but you know that you need to fix that later. That's basically a debt you have to basically to account for and later on you have to repay that debt. That's the idea. That could be in the technical solution and technical debt. That's mainly for software developers with architectural debt is the same idea. You made a choice that doesn't really fit in architecture knowing that you're going to repay that debt later on, but if you don't record that debt, and that was what I mentioned that you can use your models for that, if you don't record it, it must stay in your architecture. If you don't fix these issues later on, basically you will end up in an architecture that is a kind of trans-work of all kinds of short-term solutions while having an architecture anymore, I would say. So that's the idea. All right, thank you. I think that's clear. Jean Baptiste, welcome. Exciting day with the launch of the community. So thank you for your help with that. Question came in. Are there some questions saying, great, I have a place, well, comments. I have a place to ask my dumb questions now, which is good. And a few others, people welcoming the initiative. The question came in. Are there actually already some models that are in the repository on the community site yet, or will they be coming soon? They will mostly come soon. I have already shared one of my models and some people from the already in the community, like Nicolas Figue, already shared some things. And we are in the process of moving things around and appropriating this. And we try to have more food for people for the end of the year. Great. OK, thank you. This question, I think, is probably going to come to you, Chris, and maybe Sonia, between you. It's a question that came in earlier today around, well, it was a statement. My organization is not a member of the open group. Is there a way of getting involved in open group activities or community activities in some way, other than being a member? Obviously, one answer is become a member for the organization. But that may take a while and be difficult in some cases. But any suggestions there? I'm looking at you. You're on me. No, you're not. There you go. OK. So, yeah, clearly the typical path is by membership. But we do have opportunities for folks to contribute ideas via the white paper path. That is, if you have a topic that you believe is of industry significance, then you can submit a proposal to us to put in place a white paper around that context. Generally, the open group treats white papers as opinion pieces rather than components of the standards necessarily. That is one way to contribute. Also, if we're engaging in an area where we need a kind of a broader engagement, we will also offer an invited expert status to some individuals for a particular set of expertise that we need to pull in. And those are the typical paths we have in our members. Right. And there was a part of that same question, which I didn't ask you. But was, you know, is there a way of getting a discounted rate for attendance at events and things like that? And one I'm aware of. Well, I'll let you answer the question. Yes, I'm chomping at the bit to answer that question. The typical discount you can get is through your membership with the Association of Enterprise Architects. Membership in that organization for individuals runs from $75 for a year to three years for $145, not to be too mercenary about it. But that also gets you access to the journal and discounts to not only open group events, but other events too around the Enterprise Architecture community. So that's another path. OK, thank you. Sonya, I think I'll come to you on this one. We are users of the TOGO framework in my organization, but we are increasingly adopting agile methods. Does the open group have any advice on how these two can be combined? OK, excellent question. And actually, a response is yes. There's work in progress into the architect to phone that was back to release soon. A couple of guides about how the TOGO standard can be used along with agile and supporting Enterprise Agility. And besides that, we have several resources in the TOGO library about agile. White papers, we have a very good white paper about agility and webinars, blogs and also other publications about agile. So you can go into the library and make a search using agile. It has a key word and you will find resources in there. And these two guys are already almost finished. They are still into the project to form. And by the way, Chris Frost is leading one of those teams. And I think that content is going to provide more specific guidance on the topic. Thank you. Can I make a follow up comment, Steve? During the event this week, you've seen several presentations. In fact, Chris also covered it here today, Chris Frost. If you're wondering how to use TOGO in an agile context, please do this. Set down the myths, but the thing is a waterfall construct. Take a step back. Look at how many of the artifacts in it are related to setting a business context and guidance for scaled teams of various scales and assess its applicability to the problems that you have. There's nothing in the TOGO framework that declares it as a waterfall construct. And there are many instances over the past decade and a half that I've been involved with this organization, both as a user of the TOGO framework and as a developer of it that make me shake my head when I hear this context for pure waterfall environment. Just honestly, I struggle a lot with this idea. I know you do. We've had many conversations on that. So sticking with agile, Vishal, I think I'll come to you on this one. You, obviously for the debate purposes, took the argument that agile teams maybe don't need EA so much. Now that you're unconstrained by arguing that position, what's your real view? Yeah, it's imperative that these two can obviously coexist and the real power comes when these two frameworks complement each other. So as enterprise architect, that's the true value and that's where the value will be maximized and maximum realization can happen. Okay, thank you. Switching to Archimate. So either John Baptiste or Mark maybe jump on this one. Let's see. The big challenge with manual modeling is that most systems never budget in story points for creating and maintaining the models. Definitely not the latter. The direction should be using automated tools to create and maintain the models. So obviously there are tools out there. Can you comment on the comment? You're both coming with the use of tools. I think you should distinguish models of the existing landscape and you can also make that quite well. And we do that as well. You can get data from all kinds of sources, CMBBs, other sources and automate that. But the design of the future, you can't automate it. You have to design it. So that's something you need to do. And of course, tool support will help you do that. But there's no way that the design of the future will automate itself. That's where you need to put in the effort. And of course, if you then use that again, once you're going live with your system as the baseline for further evolving the model partially automated, I think that's the way to go. But it's not just models. It's documentation in general, of course. If you have, let's say, a sound definition of done in an agile world, the documentation of what you build is part of that definition of done. It's not. It compiles on my machine. That's not the definition of done. So it's just part of the work. We should automate more and more the creation of these models, and we do so, especially of the current state. You don't want to do that manually. And keep track of that. It's just too much work. And architects are not the bookkeepers of the present. Right. That's a good sound bite. John Baptiste, I'll come to you for this one. It's a related question, I guess, that the learning curve of modeling standards like Archimate remains a challenge. Organizations find it easy to pick flow charts versus modern modeling frameworks. What's your advice on this context in terms of getting modeling standards like Archimate adopted inside an organization? That's a very good question. In fact, I guess that what is hard with Archimate is starting from scratch with nobody to help you. Because you'll end up trying to use most of the concept that you have in Archimate, and at the end you will not be able to really create something. And the learning curve will be bad. My main advice would be to be helped by some people. And this could be the community. And that's one of the reasons why we decided to create this community. It's to maybe see that there are some usual questions that people have. For example, if you work in a field of, I would say, applications, having a map of your application in your landscape together with flows between those applications can be one simple viewpoint, which rely on many two concepts in Archimate and which is useful. So I would say that what people should try to do is to be helped by some people. And again, this could be the community that's the goal. And try to start small with only key viewpoints, which are needed in the field. And I would say that there's no reason that something which is already produced using other things like Powerpoint, V0, such tools can be the Archimate. OK, thank you. Andrew, this one's perfect for you. The Togeff Library can be difficult to navigate if you're not sure what the publication name is. It may be that the topic can be covered in several publications, but how do I find out? Will there be an intelligent front end for information searches? Well, some good news there is we will be replacing updating the whole of the publications library in probably next month. And we will have elastic search on the front, so that's going to improve things a lot. At the moment, the technology it's built with is actually well known for its poor search capabilities. And we will be replacing that. So your elastic search, I think most people are aware of, is much better at contextually finding things. So we'll be able to search through all the descriptions. Obviously, we still, as editors, and we still got to put together good descriptions that mean meaningful descriptions to help the search. But yes. OK, we're getting a new flood of questions coming in, mostly on Archimate at the moment. Let's see, where to place it. Ah, here's a good one. It relates to an earlier question that came in about, for the new community activity, does it matter what tool I created my models in? So hold that thought and then come to, is Archimate leaving the Archimate file format to the exchange format? To me, the Archimate format works better for reading and would be much preferred. So two parts to a question, I guess, there. I guess the easiest answer is that the goal of the community is to share things for people to be able to access this content. So obviously, we decided to emphasize the use of the Archimate model exchange file format, meaning that people can use it using any tool, which supports its format. And of course, we don't block people attaching other formats. So if you decided to create your model using, I don't know, a business design tool or Archi tool, just upload the model in the exchange file format. And in addition, maybe share the native format. And what we would also like people to do is to share things in an easily readable format like PDF or HTML so that people don't have to download the file, open it in a tool. So exporting the model, publishing it in PDF could be a good solution also. OK, thank you. Could I just follow up? What we need folks to understand about the Archimate user community is that actually it's just launched and is a work in progress. And we expect, and I need to thank JB and Kelly, Gerben, Dr. Figue, everybody who's been involved in trying to jumpstart this thing, recognize that it's work in progress. And actually we're expecting these kinds of questions to shape how the community develops over time. It genuinely is something we expect the folks asking the questions here to jump into in the community and help shape. There is no single answer to the questions. We're just trying to put a framework in place to get us going. OK, thank you for that clarification, Chris. Let's see. There is, let's see, a suggestion for the community. Let's together build a collaborative model in the new open workspace. So is there any thought of building things collaboratively there? See a thumbs up from Chris? Yes, the funny thing is that when we first decided to create this community, we had the kind of brainstorming session about what we could do with it. And we thought that maybe at some point in time people would want to collaborate and create contents. But our first idea was that it was too early for that. And then we boosted up the community with people that we know, so Gerber and Nicolas Figuille and lots of other people that are known in the archimage field. And one of the first questions we had is, is it possible to collaborate? So we decided to make it possible for people to create kind of work groups so that they can have their own space on the platform and so they can work as they want. Of course, it's not a real collaboration platform. They can share content, they can co-create wikipages. But there's no tool behind. So people will still have to rely on their own tooling to be able to model things on their own and share it. But that's something that is supported by the platform. OK, thank you. Great to see. A question here on Togeth, well, sorts of Togeth and ODEF and Togeth. How does an existing open group standard relevant to data architecture get visibility within Togeth? Maybe that's one for you, Sonja. Yes, of course, Steve. That's a very good question. Actually, we also have a couple of guys that are working progress to deliver more guidance and data management. There's one guy that has already been published, which is an information references model for business analytics that's already available in our library. And by the way, it has very nice archimane models. Actually, Yembeptis work engagement that work along with one of our members. So that guide is already published and it's going deeper into the subject. We also have another guy that is coming soon about data management. And we have another working group into the architecture forum, which is data integration that are working in a white paper to cover the subject. So that's it. But we have already published and the work in progress in relation to data. Okay, thank you. Related question, but this is on the Archimate. Will Archimate be addressing the data architecture in the future? Well, it does already to grab data architecture at a certain level. You have some questions, where to, let's say, stop modeling in Archimate and start modeling in a more detailed language like, say, UML, which is more targeted towards that level of, say, data with attributes, et cetera. Archimate doesn't intend to be the one and only language that covers everything in all levels of detail. It's also not going to replace, let's say, BPMM for process modeling. So there is a certain level of data modeling possible in Archimate. And at a certain point, when you need to add more detail, you want to switch to, say, UML or other data modeling approaches. Now, of course, you can discuss how much detail you want to have within Archimate and where that boundary should be. That's a metaphor for the people in the Archimate forum to discuss and what's confated as. One risk might be, if you want to add details on data modeling or details on process modeling, that the language will grow and grow, and the problem becomes larger and larger to learn the language. Like Charles was saying, you have to very precisely select what you need and the bigger the language becomes, the more difficult that becomes. So that will remain something, yeah, we need to strike a balance there and not grow and grow the standards to cover everything. So yeah, that will be an ongoing discussion probably. Right, thank you. Chris, if I can come to you on this one. Chris Frost, sorry. If I can come to you on this one. Agile approaches appear to be, I'm trying to summarize this. Agile approaches appear to be more relevant in some environments than in others. Do you see any, and I ask this because you have some experience of government related contracts and commercial contracts. Do you see any particular environments where Agile is not being embraced as much as in others? Or I guess another way of putting it. What kind of environments have you seen where an Agile approach is taking off and which ones where perhaps a more traditional architecture approach is taking off? And the question just to be clear is about Agile architecture. So it's not throwing architecture away as such. Yeah, interesting question. And as a simple answer, I haven't seen any particular sort of business sector that's more or less following Agile architecture techniques and certainly between public and private sector. Yeah, not really not a lot of difference I could see. I've had experience of some large public sector and large private sector organizations that are quite aggressively adopting Agile delivery techniques and Agile architecture with that. There are some geographic differences, different parts of the world are adopting these things at different paces, but that's not really specific to Agile delivery techniques. That's just following the general trends you see across the globe in the rate at which different countries and different regions adopt new technologies. So you do see some differences across the globe in that sense, but if you look at business sector by business sector, I wouldn't say there is any one that stands out as either leading or lagging to be perfectly honest in terms of types of system. If you read a lot of the literature, it's often said that things like perhaps very safety critical systems, for example, that need that rigor of very tightly defined technical specifications and very tightly defined requirements to go with them might not be quite so suitable to Agile architecture and Agile delivery techniques, but I have to counter that by saying personally, I've not had experience of that effect, but yeah, I know if you look in the literature, that is sometimes what is said. All right, thank you. Back to Arcumate here and the exchange format. So it's a statement with a question at the end. So it turns out that the exchange format leaves some freedom and I've encountered differences, especially in terms of layout of diagrams. The model is okay, but for instance, different tools save different things. So if you share a model, it will look differently. Will there be an initiative to drive tool providers to make diagram layouts to be more exchangeable or make the exchange format more prescriptive here? Any thoughts on that for those in the Arcumate forum? Yes, the thing is that we start to see the benefit of the exchange file format by people actually using it and exchanging models. So of course, now that it is used by some people for several use cases, I've already seen people trying to work collaboratively on the same model by using several tools from different tool vendors. So we are now facing these kind of questions. We had also some time ago, people asking for making idea persistent. So this basically leads us to a kind of balance that we have to find between having a format which is very, very precise, but that no tool supports or having a format which is maybe in some cases a bit loose, but which is supported. I guess that we are at the beginning of the story, even if the format exists or has existed for the past three or four years now, and we have to improve it and that's an ongoing process. For example, we are still not able to exchange stereotypes or customization of concepts and that's something that should be remedied in the future because people will more and more use our akimat for some specific context in which they will use customization. I have lots of, I know lots of people are using it this way. So we have to improve it and we need feedback and we need people using it more and more. Right, okay. A specific comment on this one, a follow up question there. Those involved for both business design and Archie are represented on the panel. Will they work on this? Put you guys on the spot. As you can imagine for software vendor, there are many, many requirements coming from many, many directions. So the only thing I can say is that if you're a customer of business design and you have an interest specifically in the exchange format, make sure that we know about that because, prioritization is always difficult. There's always more work to be done than that we have resources. So it's like that and we have invested quite a lot in the past and that's also something that we think about. Yeah, we put in a lot of efforts. How much can we keep up doing that? Understood, understood. Yeah, I would just have a few things, Steve. Sorry, go ahead, Ed. Yeah, I'll just say in the actual, when we developed the format, as Mark said, that we did bring as many of the tool supplies together as we could and obviously if there are others out there who want to join in the interoperability testing, we welcome them. We try and round rob in the models through the various tools as best we can. And so that's what we'd say is come in and join us. We've got an area on the GitLab project for the exchange file format. More than welcome to have other tool suppliers come in and basically exchange the models we can get them looked at and we find out quite a few things. As we did that, such as how you scale the model, your various coordinate points and so on. It's really through use and of course there's a lot of uses we see of the models that we haven't even imagined, which is the actual success. It's been picked up and used actually outside tools for all sorts of things. It's very successful. I remember when we set off back in 2012, thinking people told us we couldn't do it. Chris, did you want to add something? Yeah, it's maybe just my reading of the comment, but I want to make sure that people who are listening understand that it's not folks like me and Sonja turning around to representatives of various commercial products or open source products, dictating what components of the standards folks will work on. There has to be a common perceived value across the membership in order to work and prioritize a topic. This goes back to Mark's comment that for commercial organizations like Business Design, there are a lot of pressures for folks volunteering their time like JB. There are a lot of pressures. It's where the business value converges inside the open group for members, but that's where they tend to spend their time. I'm not dismissing the question. I'm just trying to give a little bit of insight about how work gets prioritized by the membership about what to deliver into the standard. It's both a combination of the external communications that we get through these user groups and the priorities that the members of the open group see about where updating the standards will add business value. Right. Yeah, and I know you're absolutely right about the different priorities. And I don't know who actually wrote the words, but in the guide that Mark was talking about earlier in his session, I noted down something that I loved, which was that models can help you have a better way of prioritizing than decibel-driven prioritization. I loved decibel-driven prioritization. I love that Mark, it is, yes. You've got a lot of voice, students shouldn't always win. No, that's right. The eldest voice shouldn't wheel, and the squeaky wheel shouldn't always get the oil. I love the term, so good one. And it shows I've read the guide as well, Mark, so that's good. So we are out of time, but I do want to go to this one last question because I think it's interesting. Anyone feel free to chime in? But the question is, for data architecture modeling, we can use semantic ontologies. Is it possible to envisage having an ontologies of archimage models, i.e. integration of EA, archimage and semantic technologies? Yes, it's a head scratcher. Yeah, that's really interesting because we, I remember we had a presentation, it was something like maybe three years ago at Amsterdam where we discussed the use of ontologies and knowledge covered by archimage model that was the topic. And at that time, we imagined that maybe in the future we could have some kind of a chatbot which could answer a question for architects using models. So I guess that it's not very difficult to convert an archimage model or any model to some kind of autonomy. The question is more about how to make it stand out. They are already on the internet some ontology for archimage. So the question is, does this make sense for the open group to end the archimage form to create such kind of, I would say, default ontology for archimage? And as Chris said, that's an interesting question but we have to prioritize things and for the moment that's not on the top list but that's an interesting question. But people can already try to do something on their own, they can look on the internet, there are things about it. So if someone comes with some interesting use cases and does something for sure we'll look at it and see how we can standardize it. Thank you, okay. I'm gonna be respectful of people's time there are some people who are, for them it's very late attending this right now. So we are five minutes over so I'm gonna draw the panel to a close but thank each and every one of our panelists. We shall Sonya, Chris Frost, Jean-Baptiste Suridi, Mark Langhorst, Chris Ford and Andrew Josie. Thank you all for your insights and for answering questions. And thank you all to everyone who submitted a question and to everyone who's attended today. That will bring us to the end of this session. I hope you found it useful. Please do go to the ratings channel on the left hand side of your screen. We'd love to see what you think of this and other sessions that you've attended. And thank you all, that's it for today. Thank you all for joining and keep well and be safe wherever you are.