Making the Grade: Assessing Business Architecture

In this installment, StraightTalk Post No. 28, we are going to look at a topic of increasing interest and practice: business architecture assessments.

What are we talking about here?

Performing business architecture assessments is the idea capturing various metrics about an organization’s business architecture, which can then be assessed to identify improvement opportunities and make other decisions such as where to invest.

Many people just do assessments for capabilities (which is why you typically hear this topic referred to as “capability assessments”), but consider going for the “A” and assess your value stream stages in addition to your capabilities.

What kinds of things do we assess?

Simply stated, we look at two categories of metrics: “How well is it working?” and “Why do we care?”

When making decisions, it is important to consider metrics in both of these categories because together they provide the full context of the situation. For example, a certain capability may be highly ineffective, but if it is rarely used by a small group of people internally, then perhaps it is not the highest priority for investment right now.

The BIZBOK® Guide discusses four metrics: Business Breadth, Business Impact, Business Effectiveness and Automation Level. However, these are not the only metrics that exist or that business architecture teams use, so consider what makes the most sense for you.

Here’s a quick overview of some “Why-do-we-care?” metrics:

  • Business Breadth – The BIZBOK® Guide describes this as “how widely a capability is used across the business based on the number of times it appears across multiple stages of multiple value streams.”
  • Business Impact – The BIZBOK® Guide describes this as a “rating relative to the impact that capabilities and value streams have on the business operations…A capability is of high impact when success or failure of that capability has significant ramifications to the business.”
  • Strategic Importance – This is an additional metric that some business architecture teams use to indicate a capability as being within one of four quadrants such as strategic, advantage, necessity or essential.
  • Strategic Priority / Strategic Differentiator – This is an additional metric along similar lines to the one above, though this metric simply captures a “yes” or “no” answer. Both of these metrics make it crystal clear what a capability currently means to the organization in terms of strategic relevance (which may change over time). Neither the first two metrics nor the tiers of a capability map completely provide this clarity, which is why some teams capture one of these last two metrics as well.

Here’s a quick overview of some “How-well-is-it-working?” metrics:

  • Business Effectiveness – This BIZBOK® Guide metric assesses the quality of capabilities and value streams. Some teams take this a step further and break down “effectiveness” into various components for rating. You can also refer to actual business performance metrics like revenue, cost, customer satisfaction, etc. You have a lot of options on this one.
  • Automation Level – The BIZBOK® Guide describes this as the “degree of automation associated with current state capabilities and value stream stages.”
  • Progress Towards Target State – This one can be tricky to capture, but provides very useful information. It essentially indicates progress towards a defined target state. Of course, that means you will need to define the “target state,” which can indeed be a moving target as your organization changes and grows. This concept also relates to initiatives and roadmapping.
  • Capability Maturity – Some teams use this metric based on maturity model frameworks, but it does not always yield useful results. In addition, it requires many different frameworks and trying to map them all to your capability map. This one falls into the category of “good to know,” but there are better alternatives. People often are looking for Progress Towards Target State when they ask about assessing “capability maturity.”

Here’s a handy diagram to summarize all of that for you:

Assessing Business Architecture

Sounds good. So how do we do it?

Here’s just a quick overview because this is StraightTalk after all:

  1. Determine the purpose and scope of your assessment.
  2. Define the metrics to be captured and define your methods (e.g. how will you calculate and roll things up).
  3. Collect assessment information.
  4. Capture assessment information in your business architecture knowledgebase.
  5. Create views (e.g. heatmaps), visuals, reports and presentations as needed.
  6. Communicate results and act on decisions.
  7. Keep the assessment information updated over time (e.g. if an initiative makes a change that improves the Business Effectiveness or Automation Level score).
  8. Repeat as needed.

Where does the assessment information come from?

Sometimes you can use the actual data where it is available, but for the most part, the ratings will come from conversations with the business people (potentially across functions) who are closest to the situation.

Involving business people is a smart way to go, not only to capture the most accurate information, but because having their ownership and partnership is essential—especially in situations where things may be rated as ineffective today.

When do we do the assessments?

You can either assess your business architecture upfront or assess it as you go. For example, if you are translating a strategy into a set of business architecture changes, this would be a good time to assess the capabilities and value streams impacted by the scope of that strategy.

Regardless of when you do the assessments, any information you capture becomes a part of your reusable business architecture knowledgebase that you keep up to date over time.

How detailed do we get in these assessments?

Million-dollar question. It does indeed depend on what results you are looking for.

“Detail” is a factor of:

  • What metrics you decide to capture (how many of them and how detailed you go on each).
  • What level of detail you are assessing—the capability overall or the capability instance.

