B (2:58)

Oh, absolutely, absolutely. In fact, in fact, in a way I've been lucky because I think in a sense, governments are more open. I mean, they are more willing to share lots of information in terms of, you know, things that you can learn from. There are case studies available out there. You can talk to people. Obviously sometimes it becomes an issue, but otherwise it's been more open. I think governments tend to be more open than the corporates, which is, you know, understand I found the same thing.

A (3:28)

Yeah.

B (3:29)

And therefore it becomes a good training ground for all of us. And in a sense that has helped me hone my skills, you know, and experience.

A (3:38)

So have you seen a major shift in the last 20. You've been doing this for 25 years. Have you seen any major shifts or any major threads that you've seen changed over, over the last 25 years?

B (3:51)

So, you know, my first experience about enterprise architecture was the Federal enterprise architecture framework FEA, which is the version 1.0, which as I'm sure you are aware of it, and that was the, I would say the best practice that we used to create the Singapore Government Enterprise Architecture SGEA, which was almost 15 years back. So that was my first tryst with creating a, you know, national level architecture. Of course, Singapore is a very small place, as you know, so, you know, it has its own pros and cons. But the biggest change which I have seen in, in the past 25 years, or rather at least in the past 10 years, is that there is a lot more acceptance towards the value of architecture, especially in the context of digital government. I think the, the, the convergence of digital technologies that, as we all know, has become a catalyst in a way for countries and for government organizations, for the public sector entities to see the value and benefit of enterprise architecture. So that's one part of it, the acceptance is much higher. The other part, as you, you know, rightly said, and I'm kind of extending it to that is I do see that architects, especially enterprise architects, have sometimes difficulty explaining the value of their trade, if we call it that way. And this comes back to me even today as then, you know, people say, I'm, I've, I've not been able to convince, let's say a senior bureaucrat in the government or my, or my CEO or the Chief Operations officer in terms of the value of enterprise architecture. So that is always a challenge. But otherwise as a, as a practice, I think it has been a lot more acceptable. Now it's far easier to talk about the value of EA as we know it in the context of digital government, in the context of how technology has enabled many public sector organizations.

A (5:48)

So if people don't quite understand when you say enterprise architecture, how is that different from like a systems architecture that focuses just on digital, you know, Systems like in it. So when you say enterprise architecture, do you mean your IT infrastructure architecture? What's the main difference? What's the best way to describe that to someone that's never really heard the term, or maybe someone that's heard the term but is maybe misusing it? What would be your best description of that?

B (6:18)

Yeah, so the way we do it is, and I'm going to give you a context from the government sector, but in a broad level, the way I explain enterprise architecture in the context of digital governance, or let's say digitization, is. It helps organizations execute their strategy. I think that makes a lot of sense. People understand that. I mean, you know, the big picture vision, mission objectives, goals, and the key result areas are all fine. People understand that because that has been a practice in the business schools, in the management institutes. Right. But somebody needs to take it down and execute it, and that's where the enterprise architecture comes in. So if you, if we stay at that level, it gels and it, it kind of, you know, creates a trigger within the execution team. But having said that, what we, you know, I think we, we both know that in many cases the enterprise architecture team or the group within the organization tends to reside with the IT organization. And that sometimes becomes a problem because we know sometimes it doesn't get the respect that, you know, it should.

A (7:25)

That's right, they don't get the respect.

B (7:29)

It's always been the case. But I think things are changing now. People realize that technology enables many things that would not have been possible, digital technology especially, without the, you know, availability of those things. But having said that, I mean, staying in the IT is useful. However, I have, you know, personally, I do advocate the need to elevate the role of enterprise architecture within the, within the strategic group or the strategic management group. And IT has been successfully implemented and therefore the focus there is more on the business part of the architecture and the, as you said, the systems part still remains with the it. Yeah, exactly. So there is a connection. There is a, I would say there is a line of sight between the parts of the business focused area of the architecture and the technology focused area of the architecture.

A (8:32)

So it sounds to me like it may even reside in the COO's office, the chief Operating Officer's office, because like you said at the beginning, you're taking strategy and you're creating an architecture that can support that strategy. So I can get the objectives done, the key strategies, the value chains, all that stuff, so that I can drive that to actual realization. Because there's a Lot. Especially in very large corporations and large government agencies, there's always this disconnect from the vision and the mission to what actually gets done and accomplished. Absolutely. This is that sweet spot that us enterprise architects fit in. We're going to architect a system which includes all that strategy. It includes organizational structure, process, physical locations, physical things, and also digital things.

