 So welcome everyone. Today we have a very special session for you to be very talented members of the open group who are also architects and enterprise architecture consultants that major enterprise companies are going to share an excerpt from our first fictional model from the open group, which is about enterprise architects working at a company called Archie insurance, which many of you may remember from previous case studies, which be and this is going to be published later this year by the open group press. The inspiration for this novel came as the authors were sharing their own challenges of making the shift to a digital enterprise. And as we've heard throughout the day, they noticed the problems and opportunity they were chasing while very similar and so were their solutions. Each one of them had leveraged one or more of the standards of the open group to accelerate and prove their solution for their business problems. And they also, you know, shared naturally shared the funny stories about what life is like in the enterprise architecture work at home because it leads into home life so often, and their partners had to be equally patient. So from these realizations and linking them to the existing fictional company featured in the archie insurance case study originally published by the open group art committee for this novel was born. The characters, the authors hope you'll see yourselves your colleagues and your challenges in this novel. Hopefully, you'll learn a thing or two along the way about how to apply the open standards to developing solutions. So, the following scene is set at a live event of the group. Remember, we have live events, which we miss where the open group president and CEO has invited the company archie insurance to come and share their digital transformation success story on the main stage. So, welcome to the open group event in Edinburgh. It's wonderful to be back live again and in person isn't it after all these virtual events. Well, today I have a really special treat for you. I can tell you, many of you tell me that you like our case study presentations the most and you know the ones delivered by people who don't just talk the talk but have also had to walk the walks sometimes walking across fire. Many of you have also shared with me that digital transformation and digital product delivery is what is most on the minds of your organization's leaders this year. I'd like to introduce Brad Nelson president and CEO of our insurance. Dr Kathleen stone chief architect and Nick Ross lead business architect. They are going to give you their story of digital transformation. I have to say I was so impressed by all that the company out insurance has achieved that I invited them here to share their real world story of how they kicked off a digital customer intimacy initiative a little over a year ago. They're a bit about the how and then what outcomes they've achieved so far. And finally, in a topic near and dear to my heart. They also share with you how the open group portfolio of open digital standards, help to strengthen and accelerate their digital transformation. So now, would you please give a big warm welcome from the open group to Brad, Kathleen and Nick. Yeah, yes, it's been quite a journey and we're pleased with how it's going. So what we like to do before we talk about outcomes is to go right back to highlight our aims and expectations expectations from the start. We've just been through a merger of three companies into one. After all the streamlining of processes and rationalization systems that was done during the merger. We actually felt we've made some good strides in becoming an agile organization. However, analysis showed, we hadn't really gone beyond the implementation of actual development, or as Emily or external consultant, we hired indicated me implemented actual ceremonies that's it. It wasn't really deaf adoption that alone being a transform to a digital organization. In fact, instead of being agile, we started to lose grip on the budget. So, being honest to ourselves reorganize we hadn't changed much more than the instrument of screaming as a way to develop software with capital cells, everything else, pretty much the same as before. So now it was time to really transform the whole organization to get our core operation and value streams in order with cross functional teams that work together. We simply didn't know how and where to start. And now, luckily enough, around the time Kathleen reached out to big Mastersons or CIO, and without knowing our conclusions for a need to transform, she provided us with an approach, which you actually decide to embrace. In just a few weeks in our team engage with all the business leaders, and develop the details of the approach, which she's with us today presented to the whole company. I will never forget this town hall meeting. I really felt we were turning the company around. I had the honor to present our ideas and get everybody on board. I knew I still had to convince some who were cynical about change and others who thought they might lose the empires they had built. So I got on the stage, and I asked everyone to close their eyes to imagine to imagine that we work for a company that has broken down all functional silos. In this company, we work together across value streams and are accountable for achieving common goals and objectives that each team has a shared funding model. Business value is delivered on all technology investment decisions that customers are happy with their experience that our company has mastered the use of agile practices from strategy. All the way through execution and operations and that in this company, the information technology department is no longer simply taking orders from the business. IT has a seat at the table with the business and is seen as a strategic partner. There's no business or IT. They're one in the same. And strategy development is not just a once a year occurrence. Instead, business and IT work hand in hand continuously to make incremental improvements. And we control the products and the supporting backbone that we need to deliver value digitally. The result is a team of teams capable of delivering our products on time with the quality and innovation that delights our customers. We had already identified some of the gaps due to a high level assessment that was completed at the end of the previous year. For example, in our ability to execute digital customer management and data driven insurance product offerings. To inform our business architecture, we carried out an environmental scan with our stakeholders using a questionnaire to assess strengths, weaknesses, opportunities and threats. Then we brought the stakeholders together to incentivize all of the information collected. As you can see, we also completed a pest analysis to get a sense of all of the external factors influencing our environment. We also used an organization map to improve our understanding of the organization and the context for strategic planning, deployment, communication and collaboration. To work even more gradually, we plan the team structure to enable the teams to be autonomous and self-organizing. Each able to make decisions, the aim being to minimize dependency on other teams to create flow and drive value. You know what? We don't have to imagine anymore. Our insurance is a digital enterprise. Our budget are aligned to develop streams and which help us to make good investment choices holistically, instead of in our functional silos, whatever we're working on the common goals and outcomes. In fact, our silos have broken down so much that redundancy and duplication is almost non-existent. We are agile in our digital product development from the creation of an idea all the way to operations. And best of all, and this is what makes me most happy, our customers are really happy. We no longer get complaints about being transferred from department to department. Actually, we now hear from our customers that they are happy with our service, that they get immediate support that they're looking for. We also have people process the technology in place for continuous shared customer insights. In other words, we're in touch and in tune with our customers. We did this by using an outside aim view, making our customers the key stakeholders. We owe a large part of our success to the open group standards. The Togaf standard was used as our architecture method for determining the work to be done. The IT for IT standard was used to enhance the flow of the work and to ensure the capture of service and product life cycle deliverables. We use the Archimate standard for modeling the vision, business, information systems and technology architectures. The digital practitioner body of knowledge standard helped the organization develop digital skills and establish an agile and DevOps compatible operating model. And finally, we use the open agile architecture standard to guide the transformation of the architecture capability to become lean and agile. All these standards really gave us a map for our digital journey. There was also a lack of communication between groups because the systems had been built independently of each other. We were able to narrow things down to having four core systems with integration between each one so that the information would flow from one system to the next, which has eliminated the manual reentry of data and reduced cycle times. The data objects for the digital product backbone stored in each of the four systems are the thread that creates traceability from portfolio to operations. We hope to eventually have one centralized systems, but for now the integrations are working well. I'd like to walk you through some of the deliverables. I cannot say enough about our, the work that our business architects did to frame what we needed to do. As I mentioned before, we use the open group toga standard to guide us as well as the stream extremely helpful toga series guides. The business architects spent several weeks interviewing different types of stakeholder groups gathering the pain points the concerns the ambitions and the dreams related to the current situation and understanding of their vision and objectives. This information was used to characterize the baseline state and to create a capability heat map to work out our gaps with the target state, all within the context of an end to end value stream. Identifying gaps led to opportunities and solutions that were prioritized and from that we created our roadmap. The result was for big accomplishments, which together have helped make us a digital company. We completed an application rationalization to simplify our environment. We created a digital product pipeline that keeps work flowing and traceable from strategy to operations. We deployed new technology and support of our digital product products. And finally, we established agile governance methods to guide future digital product endeavors. Here I've summarized our successes and lessons learned. The biggest lesson was that there is an enormous amount of work that needs to be done to become a digital enterprise and much of that work has nothing to do with technology. People and lines of communication are equally as important as the technology value streams and working in the end with cross functional teams has been one of our keys to success. I want to share our digital customer intimacy roadmap with you. It really shows the journey. We color coded it so you can clearly see where we use the togap and it for it standards. The togap standard in yellow and the it for it standard in blue. We started strategic planning with the business in Q4. It was the first time it had a seat at the table with the business. The strategy discussions were so successful that it's now second nature for it and business to work together. The best part about co creating the strategy as a regular cadence is that the work outlined during strategy sessions gets automatically carried forward into DevSecOps because they also have a seat at the table. Additionally, when it's time to deploy solutions, the operations group is ready because they've been involved in the strategy sessions and know what is coming down the pike. Strategy is no longer a once a year conversation. The discussion is continuous. You can see on the roadmap also that development of a governance structure was started early in the schedule. This was due to the agility we wanted to achieve with digital product development. We needed to have principles and guardrails established to keep us on track so that the ingrained gating processes did not bog us down. If we were going to eliminate the restrictive gates, we needed to put forward new more flexible guidelines. The Tugaf standard gave us a methodology for developing architecture runway very quickly for our build iterations. And we established many building blocks and reference architectures that will help us with ongoing initiatives. Getting architectural ways in place faster is something we should have focused on more. We didn't realize how much the architects and strategists needed to work with the business relationship portfolio and DevSecOps teams to keep all the work products in sync continuously and in our agile world. We did not recognize that the architects needed to be at every team synchronization meeting until it was almost too late. So true Nick, that teamwork was essential to our success. Also governance and change management methods were firmed up early and modifications were made as needed during each iteration. We were able to implement new guidelines for the architects that made it permissible for them to deliver only the level of granularity needed for each build iteration to speed up the development of our architecture runways. The Tugaf standard for digital really helped us to build our product development tool chain. For example, the strategy portfolio capability map laid out the data linkage required to achieve full traceability from a strategic team to enterprise architecture, which forms a set of proposals that turn into the portfolio backlog and product backlogger. The same was achieved for the other capability groups requirement to deploy request to fulfill and detect to correct giving full traceability of the product lifecycle by integrating our primary tracking tools. This slide shows the way that we use the Tugaf ADM in the past, where we would create all the artifacts before starting any of our development work. With agile and the need to build an increments to add value iteratively, we have adjusted to only build enough architecture runway for each minimum viable product which adds value with each release of a product and promotes continuous improvement. Now this slide shows the core architecture we developed for each iteration in more detail and how the level of completion increases as the shade becomes darker. A through H on each wheel represents the phases of Tugaf. So for example, in the first iteration, phase A, which is the future vision is the most important element to establish with stakeholders. So the shading is darker than the other phases. It becomes the guiding light for all of the teams. Business architecture is shaded a bit lighter and it also needs to be started early to establish the baseline state. The business architecture will continue to be refined in future iterations as gaps are uncovered in getting to the target state defined by the vision. Requirements and governance are lighter than the business architecture in the early iterations and they needed to be started as early as well, but may not be as well formulated until after development begins and a minimum viable product release or two has been completed. SEO, I actually have no clue what all these standards actually mean, but I'm really happy with the outcome and it really shows that it's a journey that we managed to do today. And not only did we deploy this digital capability I'll talk about, but we actually changed our culture and the way of working. And we did get away from those silent teams and we actually create value streams, which actually produce what we need to deliver to our customers. And we did that we had to change not only the development itself will also the way money was being allocated to functional groups, right from those function group to share to fellow streams in the funding model. Another big change was that we disabended the traditional product methodology and the getting that coincide with that we need to get to our continuous product lifecycle model. And all the transformations have made us agile and we provided more velocity, and we have to take on digital product implementation as a way of doing business and not just on the side. The biggest lift was getting our business work together on the most important objectives across the board, establishing traceability of work products from strategy to operation for everybody. Folks, that was such a great story. And I'm glad that you came to share it here with us today. Congratulations to everyone involved. It's quite, quite a journey. And you've, you haven't got to the end of it. I know, but congratulations on where you've got to so far. So, as we do here at the open group events, I've got some questions from the audience for you. And first question aimed at you, Kathleen, I think, how did you get the leadership team to buy into organizing the teams, organizing teams across value streams. That was one of our more difficult culture changes that we made. We needed to break down the political barriers between the functional groups. Most of the silo thinking was due to establish school and funding structures. Each functional group was responsible for completing their own goals within their own budget. Which really inhibited working together toward common outcomes. Simultaneously, this suppressed cross functional thinking because each functional silo was only accountable for their part of the product life cycle. This silo way of thinking was creating bottlenecks with work stuck in cues waiting for each functional group to pass it along to the next. It also resulted in many duplicate tools being developed to store the same type of product life cycle information. It took a while to get leadership to see the value of working in teams across value streams towards common goals. But it has been tried and proven now with several of our value stream team implementations. We do it one value stream at a time and the benefits speak for themselves as the flow of work increases when teams have the same outcomes they are working to achieve. We also set up an accountability framework where employees are rewarded for working together versus the silo way of working within the boundaries of their own functional group. That's great for answering that question. It's a particularly important question concerning digital transformation. I don't think we can say enough about the importance of teaming across value streams to work on common outcomes. It's inevitably going to increase the visibility and flow of the work. So thank you. Let me move on to the next question. This one for you Nick. I believe you had to deal with an issue caused by unexpected changes in the system. Tell us about that. Yes, we had issues with the operation of the new digital products platform. Our customers began to experience problems accessing their own information and new requests just weren't making it true. To make it worse, the operations team could not get anything out of their monitoring systems. So they were logging in manually to individual servers without access to any centralized information. I set up two incident resolution swarms, one for the product issue and one for the monitoring issue. We checked all deployments done by the teams in the previous 48 hours. Finally, Kathleen, remember that's when I felt I really had to notify you. I was pretty awkward because you were on vacations and I caught you when you were just arriving at the airport to check in. Sorry again about that, by the way. Yeah, no problem, Nick. You did the right thing letting me know. I knew you had tried everything you could up to that point, including going through all the recent change requests in the system. So that's when we started looking for changes that must have taken place outside the automated approach. Some of them simply just to try to keep up with the rate of change going on. By that time in our conversation for Kathleen was just trying to get through the airport security. Oh yeah, right. That was hard. And my husband was running out of patience for me. Then it hit us. The security team had recently released a new version of their security platform. This new system has had its own capability and automatically began to apply the highest level of security to identify mission critical systems, including any new monitoring systems, which the enterprise architecture team had not been aware of. So I contacted the security team and brought them into the incident swarm. And the problem was soon solved. So then we held a post mortem after the incident. And then, as I was looking at the it for it capabilities again, it seemed that detect to correct would help us to understand the current state of production to enable comparison between the actual product instance and the desired product instance. To allow the discovery of something implemented outside the approval process and also identify the potential impact of changes by making sure that a register of all changes is maintained in a central repository. We can now track transition states and assess the target state, which gives us much better visibility into the architecture change management. Right to here. Thank you. So Brad, you've clearly got everything set up going forward. But as with any company out there, you must have been using those monolithic systems, which are too big to change and at the same time create a block of a transformation. Have you solved the issue of those monolithic systems and often legacy systems? Great question, Steve. Thanks. I mean, yes, we had one of those. We had the BLOS in our case actually really worse. Oh, don't you mean the prolongation application? Right. Thanks, Nick. Yes, BLS BLOS actually was not a official name, but what it was become to known as actually it's called, we called it the big ludicrous old system BLOS. But as you said, prolongation applications the real name. This was a system that we marked for replacement many years ago, even before the merger, and it became more and more the form of a liability for us. It was simply not possible to scale any further. We took it to the end basically. Unfortunately, we just failed at every attempt of this replacement. It became this collective headache for us all. Yes, I remember this. Every time the team tried to deliver a replacement system, the test cycle found something else the current system was doing that nobody could have predicted. Yeah, right. And what it seemed at the time was that everybody needed to wait for this replacement system, but everybody could actually see this was not going to happen. It didn't work. And, you know, we had this guy, poor old Hans Pickle, and he had the possibility of replacing this legacy system. It was connected to so many processes. It was just too big to fail. And every time to attempt to dismantle the application failed to fail to deliver. It just became this liability. And our consultant Amy I referred to her before asked whether our big bang approach to replace it all at once was actually the best way to go. We couldn't see any other option. Yes, as Ben, Ben Cohen, one of our business analysts pointed out, all the data he needed was available in the application. It was just all over the place. There was no API in place to extract data using a query. To realize that regulation had forced a backup of data to be created for all critical systems for business continuity. So it was just a case of checking with the risk management team to see if that data contained the information Ben needed. Creating a quick fix. This fix allowed us to develop solutions for their integration as well. Removing the strain on B on the B L O S. Correct, but it did not solve the real problem of replacing the B L O S. As Amy pointed out, it's not always possible or even the best approach to try and replace something that bit, you know, that big using a big bang. So we did our research and found a concept called strangler pattern. And it's referenced in the open agile architecture standard. It basically means you sometimes have to create room to breathe by slowly strangling something. It allowed us to create space to evolve a replacement behind an API while bypassing the B L O S and still keeping the data in sync. We can't get rid of this B L O S. Anyway, as I said, poor old Hans pickle. Yes, poor old Hans pickle. I had to replace the architect in his team at least twice. Some of my team even refused to go back there. Yeah, yeah, yeah, I know I know he thought I was just trying to make his life even more complicated. He was really not happy and came to see me to want more time and money, you know, go figure blaming you actually clean for adding all those sort of new requirements. I'm glad to say that Hans has now come to the conclusion that his skills are far better suited for a different project. Well, sounds like a great result for both hands pickle and art insurance. So good, good outcome there. Thank you so much for being here today Brad Kathleen and it means a lot to us here at the open group to hear about real successes at our members companies using the open digital standards developed by our forums and work groups. We'll see you all back here in a moment for our digital transformation Q&A panel so don't go away. And that's a wrap. I want to thank our three authors for doing this role play from turning point digital journey novel. I hope it's got you all very excited to read this architecture novel and it gets published by the open group best later this summer information is on your screen so please keep your eye out for that. Today, I invite our other three speakers to join us turn on their cameras so we can start our final session today, which will be a Q&A session about digital transformation. Thank you everyone. Thank you. Thank you all. Indeed. So I don't know I know saw great. I mean, thank you for joining I know it's a time zone challenge for for many people here. So, let's get started. I'll be looking for a Q&A that's put in the Q&A tour by the in the WebEx app. I was wondering this correctly in the morning session there was a lot of emphasis on the need for a new operating model and new organizational ways of working. So, how do you all see the role of ways in driving this change upward and reshaping business models reshaping operating models, you know, helping with organizational design helping with the team coherence and things like that. We'd like to go first. Okay, so that one. The way I'm seeing I'm a business architect at heart so I am really into value streams and business capabilities and, and doing the mapping. So, I see that we really need to change to more of a value stream model in the way that we work. Instead of in like we talked about in the, in the role play, instead of being in our silos are functional silos working across the value stream so that things don't fall through the cracks. Any other thoughts on that, that role that role change for architects. From what I see is that you can sit and wait till somebody comes along and ask you a question, you know, you need to be much more providing a service to the rest of the organization as an enterprise architect, and making sure that you get out there in where it is a value stream. I think for too long, we've been really holding back and saying you need to come to us and we will serve you with the decision from our enterprise. Yeah, I'm really taking to the extreme. That's no longer accepted and for good reasons. And since it happens in this value streams being there and being with the fail with those people that are actually creating those value streams makes much more sense. You know, operating model starts to shift towards this working along those fellow streams and organize in that same way. So it is where you can be. Yeah, so really that emphasis on being embedded and feeling what the product teams feel and deal with on a day to day basis. Yeah, and it's not like you need to think of everything upfront. So you need to be with the guard rails that help the organization and the autonomous of autonomy of those decision making that needs to happen in those fell streams need to be guided but not blocked by by gates. And that's the transformation that you need to help the organization make. How do you do that. How do you make that happen. And at that point, one thing that struck me in the novel was that there's a frequent use of what I will characterize as digital terminology, terminology that comes from the more recent learnings on how we manage product delivery. Like you mentioned scrum ritual swarms. And do you think it's, it's important for us to speak this new language to be effective in driving organization change. For me it does. Absolutely. Yeah, we even made a point of that in the book that there needs to be a coming together of architecture and dev ops. And if that doesn't happen, then things go. Pretty quick. I think what is very important also is that everybody speaks the same language and that's we can create a real on all the organization and all the product lifecycle. People can understand and share the same language and the same name for the concept they use. I want to shift tax here a little bit. And I think we still have Tony we may not have Tony I had a specific question for him. No, we've lost Tony Dave, sorry. Unfortunately. So, let's see. You know, we've stressed the importance of it again in the morning session stress the importance of the product team. And came a few effectiveness in a digital enterprise. You know, how do you see, and the IT for IT models spends a lot of time talking about data flows and you heard about data governance from Arthur. How do you see good data governance supporting the effectiveness of a digital organization and how can these, all these different teams be encouraged to use good governance so they have the good data to work on. Yes, anybody answers. Oh, go ahead, Sylvan. I don't know. I think what is most important and I experienced this in one of my customers currently is that we need to simplify the way the data is handled by all the systems. And probably this will be part of the data governance that that will help to to be more oriented on the data and maybe less on the on the applications and less on the system. That was the case before so probably this is how I see that the data governance can help to be a more more digital and to be a more oriented on simplifying the way that we move to product orientation. Probably we will also simplify the way we manage the data in the enterprise. What I've noticed too is that because of the way that a lot of companies have been organized around functional silos. We've tended to have end up with disparate systems. A lot of times and redundant systems that are doing the same thing. So that's why I like business architecture a lot because you can start looking at the capabilities across many functions and start seeing where there's. Duplication of of not only information, but roles and processes as well. And tools and I think that's why application rationalization is so important when you're starting to build your foundation for for digital. Because then you could start eliminating some of those disparate systems and then the information automatically starts flowing once you have, you know, your core systems that you're bringing your data through. The enterprise architects place a really important role to speak to the part about encouraging different groups to have good data governance in that enterprise architects can actually communicate the way that data fits in in many different places and that it's not just data governance as data governance for its own sake but enterprise architects can also show how it fits into application integrations and value chains and all of these other areas. I agree. I mean, as with any governance, as soon as you start to implement gates or something like that it doesn't start to support the organization that much anymore. So it needs to be good enough to manage the flow of data across the systems. But it doesn't, you also need to be aware that you're not do governance for the government's sake. And finally, say it like that. It needs to be just enough to guide that organization. That kind of lean, lean thinking and not trying to get it all done up front as we said earlier. It's a shame Tony's not with us. One of the things that struck me about his presentation was he noted the value of rationalization. And what I would call digitization or the PP bot calls digitalization in bringing together all of the components of their enterprise. And he noted the budget savings as the big outcome of that. So one of the things I kind of wonder is what sort of business or operating model changes can result from this kind of architecture rationalization does is doing that kind of rationalization of your enterprise, help you or enable you to change your business and operating models more effectively. So when interactions change, when the novel we talked about the customers increase in customer satisfaction is all of the digitization and rationalization unnecessary precursor to that kind of an outcome. I have to say absolutely because of like I said before, all of the redundancy that's been created in a lot of our environments, because of the, you know, these functional silos. You know, different functions that are creating applications outside of core applications a lot of times. And once you start that rationalization effort you start seeing where there's all this redundancy and when you get that out of your environment you start getting it out of your environment then things simplify so you you greatly reduce the complexity in your environment and so I really do think it's an important foundational thing that people need to do for our digital. Yep. Good. Any other thoughts on that we're probably coming up on our, our limit here so final thoughts on the rationalization. Yeah, I think if you can't transform as an organization and thinking products that you deliver to customers and how it is not just a side effect of doing business but really something that is part of the business, part of the industry. You can't even keep up with what the customers are demanding going forward so it's not it's not even a question if you need to do it's a question of survival for most companies. The rationalization has to happen on an ongoing basis to because things start creeping back in so you just have to constantly be you have, you know, have to have those guardrails in place to, you know, not not have all the duplication creep back in once you've done the application rationalization, it's ongoing. Any final thoughts on that. I think rationalization is probably a prerequisite to do to do a smooth transformation on the digital enterprise, because to begin to develop digital products, you need to have a simplified organization and if you have a too much complex organization and much complex information systems, it will become much more difficult to do a good, a good digitalization and to have really valuable products for customers. Anything to add. I think that I've found valuable on that point. I'm kind of going off of what Stephanie was saying about those continued processes and this continued guardrails I find that when there are algorithms supporting some of that analysis and dashboards that help with really representing that so that stakeholders can see that decision making as it's happening and contribute to that and have that insight visible. I find that to be something that leads to more success for enterprise architect architecture teams to be able to continue that effort instead of seeing it as just a one time effort. Great. One last thought. I just wanted to say I completely agree with what Karine just said that that visibility is really essential. Well, I want to thank all our panelists here Karina. So then she's Stephanie, of course, and so. And really look forward to the publication of that novel. And so with that, I'll wind up with session and hand it back to Steve. Thanks very much Dave and thanks to all our panelists and the, yeah, the novel segment was was a bit of fun wasn't it enjoyed that. But there's some some really great messaging and really great experience gone into that so yes, do look for the novel. And that's it for for today folks thanks to all the all the speakers. As I said at the beginning a court in a pint pot we really have a lot of content to get through today. And I'm sure some of it at least will be worth revisiting in the when the when the recordings come out so do do go back over that. Thank you. Thank you to all the speakers and most of all thank you to all of you attendees who have hung in there. All sorts of different times and I know it's, it's great to have you with us and I do want to thank one final thank you for our sponsors this week. Thank you for your support and wherever you are in the world folks. Be safe and be well and look forward to seeing you again soon we will leave the the chat function will leave the meeting open if any of you want to exchange some last messages in the chat or any any feedback to us. Thank you for that as I say thank you for your for your attention I hope you found it a valuable use of time. We certainly did and see you next time.