The Canvas Awaits—How Business Models and Business Architecture Fit Together


Get ready for some StraightTalk on a topic we all love: business models. Here in Post No. 26, our shining guest star, Linda Finley, talks about what they are and how they are BFF (Best Friends Forever) with business architecture. This installment is based on our recent interview with her.

Disclaimer: we’ve made some tiny adjustments for our typical StraightTalk-style — the blue headings represent StraightTalk asking the questions and our guest, Linda, responds in turn. The blue italicized text offers additional context and commentary. Make sure to check out Linda’s interview firsthand in our StraightTalk podcast
5-Minutes With Linda Finley.

Start from the beginning. What is a business model?

Linda: “A business model describes the rationale by which an organization creates, delivers and captures value.*” It articulates the value an organization provides, to whom, through what relationships, in which channels, and by what means. A business model is an articulation of how an organization looks—not how it works—which reinforces the purpose for its why.

* Source: Alex Osterwalder, Author of Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (See More Good Stuff below).

The use of business models and the business model canvas has gained a lot of traction over the last few years. How have organizations benefitted?

Linda: Business models bring us back to an organization’s purpose and what business they are in, so the models can be used in all kinds of different ways. Organizations use them just to understand who their customers are, the value they provide to those customers, why that value matters, and how it is delivered relative to the channels, relationships and activities the organization performs. Business models can be used by start-ups and established organizations. We see established organizations leveraging business models when they need to reinvent themselves or conduct a merger or an acquisition. Business models can even be used at the product or initiative level.

P.S. The term “business model” refers to a concept. The term “business model canvas” refers to a popular visual representation of an organization’s business model into nine defined building blocks, as introduced in the Business Model Generation book. (You can just call it a “BMC” if you want to sound like you’re up on the lingo.)

As Linda tells us, business model representation and design are highly useful to any organization, regardless of its size or type. This includes for-profit, non-profit and government organizations (though they may use a slightly different name like “non-profit business model”).

How can business models and business architecture work together?

Linda: Business models are an essential step to first clarify an organization’s purpose which can then be translated into the next level of articulation, which identifies the capabilities, needed to make it real—and that gets squarely into the business architecture. Business models give us a place to start for developing the business architecture. The key activities, resources, partners and other inputs from the business model help give us our first cut at the business architecture. An organization’s business model and business architecture together define how it is structured to deliver its intention. The Business Architecture Guild® has articulated a significant connection between these two concepts as well. (See More Good Stuff for resources.)

Within a strategy execution context (refer back to trusty Post No. 3), think about business models being upstream of business architecture in the first stage where we define our business direction. For a brand new organization, the business model is designed and then the architecture is created as well as all of the enablers like people, process and technology. For an established organization, business architecture can be used to:

  • Inform changes to the business model (and even an entire reinvention of it) through innovative ideas and by helping the organization to perform “what if” impact analysis to test its choices before committing to them.
  • Translate changes to the business model into concrete actions by first identifying and redesigning the impacted value streams and capabilities (and other business architecture perspectives such as stakeholders and products) and then bundling those changes into a logically scoped and sequenced set of initiatives to be executed.
  • Communicate changes to the business model both by highlighting them on the business model canvas as well as through architectural target state diagrams, which provide people with a more specific understanding of what needs to change in their world.

The handy diagram below shows the business architecture perspectives, which are most applicable for each of the nine building blocks on the business model canvas.

Business Models and Business Architecture Domains

One last question. What’s your six-word memoir for business architecture?

Linda: Architecture creates context, context enables understanding.

The canvas awaits your masterpiece. What will you help your organization to become?

More Good Stuff…

5-Minutes With Linda Finley (StraightTalk podcast): Just in case you missed that link right there in the beginning, you can listen to the podcast with Linda on how business models and business architecture relate, which was the basis for this post.

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (Book by Alexander Osterwalder and Yves Pigneur): The book which introduced the business model canvas and methods for creating, assessing and reinventing business models. This one is a classic and a must have.

