Demystifying An Organization: The Business Architecture Take on Organization Mapping

In this installment of StraightTalk, we will break down the concept of organization mapping through the business architecture lens. Organization is one of the ten domains of business architecture (per the BIZBOK^® Guide) – in fact it’s one of the core domains – but it might be helpful to have a guided tour through some of the ins and outs, including the intent of organization mapping and its technique – one of StraightTalk's strong suits.

Okay, what is organization mapping?

From a business architecture perspective, organization mapping is a representation of an organization’s business units (including how they decompose into sub-business units) and their relationships to other business units and other things such as capabilities. We know that a business architecture should represent the scope of an entire organization and the ecosystem in which is operates, so that means the scope of organization mapping should encompass the same.

The intent of organization mapping in business architecture is not to replicate the org chart. For example, org mapping does not include people, titles, or hierarchical management structure. It just shows business units and relationships. As a result, it can be quite useful for bringing transparency to how things really work without the politics.  

P.S. Here’s the official definition of an organization map from the BIZBOK^® Guide: “An organization map is a business blueprint that depicts business units, organizational decomposition, and other types of organization-oriented relationships (beyond the traditional hierarchical view).”

What do you mean by business unit?

Even though the domain is called organization, the component that we focus on in the business architecture is primarily the business unit. The BIZBOK^® Guide mapping technique includes three types of business units:

• Internal Business Units – These are the internal business units within your organization that would typically come to mind. Your organization may call them different things (e.g., divisions, departments, units, etc.), but in business architecture we refer to them all as business units.
• External Business Units – These are partners of any type such as your vendors, strategic alliances, regulatory bodies, etc.
• Collaborative Teams – These are your informal structures such as true collaborative teams, steering committees, governance bodies, councils, teams (including agile teams), etc.

The fact that we can include these three different types of business units in our mapping greatly expands its usefulness. We can support many different business usage scenarios and a broad range of insights – all from an apolitical lens.

How are business units different than stakeholders?

Here are a few pointers to help you differentiate them within the business architecture:

• Business units are based on actual structures where stakeholders are abstractions.
• Business units are groups of people related to functional or organizational structures where stakeholders are individuals. For example:
  • An internal business unit might be P&C Claims and a stakeholder might be Claims Adjuster.
  • An external business unit might be ABC Consulting Firm and a stakeholder might be Auditor.
• Stakeholders do belong to business units, internal or external, and you can make that relationship in your business architecture knowledgebase.

P.S. Post No. 70 has you covered with the scoop on stakeholders.

What about functions?

The concept of a function does not exist within the BIZBOK^® Guide and it is not included as one of the ten domains of business architecture. This is intentional as organizational structure is intended to be represented through the business units and beyond that functions tend to be groupings of capabilities (which is why the capability map is based on business objects versus functions, so that capabilities are not duplicated – see this diagram for an example).

What information do we capture as business units?

