 So, I'd like to welcome another representative from one of our sponsors from Evolution, Andrew Luthwake. So, Andrew is a software consultant with Evolution. He joined them in 2013 and specializes in a range of EA disciplines. He's worked closely with leading banking, insurance and financial brands, helping organizations and teams implement and deploy successful business and IT strategies. In this presentation, Andrew will provide a practical overview of the TOGAP assets plus case studies and examples of how the TOGAP standard is used to drive business and technology planning. So, a warm virtual welcome from the open group to Andrew Luthwake, over to you, sir. So, as Steve mentioned, I'm going to be taking you through some areas of TOGAP to effectively support strategic planning. Hopefully across the customers that we work with, and maybe just give you some insights into how it's actually used with other potential frameworks and rotations as well. Before jumping into that though, just a quick overview, I guess, of Evolution. We are an enterprise architecture software vendor. We have been going for about 19 years now, and I've been here for about seven of those years. So, it's certainly been hands-on with quite a few customers across the globe as well, as much as we have offices worldwide during my time as a consultant for Evolution as well. I've kind of traveled, I guess, to all those customer sites in person. So, I have some experience with how Abacus is deployed, but more so, I guess, in general, how enterprise architecture has been used across these companies and across the organizations that we work with. The first thing, I guess, to reiterate, which you've seen some slides already from some other presenters today in the past couple of days, is just quickly touching on the certifications available. The key thing here, I guess, is that it is, of course, global, and there is a significant increase and a continuous increase in people adopting things like Toga for ArchiMate. And of course, as those certifications rise, part of that is that people have more knowledge, let's say, around enterprise architecture as a topic. But it's also key to make sure that those certifications or that knowledge is actually being applied in, let's say, real-world situations of where Toga or other areas are actually going to be used for. The certifications, of course, as well demonstrate, let's say, the skills that are available. It's not just a theoretical aspect. Those skills are, of course, then useful for deploying these areas into these areas. The other useful thing, of course, around the certifications and Toga being one of those, is the fact that these standards provide us with some kind of landscape to work of at the beginning. If we look a couple of years ago, things were significantly different, but the same standards and the same architecture notations existed. And that's because they are, obviously, continually adapting as well. The way we should really be treating these architecture frameworks or notations or metamodels, if you like, is how we actually use them in practice with likely a combination of other areas as well. Again, you would have, of course, seen through all the Toga documentation. You should be using it as some kind of toolbox. Many times, I guess, I've worked with customers and it maybe seems overbearing to actually deploy Toga. That word of deploying Toga should be changed to being able to use Toga or bits of Toga for the correct situation at the correct time. Now, you usually have the general term of you can search for something in Toga and you can't find it. It might not be worth using. And, of course, that applies for other notations as well. But effectively, that's where Toga is going to be actually quite useful. Now, the frameworks themselves act as some kind of, let's say, template. Of course, the data behind that that we'll be diving into as well. But the main focus for this particular session is going to be around how we're actually going to be using these four things like scenario planning within the enterprise architecture function. So Toga does actually describe this in a bit of detail in terms of defining scenarios, let's say. And when it follows relatively closely to how we are evolution tend to deploy Abacus. The last thing we want to do is come in and kind of deploy Abacus as just some other system that has to be integrated just another system that has to be maintained. The idea is that we start relatively small. And this gather, analyze, review process is effectively what you go through for any of the scenarios that you develop. Trying to capture things like your business and technology landscapes, providing graphical forms of that, making sure that that's connected to other areas of the organization. And then, of course, making sure that it's available for other people to review, communicate internally, externally. And then, of course, iterate on that. And that feeds, of course, very nicely into how you might begin building up one of these scenarios, again coming from Toga. And you might have seen as well, and hopefully it's probably a university or college days where you build up smart objectives. It's obviously key for designing any scenario or going through any kind of planning process. And you need to make sure that everything is clear. These kind of smart objectives do then tend to apply across the entire organization. And, of course, it feeds into very specific scenarios that we're actually going to touch on a bit more later on. The other key thing, and across these scenarios, is that they are constantly changing. And when we start thinking about how we actually manage different architectures, different states in time, different projects and programs, usually they're changing. And we want to understand how we can actually differentiate them. If you're familiar with Toga for an Archimate, which, of course, most of you probably are, that's when we start talking about things like the gap analysis we do, the impact analysis, the plateaus, the roadmaps we produce. How do we actually move from one state to another? And that's pretty much why Abacus is going to be used for things like scenario planning. In the tool itself, this is just a couple of visualizations to give you an idea of one potential use case. This one is actually looking specifically at trying to manage what we might classify as some kind of baseline, some current state architecture. I, where we are today. And then, of course, that's important without knowing that. It's going to be relatively difficult to actually start planning where you want to move to. So these kind of baseline views that we produce is all, again, based, potentially, on the Toga architecture framework. But the data behind it is what's driving these different scenarios that we're producing. Customers that we've worked with do have various, let's say, approaches to using these architectures. You might be planning different projects or programs, different phases, maybe more of an agile way. You're actually building these per quarter of the year, perhaps, or architectures per departments or regions. They're effectively used to build up these discrete alternative views. So these become really important for those transition phases as well. And then it allows you to start analyzing these different scenarios in terms of which one is best. So Customers of Hours, of course, use Abacus for this. And I'm not necessarily saying that any Customers of Hours have an architectural mass pandemic. But that's essentially what they're trying to do. They're trying to understand where they are now and where they can actually be within, let's say, 6, 12, 18 months time. It's about providing an overview of all of that data internally. Now, each of those scenarios then tend to be rated. So we have to have some kind of attributes to try and understand well, which scenario is best. And that might come down to the fact that we're trying to reduce costs or improve efficiency or manage risk, improve reliability of the systems we have, make sure the systems that we have are more maintainable, let's say. So this is where those scenarios or those architectures effectively fall into each of these categories. So it's always important to have these KPIs of these metrics because this kind of trade-off analysis is going to be key. And of course, it's also part of TOGAP and other notations in terms of where that falls into those phases. The other key thing about managing these scenarios is that it's available for users to understand. We've kind of moved away, let's say, from everything happening in siloed locations or it's behind the scenes where people don't have visibility to this information. You want to make sure that if you're making a decision on a project or program that's justified and documented and hopefully, visually, you can actually demonstrate that too. Now, the other aspect, I've mentioned TOGAP a few times and some other notations, but it's quite important to keep in mind that, of course, these don't exist in isolation. So TOGAP itself is obviously quite useful as a methodology. The viewpoints that you can see on the screen here are hopefully things you've seen before. And it does provide a lot of structure in terms of what you can actually start using and modeling in any tool. It's important to remember, though, that these areas are typically then expanded upon. So as much as TOGAP is useful, we also need to understand that there are other models that are also going to be useful to integrate to. So whether from a cybersecurity aspect, we look at something like SAPSA here, whether we look at things like NIST frameworks and COVID and ITIL, these are typically things that you would then integrate into this TOGAP methodology that's been defined. It's something that the other thing that the open group have done a lot of work on as well recently. So especially along the things of the ARCUMATE model, what you'll typically find is then this being applied more closely to the TOGAP model, where you're now using the TOGAP model itself with potentially the ARCUMATE notation. So again, there's some crossover across all of these frameworks, whether you're managing business processes and want to use BPMN or EPC for this. These are also the fundamental aspects of the structures that are going to be needed to accept any of the type of data import. Typically what this means is we build hybrid frameworks. So part of the consulting aspects, I guess we provide, is trying to understand what your organization is trying to do, what kind of scenarios are trying to analyze, what frameworks may be more suitable, and where we can actually adapt existing frameworks to be very specific to the organization. So whether it's taking things from, you know, PRINC2 standards, BPMN, TOGAP, ARCUMATE, P3O, PF, and there's hundreds of frameworks and notations available, the idea is to actually start using these where appropriate. You've likely heard us talk about frameworks in a lot of detail before and you end up what we call these kind of Francon models. So whereby no means suggesting that you should be using every single framework, it's using just enough, just enough of that notation on the framework that it's going to be suitable for that particular point in time. So for scenarios, I guess a lot of these aren't technically new scenarios. They become more prevalent in various time periods, I guess for now, especially for things like remote collaboration resiliency of these systems, recovery planning, it is quite key obviously because of the current COVID situation. But the idea is that you can actually start using other frameworks to help understand where these are applied or where this impacts your organization. So TOGAP, as I mentioned, provides some kind of framework or structure for this, but you might also want to utilize something like PESL model. And what kind of environmental factors actually come into play for this particular project or program? If we look at the technology factors, of course, there are things like BPMN access and licensing and communication of information. This is going to vary industry to industry, but what PESL does is it gives you a bit more of a generic model that you can actually then start applying. And this, to some extent, is some form of risk mitigation. This is helping us identify where there are areas, where there are gaps in our capabilities, perhaps, so coming back to more of a TOGAP capability-based planning phase. This is again where we can start understanding some of those changes and some of the impacts of those changes. Once we actually manage to build that structure and produce that information, of course, we want to start communicating that. So when we start looking at some of the key goals or objectives recently, these are some of the ones that we just wanted to quickly highlight, I guess, and we'll provide some visualizations that customers have used to build these. And we actually provided, during one of the summits, we had a few weeks ago, a very specific set of slides on scenario planning for the finance industry. And I guess that's quite a good use case to look at as well, because typically from, let's say, a traditional bank these days, cost reduction in systems is fine, but typically there are going to be new ways of working. And when we talk about resilience, of course, we talk about social resilience, supply chain resilience, operational resilience. There's a huge number of factors that currently are affecting organizations like that. So of course, digital channels are much more used, much more these days, let's say, and physical branches aren't. That's just one area of resilience that needs to be taken into consideration. The idea behind these goals or objectives, however, as I mentioned, is to start building some views that actually help communicate this information, because a lot of the customers I work with, the architects are obviously more than happy to develop and deploy an archimage model or a TOGAP methodology, or build process diagrams, huge A0 pages, which I wouldn't recommend. But really, when you're communicating this to other stakeholders, other business users, they might not necessarily know the notation, and it's certainly not something that they want to or should be learning. So one of the aspects of that is to actually start building what we call these dynamic dashboards. So we have exactly the same data behind the scenes. We're still looking at logical, physical application components, business processes. We're looking at org structures and requirement-based planning, but at the same time, we're representing that in different ways. Whether it's dynamic tree maps that people are drilling down to understand how the costs differ per region or per country, whether it's the cost of the various architectures or programs or projects that are in production or being developed, it's about making sure that as much as all of that data exists behind a framework, that you do have effective ways of communicating that. Cost is one we've highlighted here as a big one. Cost obviously drives a lot of change if not all change internally, and you would have potentially heard extensive WebEx as we've done before on managing costs and communicating that. Even on very detailed technical use cases like technical debt or cloud migration projects, cost is a key driver. However, there are implications to just looking at cost. Cost cutting is one thing. You also need to understand what we call these kind of second order effects. So does cutting cost impact the services that we produce? Does it impact the time we go to market with different products that we're developing? Do our processes actually still run as efficiently as they did with those systems that have been decommissioned? These are what we might call these second order effects for focusing on one KPI and typically ignoring the others. So this is really important then for trying to understand where these come into play. And one of the ways of actually understanding that is by making sure that all that information is available. I would hope that gone are the days of you drawing things manually as much, spending your hours in visual, curating a perfect architectural diagram that you're demonstrating to someone, and hopefully you move into these types of views, these kind of graph based views, where you're actually just drilling down through the content that you have. It makes it much easier to navigate through this information without the need to understand a notation. And they're very specific to each user or each domain, whether it's a focus on processes or capabilities, a focus on risk, a focus on applications or systems, value streams that we're defining internally, or databases and the data that's held within them. These views are then going to be key for those users who actually want to understand the information without necessarily seeing everything at once. Well, that tends to lead to these kind of risk based dashboards because a lot of what we talk about from a scenario planning or a scenario analysis perspective is it's all about risk mitigation. So we do want to focus on the some KPIs, of course, in terms of how we might score risks internally, whether they're business risks or technical risks. There's key indicators in here that help us address how these risks are maybe mitigated by different work packages or projects or programs that we're working on, but we're also providing this real time. Things are changing very quickly every day, and the last thing you want is some static report that was a week old or a month old. Ideally, you want an environment that users can actually navigate through this information in this live fashion. So again, focus on some of the key KPIs that you have and make sure that you make that available to those users. That, of course, then leads into some of the other metrics that we actually use internally. One of those, or certainly all of our customers, I would dare say use this particular metric, is some kind of lifecycle view. Everything we talk about in terms of analysis and scenario planning tends to fall into some kind of road map that we're producing. And one of the best ways of doing that is starting to track things like decommissioning and systems, technology end-of-life dates or end-of-support dates from vendors. These are the types of things that actually impact us the most. And arguably, these are the types of things that tend to slip under the radar. And that's why building these road map-based views allow us to drill down from a high level of capabilities that we have internally, you know, what processes are actually supporting that capability to ultimately be applications that that process is using. So it's not just IT focus, of course, by pulling that up to a process or a capability level, we can build those Gantt charts, but then we can also build entire dashboards of that information. So capability-based planning is, of course, an important aspect. And it's really difficult to make changes internally on what systems should be decommissioned or what systems should be introduced if we don't have an idea of what the organization is actually capable of doing right now. So, of course, there are gaps in here as well. There's process automation that you work through. But again, the real message here is making this data available for other users to consume. Now, this could get a lot more technical. And certainly, this is more of a real-world example, let's say, of one of the customers that we have with anonymized data. But this one is actually looking at the resilience of certain systems that an organization that we work with have internally. And the benefit of this dashboard was multiple KPIs and metrics on one view. There's no need to go to five or six different architects to find this information out. No need to go to other business intelligence tools or find difficulty in knowing who to ask at the beginning around certain systems. This gave them a click view and a clear indication of the availability of the applications they have, in this case, this IVR application. We also have this reliability score they're taking. And again, at times, this might seem like a lot of information, but these are typically things that are already available. Whether you're using the API to connect to Jira and picking the tickets that are raised against a certain system, that of course contributes to things like the availability and reliability scores. And then we quickly had a view of the complexity of that particular application in that system on the right-hand side. So again, from a resilience reporting perspective, we're relatively confident that the availability and the reliability of this system is pretty high. And luckily it is. It does have a significant number of interfaces throughout the organization. So if this system did happen to go down one day, of course, this is going to be a major issue. So again, this is where these types of views come in as key visualizations, providing live information, and of course, making sure it's accessible to everyone. Behind all of that, it is worth reiterating, of course, this is all based potentially on a Togoff metamoral methodology. And behind the scenes, we have a structure of how we're developing and building these architectures. What we're then trying to do is make sure we can communicate that in the most effective way possible. So there are a few quick things, so a few takeaways if you like, just before likely a couple of minutes left for some questions. But the main thing for me, I guess, is worth reiterating is the support of those frameworks are there as a guideline. They're used as what we might classify as accelerators. They should be modified. They should be adapted to your organization. And anyone who uses, let's say, Togoff 100% out of the box, probably isn't getting the most use now to Togoff as it was intended. The other key thing, I guess, specifically from this point in time and some to the current situation is there are some risks that we've, of course, notified and have been aware of from various customers around things like working from home. Things like VPN access, there's IT overlap in terms of systems providing the same capabilities. This effectively an increase, of course, in software purchases, as we've seen as well. All of this information should be kept in a single repository. The last thing you need at this point in time is to struggle to know where to look or to struggle to know the impact of a change. So, yes, no one's planned for this situation, but we can obviously plan for various other situations that we actually want to work towards. And again, this COVID situation should, as much as it provides risks, give us some potential solutions as well. There's always opportunities to be have in any situation, whether it's not something we planned for, we should always try and understand what this has given us in terms of potential solutions and potential benefits as well. One final point from me, I guess, is I've scanned over, let's say, a lot of use cases around cloud migration, roadmaps and technical cadets and scenario planning. We do, of course, have all of this from previous Open Group webinars and our own digital summit that was held a couple of weeks ago. So, feel free to reach out if you want more information on that. But with that, I do believe we're probably close to the time here, so it's probably worth maybe opening up to any questions that I've come through at all. Thanks, Andrew. Absolutely. Thank you very much for that. And I totally agree with your comments on tailoring, tailgate for any other framework. They're never intended to be consumed whole, as you say. So, we are up against time, so let me take this question. The tailgate standard has always seemed like a big framework, as someone said yourself, with a lot of upfront requirements. How does your approach, I guess, using tools, address the need to work in a more agile way? Yeah, it's a good question. It's probably a question that we could spend quite some time on. So, I'll be relatively brief. I mean, the thing I guess we've heard from customers when we first deploy Abacus, let's say, is to quote, let's say, is togath no longer fits our world. It's heavyweight, it's waterfall, we're working in a more of an agile fashion. But the issue with that, of course, is maybe a slight misinterpretation of its use, perhaps. Agile and togath can both exist side by side. As much as they might technically operate in slightly different spheres at times, they, by definition, go hand in hand. You could arguably say that phase AA defines an epic or a user story or program increment. That's perfectly fine. But again, coming back to that point, is that togath is pretty much just a bunch of tools that you're using to help with these situations. And I don't think, as much as agile, of course, is key. I don't think that necessarily means that as an organization, if you're agile, that you can move away from big requirements upfront. And certainly, some customers that we work with in kind of major infrastructure investments, these things need to be planned and budgeted and they're deployed over long periods of time. So it's complete opposite to agile, but of course, that's where this needs to be applied in the right situation. So yes, agile and togath, I think, can help exist together and hopefully what we do is give you some expertise and potentially a tool that can then actually help align both of those as well. Right. Yeah, it's a common question and misconception that the two are incompatible with each other, you know, but I appreciate that. Andrea, in the interest of time, we're going to leave it there, but if you're able to, there are a few questions in the Q&A, a couple more questions actually in the Q&A, but if you get the chance to answer one specifically about the tool and one is about resilience. Appreciate that. And in the meantime, thank you very much for your presentation and a big virtual round of applause. And we look forward to your time.