Value Proposition Design: How to Create Products and Services Customers Want (Book by Alexander Osterwalder, Yves Pigneur and others): A follow-on book from Business Model Generation which specifically focuses on value proposition.

Osterwalder explaining the Business Model Canvas in 6 Minutes (Video): Here’s a six-minute overview of the business model canvas with the guy who created it.

Linking Business Models with Business Architecture to Drive Innovation (Business Architecture Guild® White Paper): A Guild white paper that describes how business models and business architecture work together.

Business Architecture and Business Models (Section 3.3 of the BIZBOK® Guide): Here’s the official word on the topic of business models and business architecture.

Do Some Business Models Perform Better than Others? A Study of the 1000 Largest US Firms (MIT): An interesting piece which introduces business model archetypes. These archetypes are good to be familiar with so that you can help organizations to understand, streamline and even reinvent what they do. Check out Figures 1 and 2 on page 31 in particular.

Don’t Be Afraid of the Blank Sheets (TED Talk): Speaking of canvases, here’s a talk by Ricky Nierva on not being afraid of that blank sheet of paper. “Uncharted waters, this is what it’s all about.”

The Best of StraightTalk 2017

In honor of StraightTalk’s one year birthday this April, we created a compilation of some of your favorite StraightTalk content from 2017. Here’s a link and please feel free to share it with your friends and colleagues: bit.ly/best-straight-talk-2017.

Business Architecture In Action For Risk and Compliance Management — How Business Architecture Helps Organizations Identify and React to Risk and Compliance Challenges

Here in StraightTalk Post No. 25, we’re going to take another look at business architecture in action—this time to help organizations manage risk and compliance. You’re about to have some new fans of business architecture, like your friends in legal, compliance, risk management and audit. Good friends to have.

What’s the problem?

Here are a few common challenges related to risk and compliance management:

 

  • The comprehensive impact of new or changing regulations may be hard to assess.
  • Changes to the business or technology may inadvertently impact compliance or introduce new risks (a.k.a. whoops).
  • There is typically no enterprise level framework for assessing and communicating potential risks and compliance issues.
  • Demonstrating risk mitigation or compliance may be challenging as things are not always written down.
  • Solutions for addressing risk and compliance may be implemented in disjointed ways across products and business units, leading to increased cost and poor customer experiences.

How does business architecture help with all of that?

Business architecture can help our organizations to identify, assess and react to risk and compliance-related challenges. As we know, when things go wrong, whether related to a non-compliance issue or a full-on catastrophe, the results can be damaging to an organization’s operating effectiveness, reputation, and potentially long-term viability.

Here are a few benefits of leveraging business architecture for risk and compliance management:

  • Enable a broad set of impact analysis related to risk and compliance – For example, what if you could quickly identify which regulations would be impacted by strategies and planned initiatives? What if you could quickly understand the enterprise impact that a new (or changing) regulation or potential risk would have on strategies, business units, products, capabilities, value streams and system applications? What if you could quickly identify the related regulations or risks involved before making changes to a capability?
  • Provide an enterprise framework to assess and communicate risks and compliance issues – Why create new frameworks when business architecture already establishes a commonly accepted view of the entire organization, at a high level of detail, with an agreed upon vocabulary? For example, think how useful a capability map and value streams would be for heatmapping where there are potential risks or compliance issues so that we can analyze them to reduce the likelihood and impact of events occurring.
  • Understand and address changing regulatory obligations – Business architecture policy mapping provides a way to comprehensively document external rules and regulations as well as internal ones to increase dissemination and compliance analysis.
  • Provide clarity on how the organization works – It may sound simple, but just giving our friends in legal, compliance, risk management and audit a view of how things really work in the organization—in plain and simple language and at a high level of detail—can be tremendously valuable in itself (and may even help to demonstrate compliance to external parties). They can then choose where to go deep into operating model details to learn more once they have the big picture.
  • Translate comprehensive risk mitigation strategies or regulatory changes into a coordinated set of actionable initiatives – Like any set of business direction, business architecture translates major sets of risk activities or sweeping regulatory changes into initiatives which are uniquely scoped and harmonized with other initiatives across the organization.

