 This, as usual, is going to be a really engaging presentation. So please give a big, warm, open group welcome. Jason Newpool. Thank you. You need that, yes. Thank you. Thank you, Ellen. Ladies and gentlemen, good morning. Enterprise architect beyond models. So being an engineer and economist for probably about 25 to 30 years is sometimes hard to remember. One thing that has been very passionate for me is to models are great, but that's not it. They've got to be more than this. So this is the area that I started with. And one of the reasons why I was really interested in it, because we've got to get ourselves beyond just talking about things, because there are much more important things that need to get done once we get beyond how do we do things. So my passion became a lot several years ago about health care. And many people over the years when I told them what I wanted to do, first thing they said, are you crazy? And then they said, can I coat you on it? So some of the tag lines were, is a zero patient harm. Make sure that nobody gets hurt in the hospital. So you don't get a disease in the hospital that you didn't go there for. So generally what happened, you go there for one disease. You end up with a four more after that. And that's basically nature of their beast. So this is the kind of area where I started focusing on. But in order to focus on this area, we had to do a whole bunch of other things beforehand. So this is the project that we took on almost a year and a half ago. The result of that project, what I'm going to share with you is to research project of how to be moved forward in enterprise architecture space. So I'm going to be sharing results of his academic study that we did. And I wanted to give you an idea as to conflict of interest declaration that nobody was, as a result of this study, that I'm going to share your results with. Nobody got paid. And nobody paid anybody for it. So there was no financial gains for anybody. Any results that I'm going to share with you has no financial benefit for me or the company that I work for. So there is no conflict of interest as far as the results are concerned. So being from Toronto, I had to drop this one in there. But does anybody know what Pan Am Games are all about? OK. So Pan Am Games is a Pan American Games that has been held in Toronto this week. And that was the number one thing that the games have been held in Toronto. The other thing was you can get it from the picture. Canadians beat Americans in baseball. Now this is like French beating Germans in beer drinking. Just not going to happen. So this happened. OK. Canadians beat Americans in baseball. And we don't play baseball. We don't even have a coach who's a Canadian. We have an American coach. So we still did it. But on top of this thing, we're kicking ass when it comes to metal accounts. And we are just behind the American with the third of the population. So a number of metal accounts is great. If those things are a success, Toronto is on the maps. If you don't know, let's take a look at the Pan American Games. It's a big thing for us, because we didn't get Olympics for several tries later. We got Pan Am Games if you're from Toronto. That's it. So let me start with my presentation with you. Anybody heard of Bill Ayers? Bill Ayers is an American social revolutionary. In 1960s, he tried to bomb Pentagon before the terrorists did. So I had a chance to listen to him several times. He brought up the word that introduced to me is the word called I wonder. So he did a presentation at Dartmouth College several years, about a year and a half ago. And his topic of discussion was about what's so great about America. So he went through this long discussion about what is so great about America. And this is kind of where he elaborated for me and became very important for me to understand. So he said, if you want to change, here's the things that you have to do. First, you have to wonder what is possible. Then you hypothesize how to do it. Then you openly communicate. And this is what he meant when he openly communicated. He said, speak with the possibility to be heard. Listen with the possibility to be changed. Then he said, go do. Don't just talk about it. Go do. Once you're done do, then doubt. This was a point that he made really critical in my world and the world that I live in in health care is to when you don't doubt, you become set in your ways. You become dogmatic. You become dangerous to yourself and to people around you. If you ever been in health care, go see these PhDs and with the 67 letters behind their names, they have become so dogmatic, they're so set in their ways because they think they know everything. When you know everything, that's when you become dangerous. So these were the five steps that Bill Ayers outlined. And I thought, OK, you know, but this is a good starting point. I really enjoyed listening to this guy. I probably listened to his presentation probably about 40 times in my car on the podcast because every time I got something more out of it. So with that, I started saying, I wonder what a professional would look like beyond models. So that's the study, the results that I'm going to share you with this morning. So what did we do? Well, there are a lot of knowns. So we looked at it and said, we know a lot of knowns about enterprise architecture that are pretty stable. Based on those knowns, we created some research questions. Is it possible to define what a professionals do? Can this make be meaningful? Can be repeatable? Can be predictable? Can we teach what enterprise architects do? OK? Second question, can we measure the impact of what enterprise architects individually and as a team and impact on the outcome of the enterprise? If we propose all of this stuff, would the current enterprise architects accept any of this? Or they will say, this is a copy-cop. If they don't accept it, then what do you do? You have to go around them. Because if the current industry doesn't accept what you're saying, you just bypass them. If you look around you, this is happening all the way around today with us, is because if you think about it, taxi industry got blown away by Uber. You don't want to change? Don't change? You don't have to. You're just out of business. You can have, like in Toronto, a taxi industry went to court. Did you put an injunction against Uber? The judge said, no, no, no. You can't do this. They can do whatever they want it to do. Because you have rules, fine, fill your boots. But this guy wants to run a business differently. Judge turned around and said, I can't do anything for you guys. Uber is here to stay. So what happened if the enterprise architects are not going to listen? Maybe we have to do a bypass them. Fourth question was that if all of this is possible, what kind of consortium is like the open group, like the enterprise architects association, like the universities, what can they do to help out? So these are the four questions that we started in this research project. So I'm going to take you through the next few minutes of it and say, how did we go about answering these four research questions, and what results did we get? For the next about 18 minutes, that's my talk. I wanted to speak with you with the possibility to be heard, and I want to listen to you with the possibility to be changed. Ask you to join us. There's way too much important work that needs to get done. If you don't know who that guy is on the top left, it was a movie that was done, probably the best Vietnam War movie that I've ever seen. It's called We Were Soldiers. I'm going to reveal all the knowns with you. There's four or five of them. Then I'm going to share with you what we did for last 14 months with the help of the Association of Enterprise Architects. Birgit and Alex, they've done a great job in the last 14 months. We ran a webinar with the people every third Friday of the month. And in the webinars, we asked, we established a context, and then we asked five, six poll questions. And out of 13 webinars, we did five, six questions, and we end up with 65, 70 questions that we asked people to just gauge the pulse of the nation. So we got a fairly decent data where people were saying. On any given week, we had nearly around 200 people who actually joined us. And 100 plus people answered the poll questions. So I'm going to share with you what we learned. And lastly, there's some call to action. What can we do next? Where are we going with it? What is a known knowns? Togaf ADM is a known fact. It is probably the best piece of work that I've seen, best piece of work I've used, best piece of work that I live with. It does do things fundamentally very well that nobody, no other methods do. What it does is a first part is it gives you a very good method to describe what the problem is. That's where architecture requirements are. And then it gives you outside crop circles is how do you describe the characteristics of the solution that matches it. So it's the characteristics of the problem, characteristics of the solution, is that healthy tension between these two. That is you, the architect managing. That is where innovation is. That's where the creativity is. That is all the work that architect value is. It managing a tension between the solution description and the problem description. And ADM methods does it as eloquently as any methods I've seen. And I've been in this place for about 25 years. Second thing, second piece known fact that we have is a level subtraction. How do we look at organization strategically? Strategically, what is it changing out in the world marketplace that we have? Our work as a world is running. Things are changing. How are we going to respond to it? That's called the strategic architecture. Then we look at a segmented architecture and say, but if this is what we're going to take, what set of things that we have to do to actually execute this thing? And we take a look at the capability architecture. What really happens on the ground level? You can write all the papers and models, all you want it to do, unless something changes the ground level, nothing really matters. So framework provided us a great set of tools. Third thing, skills. Now we talk about OpenCA skills and the other skills within this four, but I wanted to tell you something that I saw last year, a health systems engineering fellowship program run by a veteran association. They ran a program with a $4 million later. They graduated three people. What they concluded at the end of the day and say, in order for somebody to be a health systems engineer, which is no different than an enterprise architect with health systems experience, they came up with this and they said, these are the skills required for somebody to be a good health systems engineer, somebody who can help lead the transformation of health care. If you look at this thing, health system delivery industry experience, modeling and simulation, statistical analysis, cost human factors, and spatial analysis, and so forth. Ladies and gentlemen, look at the other side. I don't know what we've been talking about is a OpenCA certification program. It pretty much matches one to one what people in health systems engineering were trying to do, and what we've been trying to certify people against for, since 2004, 2005. That's when I was certified first time. So same, we use different words to say the same thing. So it's a known fact, those are the skills required for to be a effective enterprise architect or health systems engineer, whatever you want to call yourself at. Fact number four, John Gasser wrote a really nice article in IEEE paper a few years ago, and his point was, is the headless role of the enterprise architecture is changing. There's many roles in the organization. Depending on the maturity of the organization, you might be doing foundation architecture, you might be extended and embedded architecture, great. And then you could take many different roles that you can take as an enterprise architect. That's also a known fact. And also known fact is that most of the times should be spent on defining the problem, not solving the problem. That's also a known fact. With this is the consistent with our thinking and consistent within our ecosystem currently today. And also the most important thing that he also highlighted in saying, not only we need more dialectic skills, we need more die logic skills. What that basically meant is that not only we have to be able to reach the consensus, we have to be able to create an environment which consensus could be taking place. So as an enterprise architect, not only you have to reach consensus, but you have to create an environment in which a consensus conversation could take place. So that's the die logic skills. If you don't have, if you ever try to create, identify architecture requirements in any program, without die logic skills, you're gonna get nothing because nobody's gonna tell you what's really happening. You need to have a die logic skills in order to understand enterprise architecture requirements. Because if you don't, you're gonna solve the wrong problem. So those are the four facts that we've known so far about enterprise architecture. So given our research questions, given what we know so far, who else we looked around and say who else solved the similar problem? BMI did it. How many IT managers actually run the projects now? Not many because they said, no, no. Do you wanna run a large project? Get a project manager to do it because I'm not taking responsibility for it. Same thing with IT service management. One of the things that they did very well, along with the frameworks and mathematics, they became very specific and said, this is what we do. This is how we do it. This is why we do it. This is when you ask me to do something. This is how long I'm gonna take to come back and give you results which you can do this with. They were specific. That's what they accomplished. So what we did, we said, well, given all the knowledge that we have, given what other people have done, what can we do as an enterprise architect? So it's a time for, as Bill Ayers will say, time to hypothesize. All right, so you wanna hypothesize what enterprise architects do? Well, let's look at Lord Calvin. He goes, what X-rays got a hoax which will go away. That was a hypothesis. Well, a hypothesis don't have to be 100% correct. It's just a hypothesis. That's why you hypothesize things. Next guy came up with a hypothesis with this guy. He came up with a hypothesis which we all knew that if you are college students, you like to get drunk and you like to get laid. Good, good, what a hypothesis. We all knew it. He validated it and he built a empire around it. So given his hypotheses, we kinda did our own. Not as fancy as Zuckerberg's, but we said, well, this is what enterprise architects could potentially do. We can build a practice and run it. It's fair enough. Another thing we can do is we can actually optimize the organization's enterprise capabilities today because you have what you have today if you can't optimally run it, then there's not much more to do because if you can't optimally use, what's the point of getting new stuff? Third thing is if we optimize it, once we optimize, then we can transform. So if you think about it, we thought when the enterprise architects could do three things. You can transform, you can optimize and you can run yourself. With that, what we did, we created a several set of service specific services that architects could do. In transformation, we can define a change strategy and it has to be very specific. So it has to be very specific starting point. It has to be a very specific ending point. What do you deliver? What steps you do? What skills are required? Why do you do something? So we actually, what we did, we actually outlined 11 set of services that enterprise architects do and we defined them in a great detail and then what we did, we took them to marketplace. We took them to the shop. So then the other part was that if that's all that happens, how do you measure the performance of an enterprise architect's professional as an individual and as a group? And then we took a little quick test of this thing that if given that hypothesis, this is set of services to do, how does that actually, how will it actually work in any given organization? This is kind of how work happens. On the left side, we have a repository enterprise capabilities, whether they're documented or not, they exist. Organizations live and they work. People, process and technologies work daily basis. So next thing happens is disruptive change happens somewhere along the line. There's always a disruptive change, whether big, small. So with that disruptive change, we make a decision. We look at the enterprise capabilities and we say, well, if I have to change them, can I just optimize them? Can I transform them? Or do I have to innovation? So then what we do, we do transform, optimize and innovate. Is that's kind of what essentially what we do? And this is what happens today. Not necessarily all the time architects are doing it, somebody's doing it. So we said, okay, you know, that's a model kind of works, it's so far on the paper. You know, everything works on the paper. You know, taking any academic and constructive case for almost anything. So next step was is that let's take it out to the shop. Well, it works in the lab, that's great. So the next thing was is that taking it out. So what we did, we created a toolkit and created all the package of information in it and we made it available to people and then we had a nearly, nearly 3000 downloads in last 12 months. Downloads don't tell you a whole story but they tell you some of the story because there's an interest. Without even telling anybody about it. So there was a download. 30, 40 people wrote comments about it but most of those comments could be taken not too seriously because those are all the people that are already knew about it. So they already direct the coolant so there's a great work, Jason. Yeah, we're like, okay, so you're already on my side so I don't need to hear from you because you're the one who helped me write this thing first place. So the second thing was that we went to client stories. We took it to client sites. We used it on their site and with a limited amount of success that we had around the whole client things. And this is when the Association of Enterprise Rockets that came around and said, well, you know, why don't we take this thing to the members? About 40,000, 50,000 AEA members that we have now. These people have sort of a drank the AEA Kool-Aid. Let's run a workshop with them, a webinar once a month for next 13 months where we explain this idea to them what it is. And it'll be an hour long, we'll set time, we'll give them 40, 50 minutes of discussion and we ask a poll question, see where it goes. And that's what we did. And we had 200 plus members attending it. So what I'm gonna share with you in the next few slides is some of the findings of the results that we had. And if any of you around this afternoon around 4.30, 2.5.30 or 4.5.30 or so, we're just gonna go through these poll questions a little more in detail and take a look at them in the next deep dive. So first question was, is that when I explained the whole model to them is that if you define a year capably like this, would it be easier for you to sell it? Now the poll size was rather limited here and pretty much everybody said yes, it's easier to sell because we can actually specifically identify what it is that we do. Somebody can put a value on it. Next one is that if you develop an ideal transition plan, communicate to your sponsor, what will you say? Only 11% of the people said we'll have a negative impact but almost 89% of people said, you know what our customers want to see what is possible before they make a decision? Could be internal customers. So this is exactly the same point Dr. Dini Ross made to us in almost a year ago, two years ago now. Her point was is that your senior management get what enterprise architecture is. And so do these people believe in trenches in the organization that their senior management get what enterprise architecture is? So next question was, can you now make the connection between year capability performance? This was a positive thing for me, is that first thing architects can actually establish that these performance measures that we identify is that they can influence them, they're meaningful. And secondly, they also believe that if they did the architecture work right, they can influence those performance measures. And these survey questions went on, how many years do architecture practices been on? More than 60% of the companies have more than a year. Most know how to extend the value chain and they haven't done it yet. That's the problem. We know it's valuable, we know our customers want it but we haven't done it yet. We've been in practice for more than a year. Majority of attendees actually agreed that this model would work. So that kind of gave me one confirmation is that I don't necessarily have to wait for them to die so I can actually work with them today. You know, there was a hypothesis made is that maybe we just wait till next breed of enterprise architecture, when this breed of enterprise architecture die, next one we will train them better. You know what, that's just too long, I just don't have that kind of time. If you proposition this value proposition to your CEO, will he or she buy into it? Majority of said yes or maybe. That's because there's more work to be done. There's more trust factor that has to take place because people believe that it's right thing to do but the question is this, one of the things, all these years that I learned about working as an enterprise architect is the senior management in your organization are the smartest bunch of people that you've ever come across. They smell a smoke six miles away. You don't even know there's a fire. They smell the smoke six miles away. Soon as they feel that this project is going south, they get off the boat because they don't want to be part of it. This is one of the reason why the senior manager because they're survivors. But if also at the same time, if they feel they can win, they'll join your boat too. So this is the kind of important thing is that if we can convince our senior manager that we actually can deliver the results, they'll join. That's exactly what the survey was pointing out to. So what's the obstacle? No wonder. It's middle management. IT and the line of business. The middle management is not cooperating. Transparency is not a good thing. If you're the one who being transparent or made transparent, you know, is it middle management? So now a question comes down is that if we went through the survey questions these discussions with the people, did we answer all these questions? The answer in my mind is that we have in part answered these questions, but we have more work left. And here's the, you know, you'll get the idea of this thing. The Canadian plug is just not gonna stop, okay? So this guy is Chris Hadfield, the one of the Canadian astronauts and he was asked a question many years ago and he said, why did they pick you to be the head of NASA, the space control? He goes, well, you know, it's really interesting. When you are a farm boy, living up in the farm country, when that tractor breaks, the city is three days away. You just have to figure out how to fix the tractor with the stuff that you have. So when you're in charge of a space station, when you need to fix this thing, you just have to find the stuff that you have to fix this thing. That's the only reason they picked me because I could fix things without anything. So his point was, he said, like, if you really wanted to be good in life, there's three things that you need to do to be successful in life. Take care of your health, become very good at what you do and take responsibility for your actions. And this is kind of what I'm going to suggest is that if what PMI and IT service management did in their space, they specifically identify what they do, they took responsibility for it. We as an enterprise architects take responsibility for very little. Well, perfect architecture, you don't like it, tough shit. It's not my fault that you're too stupid to get it. No, you don't get it because you didn't communicate. So let's take responsibility for it. So here's what I'm going to ask. Call to action to the A community. And when we did this webinar last week, we have 10 people who actually signed up for it, so they will help. So what I'm suggesting is that we actually created a toolkit. Now it was the work of a few people in isolation. What I like to do is engage more people to actually work with us on the toolkit. And what I like to do is provide the toolkit to the architecture forum as a product for them to manage. Because I think there is a much work that we have done and it's a useful work. We can move forward with it and we can take responsibility. One of the things that if we take this toolkit, create this, make it available to the forum as an open group product. One of the things that open group, in my experience in the last 10 years being associated with this organization has been, is that they are a great vehicle to deliver information out to the large population that is open and free. As to how you get stuff out. So let's make this consumable. Let's join in and help us bring this thing to the next level. Next question, next part is the, we not only have to get a community to build, take this stuff, that's stuff we can do, but we have a larger work to do is get this old thing in our house in order and we need to learn to communicate this thing to the RCE management. This is what we do. So I think this is a dialogue where what I think what we need to do is that we have done some good hypothesis work that needs to be taken into, now we have to create evidence that this actually methods work. And there's some more projects have already kicked off in some places and we can do more of them. More of these projects get kicked off and more evidence that we get. Like the healthcare, this one thing that I learned from healthcare, anecdotal evidence is just not good enough. We had to do a scientific evidence collection in order to get people to say seriously. So that's why I can ask for two parts that we're gonna be working on in our research project. So some of the work has already started with the James and the Open Group India team. We created a program for five architecture courses at the universities, MBAs and undergraduates that they're offering and they're based on this model that we have just created. So work is taking place and we have workshop this afternoon and we have a next series of workshop of the Association of Enterprise Architecture because they optimize and transform as one thing. Next big step for architecture is the how do we lead innovation? Innovation doesn't happen because of accident, innovation is a systematic thing. So we're actually gonna be running four more webinars the rest of the year. And with that, I wanted to thank you for your time. I hopefully it was worth the conversation. Well done. Let's take a seat. Sir. Well done, thank you. So to ask the questions, Steve Nunn, for those that don't know, Steve is the Chief Operating Officer of the Open Group Chief Legal Counsel and also the CEO of the Association of Enterprise Architects. So Steve, over to you. Thank you. Jason, thanks for mentioning the AEA so many times in that presentation. Appreciate it. Just a few questions for you. If senior management do really get what the AEA is, why do we hear that you just can't sell it to senior management as EA? Interesting. I don't have a lot of evidence that is a, that will stand the scientific scrutiny from, like we got some evidence in our survey, 65 question survey, but not enough where I can make a scientific claim for it. But anecdotally, a couple of things happen is to, when we think we create an architecture, we don't create an enterprise architecture, we create technology architectures. We say, hey, it's a perfect server. What the hell do you don't get out of it? Because we don't look at things like business architecture, data architecture, application. That's something that generally we are pretty good at. But we don't look at the, how does this thing is gonna fit into my current ecosystem? What's your transition plan? How are you gonna pay for it? Where's the financial model's gonna come from? Can you actually build this thing? There's no point of creating an architecture in living in Louisiana where you don't can find somebody who can read. Architecture has to work, it has to be implementable, then it has to be supportable. It is the only support. So it's a whole series of things that enterprise architecture, we don't define, we don't take the time to. We do one thing and we say, well, it's good enough. If you don't get it, it's your fault. But I think it's the whole conversation is the, we don't communicate architecture because we don't create complete architecture. We create what we think is a perfect, if you don't get it, it's too bad for you. That's my experience with it, but if you do it the right way, I have no problem communicating, just convincing people of the enterprise architecture. Yeah, it shouldn't be a problem. It's just a case of not starting with the jargon first. Right? You know, as, you know, I grew up as a bookkeeper and you don't go talking to the chairman about accruals and prepayments and deferred tax and stuff like that. You talk about the things that are useful to him, right? And the same with enterprise architecture, you know, or management accounting, it's what's useful to them. And it, you know, when I was at business school and a lot of people my age in senior management positions have gone through that experience, you learned modeling, right? And Archimate for me was a no-brainer because it's like, that's what we did at business, got more or less, it just had different labels. And so a lot of them will understand a model if it's done like that and done simply and clearly. And we just need to be able to present things that are at top of mind, you know, solve my problems is what people want. Yeah, because it's, you know, like I give you two seconds. I did the architecture for this organization about four or five years ago. And so we had to, after all the work was done, we took the architecture to a board meeting and there are three slides. And so I did my three slides and the CEO took off his glasses and put it on the table and he goes, let me understand what you just told us. You say, you telling me that you can deliver those results at that cost and those are my risks. And here's a moment for you. And if I said, oh, well, I only do the architecture. The rest is your problem. You got to find somebody to implement this thing. The whole thing was a waste of time. And I turned around and said, yes, sir, that is what I'm saying. And then he turned around to his VP and said, Dennis, I think we should do this. That's it, decision made. Had I said, I only do architecture, it was a waste of time. When I turned around and said, I immediately said to him, yes, sir, that's what I'm saying. And then it became your problem to figure it out. Then Dennis looked at me and said, yes, and I think we got work to do. That's how long it took to sell the architecture. Less than three minutes and three slides. Go. Somewhat related question, Jason. Some of the questions on the survey assume that you have access to senior management to make the pitch in the first place. Any tips or guidance for situations where that simply isn't the case? You know, if you wanted to hunt somebody, find out the watering holes. And there's no easy way to find where the senior management lives, senior management of human beings. They're a hell of a lot more human that we give them credit for. Just be ready, find out where to live and reach them. You know, I find the CEOs in all kind of weird places. So you've got 30 seconds, make a pitch. And the tip I would give is to, if you meet somebody, get them to see that you're human. They remember human beings. They don't remember technical jargon people. Give them something that they will remember you by. Well, you mentioned middle management. What if you got people in the way that are blocking you? That is a, that's the one of the areas that we're going to be exploring in our next phase of the research is how do the others go about it? And one of the things is that middle managers will take responsibility when they know they're not being held accountable for anything. And yeah, I can do this thing because I'm not accountable for nobody who's gonna hold my feet to the fire. The middle manager is to stop doing projects because project managers is because when project fails, somebody wanted to know, hey, where's your risk log? Where's the time sheet? Where's the resource file? Where's the charter? None of them existed. So no wonder project failed. So then say, hey, do you want to be a manager? I don't have a time for a higher project manager who will do those things. So I think the same thing happens. Senior manager and middle managers love to do architecture because they're not responsible for it. But we just wanted to do is that if you create this architecture, this is what you're gonna be held accountable for and be right. And then once we get to that point, I think they will back up because that's not what they do. They have a full-time job to manage things. Being an architect is a full-time job on something because it's a 24-7 job. If you're not working, you're thinking about it. Yeah, when I was in Unilever, which is a fairly large organization with lots of middle managers at that time, what I did was to find the middle managers that felt that you could actually help them look good if you did some work. And then they gave you the exposure, eventually. Absolutely, yep. But working with some of them, it's just their waste of time. You never get through. Yeah, and this is kind of where you look at it. Today, being an enterprise, if you're a good enterprise architect today, you don't have to put up with the crap from inside the organization. And you know what? You can always step outside and take responsibility for what you think as you have a good architecture for. Next question. Okay. Two questions left, both around EA as a profession. First one, primary limit on the impact of the EA profession seems to be the lack of fully-funded practices. Most EA's also do solution architecture, general technical leadership, and technical problem-solving. How can we appeal to the sponsors of EA for increased actual investment? That's gotta, you know, the lot of EA's are technical people, are technology architect. They love being the problem solvers, and they haven't given up on their old job. They got a new one, and they just don't have time to do the new one. If you wanna be a good enterprise architect, stop doing your old job, then you'll have funding for it. Because if you keep coming to the rescue, I've seen a number of architects actually still go and configuring servers because they can, and then not do their own job. And this is one of the reasons why we surveyed, we saw the results is to, practices have been running more than a year, three, four years, and they still don't have an understanding what are the top three capabilities in their organization that they make them money. If you ask the enterprise architect within the organization, most of them probably couldn't answer that question. Then I would say that you probably don't deserve to be in that job. It's a hard reality, but I'm sorry. If you can do the job, then step off. If you don't know today, if you've been an enterprise architect, you don't know what capabilities in your organization make you money. Then do you have no business of calling yourself an enterprise architect? And last question, how important do you think it is for the discipline of EA to become a profession and what difference would it make? Oh, I think it would make a huge difference because then we as a people, professionals start taking responsibility for what we do to what matters to people in the boardroom. This is exactly what the PMs did. The PMs turned around, they told the managers, the VPs, and say, I will make sure your project succeed. If it's not going to succeed, I will tell you before it fails. That's all they did. So you can do something about it. It's not, the projects are not succeeding any more than they were succeeding before, except they just now know that before they fail, they're gonna fail. And that's been a value proposition of PMs. They've been very successful. I think we can do the same thing as in EA. And you're not alone in that feeling. In the AEA, where we've got, what, 45,000, 50,000 members now, there's more than 20,000 that are actively updating their profiles. We've got 15,000 responses to the survey. You're getting people on these webinars all the time. There's a lot of people that are keen to see enterprise architecture as a profession. Yes. And there will be lots of different disciplines like other professions. Absolutely, yeah. Won't be one size fits all. So yeah, that's good stuff. So lastly for me, just a personal thank you and on behalf of the AEA for all the time and effort you put into those webinars and the series. And I hope you, I know you're talking to you earlier. You said you did get a lot out of them as a learning experience, but thank you for all the time you put in. Oh, thank you. And it was actually great. Actually, there's times when you sort of see yourself, so you keep banging your head against the wall, and you turn around and say, maybe you should stop and because it started starting to hurt. And then after this, about 14 months conversation, actually I came up with a lot more of a new energy and I think that we have a path forward that we can forge. And I think there's a huge opportunity that it may take an EA as a profession. And to the next level, I'd like to see a one day where we actually have a open sea level 30 certified people who actually take professional insurance and take responsibility for what we do that if your project, if your transformation fails as an enterprise or architect professional, I have responsibility for it, just like the lawyers and accountants others do. And I think that is not that far. While we're here, do you want to say just a few words just to give people an inkling as to what you're doing in India with the universities? Yes. With the help of James Dureve and his India team, we introduced, they asked me about a year and a half ago to say, can you teach some faculty members about TOGAF? And then we went ahead and these are faculty members, they're academics, but when we started teaching them basic TOGAF, they didn't get it. And teaching TOGAF, because all our material that we had set up so far was teaching TOGAF to enterprise architects. But we had to do turn around and we had to teach them how to do enterprise architecture using a TOGAF. So we kind of redid our program. And then we went a second time around at the beginning of the year and we had professors from six universities who came in, some of them came about after two hours of public bus ride to the campus where we held the sessions. So it was very encouraging. Then from that point on, we said, okay, so then they all became individually with their principals, many times, came over to meet with us during the week that I was there. And they said, well, we are very interested in doing this thing. This is the class that we have. And some had an MBA class that was a eight plus years experience. Some had an MBA class that was a graduate student just coming out of this thing. Some had a two, three years experience. And some were as an undergraduate computer science and business and IT schools. So they had all had very different needs. So then what we did last year, at the beginning of the year, we developed five training courses. Not how to teach them in Togaf but how to do enterprise architectures using Togaf. So right now we are in a pilot phase at four colleges. And they're all associated with the University of Mumbai. So they're all in the Mumbai. We hope to get about a thousand graduates by the end of the year. And each one of those, it's a case-based training that faculty members are leading. And as a result of that, there will be submissions from these students because some of them are using the work, architectural work that they do with the academic rigor. And they're also using that as their capstone projects. So our hope is by the time October comes around when we have a first cohort, students would have completed all the deliverables. Take a look at the material once again. Take a look at what they've produced. And then run some kind of pavilion where we can award people with the best architectural work that they've done, best thinking that they've done. And then package up these programs for academic universities anywhere in the world who a university wants to become a, take these five programs, run them within their university, and then they just have to become an academic member. And I think in India was a, the James's team in India, they're doing a great job. One thing is that they are going around like Andhra Pradesh, they said, New Delhi, the federal government, and some state government. They're creating a demand for enterprise architecture. But you have to want to create a supply for it. So the universities are the ones who are creating a supply for these people. And it's actually, it's a great marriage that is happening between the two, at this, happening at the same parallel. And it's a very exciting time. I'm really looking forward to be part of it. It is, it's great. Anyway, for the time being, thank you very much. Thank you, sir. Great presentation as usual. Well done.