This is one of those domains where we capture actual information. Business units are not abstractions like we would create with our business subject matter experts for capabilities, value streams, information, or stakeholders. (Check out this handy diagram for a bird's-eye view of the sources of content for all domains.)

So, for example, if your organization calls a business unit “P&C Claims,” or “Internal Audit” or “Transformation and Integration Office,” then you will capture those names exactly.

BTW, if your organization mapping reveals that perhaps your organization is not optimally structured (e.g., multiple business units are redundantly performing the same capability), you still represent the exact current state. Do not abstract or adjust your organization mapping to make things look better. The entire point of org mapping is to provide transparency and clarity so that we can understand the organization’s structure today and identify opportunities to improve or transform it when applicable.

Where does the business unit information come from?

Business unit information typically comes from the following sources:

• People – People can tell you which business units exist (of all three types) and provide attributes such as a description, which is oftentimes not available otherwise.
• Documentation – You can leverage a variety of source documents to identity business units and their relationships.
• Systems – You may feed business unit information into your business architecture knowledgebase directly from a system that is the source of record.

A word to the wise: While getting a feed of business unit information from a system sounds like the best way to go, it can often be overkill when you are starting out. Also keep in mind that even if you do source business unit information from a system, you will need to keep it up to date and there will be information you need to gather that cannot be obtained from a system (e.g., partners, informal structures and their relationships to internal business units).

How much business unit detail should we capture and for what scope of the organization?

As always, once you have established your business architecture baseline (i.e., capabilities based on defined information concepts, value streams, and a cross-mapping between the two), then we capture the rest of the business architecture content just enough just in time to support how we are planning to use it to deliver business value. So, the answer to how much scope and detail you should capture for business units depends on how you are planning to use your organization mapping right now.

For example, if you just want to do some high-level impact analysis, then perhaps you only capture the top level of business unit detail for the entire organization. If you want to bring clarity to how the organization is structured, perhaps you go another level or two down in detail. On the other hand, if you are focused on a business scenario related to one business unit, perhaps you do a deep dive to capture many levels of internal business units and also capture external business units, but just for the scope of that business unit.

So how do we do it?

There are two parts, one required and one optional:

1. Capture business units within your business architecture knowledgebase (this one is required)
2. Create visual representations of business units to support your business usage scenarios when applicable (this one is optional)

To capture business units within your knowledgebase…

1. Determine the scope and level of detail you are going to capture now.
2. Collect business unit names and capture them within your business architecture knowledgebase.
   • Keep in mind that organization mapping is anchored by the concept of an enterprise (business unit level 0 per the BIZBOK^® Guide) and then business units decompose from there.
3. Capture attributes for each business unit, including their type (i.e., one of the three described earlier) and a brief description.
4. Cross-map business units to the capabilities they have and create other relationships as applicable (e.g., to stakeholders).

To create visual organization map representations…

1. Determine a clear purpose and focus for your organization map. (If you try to represent everything, the diagram can quickly expand to fill up a large space.)
2. Determine the scope and level of business unit detail you will need based on #1.
3. Capture the necessary business unit information within your knowledgebase (see step above).
4. Create your organization map view(s) that is oriented around your purpose and articulate specific insights.

Is org mapping still useful even if our organization restructures frequently?

Yes, and perhaps even more so. Organization mapping can help bring visibility and attention to the frequent restructuring, and can clarify the scope of the restructuring and its impact. An org map is very useful for communicating changes.

Organization mapping and the business architecture knowledgebase can be a powerful tool when used prior to restructuring as well for comprehensive impact analysis and to uncover opportunities for improvement or change.

How can we use organization mapping for business value?

Here are just a few common usage scenarios, hopefully to inspire many more ideas of your own.

• Organizational clarity and transparency – Leverage organization maps simply to communicate the current structure that is in place. This is helpful not only for new employees and partners, but also to provide everyone with a clear, shared understanding of the organization. This can be helpful at any level, including the very highest level for an organization that encompasses multiple entities (e.g., think about representing all operating companies within a parent company or representing all agencies/departments for a government).
• Organizational design and effectiveness – Analyze an organization map (including its connections to other business architecture perspectives such as capabilities) to uncover opportunities for improvement (e.g., redundant capability enablement, excessive committee or governance structures, etc.).
• Outsourcing decision-making – Leverage the organization map to bring visibility to outsourcing and identify opportunities for improvement. For example, which capabilities are we outsourcing? To which partner(s)? Do multiple business units outsource to the same partner and if so, are we receiving the best pricing/volume discounts? Do we have opportunities to consolidate partners?
• Impact analysis – Leverage business units as a key perspective for impact analysis. For example, if a policy changes (e.g., external regulation or internal policy), you can identify the capabilities impacted and follow them through to the business units that will be impacted as well. As mentioned earlier, also use business units and the rest of the business architecture knowledgebase to assess the impact of potential organizational changes and restructuring to the entire business and technology environment.

 And here’s a handy diagram that summarizes those usage scenarios and helps you visualize what org map looks like.

An Overview of Organization Mapping

Downloadable Media

Happy mapping and discovery!

More Good Stuff...

Sections 2.3 of the BIZBOK^® Guide (Business Architecture Guild^®): The full story on organization mapping from the source: the BIZBOK^® Guide. (Business Architecture Guild^® membership required.)

Organization Mapping (BA Guild webinar): A Guild webinar that describes organization mapping. (Business Architecture Guild^® membership required.)

What Explains the Rise of Humans? (TED Talk): A brilliant TED Talk by the one and only Yuval Noah Harari, best-selling author of Sapiens and Homo Deus and more. He articulates the real difference between humans and all other animals. Where humans differ is not on the individual level, but on the collective level. “Humans control the planet because they are the only animals that can cooperate both flexibly and in very large numbers.”