B (9:29)

Right.

A (9:30)

That's kind of, you know, how I, I just described, you know, gdxa, right?

B (9:36)

Yeah, yeah, absolutely. In fact, I, you know, I like the word you, you know, use the word system because the people, when you use the word system, people immediately think it must be an IT system. But this is the more generic, broad aspect of system. And you know, whenever I, you know, never talk to people, I said, don't forget that, you know, systems are much bigger in context. It is just one type of system. And that's true because I've been trained in systems thinking at MIT Sloan. So I, I, I just love systems thinking. But you're right, I mean, it does make a lot of difference when the enterprise architecture team is positioned in an organization which has the authority to, you know, realize that transformation. Because at the end of the day, the CEO, you know, especially if you're looking at it from a corporate perspective, but if you kind of take it to the government domain, an equivalent, let's say, you know, a senior bureaucrat in the strategic manner, typically to get stuff done. Right, exactly. Exactly. So that's how it should be, ideally, should be positioned. I know that at a practical level, many times it does not happen, but it does help a lot when the, when, when the, when the team that is kind of responsible for implementing the transformation has the authority to implement that transformation. Otherwise it is very difficult to bring the change. And as you mentioned, when we are building a system, it could also lead to organizational restructuring. And we both know how political restructuring can get. It is technology is the least of the problems. You know, so something, you know, so something for us to kind of think.

A (11:14)

So true. That is so, so true. So let's talk a little bit about this. You've been in, you've, you've gone through these digital transformations with organizations.

B (11:24)

Yes.

A (11:26)

Have you tried to do one without an enterprise architecture?

B (11:32)

I would say no. Never. Now?

A (11:35)

Never.

B (11:36)

Wow. Yeah. Yeah. Because I, I see the enterprise architecture which provides a structured methodology to see, I mean, for me, that's what it is, Right. Because it is, it provides a structured way of thinking. Now, people may use different terms. For instance, you know, I know that there are some, some people who may want or at least a few decades back, maybe 20 years back, they would probably use systems planning, you know, as a term, which in my view is like a precursor to enterprise architecture. I mean, I've interacted with John Zachman himself. So, you know, we've had exchange, you know, discussions on that. Exchange notes. So, yes, it may be called systems planning, it may be called strategic blueprinting. But in a nutshell, if you see the nature of it, it's what architecture brings into the picture. Yes.

A (12:25)

I really, I really like, I really like where you headed with that. Because even if we didn't have a name for it, that's what we were doing now, now we have a name for it. How do I capture the best practices? Because experts like you and myself that have done these digital transformations with architecture, there's got to be some way to capture the, the success stories and the failures. There's been major, major failures. Enterprise architecture, well, I shouldn't say enterprise architecture. There's been major failures in corporations that did not change, and there's been major failures with organizations that tried to change and just couldn't pull it off. How do we capture those best practices or those lessons learned? Is there a place where, as an industry, have we done anything to help capture so we don't keep doing the same dumb things over and over again?

B (13:25)

Very interesting question. In fact, one of the things which we've tried to do, you know, especially during my, you know, stay with Open Group, is that we've tried to cap. We've tried to document case studies, both success and failure stories. As, you know, failure stories, especially in the government sector, is not easy because there are, there can be political, you know, implications of a failure story. I mean, a real failure story. But there are documented failure stories. But in terms of creating the best practices, in my view, there is no dearth of frameworks or, you know, or guides or methodologies. I don't see that as the issue. The issue here is that we do not have enough documented case studies. And that's what we've been trying to do in the past four years or so. I think we have met with a lot of success in the past four years. I think if I don't, if I, if I'm not mistaken, in the Open Group library, we have added at least 20 new case studies in the government domain. And these are, you know, and these are not fictitious case studies. They are real case studies with the countries or the agencies or the organizations named, how they went about. And one of the things that we do within this case studies is towards the end we identify what are the learning points. Now I think architects have enough intellect to understand the frameworks and methodologies by themselves. They don't have to be taught in general. It's the learning points that really adds value and we would like to continue doing that and therefore bring that kind of increase and contribute to the body of knowledge, so to speak.

A (15:11)

So this is really interesting because I remember I went to MBA school back in the late 90s and then I've, I've done my PhD as, as you know, in systems engineering and, and specifically in cyber security, converged systems. Where, where are we teaching enterprise architecture and change management? It's not in MBA school.

B (15:37)

Not at all.

A (15:38)

