We’ve been very business-focused in our StraightTalk so far—and intentionally so. But a business architect always has a foot in two different worlds: one as part of the business and the other as part of the enterprise architecture team.

P.S. Remember our formula for one happy family from StraightTalk Post No. 1:

Enterprise Architecture = Business Architecture + IT Architecture (where IT Architecture = Application Architecture + Data Architecture + Technical Architecture).

So, for the next two posts, we are going to focus on how business architecture relates to IT architecture, and we’ll see how these two really are BFF (Best Friends Forever). Business architecture provides the business context and direction, and IT architecture makes it real through automated solutions.

But wait, there’s more. We’re introducing guest stars on StraightTalk! From time to time, we’ll be joined by some experts who will StraightTalk with us on their areas of expertise to broaden our perspective. We are starting with Mike Rosen, a highly respected industry leader who has served in many different architecture and leadership roles.

Here in Post No. 14, Mike gives us the straight talk on business and enterprise architecture. This post is based on our recent interview with him. Disclaimer: we’ve made some tiny adjustments for our typical StraightTalk-style: the gray headings represent StraightTalk asking the questions and our guest, Mike, responds in turn. Make sure to check out StraightTalk podcast 5-Minutes With Mike Rosen.

So what is enterprise architecture?

Mike: Fundamentally architecture is a representation of concepts and relationships in a context. For enterprise architecture, the context is the entire enterprise. Then to get our head around the big picture, we break the enterprise into domains like business, information, application, and technology.

P.S. Those are the traditional domains but Mike usually adds performance, security, service, and integration, which are new concepts required for digital enterprises.

Since we’re all about business architecture here at StraightTalk, how does it fit within enterprise architecture?

Mike: Business architecture is a critical aspect of enterprise architecture because it formalizes the enterprise strategy and goals, and translates them into specific business concepts such as capabilities, value streams, information and so on—and then these concepts can be mapped down to other IT-related concepts like system applications and infrastructure.

P.S. You know we like diagrams. Here’s a good one showing business architecture within the context of the other enterprise architecture domains.

Just because we know it’s on some people’s minds, what are some of the popular enterprise architecture frameworks out there that are used?

Mike: The popular frameworks haven’t really changed much in the last decade, like TOGAF (The Open Group Architecture Framework), DoDAF (Department of Defense Architecture Framework) and the Zachman Framework. But that’s really the wrong question to ask.

What question should we be asking?

Mike: We should be asking how architecture teams are influencing decision makers with architecture, not how they are building deliverables that may or may not be relevant. Creating architecture delivers no value—the value is only realized when architecture is used to influence decision-makers.

Agree. When people use those enterprise architecture frameworks, how do they integrate with the business architecture framework, which is, of course, the BIZBOK^® Guide?

Mike: All of the enterprise architecture frameworks address business architecture as a domain. But most were developed before business architecture matured to the point it is at today. The BIZBOK^® Guide provides guidance on business architecture that can be easily integrated into other frameworks and approaches. And because the BIZBOK^® Guide is principle-based, it focuses more on achieving results than on a specific structure.

And great news, the Business Architecture Guild^® is working closely with the Open Group to integrate BIZBOK^® Guide concepts and principles into future versions of TOGAF.

How do the various types of architects work together?

Mike: Typically architects focus on their domain and then work together through some sort of formal review board structure or a less formal community of practice to make sure that what they are doing fits together.

Hot topic, but we have to ask. Is there a separate role for an enterprise architect and if so, how does that role interact with other business and IT architects?

Mike: Business architects often report through a business unit rather than IT. That’s a really good structure, but when that is the case it’s important to understand how we align them.

Really successful architecture follows the principle of “think globally act locally.” So, the enterprise architect is responsible for the global view and how all of the pieces fit together. Business architects have the business perspective of capabilities, value streams and so on, and IT architects have the perspective of applications, infrastructure and security—and then hopefully they all have a shared perspective on the information. So, within the local context of an initiative or project all of the architects work together to bridge the tactical concerns of the project and the strategic concerns of the architecture.

Got it. Anything else?

Mike: Well, it’s really fake news that doing architecture takes longer. When architecture is done right, projects that use it are more successful, more evolvable, closer to on-time and on-budget, and have fewer issues. And the enterprise builds reusable assets instead of redundant liabilities. Unfortunately, the idea that architecture makes things take a long time is a stereotype that we need to overcome.

You know we love six-word memoirs. If enterprise architecture were to have a six-word memoir, what would it be?

Mike: Architecture’s value is influencing decision makers.

---

More good stuff.

5-Minutes With Mike Rosen (StraightTalk podcast): Just in case you missed the link in the beginning of this post, you can listen to the podcast with Mike Rosen on understanding business and enterprise architecture, which was the basis for this post.

Business Architecture: Putting “Business” into Enterprise Architecture (CIO Review article by William Ulrich and Richard Soley): A concise piece on why business architecture is an essential component of enterprise architecture.

Enterprise Architecture Definitions (FEAPO): Important stuff here. These are the official definitions for enterprise, business, application, data and technical architecture, ratified by all FEAPO (Federation of Enterprise Architecture Professional Organizations) members, which together represent a very large number of practitioners worldwide.

Business Architecture and IT Architecture Alignment (Part 6 of the BIZBOK^® Guide): Here’s the official word on the topic of business and IT architecture alignment. Section 6.2 has a specific focus on how to align business architecture with other enterprise architecture frameworks (requires Guild membership to download).

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.)

• Vision, Strategies and Tactics – 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, Rules, Regulations – 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 and Services – 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 and Measures – 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 and Projects – 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^®): 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.