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, Post No. 24. 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 the 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
- Identify Scope and Goals for Policy-Related Analysis.
- Create or Leverage the Minimum Business Architecture Baseline Content (capabilities, value streams and cross-mapping).
- 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.
- Perform Your Analysis (e.g. to perform impact analysis, identify potential areas of risk, etc.).
- 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.
Here's a diagram summary of all of the above:
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) (see Business Architecture Guild®Public Resources page): 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.