Because those guys all talk strategy. I absolutely, I should say those guys, I was, I, I won one of those guys. I was a cio. We talk strategy and then we drop our strategy down onto our team and say, go do this. Are there places where we are developing these systems engineering or system of systems engineering? Are there schools out there that are teaching this and are they leveraging the library that's coming out of open group on these documented case studies?

B (16:09)

So there are a few schools that do teach, I think. And coming back to one of your earlier points, what are the changes that I've seen in the past 10 to 25 years? So one of the change I've seen is that now it's also been recognized that enterprise architecture, whether we call the term enterprise architecture in that shape, you know, is irrelevant. But the point is those, those thinking that kind of architecture thinking, big picture thinking and taking all the way down to execution is being covered in business schools, you know, and many of them are taking benefit of the case studies that we are developing. In fact, within the open group, we have a work group which looks at introducing enterprise architecture as a graduate level subject, which is business schools and you know, other graduate level subjects. And we have been starting to use, and many of these schools are using the case studies that we've identified. However, the biggest shortcoming that I see at this point is it is not easy to find faculty who can teach this subject comfortably because it has not been an academic subject in the traditional sense. Right. It's come from the practice and therefore, you know, it will take some time before it gets academic acceptance. But. Yeah, go ahead.

A (17:32)

Yeah. To be an enterprise architect, you've got to know IT systems, you've got to know OT systems, you've got to know process, organizational structures and strategies. It's, it's not your typical business Type of person. Right. A lot of business people are, are have marketing or finance and, and things like that. But you've got to have some pretty deep understanding of system of systems thoughts.

B (18:00)

Absolutely, absolutely. In fact, there is a, and I was coming to this, there is a paper, Harvard Business Review 2023, which talks of how the MBA curriculum, you know, I mean, I can send that paper to you. MBA curriculum needs to be updated, you know, and one of the thing that it identified, the authors identified, is this kind of systems and enterprise architecture thinking needs to be taught to MBA students. Otherwise, today's business school graduates need to understand how technology can be used to create new businesses. Because, see, there was a time when, you know, we have been through that process. Right. There was a time when the general perception was technology follows business. Right. Business defines what needs to be done. And technology. Yeah, that is not the case anymore. Today, technology is creating new businesses. So therefore, business school students need to understand how it needs to be architected. And that kind of thinking is coming. I'm seeing that transition happening and I'm sure in the next decade or so there will be a lot more, you know, adoption of this kind of approach and thinking within business schools, connecting to the corporate entities as well.

A (19:14)

It sounds to me like you and I are going to have great teaching jobs for the next decade.

B (19:20)

Absolutely, absolutely.

A (19:22)

For anyone listening from Harvard or, you know, Wharton School of Business.

B (19:27)

Yes.

A (19:28)

You got to hire us.

B (19:31)

You got.

A (19:31)

To pay us a lot of money to do.

B (19:32)

Absolutely. Yeah.

A (19:35)

So, so let, let's talk about the role of, and I'm glad you brought up that technology should be driving business now. I'm. It really should. Let's talk about the role of generative AI in enterprise architecture now, because I think it's actually a game changer. I, I think it can help accelerate the adoption of enterprise architecture and also in the governance and the implementation of enterprise architectures.

B (20:06)

Yes, absolutely. Because one of the things that I see is that architects create all of these models. It could be using any of the formal notations, any of the big ones.

A (20:20)

That we all know.

B (20:21)

Yeah, exactly. You could be using maybe even UML in some cases, even though it's not meant for architecture. But that's fine. ML. Right. The question here is can those models become executable models? And therefore it becomes far easier for organizations to try out the solutions, you know, in a way, you know, some kind of a sandboxing mechanism. Right. Where. And I've seen that in the government domain, because there are services which can be prototyped using These models. So the executable models all the way, you know, come down to implementation. And that's where I think the enterprise architecture becomes more convincing. Because if you remember in the beginning of this discussion I said that sometimes architects find it difficult to show the value because the C level are asking for results. And how do you show results when you've not even implemented it? So maybe one way to do that is creating some kind of a sandboxing mechanism where governments or organizations can try out their solutions, so to speak, and see what is the impact. And if generative AI can accelerate that. Oh, I mean, that is really going to be a game changer. That's a game changer, yeah.

A (21:35)

Because I've noticed when I've created these beautiful architectures with slide decks, hundreds of pages of documentation, no one wants to read it.

B (21:47)

Exactly right.

A (21:48)

It's like, it's like an architect of a, of a building that creates all these beautiful blueprints and the guys on the ground just do whatever they feel like.