Always keep things as simple as you possibly can and make sure that anything you capture is contributing to the information you really need.

Back up. What is “capability instance?”

The BIZBOK® Guide defines a capability instance as “a specific realization of a capability, as it exists or as it is envisioned to exist, in the context of a given business unit, value stream stage, or other situational context.”

You can think of it as a capability’s “plus one.” A capability instance could be that capability for a certain value stream stage, that capability for a certain business unit, that capability for a certain product, etc.

The concept of capability instances becomes very important within the context of business architecture assessments because they provide the level of granularity that is often needed for solid analysis and decision-making. For example, a capability may be working effectively within one business unit but highly ineffective within another.

How do we use the business architecture assessments?

Here are a few ideas:

  • Leverage them during top-down translation of business direction – For those capabilities impacted by a strategy (or other business change), you can assess how well they are working today and if we need to address any issues before leveraging them.
  • Analyze them to identify improvement opportunities – Any potential improvements you identify may be input to new or existing initiatives.
  • Create a quick ranking for current or proposed initiatives – For example, using the four BIZBOK® Guide metrics, you can obtain a directional score for the subset of initiatives that are the highest priority and most ineffective to target for further analysis.
  • Represent the current and target state of capabilities – Representations may be created for a specific scope (e.g. a business unit) and/or collective views across the enterprise.

Anything else?

Be aware that there are some cases where things are not entirely straightforward. For instance (no pun intended), a capability may be assessed as highly effective for each business unit instance—but when you consider the bigger picture, the overall capability may not be as effective. Example: A capability such as Customer Information Management could look good from an individual business unit perspective, but if the information is replicated across each business unit, this may lead to a fragmented view of a customer and suboptimal customer experiences.

Also, an automated business architecture knowledgebase tool can be really, really helpful here to capture and leverage all of this information, especially if you are working at the capability instance level.

Happy assessing!

More Good Stuff…

Business Architecture Assessment Content (BIZBOK® Guide): Check out Section 2.2 on capabilities and Section 3.7 on business performance management in the BIZBOK® Guide (Business Architecture Guild® membership required).

Using Capability-Driven Assessments for Strategic Planning Case Study (Principal): Learn from your friends. Here’s a talk from the 2015 BA Guild Business Architecture Innovation Summit on using capability assessments.

A Few Great Books On Business Performance: Check out some of these classics to inform your perspective:

Hey Science Teachers—Make It Fun (TED Talk): A TED Talk by Tyler DeWitt on the power of story in teaching. There are some good parallels for socializing business architecture here—including his reference to a quote by famous architect Mies van der Rohe: “Sometimes, you have to lie in order to tell the truth.”

Making a Global Impact–Whynde Kuehn Presents to Principal Financial Services

On May 8, 2018, Whynde Kuehn, Founder and Managing Director of S2E Transformation Inc. was an invited speaker at Principal Financial Services, Inc. on the topic of volunteerism. She presented a talk entitled, “Making a Global Impact.” Kuehn demonstrated that individuals have the power to make a global impact. The ripple effect one person can have on an organization, a community, a nation—our world—is immeasurable and truly possible at this unique point in history. Whynde shared her story of how she has personally woven together work, life, adventure, and service to others into one journey of continually increasing impact. Most importantly, she discussed how individuals can make a global impact now from any place on the planet, and share some practical ideas for moving into action.

Principal Financial is committed to promoting volunteerism throughout the company by enabling a network that is made up of company employees that actively seek to contribute and improve quality of life in their communities.

Whynde Kuehn on Making a Global Impact
Whynde Kuehn, S2E Transformation Founder, speaking on“Making a Global Impact” at Principal Financial Services.


Being on the SAFe Side: How Business Architecture and Agile Fit Together

StraightTalk has another BFF and it is agile. Here in Post No. 27 we will talk about a hot topic with our guest star, Alex Randell, who gives us the straight talk on what all of this agile stuff means and how business architecture can help. This post is based on our recent interview with him.

Disclaimer: we’ve made some tiny adjustments for our typical StraightTalk-style — the blue headings represent StraightTalk asking the questions and our guest, Alex, responds in turn. The blue italicized text offers additional context and commentary.

Make sure to check out Alex’s interview firsthand in our StraightTalk podcast 5-Minutes With Alex Randell.

Let’s start with the basics. What is agile? What is SAFe?

Alex: “A lot of people are familiar with agile, in many different ways and with many different methodologies. The short version is that agile is an incremental approach to delivery, often focused on software delivery.