Got it. So how do we actually do this?

This is another scenario where for the most part, we use the business architecture knowledgebase to help us analyze, organize and present information to help us deliver on those great benefits described above. The biggie here is that we need to do some policy mapping to make it all possible.

Hint: In the BIZBOK® Guide the definition / domain of “policy” = external policies (e.g. regulations) + internal policies (e.g. business rules)

Here’s a quick recap of how we do this:

  • Step 1: Identify Scope and Goals for Policy-Related Analysis – Clarify what you are trying to achieve and the scope of policies and other domains that should be included within your analysis. For example, are you looking to do a regulatory change impact analysis and if so, how comprehensive would you like it to be?
  • Step 2: Create or Leverage the Minimum Business Architecture Baseline Content – If it does not already exist, create the following baseline content in the business architecture knowledgebase at a minimum:
    • Capability map (one that encompasses the whole enterprise scope).
    • Value streams (a core set of value streams, typically customer-facing, created at the enterprise level without business unit or product specificity).
    • Capabilities cross-mapped to value stream stages.
  • Step 3: Capture Additional Content Needed For Analysis – Capture additional content in the knowledgebase. For example, if you would like to have a rigorous way to analyze the comprehensive impact of ongoing regulatory changes, then you will need to capture the policies you care about and cross-map them to things such as capabilities, business units and products (and also make sure your capabilities are cross-mapped to any other things you may care about such as value streams and operating model aspects such as system applications and processes).P.S.: Team up with your friends as needed to figure out this information (e.g. legal team members for policy information or application architects or owners for system application information).
  • Step 4: Perform Your Analysis – Assess the information you have collected in support of your original goals (e.g. to perform impact analysis, identify potential areas of risk, etc.)
  • Step 5: Visualize the Results, Share Insights and Take Action – Finalize visuals, summarize insights and recommendations, and share with legal, compliance, risk management or audit team members and any leaders as applicable. Work with the leaders and their teams to take action on the results.

One more reminder. In order to “translate comprehensive risk mitigation strategies or regulatory changes into a coordinated set of actionable initiatives,” we need to use business architecture more comprehensively as part of the strategy execution life cycle. More on how we do that is in Post No. 3.

Give me an example.

True story: A new regulation had been introduced related to the readability of documentation provided to customers in a certain industry. Here is how one large organization reacted to this regulatory change, as a case in point. First, only one business unit in the organization identified the necessary change and shared it with other applicable business units, but due to the fact that there wasn’t a methodical way to identify all business units that should be involved, some units were overlooked. Since the business units were siloed, each one that was aware of the necessary change designed their own solution to address the regulation, and of course changed their own processes and systems. The end result was multiple different solutions for the customer to receive their communications electronically by having to navigate to different areas of the website—with one scenario even involving faxing as part of the solution. High tech. From an overall perspective, this led to a poor and inconsistent experience for customers who had multiple products as well as extra cost to build and maintain multiple solutions.

Using this situation as a catalyst to improve, this organization decided to take a business architecture approach for addressing regulatory changes going forward. They documented key regulations (as “policies”) in the business architecture knowledgebase and cross-mapped them to the impacted business units and capabilities. Now when a regulation changes, they consult the knowledgebase to first identify all people who need to be at the table, and then they architect (and invest in) solutions for the impacted capabilities together, leading to integrated and effective solutions both from a customer and internal perspective. That’s a win.

What’s the fine print?

There are similarities here to what we talked about with product mapping in our last installment, No. 25. As described in Step 2 above, you do need a minimum baseline of capabilities and value streams before your policy mapping will be useful. However, remember that Post No. 22 gives us ways to accelerate the creation of our business architecture knowledgebase.