B (21:58)

Oh yeah, absolutely. Absolutely. Yes, yes.

A (22:09)

Right. So I think you hit the, the nail on the head there with that one, which is unless we can actually show it. Simulate my architecture.

B (22:19)

Yes, that's the right.

A (22:20)

Show it running, do a proof of value for it, and then have some way of that quick prototype turning into a governance model or automated processes that can guide organizations through it. I think we're still in the. Here's a big document.

B (22:41)

Exactly. And you know, and, and given that I worked in the government domain, another thing that is very important and many architects don't understand, is that to implement the transformation which is being realized or which is being enabled by the architecture, governments need to make at times many regulatory and policy changes and sometimes they are unwilling to do that. See, the, the prototype will work, but if the policy is not changed, it cannot be rolled out, so to speak, because governments have a different way of things and sometimes laws need to be changed. And you know, both of us know how difficult it is for, for any country to change its laws. Unless of course, you're an autocratic, you know, you have the king or the emperor doing something, that's a different issue. But otherwise it is a very, very big ask for us to change the law so that the benefit of the transformation can be realized by the people realized.

A (23:35)

There's a prime example for this Canadian government. I was up there helping them with their digital transformation, moving to multi hybrid cloud architectures from building their own data centers to cloud and things like this. In their law, in their procurement laws, they had no way of purchasing cloud services because they could and they couldn't even purchase hyper converged infrastructure because they, the way the laws were written was I buy storage, I buy compute, I buy network, all three separate, all procured separately. And I was like, what do you mean you can't buy cloud services? Right. This was decades ago.

B (24:18)

Right.

A (24:19)

So we actually had to help them rewrite the law. Right. In order for them to purchase hyper converged infrastructure and bundled packaged solutions like that. So it was, it's fascinating. It blew my mind that I said what, you know, it's true. Yeah, that's a very good point. That sometimes policy and laws and regulations have to change.

B (24:46)

Yeah. In fact, I've seen in many countries, you know, I work with the, you know, work with the United nations, work with the World bank, you know, help them. And in many of the developing countries I've seen digital signatures are still not legally acceptable. That requires a change in law. Right. It's not a technology thing that we cannot implement a digital signature solution. Right. It's just the law doesn't recognize that it's a, you know, it's, it's a valid signature. It's as simple as that. You know, and we don't realize how architects need to really think about everything to, you know, to show the value of transformation. Yes.

A (25:24)

Well, maybe, maybe government enterprise architects need a, a degree in political science too, or maybe a law degree.

B (25:34)

Absolutely.

A (25:35)

Maybe we're going back to school.

B (25:37)

Yes, yes, yes, absolutely.

A (25:38)

You and I are headed back to school. Yeah, just what, just what we need. All right, let, let, let's shift gears a little bit and talk about standards around all this.

B (25:49)

Yes.

A (25:50)

So if, and this, this is dear to both your and my heart.

B (25:55)

Right.

A (25:56)

If, if. What's the importance of standards when we're starting to talk especially around government enterprise or enterprise architecture and change, what's the benefit of having some kind of standard that a government could adhere to? Or is there, is there any benefit?

B (26:14)

There is a lot of benefit. Governments. Okay, the, let, let me take a step back now. Many countries in the world, almost, let's say There are about 196 recognized countries in the United nations, in my view, at least 150 countries don't have an architect role, a real architect role, because, you know, it's, it's not mentioned anywhere. Now the reason why standards are required is all of these countries are looking for guidance, looking for direction in terms of how they should go about implementing their digital transformation. Now all of these countries are wanting some kind of guidance, wanting some kind of direction. And that's where the standards come in. And why the standards are required is because it gives these countries, I would say, a kind of a structured way of doing things and to generate value. In most cases, what happens is if you, if you see the, you know, the functions of a government, barring, you know, slight differences, they are very similar. I mean, yeah, that is the reason. Obviously, large countries may have their own complexities. All that is fine. But in general, governments typically do the same things. Right. And therefore there is a lot of potential for us to standardize so that the, you know, the run of the mill aspects of it can be provided out of the box, maybe through a commercial tool or a professional tool where the, so that the governments can focus more on improving the quality of governance. Because I keep saying a government's job is not doing architecture. Architecture should help them improve the quality of life, quality of governance. Right? That's their core activity. They should be focusing on development outcomes. They should be focusing on how to grow the economy. That's what the government's job is. Government's job is not to read UML models and understand them. I mean, there may be people who are doing absolutely right, but that's, that's not what it is. Right. I mean, we have interacted with bureaucrats at the senior level and that's what they say, Tell me how it's going to change the quality of people's lives. Is it going to, for instance, double the farmer's income? Is it going to improve my agricultural yield? And that's the kind of questions that architects should be able to answer. Right. And therefore, it's very important that if some of the, some of the common aspects can be standardized, governments can focus on what matters to them rather than trying to solve the same problem from country to country to country to country. You know, it's like, you know, reinventing the wheel again and again and again and all of these things happen. Yes, yes.

