 Hello, I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognised experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organisation can be derived when they are used in unison, for some of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required and recruiters can take the guesswork out of the recruitment process, all backed up by our Open Badges program. My name is Terry Blevins with the Toolkit Tuesday Tip. In my very first Toolkit Tuesday Tip, I suggested two considerations for supporting digital enterprises. One is to make sure you see your role as enablers for the digital effort and the other is to think about enterprise architecture as a set of architectural capabilities to be delivered to those in need through a service delivery model. In today's tip, I'll expand a bit on what it takes to deliver architecture capabilities through a service delivery model, recounting from an old Open Group blog I wrote a few years back titled Enterprise Architecture as a Service How, Reach for the Stars. In this blog, I highlighted five areas. One, resource with the right mix of people. Providing enterprise architecture services requires a broader mix of skill sets to address more than the IT architect role. Ensuring your people mix includes skills in customer relationship, risk and project management, as well as in planning, contracting, requirements, understanding, negotiation, leadership and influence is essential. Two, educate your architects in best practices and service delivery. Services delivered through best practices that are open enables an organization to train easily, hire selectively and produce more consistently. The third area, apply the best in class tools proven to improve production capability. Utilizing a consistent set of best in class tools helps ensure that deliverables are consistent and it enables reuse, which can improve speed and quality of delivery. Tools that support the best open practices are even more valuable. Four, collaborate with partners to evolve the open practice. Collaboration on the best open practices provides an avenue to improve the best practices based on real experiences. It also improves your market perception and helps keep the bar raised for the industry. The fifth area, hone your organization to deliver value quickly and a pace commensurate with the digital effort. Supporting agile application of resources in short projects that have big impact will have big impact. In summary, to support digital transformations with an architecture service delivery model, reach, resource appropriately, educate in best practices, apply best in class tools, collaborate to improve the practices and hone for quick delivery and success. For more information, please check out the TOGATH library. Keep architecting for enterprise value. Thanks for watching. Welcome, everyone. Welcome to today's Toolkit Tuesday, and I'll start by giving a big thanks there to Terry Blevins of EnterpriseWise, LLC, for his latest Terry's Toolkit Tuesday tip. As he always ends, everyone, keep architecting for enterprise value. It's what we all have to remember. So a quick few words before we move on with today's main agenda. And the most important thing is to, again, repeat my welcome and to wish, hope that you are well wherever you are and keeping safe. And we really appreciate you joining us today. We know there are lots of ways you can spend your time, but I'm pretty sure that you'll get something out of this and you'll be glad you did. So thank you for joining us. One thing for those of you who are joining us live today, the way we would ask questions of our speakers today is through the Q&A channel. So there are various channels on the WebEx tool, but if you go to the, you'll see in the bottom right hand corner of your screen, there are three little dots. If you click on those, you'll see Q&A as one of the options. And that's how we would like you to ask questions of our speakers today, please. Use the chat channel to talk amongst yourselves. Tell us where you're joining from. This is very much a global event. We have people from all over the world joining us today. So do use the chat channel to let us know where you're joining from. It's always fun to see. And I hope we have a great session today, and I'm sure we will. Our focus today is on Archimates, the Archimate Modelling Language. And we'll hear more about it very shortly from our two speakers today. But first, I want to acknowledge and thank the VanHaren Learning Solutions for their help in putting together this particular episode of Toolkit Tuesday. So many thanks to the folks at VanHaren Learning Solutions. Today, as I say, we're focused on the Archimate Modelling Language. And we're going to hear about how it's used in the real world, real life examples. And two great speakers today joining us. We have Patrick Dirty, who is Bayon9.0, COVID-5, Togaf 9.2, and Archimate 3.1. And finally, Sophia Six, certified enterprise architect. Congratulations on all those certifications, Patrick. He's more than 20 years experience in the different domains of enterprise architecture in financial institutions, retail, government, utilities, et cetera. He is founding member and director of the Data Management Association, managing partner of EnVision. And in 2018, he started developing the Bayon Information Architecture and became responsible for the Bayon Architecture repository. So welcome, Patrick, glad you can join us today. Our second speaker today will be Marine Crawl, who is low code architect and architecture trainer at the CapGemini Academy with over 10 years of experience as a solution architect. As an architect, Marine embeds the use of low code and cloud technologies into the enterprise architecture, sets the constraints for successfully scaling low code and microservices in organizations, and guides agile low code development teams by applying Archimate, Togaf, and demo. As a trainer and coach, Marine guides developers, business analysts, and architects in their journey to become an experienced agile architect. So a warm welcome from the open book, please, to Patrick Dirty and Marine Crawl. Over to you, gentlemen. So good morning, good afternoon, good evening to all of you. I'm going to share my screen first to show something. So I'll share, I'm going to presentation models. So my name is Patrick Gerde and I'm the lead architect of the banking industry architecture network, and it is in this role that I want to be a witness of the power of Archimate. Now, to tell you this, the first thing I want to do is to tell something about what is beyond the banking industry architecture network. We were facing with the problem of the interoperability of the information and our information services. These, this interoperability was complex, but as a high cost, and we wanted to lower the IT costs and the operational costs. And for that reasons, leading banks and suppliers that collaborate together to realize what we call the banking industry architecture network, which is a financial industry reference architecture framework. And in that financial industry reference architecture framework, that's actually a toolbox into which we have offered service domain architectures, which are actually capabilities, business capability mobs, business processes called business scenarios, data models, semantic APIs, trainings and white papers, and all to realize and to architect an agile digital bank. All the information can be found on the website of beyond.org and is free for use. And where beyond and the open group are in common, it is in their vision and their mission of realizing this boundaries information flow and with open systems for interoperability. Well, these open systems for interoperability allows us that we can exchange our information and information services between the banks and between the applications in a very smooth way. And for that reason, the beyond organization that align with the way of thinking of Togaf, but also the way of writing of Archimate. And beyond that, first of all, develop a meta model, which is expressed in Archimate language. And the language is especially interesting because it is a language that enables us high level modeling within the domain, but also between the domains. And it allows us different visualizations and analysis. And most important for us was the easy linkage to other related standards such as UML and the object management group. Now, on this diagram, you see how we did express our meta model in the UML language. And when you compare it to when expressing it in the Archimate language, then you see with eyes closed how much more expressive our meta model was without showing any context, simply showing the shapes of the concepts. Someone who knows the Archimate language knows immediately the full context of the Archimate model. So this language I can show you in real practice by going to the website of beyond. Going to the website of beyond where we see that we express our language, our model into the Archimate language by using the capabilities. And by using the capabilities, each of these capabilities, these are more articulated into the business architecture elements. And I show you this. We have a service domain called consumer loan and we see which business architecture elements are articulating it. And we can easily link to UML for showing the data model. But even more, we can easily link to the semantic APR representation into the different rest formats or whatever. So really powerful instrument is this Archimate, as you see, very easily linked to all the languages. And from the perspective of visualizing and the perspective of making analysis, well, it can be used for creating all types of visuals for CEOs, business architects, chief architects, all need their own representations. But everything is linked to this Archimate language and the use of it and realizing it in real repositories. And that's actually what I want to share with you, the power of Archimate in the banking industry. So I want to give the word now to my colleague, Marine. Yes, thank you, Patrick, for this insightful presentation. And thank you, Steve, for the introductions. Just waiting until the screen gets back to presentation. Thanks. So as Steve said, I'm an architect mainly involved in low-code projects. And as the nature of low-codes is really close to the business, I'm also often involved in agile projects. And often I run into architects that find it difficult to find their way in these agile projects. Because from architecture, we tend to deliver very strict and detailed models, while scum teams often want to neglect all the architecture and the models that are there and just want to do their own thing and work with user stories. So I have a really nice example of how we combine these agile teams and also some architecture modeling at Posternel, the Ditch post. And I now go to the next slide. It's like this. I found it. So what we do currently at Posternel is we work with a scrum team and agile team. And we're actually replacing one of the core planning systems with a low-codes platform that is focused on backend development. What you see below is an archimage picture. Maybe you cannot read it all. That's not important for now. But what you see at the top of this picture is actually the business processes and the different actors that are involved. In this case, it's the process of the leave. Of course, the leave is important when you start planning people for work. And below you see the different systems that are involved. And actually at the far bottom is the core planning system we're currently replacing, while on the left and on the right you see some existing applications in SAP. And I think it's a really nice picture because on one hand it's really linked to the business and their processes. It's also linked to actually the epics and the features that are defined also for this project because the different services that you see are actually the features that are guiding the development. And what you also see is, of course, the important interfaces that we have to deal with as a development team. And what's really interesting is that these pictures, actually they work for both the business because they recognize themselves in the processes and the supporting applications. And also the developers, they really like these kind of pictures because it helps them to get an understanding of the context with also to guide the development to make sure that the user stories get a bit of focus, that we do not forget important interfaces that are in there. So it really guides the development that's going on in the scrim team, while still these pictures are understood by most important stakeholders. And in a sense you can also say from a Togov perspective that we're working with the different layers that you can identify, where there's, of course, a more strategic direction, which is then detailed into the capability architectures or maybe even the different sprints that we have. And in a sense these pictures really guide the quarterly planning that we do. And actually there's one thing I want to add to the picture on the right because what you'll really notice that there is also a feedback loop coming from the development team to watch the architecture. And I think that's really important in an agile setting that it's not just top-down architecture, but that there's really space for the development teams to come with new ideas, to bring in new ideas also on the architecture. So there's really a feedback loop going on on the lower levels of this architecture. And I also can imagine feedback loops on the higher levels in architecture. So that's just an example from the Dutch post where we apply Archimedes in an agile context or even a skilled agile context. And I think an interesting example of how you can apply this. So thanks, Steve, for now, I think back to you. Thank you, Marine. Thank you, Patrick, that was great stuff. And you've finished with plenty of time for questions, which isn't always the case on these occasions. So thank you for that. So if we can, Patrick, if you're able to join us on video again, we do have some questions coming in from the attendees. And one I just want to start with you, Marine, perhaps. Can you explain a little more about low code? How would you explain what low code is? I don't think we can hear you, Marine. Yeah, sorry, I just noticed. Thank you. Yeah, I was just saying we have 10 minutes. I think I can talk for hours on this subject. But in a nutshell, low code is really the new way of software engineering, I would say. It's more visual based. It's more model based. And I think that's also the interesting part also for architects that you have to find a way to deal with these different models that arise because a lot of low code is based on models or model development, which, of course, speeds up the development, but also makes it a bit more restrictive. It's something you really have to think about and take into account when you try to model the architecture. Right, thank you. That's helpful. So, Patrick, questions come in here. Are there any Bayon models available in Archimate format that? It's just disappeared off my screen. Are there any Bayon models available in Archimate format that can be uploaded to an Archimate tool? Yeah, it is also one of the strong parts of the Archimate language that has developed in an Archimate exchange format, which means that we as Bayon and for our members, we have chosen for Archimate because we are able to use the exchange format to exchange the Bayon models from our repository to the repository of the members. So, and the pictures are nicely kept, so people are very happy with it that they can import the Archimate models via the Archimate exchange format. Okay, thank you. Yeah, I've always thought that exchange file format is a really great, a really useful tool for architects and others using the Archimate modeling language. It really makes the use of it pretty tool agnostic as long as the tools are up to it, of course. So, okay, there's a comment followed by a question. The UML versus Archimate diagram is striking in highlighting the advantages of Archimate, but how can we justify visualizations that cover far more than a normal single screen or paper page? I've just found the example set up new card for card application in the Bayon reference model. Is that way too much detail to enable clear understanding? Maybe that's for you, Patrick, we're certainly the second part. Yeah, one, not sure which part you're talking about, are you talking about what we call a service domain and how the service domain is expressed in the Archimate language? It's hard to say. There's a specific reference from the person asking the question to the set up new card for card application in the reference model. Yeah, okay. It is referring to what we call a business scenario. Yeah. What we do, and Bayon is also using a new way of thinking, actually, instead of the process-driven way of thinking, it's a service-driven way of thinking, service-driven by components. And Bayon is working in capabilities, in capacities to do something. We call that a service domain. And service domains are actually offering their services in the card payment business, in realizing something. And by exchanging this information or these services, we, after all, realize a business service. But that's expressed in the business scenarios. And the business scenarios, why not a BPMN, for example? Because the business scenarios are also focusing on this exchange of information and information services. So is it too detailed? No, it is not part of the standard of Bayon, but it is part of, it's an example of a business process to do such a thing. And in my opinion, it's still real high level. Right. Okay. Thank you, Patrick. Okay. Maybe I can point this one at you, Marine. Archimate, there's two questions that follow a very, it's really the same question, but Archimate is a lean and efficient modeling tool for IT folks. But how do you educate business stakeholders to share with them directly, Archimate models for them, it may be less natural. Similar question, I find that executives don't like looking at boxes and lines. Do you have any suggestions for making presentations to executives that are more visually appealing? Yeah. Well, first I totally recognize this. So let's be clear on that. And in a sense, of course, it's good because Archimate is really detailed and specific. And on the other hand, Archimate actually also provides the solution, I think, to this issue, is to work with views or viewpoints and then still, I think sometimes we're a bit hesitating to bring these models to the business or to the stakeholders. Or if you explain them what a process is and how a process model looks like, I notice a lot of people naturally understand it. They may not understand fully the difference between flow and a trigger or something else. But with just simple explanation, you can really easily talk them through, I think. And of course, there's always the thing that you don't need to show all the details. So from the picture that I showed to the business, I only take the process and the applications that are involved and I leave out the interfaces and the services and everything else to make it understandable. But to work with you in a smart way, I think it can be the solution. And for other audience, you really need to grab PowerPoint or nowadays you go to Instagram if you want to talk to your stakeholders, right? Other way of visualizing might be needed, yeah. Right, thank you, thank you. There's lots of questions coming in. Let's see, I saw one that was just right for you, Patrick, which was, yes, does Archimate have anything that is domain specific, for example, for banking or retail? Archimate itself has nothing that is domain specific for banking or retail, but you can Archimate to create sector reference architectures of courses such as the one that I showed you, the beyond reference architecture, that's one that is expressed in the Archimate language and that is defining actually the financial industry domains and the financial industry domains that are actually all these capabilities that we are expressing via Archimate. So yes, it do exist there, now it is already a lot of examples where industries have their reference models expressed in the Archimate language. So beyond is one of them, the banking industry. Right, okay, great, thank you. And let's see, Marine. Here we are, it's two again, somewhat similar. I'll go with the longer one. We're finding in our enterprise that low code opportunities often resist best practice architecture in favor of value as soon as possible. Tight coupling and business logic in the UI, for example. Has Marine been able to use Archimate to better describe the long-term value of developing low code solutions under more robust architectural practices? Ooh, that's really, it's a long question. It is. Actually it's a question I would really like to think about but maybe to give a brief answer and maybe ask Clay to do a follow-up with me. Yes, I do recognize that the longer-term value of low code or applying low code is difficult sometimes to express. And yes, there are definitely differences also, I think between a low-code architecture and a high-code architecture, where in low-code I would definitely advise not to detail too much and leave it really up to the platform to detail the models where it's needed. And yes, that often or sometimes actually conflicts with the longer-term value. And still, if you really go back to architecture principles like making functionality available on both web and mobile, you do can find and make explicit the value of these kinds of platforms. I've never done it with the Archimede language before but I'm sure it can be done. So I think it's interesting also for myself to think about this question a bit longer, maybe, and have a nice discussion also on this, yeah. Giving you an idea for the question, yeah. Let me just think about it over the holidays, huh? So, yeah, so maybe Clay who asked the question can follow up there. So we are out of time, but I just want to, there are various questions and there's always talk when Archimate comes up about tools. So here at the Open Group, we have a set of accredited certified architecture tools that allow people to embrace the modeling, the Archimate modeling language and different levels of functionality, et cetera. But one direct question asked here, what tools are you guys using? What are your go-to tools? Is that the question to us? Yeah, we from beyond perspective actually we are using the Business Design Enterprise Studio tool because this tool allows to model Archimate and also to model in these other language and easily link them to each other. And when we are publishing our content, then actually for testing purposes, I'm using the Archie tool. What I'm doing, I'm exporting in the Archimate exchange format and I'm testing if it is working in the Archie tool. So that's that are the two tools that I'm using. Okay. Marine, anything to you? Yeah, well, I often advise the people that start with Archimate actually to use Archie. I think it's a really good tool and easy to use. It supports the language. I think maybe even the best. So to start, it's really easy to start this download and go. Once you come into a more corporate environment, you often will need a tool with some repository behind it, like Sparks, Enterprise Architect, like Iris, like, well, I don't know which tools are there. I've used them all probably. It really depends on what you really want. But if you go to a bigger environment, you should definitely have some repository or tool that supports that. Right. Okay. Gentlemen, a big thank you. We're gonna leave it there. I'm gonna close with it with the last thing I see in the Q&A, which is no questions, only a lot of appreciation for this presentation and the time and effort shared by Steve, Patrick and Marine, so forget about my time. But gentlemen, thank you for the effort you've made on this. And, you know, you've triggered a lot of questions and hopefully I know shared a lot of insight that will be valuable to people. So thank you very much for joining us today. Thank you. Oh, thank you. So that concludes Toolkit Tuesday for today. All that remains for me to say is we're taking at this time of year, we're taking a little break even from Toolkit Tuesday. So rather than two weeks time, we'll revert on Tuesday, January the 18th, will be the next Toolkit Tuesday where the topic will be Open Agile Architecture Certification, which is a new certification program just launched by the Open Group. So in the meantime, thank you again, everyone for joining us today. Thank you to Patrick and Marine for their insights and their time and effort. And I wish you all a happy holidays, stay safe, enjoy this time of year and see you next time on Toolkit Tuesday. Thank you for joining us. Bye-bye for now.