 We've done these Oxford-style debates at a number of events there, you know, we're actually really quite privileged to have the two gentlemen that are going to be speaking on these topics today. The open group debate here will be about we do not need to have a specific methodology like TOGAP for delivering EA, modeling using Archimate is enough, and if you think that's an abstract concept, you should come inside the open group and hear the raging debates that go around the use of these two specifications. So this is the format of the debate programs that we operate. We have some rules and procedures. We have a proposition declaration. At the beginning as we present the proposition, we ask you to vote on face value of that proposition before the debate occurs. So the proposition declaration should be consequential for the open group and or industry supported by the open group. And the proposition being debated today is that we do not need to have a specific methodology like TOGAP for delivering EA, modeling using Archimate is enough. The four position is if you just fill out an Archimate model, you will have created an enterprise architecture good enough for decision making. And the against position is that using Archimate itself is not enough. One needs a method to guide the collection of the pertinent information to populate the Archimate model in order to create a model good enough for decision making. Now what we're going to do is ask Chris to take the four position articulated for us and I will count in down. So every minute or so I'm going to say Chris, your time is running out. All right. Super. So Chris, you have seven minutes. All right. Well, thank you very much, everybody. So yeah. So I guess I'm basing the whole approach on we don't need any stinking methodology. Right? I mean, who actually reads any of that process stuff anyway, right? So my experience tells me that people do work and will look at process guidance as a last resort if they have absolutely freaking no idea what they're doing or what they're trying to achieve. And so think a little bit about cooking, for example. So when you're trying to cook something, you go into the pantry, see what you got, and you're constrained possibly by the spices and oils and equipment that you have available and the things that are in your larder of various types of fruits and vegetables and meats and so on and so forth. And you know, you can just go pull things out of that pantry and larder and put it together and start sauteing things, tasting it while you're cooking it, sharing that content with your key stakeholders, your significant other or family that you're cooking for. See if they like the taste of it or not like the taste of it. You don't necessarily need to be an expert cook or be skilled in the culinary institute of America or other French cooking institutions, namely, people know good food when they taste it. And as I'm sure some of you might have heard, most people don't care how you make the sausage. They just want to eat sausage. So my claim is if we don't need guidance from things like Togaf to construct useful enterprise architecture because Archimates pretty much got it all covered already in the food stuffs that are in our pantry. So if we take a look at what Togaf talks about and what Archimate talks about, one could make a claim that there's a little bit of duplication. So for example, you know, Togaf says that you should describe the business architecture and the data architecture and the technology architecture and that you should do gap analysis and then do planning. Well, Archimates already got all that covered. As some of you may know, there are a number of different domains or layers with an Archimate. So there's a business layer. There's an application layer, a data layer, physical layer, implementation and migration layer. Motivation is a cross-cutting concern where we've got specific elements particularly for planning around gaps and requirements. So basically everything that you need to describe any possible scenario that you might encounter with enterprise architecture is already in the toolkit. So however, I will defer to, and I don't know if this is out of balance, so slap me if I'm changing things. There is another standard on which both Archimate and Togaf are based upon in my opinion that is far more material and that would be ISO IEC 4210, 2011. Anybody familiar with that? Okay, so it's a mouthful. So it is an industry standard description of architecture descriptions. And so what it talks about is, A, all systems have architectures. Now the question is how well are they comprehended and understood by human beings? That's a different question, but that's the whole point of why we build models is we're trying to create human contrivances of things that really exist, even though they may be rather abstract, but it's based on the whole idea that we just don't start slinging models because we have a modeling tool or a modeling language. We want to do it with intent and purpose. So ISO 4210, formerly known as another acronym, IEEE 1471, basically says, well, before you start modeling stuff, make sure you understand who your stakeholders are. So that's obviously an important part of any type of engagement. Who am I doing this work for? And then using that to then determine what are their concerns? What keeps them up at night? Three minutes, Chris. What's that? Three minutes. All right, I'm good. Thank you. One of the things that they need to know in order to make better decisions that are contextual to the problem that you're trying to solve, use that to point you towards what's called a viewpoint library, a collection of ways that you might render content in a useful fashion to address stakeholder concerns. And then use that to actually synthesize views, which are, again, ways of getting glimpses into complex models that hopefully satisfy stakeholder concerns. So my opinion is that, again, because ArchaMate's got all of the architecture domains and related domains related to planning and delivery already encountered, that we don't need any stinking process or other frameworks to make things more complicated. So for example, again, my experience says that people will use a process description as a last resort if they can't get any better guidance. And so one of the best ways, and this is certainly related to work that we're doing within the forums, is creating examples. So I think a lot of people could do pretty darn good with creating good ArchaMate models if they saw examples of what other people had done in similar scenarios and or patterns. So namely the whole idea that I don't have to do something completely from scratch, I can basically take a look at the ArchaMate standard where there's now a set of non-normative viewpoints that are defined. So for example, you should create an introductory viewpoint to kind of frame up what the big picture is. Well, that's pretty much what Togaff says in phase A architecture vision. You need to create a business function viewpoint, a business process cooperation viewpoint and application data relationship. And as you may know, there's a lot of different ways that we can express this content. There's no doubt that ArchaMate excels at the graphical rendering of this. But as you may know, there are multiple ways and forms that we can share content with people. Some is graphical, some might be tabular reports, some might be traceability matrices, all of which content can be extracted from a good ArchaMate model. One minute, Chris. That's it? One more. One more minute. And so my opinion is that if you have good situational awareness and trying to embrace some of the best practices from agile, which is to fail fast, fail early, have continual customer evaluation, again, think it about cooking. You don't want to go off and do a black hole and do a bunch of modeling without any feedback because you could come out of that completely in left field. So build a little bit of model. Show it to the stakeholder. Have them taste it. Think of have get some response to see if they think it's addressing the stakeholder concerns. If it's not, adjust and take a different approach. But I think, again, just with the toolkit and the pantry that ArchaMate has to offer, that is sufficient. And we don't need anything like the TOGA framework or ADM. You're done? I'm done. OK. Thank you very much. Thank you, Chris. Now we'll ask Andras to take the position argument to rely on in ArchaMate itself is not enough. One needs to method to guide the collection of put in information to populate the ArchaMate model in order to create a model good enough for decision making. Andras, thank you for being with us. You have seven minutes. Well, I think that in order to actually kind of answer this question, you really got to ask or address, what is TOGAF? So first, I offer as evidence that the Defense Department contributed TAFM as the seed to the open group. And TAFM has evolved into what we know as TOGAF 9 as it exists today. You could say, well, Andras, TOGAF is the ADM, and you'd be partially right. You could say that it's the continuum, and you'd be partially right. You could say that it is a set of best practices, a framework, and a descriptive model of the layers, and you'd be partially right. You wouldn't be wrong. You could also say that it is a meta model that is embodied in a tool called ArchaMate, and you'd be partially right. But you wouldn't be completely right. In fact, really the reason why the DOD contributed TAFM to the open group was because that we had a budding, a very active group of architect experts and ecosystem. So TOGAF is not necessarily just the ADM, although it's very important. It's not the continuum. That's kind of interesting and important. It's not the concept of mapping business capabilities to enterprise architecture requirements. That's really important, too. And it's not creating a meta model that results in a tool which allows you to automate it, although that is really important. It is, however, if you look at it more closely, considering the fact that we're on TOGAF 9, not a methodology at all, really, but a community that's working together to evolve with the changing times, technologies, and techniques. And my true supposition here is that while ArchaMate and a meta model is important because automation is good and solid tools in which you actually construct artifacts is a very good approach for consistency, say, it cannot represent you and what you do. And that is contribute different ideas, concepts, and change. And in fact, this whole debate and conversation is one group trying to wrestle control from the rest of you and turn it into a very concrete discussion about what TOGAF is. It's not your contributions. It's what our tool does. And that is the wrong way to go in my mind. Is it important? Yes. Is it essential to ensuring consistency across different implementations? Absolutely. But is it what TOGAF is? No, TOGAF is the community. TOGAF is the contributions that you make. It is that non-normative set of contributions and pieces of information that are in the continuum that are part of the industry and so on and so forth that aren't in the meta model. And in fact, this has been tried before. I mean, Grady Butch tried it with Rational. And their meta model approach has seen its best days. I think. And the reason for that is they just didn't have what TOGAF has. And that's you. And it's a community of people that are constantly evolving. And if the meta model has to change, really you have to make the changes to the meta model and insert those cultural tweaks as the industry and technology changes. We're facing a huge inflection right now on cloud computing and artificial intelligence. And TOGAF has to change and will change with respect to that. And the community is going to make the difference here. So it's not just the methodology. It's the community, the approach, the work that you are doing that is actually going to inform the meta model and automate in the future. I also think that when you're building a tool, you have this tendency to throw the kitchen sink at it. And Archimate has done a good job up to this point of actually avoiding that. But you can see the trapping on the wall. They want to add all these things to it that then they can just say, look, this container, it is TOGAF. Therefore, we don't need all of this other stuff. But the problem is then it becomes like amber. It becomes solid and stagnant. And it becomes just like the OMG, heartless and unevolving and at the end of the day irrelevant. So you have to fight for your position in this process of defining method and capability and techniques because it's you who have gotten us to TOGAF 9, not strictly a meta model by itself. Thank you. Thank you, Andrew. OK, so the next step of this activity is to open the floor up to audience questions and challenges to our debaters here. Another question here? Yeah, I think I heard in the debate a challenge that with TOGAF there might be some challenges with an agile methodology of doing a model and then getting quick feedback and then having mature itself as opposed to more of a flow of when things should happen. So I would ask to address how TOGAF works well with agile or what challenges it has. Yeah, that's a really good question. I mean, so you could say that enterprise architecture generally isn't about applying agile software development techniques, which by the way, I'm a big proponent of. Within IBM, we use IBM design thinking and agile development. But the ADM defines a lifecycle. It doesn't tell you that you can't use agile. It just says that you need to consider these things along the way. And we found actually within IBM that a lot of folks throw the baby out with the bathwater. Minimal viable products turn out to be minimally viable and then they get thrown out into the production space far too soon in many cases. So we kind of have to, I think, take a step back. And this is part of the next phase of TOGAF. How do you apply design thinking and agility concepts to both enterprise architecture as well as software development from an enterprise structure point of view? I think there is an intersection between things like IT for IT, we've got the business architecture forum, and we have TOGAF. All kind of inform each other, and we try to make sure that in the open group that they're all kind of consistent. But the methodology, the process that represents all that is TOGAF. So I do agree. Next step is to ensure that everybody who now has a good hand-lawn agility can find those concepts within TOGAF. Certainly. Well, and of course, it seems a little bit of a tangential question to the core topic. A, and as many of you may know, we actually had a debate on this topic for a full hour. Do we need to change anything in TOGAF to address agile? But I think taking the opposite position of my worthy adversary, so whatever he says, I'm going to say the opposite, is one could look at TOGAF, and particularly the ADM, as some of you may know, the crop circle diagram with arrows flowing in a single direction. Sure as heck, looks like a waterfall method to me. And I think if you interpret it too literally, you may be taken down the golden path or the wrong path and missed the forest for the trees. I'd like to suggest that I think we can embrace most agile software development principles very explicitly in enterprise architecture. So as some of you might know, fail early, fail often. Continual customer interaction, we need to do that. Continual integration, we need to be able to do that. And probably the trickiest one, in my opinion, where I think there's a lot of opportunity for improvement, is continual testing. But it brings up an interesting perspective. What does it mean to test an enterprise architecture? Because at the end of architecture work, you've got a bunch of standards, plans, requirements, and models, right? What has changed? Nothing. What evidence do you have that any of it's going to work? Zero. So you're taking a huge risk if you go through the ADM in a very waterfall-ish fashion that you've really missed the whole point. So in my opinion, the most important consumer's downstream of enterprise architecture is the solution delivery community, both in business and IT. Namely, they have to understand that content because they're the ones that actually execute the transformation based on the plans and content that we've built. And so what we really want to do is instead of waiting till we get to the end of phase F, for example, in the Togaf ADM, we want to be sharing content with those downstream consumers immediately and get their feedback and actually to have them try to use it even before we're done. But we're often get interesting feedback from some participants. We're like, well, I don't want to use this incomplete partial product because it's not done yet. And then that's where you need to go, where have you been the last 20 or 30 years? It's never done. Version one that I get you at the end of the cycle is not the last version. It's the first version. So let's really get those feedback loops go and get that evaluation. And I think, again, in particular, just to get it back to the whole Archimate thing, that Archimate as a modeling language and as a predefined vocabulary and constructs is a platform for doing that continual evaluation. Thanks for us. Do we have other questions? Sir. Mr. Armstrong made the interesting point of needing situational awareness in order to have a good Archimate architecture. The question I have is how do you get there? How do you get there from here to there? The reason why I ask that is because most enterprise architects, myself being one of them, didn't grow up as an enterprise architect. We came in as a specific domain architect, or programmer, or developer, or something along those lines. And we were evolved or forced to evolve or were thrown at the wolves, and we had to grow. Most of the question would be, given this particular argument of the forum against, if somebody was a single domain knowledgeable person, a SME, and only studied Archimate, how could they become an enterprise architect versus somebody who had to study Togoff and then could become or evolve to an enterprise architect? So without one or the other. And Mr. Armstrong? Sure, sure. Good luck. All right. Well, thank you very much. So, and I think just to make sure I'm grounded in the right reality, so if you're coming up the ranks through a particular professional development path that many of us have, that's not exclusive, of course, and there may be future entry pass for future architects that have nothing to do with IT or anything like that. But despite that, that's a different topic, because I think that was another debate that we had. What I would do, I mean, if you happened to be good at data architecture, the entry point into Archimate is to find your situational awareness. So what does Archimate say about data architecture? What are the constructs that represent that? So I kind of think about Archimate as a map of all the different places that you can go. So like when you go into a mall, right, it says you are here and then shows you the things that are around it. So you could go into the Archimate standard, find the stuff about data architecture. Hopefully it resonates with your experience, perhaps informs some different perspectives. But then you look at the MetaModel and you go, oh, well data objects are supposed to be related to one another. They might be transmitted through flow relationships and processes managed by applications and put into data stores or excuse me, as artifacts as they're known in Archimate. So I think the MetaModel of Archimate should be sufficient to kind of give you that orientation because ultimately what any MetaModel is trying to do, in my opinion, is synthesize a common language that we use to describe the problem domain. So what I think Archimate as a MetaModel is in some ways is the information architecture of enterprise architecture, namely what language do we use when we talk to stakeholders and other practitioners when we talk about enterprise architecture and Archimate's the lingua franca, it's got it all figured out. But the big issue is that you may need to adjust the local variable terminology that you've either personally been accustomed to using over the course of your career or the language that's being used within the particular organization that you're doing work to say, hey, there's 50 nouns that we can use to describe the entirety of the enterprise, capability, course of action, tactic, strategy. And let's just agree on that common terminology because again, as you probably have experienced, that is usually where the biggest problem start with the humans, which is we're using language casually as if we agree upon what these nouns mean. And to many people, the same word means two different things or two different words mean the same thing. Archimate covers all that with the definition of those fundamental terms and their possible relationships. So that's my position. Togeth is far more than just the MetaModel itself. It is the community, it is the industry views, it is the experience that one has in the industry itself in understanding how enterprise architecture is realized in that context. Can you use a modeling tool to actually guide you? Sure, you can use more than Archimate. There are many out there. I think the question at hand within our community, you know, since Archimate is our metamodeling tool is is it embody all of Togeth? And you have to say no, it doesn't. And the trap that you get caught in, that the OMG and others got caught in was that if you do, then you begin to heap more and more stuff and functionality into that metamodel or that tool and it becomes very rigid, heartless, and essentially evolves very slowly as you see these paradigm shifts come about. And you have to be careful that you have this balance between where that metamodel is today and what you can put in that tool versus what's non-normative in Togeth as well as the guidance, the industry views, the communities, perceptions, the experience that you get when coming to the conferences to debate the different methods and your own expertise that you've gained over a period of time. If you just simply and blindly follow the metamodel or hire somebody to do so versus somebody who is a certified practitioner of Togeth, you're probably gonna get two separate different architectural views. So just to follow up on the situational awareness thing, there's a set of materials published in the Togeth Library called World Class EA Topic. And one of those white papers identifies a capability map for enterprise architecture. And in that capability map it shows you how you might manage or lead or have tooling and it's also situationally oriented. It says as an architect, do you know whether you're doing architecture for projects, architecture for portfolios, architecture for strategy, architecture for managing third parties, what is your situation, okay? So I took your question to be more oriented around where, how do I know where I am? That's one mechanism for coming to understand that and that is applicable whether you're talking about Togeth or Archimage. So I think the situational awareness thing is really, really important because if you're an architect and you think you're doing enterprise architecture, but what you're actually doing is product or solution delivery architectures, you may be focused on the wrong outcomes. So that's just, so another question. I was driving at was slightly different and that was how do you grow up to become an enterprise architect if you only study Archimage versus if you wanna grow up to become an enterprise architect to study Togeth with Archimage? That to me- And I think we kinda, or at least I try to answer that is that you have to be part of the community and you have to get the personal experiences in order to know the subtleties and differences about how you approach the structure of the enterprise architecture. I mean, Archimate is kind of at an inflection point right now where somebody brought up agility. It has none of the concepts of design thinking that it would need as we go into the future. So Togeth is gonna involve to include design thinking and agile scrum types of processes and approaches. I agree that it's a bit waterfall-ish, although those lines in the ADM can go both ways. There is no requirement for you to go absolutely one step at a time creating all the artifacts in the crop circle itself. And many, many companies and organizations have modified the ADM to be more agile with respect to the challenge or development at hand. So Togeth is very, very flexible. Whereas Archimate and the Meta Model is kind of quite rigid and heartless and structured and in my mind, it is the embodiment of what people think of as waterfall. You have to do one thing after another after another. And we are going to change in Togeth to be more agile and to reflect design thinking as we go into the next phases of Togeth. And well, they'll just have to adjust the tooling in the Meta Model to meet that. So you can't go the other way. So I think your question is a little bit about entering the profession and elevating yourself within the profession. So I don't want to steal, take everything away from Togeth, but one could claim, and again, I'm focusing specifically on ADM, the method that's in it, one of the great things about it is it does describe what do you need to do to do enterprise architecture. And so I consider that to be descriptive method. But what it doesn't address, which happens to be a big part of what we end up helping a lot of end user organizations with, is how to do it, prescriptive method and technique. And so I think the Archimate standard has a good ecosystem in place to start trying to facilitate that. So Togeth will say things you might want to think about describing the business architecture. Duh, what it doesn't say is how to do it because that's, again, an intentional design feature to not make it too explicit. But Archimate fills that gap. So, and it's not completely prescriptive in the sense that it says there is a single one and only one way to do it, but there are, it is more obvious and more clear in my opinion, what, because again, I think a lot of people are like, can you just show me an example of a business architecture? Maybe that'll help me figure out what the hell I'm trying to do and what it makes a difference. So one of the other great things that is going on in the Archimate forum, and this has been a regular criticism that I know that we're trying to address similarly in the architecture forum with Togeth, is please show me real world examples of this. Because again, I would consider an expert or even a new person, the first place they're gonna go is not to a 700 page document that talks about what, but more, I have a problem to solve and I will notice whether I'm in the right place if I see an example that resonates with me or potentially my stakeholders. So for example, within the Archimate forum, we now have a library of Archimate models. And because there is an exchange standard, we can build content independent of specific vendors tools and of course just to be clear, I represent a vendor that is in that space. But we can create enterprise architecture models with Archimate using Spark's Enterprise Architect, export it to Archimate Exchange Format and then that can be imported into Enterprise Architect or BizDesign or Archie. The whole point is as the consumer, you don't have to be using the same technology platform as the consumer is, but the ability to again provide real world examples of content, I think is the real big thing that we need to focus on is not so much and this was similar feedback I provided to the Archimate forum as well, which is I think the Archimate is good enough in 3.0. I don't wanna make the claim that it never should be updated or changed, but I think it is minimally sufficient or even perhaps a little bit more than that to handle just about any kind of architecture scenario you might find in. What we need to do is we need to provide guidance to people on how to use it, not so much arguing about what it is. You know, look, Chris and I have known each other for a long time. We both know that we're kind of in the same canoe here rowing. So it's kind of weird to be kind of giving opposite viewpoints here for what really is one thing and that is Togaf and the realization of a notation for Togaf and then the meta model that supports tooling, right? So we have this concept in the open group of executable standards, that is that a standard is not just a white paper and a specification that it actually has some code or implementation behind it. So certainly Archimate kind of meets that definition in spades. But you cannot, there is a process by which we actually are realizing both the notation and the modeling as well as all the best practices and that starts with the community, starts with a debate, starts with contributions from other companies and then goes through a wrangling process where we come up and distill that down into a set of capabilities that we think are appropriate for Togaf. I mean, Togaf's not really an enterprise architecture methodology by itself and what it needs to do is actually have the ADM broken down into life cycle types like Agile as well as almost waterfall. I don't like the term waterfall because it's almost never used with the exception of defense, aerospace, engineering requirements, right? That follow a very, very prescriptive, step-wise process. Most everybody's methodology today is Agile in some way. So what you can't do is start from the tool side and go the other way because that'll never work and what you don't wanna do is have the community hijacked in lieu of a model specification that says align with a dot in the back with an arrowhead means this and only this because you won't have all the other subtleties basically kind of readily available, all those non-normative elements that you should be considering and then the debate process itself. So Archimade definitely has a place and it will continue to evolve. They have their own challenges and risks too, one of which is trying to add too much to the model and the meta-model itself because everybody is basic. Some people are saying like, I don't use Archimade because it doesn't do this, that or the other. Well, the temptation by the tooling folks are to try and shove that into the tool and maybe that isn't gonna work out so well over a period of time. It certainly hasn't worked out well. It didn't work out well for us within IBM. Eventually the tools became kind of heavyweight, difficult to maintain over a period of time. So there's a trade-off and we no longer actually produce those tools in the form that they were in the last five, 10 years. So, Chris, I mean, what's your point of view? Well, I also think that we might be potentially at an inflection point in the profession and not to leave anybody behind, but it is the 21st century, right, last I checked. My opinion, and again, this is not just because I represent a tool vendor but also as a practicing architect, I don't know how you can possibly support agility without tooling. I believe they are required synonymous. I mean, if you think about, again, solution delivery with the tool chains that are in place, agile cannot be done without sophisticated tooling that take up the human administrative, administratively maintenance things that really impede agility and they're not value adds. So my opinion is that moving forward, if you do not have a tool and you are not managing your content rigorously and formally in a repository, you cannot possibly do agile enterprise architecture. And the case and point being, I'm sure you guys have heard this notion of accounting and people, there is generally accepted accounting principles, double entry accounting systems. How many people do accounting on Cuneiform clay tablets? Or use abacuses or use double green bar paper, right? And actual double entry stuff. It's impossible. You must use a tool to keep on track of your financial stuff. And I would claim, just to continue that analogy, you do not have to be an expert in double entry accounting to understand a financial statement to make good decisions. So again, the whole idea of the implementation of the meta model and all that sort of stuff, those are implementation details making the sausage, but to keep up with the pace of change in today's world, you gotta have a tool. If there are no more questions, then we'll close the floor and move towards summation. Just one last check to see if we've got any questions. Okay. So, Andres, would you mind giving us your again summation? You have five minutes, sir. Well, a whole five minutes. Indeed. So, again, Togep is a community, a process, and it is realized in tools. But you cannot essentially distill it down to just the tool itself. The community defines the methods, the capabilities, the continuum, the different pieces and parts of Togep that inform what are the proper tools. Absolutely, tools are part of cloud native development. Couldn't agree with that more. But that doesn't mean that Togep is the tool. Togep is realized in a tool. And Togep is more than the methodology itself. It is the community and it is you and your participation in the evolution of the Togep capabilities and the framework itself. Don't forget, F stands for framework in Togep. It doesn't stand for methodology. And that should be front and center of your thinking when considering which point to vote for. Thanks. Thank you, Andres. So I guess my summary would go back to, Archimate has, I think, a good representation in the domains that we care about in enterprise architecture. Strategy, business, application, data, technology, implementation, migration, motivation. It describes the language that we use or should be using when we talk with the stakeholders about how we describe and understand the enterprise landscape. We can go back to the good old days. Some of you guys might remember a guy called John Zachman, have you ever heard of him? Right? And some of you may know, I don't know if you've had the pleasure of seeing him speak. He's very terribly entertaining. But it wasn't only until recently, to be honest, he moved to, you know, it got off of his foils. And when asked, how come you're not using PowerPoint and modern technologies? Like, well, nothing's changed. It's all the same. And I would suggest he's true. It's true to a point that's still the same. And so, hey, if the Zachman framework, which is a taxonomy and a hint at a metamodel, right? The who, what, why, when, where, and how at five different levels of abstraction. You know, if that's good enough for John Zachman that started this whole profession called enterprise architecture, well, surely it's good enough for us now, right? I also think that, again, just in summation, we want to, again, have that situational awareness, build content and models incrementally, giving and getting feedback from our critical stakeholders as we do it, because as I'm sure you've also heard, you know, all models are wrong, but some models are useful. We want to make sure that, again, we do not want to build models that populate repositories and exploit functionality of pieces of software, but if nobody cares about them and they don't influence decision-making, again, fact-data-based decision-making, then I would suggest you've missed the mark. And, you know, I think as we move into the 21st century, we really need to start thinking about how do we build skill sets for people to use such things, because I would agree that there is possibly a gap on, again, the critical competency that I believe that you need to have as a 21st century architect in the digital world. So I don't know if you guys are involved in digital business transformation, right? Well, to me, well, to do that, you need to digitize your enterprise. And what does that mean in practicality? You put it into a repository in some way that aligns with a metamodel. How can you, again, possibly make informed decisions? I mean, it's great to digitize your service channels and your customer-facing things, but you really need to do pure digitization, which is actually create a representation of your organization and your ecosystems in that repository. So I think, you know, we can maybe say, is it time to move past what is enterprise architecture and move into what does enterprise architecture do for me? And I think that's where Archimade and modeling can solve that problem. Thank you, Chris.