A (28:55)

So I really like, I like that. Here's a question. If I have standard enterprise architecture with standard, maybe even it architectures underneath it, and standard physics, when vendors come in and now bid on things, what helps them differentiate themselves? Don't standards get in the way of the uniqueness that a vendor could have that selling to the government?

B (29:30)

Oh, see, the vendors have a big role to play because once there are standards, even the vendors can focus on, you know, implementing some of the standard base specification, maybe a building block which can be, you know, brought together to create a public service. So the differentiation that the vendors can provide is how it can help or how, you know, the vendor can help the specific government agency achieve its business goals. Coming back to our first point, right, at the end of the day, the architecture team should be able to articulate the business goals and how it helps governments or corporate entities achieve their business goals. Now, again, you know, I face this situation myself. In certain countries, the word business is not taken in the right context. It's taken more as a commercial word. So in the government domain, you don't use the word. Exactly. In the government domain, you don't use the word business. So I tend to use the word development goals, you know, because UN provides the Sustainable Development goals and therefore the vendors can show to the government that through the use of standards and the building blocks that you have provided as a specification, I'm going to help you achieve and improve the quality of life, quality of governance, quality of doing business. You know, all of these things. That's where the real vendor value comes in. So vendors also have a big role to play, actually.

A (30:55)

Yeah, I actually like that a lot because now the vendors can focus on real value differentiation instead of vendor lock in which a lot of them want to do. Hey, you know, once you use us, you're stuck with us. That happens a lot. Especially in the military. All over the place.

B (31:12)

Yes.

A (31:13)

You know, proprietary, proprietary protocols and all this stuff. I'm like, guys, you're slowing down progress just to protect, you know, your, your small position. I really like this. This is like more true competitiveness where I'm actually providing real value and, and I'm focused on those development goals, as you said, which I think is really valuable. So this has been, this has been great. We're running out of time, but we most definitely have to have you come back on the show. If people want to find out more about enterprise architecture and all that stuff, where do they go?

B (31:57)

More about enterprise architecture in general? I would say Open Group Library is a very good place. It is free of charge.

A (32:04)

Charge.

B (32:04)

Anybody can go to our library download. Now, I mentioned the case studies. They are also in the library. You know, we'd be happy to provide links to all of those things, but they are all available. There is a lot of material out there, you know, especially, I'm not talking of the other sources, but even within the Open Group Library, there's a lot of material on enterprise architecture. I think most, most people in the world would have heard of TOGAF as a default standard. Global. Global standard. So, yes, that there's a lot of history and lot of body of knowledge around that. So all of that is available in the open group library. Great.

A (32:39)

And if people want to reach out to you individually and learn more about like government, enterprise architecture, how can they get a hold of you?

B (32:46)

Palo the best, best ways. I'm on LinkedIn. I'm quite active. I keep posting articles, blogs on LinkedIn. So just reach out to me. My name is on the, you know, on the screen here. Just reach out to me. I'll be happy to reach out and in fact, many people do, you know, reach out to me that way and, you know, we get connected.

A (33:04)

That's awesome. Hey, thanks for coming on the show. I always have fun talking to you because there aren't many of us out there, so.

B (33:12)

Absolutely.

A (33:13)

We gotta, you know, you know, stay strong together, right?

B (33:16)

Yes, exactly. Thank you. Talking to you. Great is always. And, and we missed, you know, in Riyadh. But I'm sure we'll meet again.

A (33:24)

We'll see you in Houston.

B (33:25)

Yes, yes, most likely. Most likely in Houston in November.

A (33:28)

There's a big open, open group conference. Absolutely. Finally we'll get to meet up.

B (33:34)

Yes.

A (33:37)

Thank you for listening to Embracing Digital Transformation today. If you enjoyed our podcast, give it five stars on your favorite podcasting site or YouTube channel. You can find out more information about Embracing Digital transformation@embracingdigital.org Until next time, go out and embrace the digital revolution.