Back to business architecture school one more time. In Post No. 12, we talked about how to map out (a.k.a write down) the “core” business architecture that included capabilities, value streams, organization and information. Here in No. 13, we’re going to talk about mapping the “extended” business architecture domains.
Here’s that famous diagram again, this time with those “extended” business architecture domains highlighted in sienna (brown) for reference.
Okay, explain. What are these “extended” business architecture domains?
Once you have the core business architecture in place, you may want to seriously consider expanding your knowledgebase to include extended business architecture domain content. Each of those domains is listed below along with some hints on what they are all about and key interpretation points that you will only get from reading the fine print in the BIZBOK® Guide. But here you go because this is StraightTalk. (You’re welcome.)
- Strategies – Key point: all business direction from visions, strategies and tactics boils down to one thing in the business architecture knowledgebase: the “objective.” Objectives are the concrete thing to which you’ll connect your value streams and capabilities.
- Policies – In the BIZBOK® Guide, we group both external perspectives (like regulations) and internal ones (like internal policies or business rules) into one thing called a “policy.”
- Stakeholders – Stakeholders can be internal or external (like customers and partners). BTW, stakeholders in business architecture are mapped at a higher level of detail than what you’d typically think of for roles.
- Products – These are the things your organization provides to its customers (or constituents or whatever you call the people who you serve). You can use either term, but for simplicity, the BIZBOK® Guide typically refers to both products and services together as “products.” Super important: some people refer to various things internally as “products” (e.g. what IT delivers), but when you map your products, they must represent an external perspective otherwise you will cloud the enterprise view you are after.
- Metrics – There are two things to keep in mind here. 1. When related to objectives, capabilities, value streams and initiatives, metrics can be used to assess business performance and initiative results. 2. Business architecture also contributes some additional metrics to capture various aspects of business effectiveness as it pertains to capabilities and value streams.
- Initiatives – For simplicity, the BIZBOK® Guide uses “initiative” to encompass all concepts including programs, projects, etc. When changes are needed to any aspect of the business architecture, they are delivered through initiatives.
P.S. See the BIZBOK® Guide for official definitions on each of these domains.
Anything else?
Yes. We also need to create relationships between (a.k.a. “cross-map”) each extended business architecture domain to the core domains—to the value streams and capabilities in particular. For example, we would cross-map policies to the value streams in which they are applicable, and to the specific capabilities within those value streams.
We can also map the extended domains to each other as well when we have a good reason to do so.
This is of course all done in our business architecture knowledgebase.
P.S. Remember that you can geek out with the “metamodel” in Appendix B.4 of the BIZBOK® Guide that tells you how all of these business architecture pieces relate to each other.
And why do we care about all of these extended domains?
Here are two big reasons.
- Connecting strategy to execution – Business architecture is the only discipline that provides us with the ability to trace from an objective, through the business architecture (first to impacted value streams, then to their stages, then to the applicable capabilities within those stages), and down to the initiatives that make them real. This idea is called (big fancy word alert): “traceability.” Having this traceability allows us to do things like understand if the results an initiative delivered actually met the business objectives and metrics that it promised in the first place. Or, let’s say a business objective is no longer a priority, we can quickly identify all of the initiatives that are executing on it and put them on hold.Here’s a handy diagram that shows that whole “traceability” idea.
- Killer impact analysis – Just like that “butterfly effect” we were talking about in Post No. 12, if we want to know the impact of a potential strategy, a new product, a regulatory change—anything—as long as we can identify the value streams and capabilities impacted, then we can follow them through to understand the full of the change on the rest of the organization. When we have our extended business architecture domains documented in our knowledgebase, we greatly increase the scope and usefulness of this analysis because we can identify impacted stakeholders, products, policies, objectives, metrics and initiatives.
This is a lot of information to capture. Are you serious?
Yep, but here’s the secret. Document your extended business architecture domain content opportunistically. Capture the information just in time and just for the scope you need in order to support how you are currently putting your business architecture to use. Of course the idea is that you continue maintaining the content you document along the way so that you can reuse it going forward.
For example, let’s say you begin working with a product manager in your organization to help them translate their product strategy into initiatives. Assuming you already have your core business architecture in place, for this scenario you would expand your knowledgebase to document the relevant objectives, the products within the product manager’s scope of control (and maybe any other products likely to be impacted), as well as any relevant initiatives.
However, if you are in the rare situation where you do have management support and loads of time on your hands to build out your whole business architecture knowledgebase at one time, then more power to you.
Where does this information come from?
As with all of your business architecture, it should be created collaboratively with the business. Business people provide the subject matter expertise and “own” the business architecture content, while business architects “steward” it on their behalf.
You may find yourself working with many different people across business units to document the extended business architecture domains, like strategists, product managers, various business subject matter experts, legal and compliance team members, and planning team members.
I think I understand how to map out the business architecture now. What next?
To summarize Posts No. 12 and 13 then, map your core business architecture domains first with a focus on value streams and capabilities, and then map your extended business architecture domains opportunistically (and cross-map them to the core).
As you continue to build out your business architecture knowledgebase over time, you can also map other non-business architecture domains to it, like system applications, processes and requirements. This involves working with other teams and is typically approached opportunistically as well.
AND, as always, we should be continually using our business architectures to create value for our organizations. That is the reason why it exists. As the wise words from J.R.R. Tolkien’s, The Hobbit, tell us, “The world is not in your books and maps. It’s out there.”
More good stuff.
What is Business Architecture? (S2E white paper): Still relevant to this topic. Just in case you missed it, this white paper is a really handy one that breaks down what business architecture really is and is not.
Introduction to Business Architecture (Part 1 of the BIZBOK® Guide from the Business Architecture Guild® located on the Public Resources page): The introduction from the BIZBOK® Guide which overviews business architecture, openly available to everyone.
Business Architecture Policy Mapping: Little Understood, But Highly Critical (BA Guild webinar): A good walk through of policy mapping (requires Guild membership to download).
Just for fun. Geek out with maps.
- The History of the World’s Civilizations in 2 Minutes – Time elapse video of the history of the world in just 2 minutes. Now that is serious StraightTalk.
- Human Population Through Time – Another cool time elapse video
- The World’s Immigration Flows, Country by Country – And another.
- Interactive Map of Global Wind, Weather and Ocean Conditions – You have to love this one.