So how was enterprise architecture seen from an executive level within the company? Have you got sponsorship within--
Absolutely. Absolutely, there is a great support.
OK, great.
I have to admit, great support. There is also people are really educated in architecture. You have people who are coming from different backgrounds, and they are quite conversant in terms of architecture speak. They know what they talk about.
So it's helped because basically, when you talk about architecture, people now know that OK, there is the business architecture. There is operational architecture. There is the system architecture. Once people know how to kind of differentiate all those things, make it very easy to engage cross-functionally, so I think yeah.
And sponsorship as well, yes. I think people know the role of architecture, architects. So thinking in that sense, I would say the company is quite--
So do you have a sort of central internal team that are acting as a sort of EA consulting type outfits, the rest of the organization?
Yeah, yeah, they have that, both from the IT perspective and from the business perspective as well. And we have a team like the change team, for example, who are-- sorry-- using architecture skills, skill set to actually seed that [INAUDIBLE].
So is that more like the transformation team?
Absolutely.
And they're driving program exchange.
Right to drive program exchange. And then they kind of work with the architecture to make sure that all those programs are actually well coordinated.
OK, yeah, interesting. Yeah, so traditionally, the enterprise architecture, I guess, 10-15 years ago has been driven by standards, internal standards, and IT driven, and EA really driving. Yet you can use the application, but you must use that network protocol or whatever.
I guess you're seeing that change there, if it's been more business driven. It's more about operational processes?
Yeah, you could see that, absolutely. Absolutely. And it's vise versa. It's like the business needs to understand more the IT sectors. And the IT people need to actually step up and understand more about the business. So this need for coherence, coherence or integrity, is really kind of really pushed through by the senior management to make sure that people understand that everything is driven by the business.
Absolutely. And then I guess for-- what I'm interested is, how do you communicate the architecture to other stakeholders in the organization, that aren't necessarily architects?
Yeah, I think this is where the Erwin tools make a difference because it's really helped people who are completely neophyte in terms of architecture to understand what it means. So let's say, for example, process owners, once you show them where the process fits into the architecture by simple visual artifact through the Erwin tools, automatically they soak it.
Ah, now I understand what you mean by architecture. You mean that OK, where my business is fitting compared to the customers from the customer front to back. So I think yeah, these tools allow us to bring it to a conversation level. And it helps a lot.
Apart from that, the way people get to know it. I think, generally, it's people who are working in architecture who really know that. And the rest are just working. And then after that, they say, OK, whatever you do is belonging to this part on the architecture, that again, unless you have a tool that can actually bring those things into life in a very simple fashion, it's very difficult for people to actually connect the dots.
So based off that, then I guess you've got a core set of people that use the EA tooling as part of their everyday job?
Absolutely.
And then you've got a set of people that are sort of touching on it occasionally but need to understand the value of it as they touch on the architecture.
Exactly, exactly.
And the majority of those people in the business or on the IT side or both?
Both, both, so you've got people, data, data experts, system and application experts, business experts. And then they have their own tool as well. They have their own tooling to have the landscape and the catalog of the applications, landscape and catalog of IT systems.
The other one has a other system for the processes. But then you need to bring all those things together so that it makes sense for the senior management team to actually say, OK, now that we have all those nice stuff, what does he mean, in terms of decisions and things like that?