Business Function Matrix

A business function matrix (BFM) is a matrix that documents the business functions that your organization performs and which organizations within the enterprise perform them. The steps to creating a BFM are fairly straightforward:

  1. Document the structure of your enterprise.

  2. Define the business functions your enterprise performs.

  3. Map the business functions to the major organizations within the enterprise.

Creating the BFM might not take very long in a simple business like iMall. In a complex organization, the process might take considerably longer. The U.S. federal government has a BFM called the Business Reference Model that was assembled over the course of several years.

Organizations' units are arrayed along one axis of the BFM. The chief decision is how fine-grained you want to be. It's entirely reasonable to start the process with a high-level, abstract view of the organization and then drill down into more specific information as the IMA process evolves.

The goal of building a business model is to determine what functions various parts of the company are performing. If this were a business book, we'd be concerned with finding out if those activities led to competitive advantage, but that question is clearly beyond our scope. We're merely trying to find out what happens, not decide whether it's the right thing or the wrong thing. Your organization may have already performed a competitive advantage exercise, and in that case, the information about who's doing what will be readily available. In most cases, however that will not be the case, and you'll have to start from the beginning.

In the end, you should have a list of functions that the various organizations in your enterprise perform. This list should give the function a name, organization that performs it, and contain a brief description. In many cases, the description will be a list of subfunctions. Some of the functions may seem very similar to functions performed elsewhere in the organization. We'll normalize this list later.

Build the function list by talking to members of the various organizational divisions and asking the following kinds of questions:

  • What is the business of your organization, team, or group?

  • What tasks does your organization, team, or group perform?

  • How do the tasks your organization, team, or group performs contribute to the function of the group or organization you belong to?

As you work your way through the organization, divide each function into subfunctions by decomposing it into smaller steps. "How do you...?" is a good question to ask to get the answers that lead to decomposition.

Remember that our goal is to understand the business and how identity is used in support of business goals. As you perform the functional decomposition, make note of any functions where identity information or activities are being used. This information will be helpful in understanding identity processes that business units use to accomplish their function.

There are a few caveats:

  • Organizational names are not necessarily good indicators of the functions that the organization performs. For example, "Finance" isn't a function. If you asked people who work in the finance department what they do, they probably won't say "finance." They'll talk more about the tasks they perform.

  • Many of the tasks people perform are not functions in the sense we care about either. Examples include sending email, writing memos, and so on. You should steer people toward the reason for sending the email or the business function of the memo or spreadsheet.

  • Functional decomposition does not necessarily follow the organizational chart, so don't be caught up in the organization so much that you lose the functional model. Cross-functional product teams who come from many disciplines to build, deploy, and maintain a product are a good example of where organization and function do not match. The product team may not show up in a formal organization chart, but their function is a crucial part of the business.

  • Keep in mind that you're not trying to determine workflow or do business process modeling. The scope of those tasks is far greater than what we're after here and will mire the IMA team down.

As we said earlier, the BFM is a matrix that maps organizations to the functions they perform. The reason we treat it as a matrix rather than a simple hierarchy, as the results of the last section would suggest, is that more than one group in the enterprise often carries out similar functions. To get a matrix, we must collapse similar functions into more general descriptions and combine definitions where appropriate. I call this process "function normalization." As you do this, and keep track of which organizations are performing the functions, you'll find that the matrix creates itself.

One of the things you'll find is that multiple organizations inside the enterprise perform the same function by description, but they do it in different ways, as indicated by the subfunctions. There are two possibilities:

In the first case, the function can be completely collapsed, after the two subfunction trees have been normalized.

The second case is both frustrating and the reason for doing this exercise. Our job is not to change either business unit so that they use common processes for performing the same functions, but to document what actually happens. This information will be useful when policies are created or systems are being implemented. At that point, the CIO or another appropriate manager may want to initiate discussions about whether these processes can be normalized, but we must accept the fact that often they will not be, and the IMA and related infrastructure will have to accommodate the differences.

Our ultimate goal is to create an identity management architecture and digital identity infrastructure that supports the business. Detailed functional data about how different business units accomplish similar functions in different ways is crucial to creating an IMA that will be used by the business and adds value. Imagine not creating the business model and then finding this out after you've spent a lot of money creating an infrastructure that supports one way the business does something but not the others. That's what causes many IT projects to take longer than planned, cost more than budgeted, or outright fail. Having a good business model helps avoid these issues.