SAFe stands for the Scaled Agile Framework.® It is a focused methodology that aligns multiple agile teams as a way to scale an agile approach. Typically this is done in support of common themes and strategies. The SAFe framework and the additional levels that are included in the methodology provide us with additional opportunities to apply more advanced business architecture concepts around strategies and initiatives.

BTW, business architecture can help with any form of agile.”

What are some benefits of agile approaches?

Alex: “I’ve seen a couple key benefits in particular.

One. Agile approaches seem to pull the IT areas and the business closer together. We are increasingly seeing a blurring of the line between “business and IT.” In part the technical resources, often using agile methodologies, have driven this blurring by becoming better versed in what the business is trying to deliver and how the technology supports it. An additional consideration is how business resources need to become more technically proficient as well.

Two. Agile teams seem to have greater ownership, greater mastery and greater focus on the work that they are assigned. This is a common benefit of agile. As the teams become more empowered with ownership of the technical aspects of the business, they also naturally become more focused and accountable for business results.”

How does business architecture work with and provide benefit to agile development?

Alex: “In its simplest form, agile is about getting things done—and business architecture helps us get the right things done. While business architecture focuses on the business, its strategy and how to approach business transformation, agile teams are the mechanism that takes the handoff from business architecture’s strategy to execution methodology and delivers on those business results.

By using the framework that business architecture provides, agile teams can better:

  • Identify their work through capability assessments and heatmapping
  • Align their work to the value streams and the capabilities of the business
  • Measure their results using the business performance framework

In turn, agile teams can provide business architects with a line of sight to the front lines and the experiences of customers and internal stakeholders. This insight can be invaluable to business architects by allowing them to see the real world application of the strategies they facilitate and the framework they develop.”

See below for a handy diagram which shows where business architecture fits within the SAFe framework.

Business architects work at the portfolio level and focus on:

  • Informing prioritization
  • Providing business context and framing for work
  • Providing a common vocabulary and mental model
  • Connecting dots across the enterprise related to business direction and initiatives

Business Architecture and SAFe

Some people have concerns that business architecture may slow down the agile development process. How would you respond to this?

Alex: “Agile is great at getting beyond processes with a focus on working software from the Agile Manifesto. Applying business architecture does not—or perhaps should not—get in the way of that progress. Rather, business architecture applied to agile programs helps teams by setting a foundation, focusing them on the highest priority capabilities and work, and assuring alignment to strategies of the business.

So, does business architecture slow down agile teams? Not if applied correctly. Business architecture doesn’t get in the way of the team, but rather works alongside to help them be best focused and prepared—which speeds things up rather than slowing them down. And, it ensures that the agility and the success of the team is applied to the highest value parts of the business.

You know we have to ask. What’s your six-word memoir for how business architecture benefits agile approaches?

You know we have to ask. What’s your six-word memoir for how business architecture benefits agile approaches?

Alex: “Business architecture, one of Agile’s BFFs.”

Anything else?

Alex: “The story really isn’t complete. Even though we’ve been working on agile and business architecture for years now, we’ve really just started writing the story. Business architecture and agile are two exciting parts of our world, and there are many opportunities to contribute to the thought leadership, methodologies and stories of success related to how they align and benefit our organizations.”

More Good Stuff…

5-Minutes With Alex Randell (StraightTalk podcast): Just in case you missed that link right there in the beginning, check out the podcast where Alex talks to us about how business architecture and agile approaches relate, which was the basis for this post.

Leveraging Business Architecture to Improve Business Requirements Analysis (Business Architecture Guild® White Paper): A Guild white paper that describes how business architecture and requirements work together.

Business Architecture and Agile Methodologies (Business Architecture Guild® White Paper): A Guild white paper that describes how business architecture and agile methodologies work together.

Aligning Business Architecture and the Scaled Agile Framework® (Business Architecture Guild® White Paper): A Guild white paper that reconciles the terms value stream and capability between business architecture and SAFe.

Requirements Team Blog (Business Architecture Guild®): Some fantastic posts from Guild members on business architecture and agile approaches.

From Strategy to Agile Stories: An Epic Journey (Business Architecture Guild® webinar): A great webinar on business architecture and SAFe. (Business Architecture Guild® membership required.)

Business Architecture and Requirements Alignment (Section 3.8 of the BIZBOK® Guide): Here’s the official word on the topic of business architecture and requirements. (Business Architecture Guild® membership required.)

SAFe 4.0 in 5 Minutes (Video): Here’s a quick animated video introducing the Scaled Agile Framework (SAFe), version 4.0.

5 Non-Agile TED Talks About Agile (TED Talks): Here are five great talks that were not originally about agile concepts, but unexpectedly teach us much about them. Find out what we can learn from neuroscience, animated movies and even semi-intelligent slime.