 We're now going to move to our Q&A panel. Unfortunately, we're a couple of panelists down today. We don't have Peter Haveland, and I don't think we have Jean-Marc Bénus for either. But we will see. It may change as we get going. But basically, everyone else you've heard from in the videos will be on the panel. Plus two additions, Antoine Longin, who is the Chief Innovation Officer for MEGA International. Antoine has contributed to the foundation of the HPEX Enterprise Architecture Toolset and is also involved in standard organizations such as the OMG and the Open Group and has been a longtime contributor inside the Open Group. And also another colleague of mine, Chris Ford, who is VP of Enterprise Architecture and General Manager for Asia Pacific for the Open Group. Chris has global responsibility for the Enterprise Architecture activities inside the Open Group, including the TOGAF standard and the Archimake Modeling Language. As an Enterprise Architect, Chris has held various leadership roles throughout his career, including implementing and managing EA practices, application development, information management, and technology operations teams. He is also the CEO of the Association of Enterprise Architects. So welcome to all our panelists. We have a number of questions and questions are still coming in. So we will start to get through them. So the first one, I think, Antoine, maybe I'll come to you since we haven't heard from you yet. And that is, can you say a little about what has changed in the standard since the draft version or the snapshot? Oh, yeah. So the TOF is like any kind of agile endeavor was a kind of made by incremental and also feedback from the first delivery we had. So the idea, of course, is what we have a kind of two steps to provide a first snapshot for having initial feedback on the foundations. And at that time, we had some of the main principles being set up, but other ideas or other connections between product architectures and operations were still up and running. And also this ability to have a two-phase feedback from you as a community yourself help us building, I would say, a more valid experience to the community and also complete because it made incremental steps and essentially those final items that Frederic showed on the connection between product architecture, strategy and operation. And I think that was the most final phases we ended through. But clearly, I think something we experienced also within the open group was this two-step validation process, not having a large validation of a very big document, but being able to have incremental validation with the market and the team. I think that was also something key for the development of the OO. Thank you, Antoine. Anyone else on the panel want to add anything about changes from the snapshot? Otherwise, we will move on to a question I'm going to pick on the other person we haven't heard from yet, Chris. So, understandably, I said at the beginning that the open group is known for enterprise architecture standards and none more so than TOGAP. So, a couple of questions related to that, Chris. The first was, does this replace TOGAP? And the second related question is, what's the sort of intersection or how do the OAA standard and TOGAP, then the TOGAP standard work together or coexist? Okay, so the very short and brief answer is that OAA doesn't, in the open group's view, replace TOGAP. But it does come with a very specific viewpoint and community viewpoint about what agile architecture is. So, the intersection between these things, just use an example. Over the years of development of TOGAP through 8 to what now 9.2, the standard is always mentioned that you need to be managing culture or taking into account culture and organization in the context of the enterprise architecture practice and the enterprise itself. But the way those things get implemented in a given enterprise vary a lot. And so, it's very difficult for a particular framework to articulate the situations that exist for every single enterprise. But TOGAP was a little bit obscure about exactly how you would go about organizational design or cultural issues, things like that. I would offer that the open agile architecture framework deals quite explicitly with how to take into account those particular types of issues and the current best practice thinking about how to approach those problems and to consider how you might, as an architect, help your entire organization or your ecosystem to take into account those particular types of issues. Move through those issues with the context that's provided in the agile architecture framework. So, they are complementary, but specifically community-oriented viewpoints on what enterprise architecture is today. It's clear that TOGAP has been used and is used in digital transformation contexts. You've only got to look at some of the work going on in the Indian national government, which is TOGAP based with our own digital transformation to see that. But the OAA is targeting a community audience of architects and other folks undertaking digital transformation. And it's an expansion of the enterprise architecture portfolio for the open group. It's complementary, not a replacement. Right, yeah. I mentioned the toolkit earlier. It's another approach that can be taken for enterprise architecture. Does anyone else on the panel have a comment on how the two standards play together? If not, we will move to an ever-growing list of questions. Okay. Let's see. Question came in fairly early on. Is there a plan to add or extend the standard to address concerns of government where legal requirements are always important? It's not just about value-based metrics. I guess a related question or similar question is, do you see the standard being capable of being used in a government context too? Who would like to take that? Maybe I could try to answer that one. Let's say that the OAA has been developed with various organizations which included banks. And as you know, the banking industry is a heavily-related industry. And I think also, Badi mentioned the regulation issue in the health care industry that he is working in. So we have taken the dimension of compliance very seriously. And I will not go into details on how we include it. But I think that if you refer to Badi's talk, he's offering a less common and controlled way of getting things done and making sure that constraints are followed. And I think that these can not only include somehow business constraints or technology constraints, but also compliance constraints. And I think that it's a key dimension for agility at scale. Because if you cannot move from the old way of achieving compliance to a new way that's compatible with speed, then it means that you are not going to benefit from the speed that is required for digital transformation. So that's very important to basically do both. And I'm not from the government industry. And there may be some aspects that are more difficult than health care or banking. But we would really welcome people from government to join our working groups so we can add also that dimension in the future release. That's a great point, Frederick. Thank you. Okay. So that question is about government. Next question is about We could do something about it here. Of course. Yes. It's just sometimes there is a kind of a position between a commercial organization and governments. And one is only value-driven and the other one is not. But I think the government is also value-driven. The experience of the e-government part is important endeavours also. And they measure the value that governments provide. Of course, the measure of the way the value is measured is different. But value-driven is also applicable for government, basically. That's a good point, Antoine. We would hope that our governments are value-driven to some degree, wouldn't we? I'd like to think so. Thank you for that addition. So next question is on governance. Agile architecture needs agile governance. Can you say something about how that's handled in the standard? Or are there any principles around governance in an agile at scale world? Any volunteers for that one? I'm happy to speak to that if you'd like, Steve. Perfect, Paddy. Thank you. So I mean, I think from my perspective, there's certainly one of the key focuses there in terms of governance is the topic of guardrails that I alluded to in my little segment. And guardrails really are about that transposition of the governance into a statement of what people can and can't do as they proceed in an agile manner for the components they're responsible for. And I guess to me, that's the key to this, right? That if you want the team to act in an agile manner, you need to create the space for them to do that. You don't want them to do things that are inherently problematic or conflict with your constraints or your governance process, but you want to give them the space. And to me, that's where the guardrails become that central point where you just get them in, get them wrapped around it and proceed on that basis. And I think that's the thing. And I think the other thing I would say about that as well is in the best possible sense of the word, if the team can be involved in the generation of those guardrails and own those statements themselves, rather than feeling that they're being sort of pushed down upon them, that further sort of buys them into the process and makes them part of it so that they're not railing against the restriction, but rather to understand what's being achieved and what's it's there to do. Very thank you. And there's a related question. I'll see if anyone else has anything to ask, but you mentioned guardrails again. The related question, is there a relationship, do you think, between EA runways and guardrails or are they interchangeable terms in the OAA? Can you touch on that again, Patty? I don't hear somebody else jumping in, so I'll do my best. I'm not the world's... I'm not... I suppose I didn't arrive in my role from an EA background, so I'm not the world's greatest expert, so I'm going to be careful. I think in one sense, guardrails are whatever they need to be for your org. And I think that's really important, because what you need to do is find the statements that empower the people you work with to do what they need to do for you. And if that means that they're EA runways, well then great. If that means they're not, because they don't meet some of the criteria, well then they're not. But what you want to do, and I guess to me the whole statement of agile in this sense is about bringing something to your organization that allows it to act in an agile manner and doing whatever it takes to make that happen. And sometimes that involves taking slightly odd perspectives on things and bringing them in in slightly odd ways, but that would be my viewpoint. I don't think there's a hard rule, but I think the guardrail should be whatever it needs to be for your org. Okay. And I would add that if I hear correctly runway, there might be a reference to the architecture runway concept from SAF. And in the agile architecture standard, we are not using the actual runway concept because we think it's very fuzzy concept that may mean many different things to different people. So we prefer to talk about intentional architecture. And to close on governance, we have a building block that talks about agile governance. So if you're interested by that theme, I would encourage to go and download the standard because I think it's now available and look at that chapter on agile governance. Right. Okay. Thank you, Frederick. Okay. So there are a number of questions that are around the role of software architecture. So I'll read the latest of those. Agile for us means more responsibility is placed closer to or in software development teams. Does the OAA involve methods for architecture roles like software architecture? It's not prescriptive too much on roles because we think that in agile enterprises, those roles are very contingent to the specific context of the enterprise. What I would say is that in an agile world, we are thinking about cross-functional teams. So which means that if you take a featured team or a squad, should not be composed only of software people. It should also be comprised of people of other discipline and in particular business discipline. So from that standpoint, the software discipline of engineering is important, but it should not be seen in isolation from the way it interacts with the other competencies of agile teams. And overall, we are looking for a simpler way of looking at roles. And for instance, one of the large enterprises which contributed to the OAA now has reduced the number of roles to enterprise architect, full stack architect. So instead of having specialized architect roles which are more competency, a data architect, an application architect, full stack architect, and solution architect by a position to the enterprise architect, the solution architect having a sort of smaller scope. But here you see that sometimes the roles are linked to the seniority, sometimes to the scope, to the type of work they do. And we don't believe that by multiplying the type of actual role, we are doing good service to architecture. And to the extreme, I remember a talk from a leader from a large retail company who said, well, in my enterprise and in many large, pure internet company, you have no architect or you just have one architect and sometimes he is the leader of the enterprise. So here it's the other extreme. I don't think we go that far, but it's certainly advocating for a simplification of the type of roles. Thank you, Frederic. Thank you. Maybe the goal to add to it, the goal is to raise the enterprise skills level of architecture and all the stack and all the different discipline of the enterprise. So it's a skill set that should be shared, as Frederic said, top down in the organization. It's not a property of some specific people in the organization. Okay. Thank you, Antoine. Now, we have a question about, I'm sorry to go back to this Paddy, but there is interest in the inverse Conway rule. Can you emphasize the inverse bit? I think there are a couple of questions on that. What do you mean by the inverse bit? I mean, you talked about what Conway's law was, but can we have another run at that one? Of course. I should prefix before I start this bit that my colleague, another contributor to the OAA refers to the inverse Conway as his favorite wrestling move, which might help people as well. Anyway, so the inverse bit really refers to if we take Conway's law as a statement of fact effectively, we can invert it by deliberately designing an organization structure to influence an architecture. And that's what the inversion is really about. It's about saying, well, if this law exists, let's take it and turn it on its head for wonderful phraseology at the beginning and design an organization structure so that it influences the architecture. And that's really what we're saying in terms of the inverse. Understood. All right. Thank you. Thank you for that. So let's see now. There are some other questions coming in as groups. I'm trying to hit the popular topics most. Question about maturity. The statement here is that maturity seems anti-agile, anti-agile, depending on which side the Atlantic you're on. Is that a statement you agree with because the OAA still talks about maturity? Is maturity anti-agile? The broad question I realize. That's okay. Do you want me to jump in there, Steve? Why not? Why not? You're on a roll, Patty. I'm on a roll. Well, I'm not sure about that. But I think my answer would be, I think there are some groups or organizations who treat agile as a carte blanche, as he says, butchering the French. Poor Frederick is probably cringing down the phone. But to act with utter freedom, to disregard documentation and other practices necessary to produce high quality outcome. And I guess, yes, if you view agile in that way, then any mention of maturity is, of course, the antithesis of that. It takes to the opposite direction. My answer would be nuanced, and I guess you can take the view that coming from a background of a very large organization, that's just the world I live in, which says there is some level of maturity and governance and good practice that is necessary to have successful agile. And what's successful agile? Well, I'm going to be blank and corporate and say, it's one that leads you to a project that makes money. Whether that money is paid by external customers, as it is in my case to pay for the product, or whether it's internal customers deriving value for your business and ultimately making money out of it that way, success is measured that way. And it has to be first, because otherwise we're not in the commercial business. And if you define it that way, well, then my answer is successful agile does require governance. And it does require all of those things wrapped around it, because that's what's going to drive that success and ensure it. You can be lucky and not have any governance and still be successful. But if you want reproducible success, then you need governance. Excellent answer. Thank you, Paddy. Anyone else want to chip in on the maturity question? Hearing none, I will move on. Question about OAA and SAFE. For an enterprise recently adopting SAFE and needing to mature rapidly, do we focus on SAFE first, agile architecture first, both in parallel, or can I not use them together? Are they different beasts? Maybe I can take up. First of all, several of the enterprise we've been working very closely with, including internal DXC, are deploying SAFE. So we have an experience using SAFE. We've designed the AA to be compatible and to complement SAFE. Actually, what happened is quite interesting here, because we've published a snapshot about over a year ago, and that snapshot was putting on phases on organizational agility, business agility, and many things that we talked about today. And a few months later, we had SAFE version 5.0, which included many of the new concepts that we introduced too. Because these things were done in parallel, that shows that, first of all, the industry is moving in direction that's consistent. And secondly, that there is compatibility between the two. We really think that there are two aspects where the agile architecture is really important and complements SAFE very well. First is that on the official side, SAFE proposes a dual organizational model. And we don't think that one size fit all organizational model works. So we prefer to define a way to craft a specific organization that matches the specific circumstances of the enterprise at some point in time, and that would evolve rather than that sort of pre-designed dual model. The second aspect, and probably is the most important, is that those SAFE position architecture rules within the framework with less guidance on how you architect experience, how you architect products, how you architect operating models, and the enterprise operations in SAFE. And these are important because if you want, for instance, to structure the, for instance, a PI, a prime increment or an agile release trend, you're better off if you've got a good vision of the actual experience products and operations and also software. So we complement SAFE on that one. And I was thinking, because I attended a few weeks ago, SAFE training that we delivered for our people and gave me quite a lot of ideas on how to create a specific training that would cover agile architecture and that we could run by the people who have already been trained to SAFE. So that certainly is something that would have a lot of appeal in the marketplace because SAFE is probably the most used GILET scale framework in the market today. Thank you, Frederick. Anyone else want to comment on that? If not, then... We have a discussion on different from Frederick, which is on the consulting side. We have a lot of questions about how to connect to a repository environment to APC and so on. And I think the work being done also in the agile architecture framework on product architecture and operational architecture is a very good fit to help people organize that split to have the agile trend to be well defined and well scoped. So we see these parts that we've been working on on the agile architecture framework have very good complements to drive and shape the top level of SAFE indeed. Thanks, Antoine. Thank you very much. So to take it up a level, generally a question I thought was interesting myself was, do we still need architects in a dual digital agile enterprise? And if yes, how might the architecture roles evolve or develop? Anyone want to tackle that one? Sure. So I guess I definitely see a role and certainly, you know, in my experience, it's something that's still required. I think there is a difference, though. And I think it goes to a phrase that I think I mentioned in the video of continuous architectural factoring. And I think, you know, from my perspective, the difference here is about not defining an architecture to be executed and letting that run, but rather to define a best guess, perhaps, an outline architecture with the guardrails and the other elements, allowing that to spread. But then, you know, refactoring that when it becomes obvious or when the situation changes or the requirements clarify themselves, and then stepping back in refining the architecture, refactoring it as necessary, restructuring, and then iterating on that. And I think, from my perspective, you know, in a sense, it becomes one of iterative architecture rather than, you know, that notion of stepping back and producing the architecture and then executing against it, it becomes much more iterative. And that is, you know, it's not different because in some senses, although you're doing it again and again, it's not that fundamentally what you're doing is any different. You probably make different trade-offs because you know you're going to come back down the road. But at the same time, I would argue that it is still very much the same discipline just with that different perspective on it. And I guess the other thing, you know, and again, it's one that sometimes we get a bad rep for is to make ourselves available to the team as experts. You know, it's not just about the documentation that we share or the vision that we share. Sometimes it's just about making our own expertise available to people so they can ask questions and inform their own decision making and you become that sort of hopefully font of knowledge if it's successful in that way with the team. Right. Thanks, Petty. Anyone else on that topic? Okay. Got a number of questions that relate to, we talked earlier, in fact, Chris took the question about how OAA, the OAA Standard and TOGAP Standard might interplay together. But a number of questions around if I'm starting out architecture in my organization, should I go to TOGAP first? Should I go to OAA first? Can I use Archimate, another standard of the open group in an agile way? There's a lot of activity going on to try and address these things. Can you talk to that a little, Chris? Sure. I saw that I'm having a little bit of difficulty listening to the panelists in context switching to the channel so I appreciate the call out there. I would say that if you're starting out on something, that is, let's say you're in a green field or a brown field kind of environment from your architecture practice perspective, or you're contemplating getting your head around an agile or digital transformation, there's a couple of places to look. There is a massive body of knowledge related to TOGAP, but the document that deals with establishing and operating an enterprise architecture practice, a TOGAP series guide on that, is a good place to start. And then also an equally good place to start is the open agile architecture material that we're discussing here today. And I think that one of the interesting problems that we discussed in setting up this event was twofold. One, we're trying to present to you today, and if you haven't seen the material, it's available online for download of the agile architecture framework, the agile architecture standard, there's a lot there, but it's a fairly quick read, right? If you're coming at this from a TOGAP perspective, operating and managing a practice, that guide with actual agile context in it already has been available in the TOGAP body of knowledge for more than two years now. So sometimes things get a little bit lost in the volume of content available from the open group around enterprise architecture. But specifically to the question, there are a couple of documents that would be very useful to dip your toes into one we're discussing today. And the other one I mentioned in the TOGAP body of knowledge, the TOGAP series guide on establishing and operating an EA practice based on a TOGAP standard. Thanks, Chris. There are some various guides underway in the agile and digital space around that TOGAP series guide. But let's get back to the OAA today. And a question coming in here. If repetitive success for enterprise architecture requires governance and agile is almost the opposite of maturity when compared with architecture, once we need more requirements up front, how does agile architecture handle this problem of we know? And there was a related question about in a lot of organizations, there's a lot of agile projects that are going on in a pretty uncoordinated way and resulting in a need to then look back and say, okay, well, how do we actually architect these various things or how do we bring them all together? So I guess how does agile, it's a similar concept, I guess, to how is the role of the architect changing. But how does agile architecture handle this issue of requirements up front and yet needing to do things in an agile way? I see two questions here. I mean, first is the question of requirements. And clearly the agile architecture shifts from a requirement-oriented approach to an outcome-oriented approach. You can throw a lot of features to create a new product that you think will appeal the market. But if those features do not solve your customer problem, do not bring value from a lean standpoint, it's somehow West. So to illustrate that, I'm thinking about a book that Mr. Kagan, who is a guru of product management in Silicon Valley, said criticizing the product owner role in the agile world. He wrote that those product owners are mostly managing requirements and backlog of requirements and that it was not really what product managers should do because a product manager should make sure that value is delivered to the client and not all requirements deliver value. On the second aspect of the question and probably it's a different question is if you have many agile teams that run in parallel, those agile teams could create a mess. So you need to strike a balance between the autonomy of those teams and the fact that they are going to pursue common purposes that they are going to be aligned. So in the agile architecture, we have a chapter on governance that addresses that issue and provides guidance on how to achieve that alignment. That alignment is not going to be achieved via common and control style of culture, but more via the definition of objective and key result that clearly gives a common purpose to teams. Then teams have the autonomy to actually achieve, deliver those objectives with some autonomy and that's the first way to align them. The second aspect is that of course you should pay a lot of attention on how you divide enterprise into teams of teams and teams and we talked at length about the investment on way maneuver. So the idea is that you start from a good architecture vision and you align the way your team structure along that vision which defines your product architecture, your operations architecture and by doing that you reduce the situation where two teams are doing the same thing or you've got a blind spot where no team is addressing an important issue. So by combining a different way of governing and by aligning the team toward an intentional architecture you can avoid the type of situation that you are thinking about. And another guidance is provided on this and the kind of category of teams like you have streamlined teams which are really guided towards product and also platform and competency teams which play a cross functional role. So there is also a proposal in a kind of pattern of team organization that helps having kind of commonalities being managed by these different relationships between teams. So I encourage you to look at this in the framework. And I think you know if for those of us that have worked in teams of teams environments one of the things that may not be explicitly obvious from what Frederick and Antoine are just talking about is that in an environment where you have the interaction between the teams occurring there is an accelerating effect that occurs where teams have focus in one area. The blind spot is suddenly apparent and you can flex the organization to deal with the blind spot. So the ability for an effective cross functional governance model to accelerate the value delivery not everything has to rely on a single team or a command and control structure to accelerate that delivery. The flexibility of the organization to respond to the blind spots and the issues is extremely powerful and I think that that may in part be what Patty was referring to earlier about the organization's ability to deliver is this accelerating factor in a team's environment that's managed in a more flexible manner. Of course it needs guidance it needs all of those things but architecture definitely plays a role in that kind of operating model. Thank you, Chris. Anything else on that? A few good comments. Okay, question on operating models. The strategy architecture DevOps or Star DevOps model is extremely useful for organization design and functioning. Any comments on that in relation to the OAA or response on operating models? And specifically at the end of the question as opposed to biz DevOps. This is Star DevOps strategy architecture DevOps. I'm not familiar with the material they're referring to. I'm sorry. No I think that's one that may have us may have us flummoxed there. Okay, we'll move on. Sorry about that but I think, let's see we can go to, do you have, can you share an opinion or any experience of using open agile architecture or those similar approaches in either a small retail business or a large organization specifically oil and gas industry where safety is very important. So anything relating to a small retail business or oil and gas specifically or I guess any industry where safety is and regulations are particularly important. Maybe I can take the safety part at the core of the way. Lean thinking plays a big role and lean is not a set of tools and methods. It's also a culture. It's a management model. And in a lean culture, respect of the individual, trust, talking openly about the problems is very important. And if you look at the safety culture on the other side, safety relies also on the use that are fairly similar because in organizations where you cannot talk openly and freely about problems where when there is a problem, blame is the answer. Those type of organization are not going to be capable of handling the safety that mentioned the right way. And to illustrate that, I would really recommend if it's still available on the internet that you look at an interview that the IT revolution website, Gene Kim, has recorded where he put in the same panel, people from the lean culture with people from the safety culture. And it was extremely interesting to see how those two cultures would complement or differ from each other. So definitely the way by its lean roots, I think is perfectly compatible with safety. On the other hand, it does not include some specific safety body of knowledge. And I'm thinking about methods, that have been developed by the MIT, but they are really complementary. So it's not difficult to complement the OF with those safety approach. And in the course of developing the OF is also in connection with the large organization building in the aircraft industry. And clearly they were having that change to traditional command and control, to build the aircraft to a new agile organization, exactly as Frerich said, trying to share the problems they face when they build this new kind of aircraft. And clearly the organization culture change was a very big endeavor, wasn't it, Frerich? But indeed. So I think they were not mature enough to publish all together with us the way they are, but they had a one billion project to ensure this transformation within this big organization. And what Kitapika remember was the way they did distribute responsibilities. And because in fact, when you build a different part of the aircraft, usually the chief engineer of part of the aircraft was responsible legally against, could have a good on trial when there was a problem. And the change in mind was to share not per part of the aircraft, but across the whole aircraft altogether. And it was changing the responsibility and even the earning of people being in charge of the various parts. And the change in the organization was absolutely key. And it was a big transformation endeavor. So clearly the team approach, the agile approach we promoted together was a good input for them. So yes, indeed, it was not in the but it was clearly in the aircraft industry. And we were happy to see they were facing the same concerns and the principles that we share in the in the book also with the DP book was the ones they were trying to build on indeed. Thanks Antoine. Thank you. There were a couple of questions about specific topics. Are there going to be specific topics or as we call them in the DOAA context playbooks? Andrew, you answered in the Q&A panel that there will be a security playbook. There was a question about will there be a governance playbook. Are you able to say anything about specific playbooks that are under development? I think there's there's a couple in fact. Frederick probably knows them more than me. There was a security was quite well progressed meta model. What were the other ones Frederick? Can you remember? I'm drawing a blank. There were about two or three. We talked about modernization and but here one of the way we approach that development is to make sure that we are at least one but preferably several contributors who have a real world experience in some enterprise and who could devote enough time to write content. So really we are driven by identifying those people who are willing to spend the time sharing their expertise. So if we get those people then we'll get new material. If we don't get enough time from those people in some area it will be slower. And for governance we have an agile governance chapter. So it's already in the way standard has published today. Yeah I just looked up the other book that was a possible as you say it relies on contributors is the cloud. There was a cloud playbook as well. And that's a great point that you make there Frederick and Andrew. It is about contributors. So if there are areas of particular interest to you then the way to get those worked on inside the open group is to get involved. We'd love to have you. One last question before we wrap up folks. Interesting way it's put I guess. Can we understand the OAA standard as a way of incremental building of software product lines plus user experience. So services can be selected. Is it a way of is it a way of approaching and building up those those product lines plus the excuse me use experience not user experience. So services can be selected. It relates to another question which was about the role of services going forward and how it relates to that. Is that a way that you would want the standard to look at after your hours of contribution to it folks. I guess I'll jump in again. So I think from my perspective Steve you can certainly look at it that way. I have certainly no objection to anybody looking at it that way or using it in that light. And I think there's some interesting questions there about how those criteria for service selection come into being. And I think yes I'd love to say taking an agile approach to that saying here's our initial set of criteria. Let's use it. Let's validate our experience with it be that with real use or through a testing process or whatever and then inform that and go forward. Absolutely. Is that really what we've written probably not quite so much but it's certainly in there certainly something I would happily encourage. I don't know if the others have any additional. Thanks Betty. Any other last comments on that or anything else from the panelists. If not then I'd just like to thank all of our panelists for their efforts with the videos ahead of time and for taking the questions today and for all your efforts to help develop this standard. And that we're proud to launch today. So thank you all very much the panelists and obviously to all our participants today we've had some great numbers of people on on here today. Hopefully you've got much more of an understanding or a flavor of of the open agile architecture standard and please do go and look at it. The link to it was in the chat channel but you'll you'll also I think it was also in in what Chris showed as well. So Andrew actually Andrew Andrew's video those specific link but we can certainly put the link in now in the chat channel and we will leave the chat channel open for just a few minutes after the after the event actually concludes just in case you want to share any any comments with each other or or just as close as thing we get to networking with a virtual event of this type. But thank you all for for attending. Please go and download the standard. We hope it's of use to you in your day job as I said at the beginning and thank you all for joining today and look out for more about this and other things in this space from the open group in the near future. Thank you and have a good rest of the day evening whatever it is wherever you are. Be safe.