I think you're touching on some interesting points, and I think many organizations operate their organization in silos and they operate within the ecosystem that what we have as our business and social landscape in the same fashion because of the scale of change, the amount of integration, interoperability and the sheer amount of information that's flowing across and past most organizations, it's really going to be important for organizations to start to work together and collaborate. One of the things that I think the architects, all architects, not just business architects, but all of them need to start to do is to start to think and collaborate more. I think they need to share more information. There's a lot of organizations that, for example, have, let's just say capability maps and they don't share those because they feel like that's proprietary information. It's a conceptual framework that should be, for the most part, pretty much ubiquitous across most organizations. The fact that they may create too much detail in some of their hierarchies or strata around business, architecture and capability maps is maybe part of the problem. There's a need for business architects to start to work together and align and look for ways of cooperating and extending the practice rather than, let's just say, competing amongst each other.
I think that the guild tries to do some aspect of that which is useful. I see the same thing when I look at business relationship management, a lot of these folks are trying to do something on a similar manner in terms of trying to make that into a more robust practice and discipline. There's not a lot of helping each other and supporting each other in terms of making common sets of frameworks and mappings just simply available so people can take them and implement them. Going back to the previous question, how do we make it more approachable for some of these smaller and non for profit organizations? We need to figure out ways of making this information reusable so that they can plug it and play and modify it much more easily. I don't think most folks are going to read through a large body of work. And I don't think a lot of folks can relate to a lot of the work if they don't see a use case that specifically outlines their domain of expertise or their specific nuances of for their organization. There's there's a need for going past some of that and making some of the stuff much more digestible and much more usable where possible.
I think it's important for all architects to start to look across the landscape and look for ways that there are going to be synergistic fits within their disciplines and how we can start to help all organizations benefit from the body of work that's been put out there by all these different practices, not just enterprise architecture, business architects, there's data architects, information architects, knowledge architects to talk about that maybe a little bit later. But then there's also the technical architects and there's all these different landscapes that some of the stuff is changing at enormous rates. We have business process that's also somehow trying to keep up with the pace of change. And where does that come into play along with all these other disciplines? And I think there's again, there's a lot of these things that are starting to come together with some of these more accelerated efforts around IoT, Industry 4.0, 5.0, digital twinning, the whole area around knowledge graph is really going to be an interesting play. I think that's going to be a game changer for a lot of what we think about as architecture and business architecture.
Business architecture, since it needs to be more collaborative oriented, more sharing oriented, let's draw a contrast to the enterprise architectures and the enterprise architects that would have preceded that evolution. And I tend to think that they did not operate in that fashion. You and I both played enterprise architects at some point or another in our career. And I think I would say that we all, certainly for myself, you should obviously speak for yourself. But for myself, the perspective was that it was always kind of a weighted down by its association with the I.T. folks. Its principal use case was, as it was for IT portfolio management. And so enterprise architecture was kind of had their own, you know, sort of Free Brittny perspective on this. They were trapped in a conservatorship of IT control and they really weren't able to get out of that. Various business architects not only should be free of that, but I think many of the concepts in business, architecture, architecture are essentially more abstract and intended to be inter-comperable across businesses free of any concerns about violating intellectual property or copyrighted things or anything else that might be seen as as something that should preclude sharing. And I think that that's a good point. The guild, for example, I think that's part of their response in creating these reference models that you and I know they've been pushing for the last couple of years. It seems like one pops out every quarter.
Those are at least an attempt to get it in a shareable kind of way. I think enterprise architecture never quite got to that. It seemed to create patterns out, have sort of higher level, mostly technical patterns, and those are still there. But that's not the same as a reference model that says, see if you want to outfit your organization in the financial market to be a bank, for example, here's something to follow. The analog to that in the BPM side is there are reference models out there, but generally they're called process classification frameworks. We actually had someone on from APRC earlier in this podcast series and they're they're still going strong enough. So you have, from the BPM perspective, the kind of, if you will, starting point a framework, whatever you want to call it, for a process of understanding. There is no analog on that on the business architecture side other than what I think we are seeing the guild produce at whatever pace they're trying to produce. So I think that was an excellent point. And I think it's one of the things that further separates a business architecture from from enterprise architecture. Speaking of use cases, let's use that as a segue into the second question that.
So let me just comment on that. I was going to just throw out APQC because the reason I think that they have had the sustainable value proposition and has so many followers is because they have always published those referenced models. And those are what we call. accelerators. They are a lot a lot of people start out when they don't know where to go with douthit starting their capability maps, they start with these process maps because it has a certain amount of categorization and there's some context around that. You could argue that there is a hierarchical model that's built in the way that they define the framework. So I think that's something that really, every discipline can do. It's an easy one to do that takes some time to evolve. It doesn't have to be perfect. One of the things I would like to see, maybe the Business Architecture Guild tackle separate and and maybe in concert with some of the work they've done with the the reference model is something called a domain model. A lot of organizations argue about what our what is the domain? How do we found the stuff that we're working on. And there's a need for this, especially because more and more organizations are trying to figure out how to incorporate, the activities, processes that belong within a containerised bounded envelope. What is that envelope? Is it a department? Is it a business unit? Is it a discipline? Is it a vertical? Could it be all of those things? Well, maybe, but that's a very messy way to create componentatised reuse. I think there's a need for domain models. Rather than having the technology people evolve it on their own, I think it would be a huge service to bring something like that forward. Not only would it be useful for, let's say, business architecture, but it would be useful for virtually every type of architecture. And I think it would be very helpful for the folks that are doing business process modeling.
I couldn't agree more. It would be no surprise to you that APQC also sees this as a use case for their process classification frameworks as a starter kit, if you will, for capability map, she says, is that they said this is often the case. But the guest we had that day was Holly Lyke-Ho-Gland. She is one of their main researchers. She was very good in covering this material. And we hope to have her on again at some point.
If IT portfolio management, which business architecture can still do, but it runs the risk of pulling it into the abyss of part of IT, what other use cases can we have? Now, you mentioned in our correspondence on this corporate planning, I'm going to add one more in here. Mergers and acquisitions, which to me is both of those are criminally under explored in in the use of business architecture. And even when I present those questions to the founders of the Business Architecture Guild, they all nod their heads in the set. But I'm like, how are you going to bend the change in that direction? They have some ideas, but I'm not sure that they see a long term hoping that. The only thing that we have agreed on and then the question was that they are trying to make some inroads into the MBA programs, which is an idea I also suggested to them. They said, yeah, we were doing that. So I think if we can you know, if business, architecture concepts and the general generally accepted portions of business architecture as a discipline can be incorporated into MBA curriculums, that's at least a start because then those people will carry it forward. But again, that's going to take a while. What other use cases can we imagine and how would we use business architecture for things like corporate planning or strategy sessions and exploring mergers and acquisitions like vetting the possibilities of a merger and acquisition with another company by comparing two different business architectures?
You touched on it a little bit. If people perceive business architecture as an extension of IT, which I see in many companies, by the way, the business architects report to the CIO. Which is kind of a head scratcher. Only if you look at it from the standpoint of, well, you know, they're just there to make sure that business and IT roadmaps are aligned. And it's like that's not really what the intent is. It is how many CIOs see that? Because the problem is you're using this term architecture and immediately people think, oh, that's a technology thing, OK? When I do business architecture or enterprise architecture or any kind of architecture, I don't really call myself architecture, I don't really talk about architecture, I really try to help people understand how to connect the dots. The challenge with enabling and encumbering -at the same time business architects - is that if the span of use cases is narrowly defined, then that's the constrained world that they're going to live in. In other words, if I'm an executive, why do I want to talk to a business architect? Are they going to tell me how to plan my business? Their expertise is with IT and trying to help IT figure out what we're doing. So they only need to know enough about what we're doing to kind of coordinate that. In many cases, you'll see the business architects maybe along for the ride if they're in a larger company, they might be talking with business relationship managers who may be closer to the business side and they're matrixed into the business.
And that's one of the entry ways for them to maybe ply their trade and maybe make a larger influence. The challenge, I think, is that the positioning of business architecture when it starts to get into the business arena is the same problem that enterprise architects ran into two years ago and still do. And I think it's part of the way that people perceive the term architecture and also the role of what is that person all about. I can imagine somebody that deals with let's say the project management. PMO, their focus is primarily around portfolios of system process, maybe organizational change. They're limited. They deal with a limited number of portfolios. I can argue that there are upwards of twenty to twenty five core portfolios in every medium to large organization. But the PMO isn't concerned with all of those different portfolios. They only focus on a very small subset. I look at change management experts and folks that are trained in prosy and some of the other change management disciplines that have sprung up on the last number of years because people are trying to figure out how to prioritize all this work and what should we work on next. When we look at the realm of what is business architecture and what impact could it have on organizations, there's a huge number of use cases that we aren't even discussing right now that I don't really hear from the lips of business architects. I think this is part of the challenge.
Whether or not you call yourself a business architect or not is irrelevant. It's more of what's the impact that you think you need to have on an organization. How do you create that quiet leadership that incorporates disciplines around change management, engineering, strategic planning, portfolio management, M&A to say nothing about this whole movement around digital transformation or transformation of any kind? All of these different things have an enormous impact on the areas that are touched upon by business architecture. The key is how do you coordinate all of this? How do you integrate all of this? How do you get your hands on all of it? Yes, there are mapping paradigms that have been put together by business architecture. There are templates and there are scenarios that they've outlined that you can use. The challenge, of course, is the same as enterprise architecture. We need to move it from the paper model to the digital landscape. It's much more aligned with the information and data landscapes that are currently out there in many ways. And I think there's a need for that alignment and that close working relationship, because much of what we talk about in business architecture, whether they're domains, whether they're capabilities, whether they are processes and or products and or services, all of those are subject to long conversations. What do we mean by those terms? So when you start getting into terminology and context, you're now moving into the realm of data, information and knowledge. I think there is a natural opportunity for creating a relationship with some of these different architecture disciplines so that we can clarify the landscape and improve the way we bring these various pieces together through these I'll call them relationships.
The relationships may be instantiated within maps. They might be instantiated in systems and or the data itself. The question is, how do we bring it all together so that if we're trying to figure out something, just change whether it's a policy or it's a system or a customer that isn't happy. Or maybe it's a new opportunity. How does that impact everything with my strategy? How does that impact my existing portfolio of change business systems, technology products, et cetera? How does that impact my operations, my supply chains, my logistics? And if it takes you months to figure that out and hundreds of meetings, then the real question is. Which of these different disciplines really needs to pull that together so they can turn that from months into moments? I think there's an opportunity to architect a lot of that. And it's data architecture. It's information architecture. It's business architecture. And we also need to architect the portfolios of change we don't have project architects. We have project administrators, but architecting portfolio change is not something that project managers and portfolio management PMI really they don't really talk about that. I think there's a there's some missing pieces in there, and I think part of the challenge is that some of those folks have been left out, and because there isn't time to figure it out, we're just going to throw agile at it. And that's sort of where the landscape is today.
I think with project managers, the closest they will come to this level of recognition will be in looking at critical path analysis for project steps and phases. Technical dependencies or operational dependencies are going to generally elude them because that requires a deeper set of knowledge about the organization.