And, the good news is that depending on the intent of your analysis, you may capture varying levels of detail in your policy mapping. For example, you can just capture policy name if that’s as much detail as you need for now versus all of the actual logic contained within the policy.

Of course, here’s a handy summary of all of that.

Business Architecture in Action: Risk and Compliance Management At-A-Glance

Common Challenges

  • The comprehensive impact of new or changing regulations may be hard to assess.
  • Changes to the business or technology may inadvertently impact compliance or introduce new risks.
  • There is typically no enterprise level framework for assessing and communicating potential risks and compliance issues.
  • Demonstrating risk mitigation or compliance may be challenging as things are not always written down.
  • Solutions for addressing risk and compliance may be implemented in disjointed ways across products and business units, leading to increased cost and poor customer experience.

Opportunities with Business Architecture

  • Enable a broad set of impact analysis related to risk and compliance.
  • Provide an enterprise framework to assess and communicate risks and compliance issues.
  • Understand and address changing regulatory obligations.
  • Provide clarity on how the organization works.
  • Translate comprehensive risk mitigation strategies or regulatory changes into a coordinated set of actionable initiatives.

How We Do It

  1. Identify Scope and Goals for Policy-Related Analysis.
  2. Create or Leverage the Minimum Business Architecture Baseline Content (capabilities, value streams and cross-mapping).
  3. Capture Additional Content Needed For Analysis:
    • For example, capture the policies in scope and cross-map them to other domains such as capabilities, business units and products. Also make sure your capabilities are cross-mapped to any other things domains you may need such as value streams and operating model aspects such as system applications and processes.
  4. Perform Your Analysis (e.g. to perform impact analysis, identify potential areas of risk, etc.).
  5. Visualize the Results, Share Insights and Take Action.

Considerations

  • The definition of “policy” in business architecture includes both external policies (e.g. regulations) and internal policies (e.g. business rules).
  • A baseline of capabilities and value streams are a pre-requisite before policy mapping.
  • Varying levels of detail may be captured for policy mapping depending on the intended use.

Download Summary >

More Good Stuff…

Business Architecture Policy Mapping Content (BIZBOK® Guide): Check out Section 2.9 in the BIZBOK® Guide (Business Architecture Guild® membership required) for the official word on the how to map policies and cross-map them to other business architecture perspectives.

Business Architecture Policy Mapping: Little Understood, But Highly Critical (Business Architecture Guild® webinar): A webinar that summarizes policy mapping and its usage. (Business Architecture Guild® membership required.)

Adopting a Systems Thinking Approach for Managing Business Architecture Risks (Presentation): Learn from your friends. A perspective from the European Commission on business architecture and risk management, presented at the Guild Business Architecture Innovation Summit in Brussels, June 2017.

Leveraging Business Architecture For Crisis Management (BrightTALK by William Ulrich): A talk on crisis response challenges at a major financial institution and the role business architecture should play in addressing a variety of related scenarios.

Three Simple, Fun and Effective Tools to Help Manage Risk (TED Talk): A TED talk by Will Gadd, a National Geographic “Adventurer of the Year,” who lives—and survives—epic and dangerous dreams. Here he talks about completing those adventures safely, and helping individuals see the world and themselves differently.

Happy birthday to StraightTalk!

Just one year ago on April 3, 2017, we launched our first StraightTalk blog post. Today, we have subscribers in 18 countries and counting.

To all of you who subscribe, read and share the blog with others—THANK YOU for being on this journey with us. Thank you for your engagement and for the kind words you have shared. It is our joy and honor to continue producing the content that gets to the heart of all things business architecture. Here’s to another great year of StraightTalk and continued growth of the discipline we are all so passionate about!

How can you help? Keep reading and share with a friend! If you know someone who would find value in straight talk on business architecture, here’s a link for them to sign up: bit.ly/ST-sign-up.

Remember that all past installments of StraightTalk are always available for you in our archives, too.

Copyright © 2024 S2E Transformation Inc. All rights reserved.