Business Architecture In Action For Investment Decisions

How business architecture helps with analysis, rationalization and decision-making

Keeping with our theme of business architecture in action, this post focuses on how business architecture helps with analysis, rationalization and decision-making related to project investments (a.k.a. project portfolio management) and system applications (a.k.a application rationalization and application portfolio management). We’re going to blend a couple topics here, since conceptually business architecture plays a similar role for each.

What’s the problem?

There are a couple themes related to decision-making for both projects and system applications.

One. Our organizational structure often drives us to take a fragmented approach to planning, whether it’s funding projects or creating business and IT solutions. Not to say that there is not overall direction, but many decisions are made based on each business unit’s view of the world, their priorities, and their budgets. From an enterprise perspective though, this leads to—you know it—redundancy and complexity, which means inefficiency, higher cost, a lack of overall organizational agility, and suboptimal customer experiences.

And two. Knowing the priorities is not always as easy as it seems. Project requests may or may not be tied to strategic objectives and even if they are, it is not always clear which objectives are more important than others. Finding the best way to scope and sequence projects so they do not overlap and can logically build upon each other is not the easiest thing either. On the other hand, when evaluating the portfolio of system applications, priorities may not be clear if there is no business lens with which to identify opportunities or make decisions. For example, how do we know if an application is really redundant from a business perspective? Which high risk applications are most important to address first?

How does business architecture help with all of that?

The bottom line is that business architecture provides us with a true enterprise view on things, so for the first time we can actually make the best decisions about how to allocate our precious resources from a collective enterprise perspective, not a fragmented one. (Truthfully, some individuals are not fond of this idea, but it does what’s best for the organization as a whole.) With business architecture we can:

  • Identify where we have redundancy or potential redundancy because using an enterprise business capability map (with capabilities mapped to value streams for context), we can catalog where project requests are intending to do the same things or where system applications already do the same things. The capability map actually allows this type of redundancy to be identified because of its special structure, which is oriented around business objects, not processes or organizational structure.
  • Prioritize the projects which are most closely aligned with strategic priorities because of the traceability business architecture provides from project (initiative) to capabilities and value streams and then to strategic objectives.
  • Prioritize system application investments from a business perspective because when they are tied to capabilities and value streams, system applications can be assessed within a business context. For example, making changes to system applications which support customer-facing capabilities and value streams may be a higher priority than to those which are internally focused.

Got it. So how do we actually do this?

For this business scenario, we simply use the business architecture as a “framework” (i.e. a fancy way to say that we use the structure it provides to analyze and organize information)—unlike the more robust way we looked at using it across the strategy execution life cycle for business transformation in Post No. 9.

Here’s a rundown on the major steps for using business architecture for either project or application portfolio management decision-making. And make sure to check out More Good Stuff to see examples from your fellow business architect friends.

  • Step 1: Define Scope and Goals For Analysis – Clarify what you are trying to achieve and the scope of projects or applications within your analysis. For example, you may be looking to identify potential strategic misalignment and redundant investments within a specific project portfolio or across multiple portfolios.
  • 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 your analysis including:
    • The list of potential initiatives or applications within your scope
    • Attribute information about the initiatives (e.g. sponsor, requested funding amount) or the applications (e.g. level of risk, level of business functionality support)
    • Mappings to the business architecture baseline such as:
      • Initiatives mapped to objectives, capabilities, value streams and business units
      • Applications mapped to capabilities, value streams and business units
    • PS: Team up with your friends as needed to figure out this information (e.g. planning / business team members for project information and application architects or owners for application information).
  • Step 4: Perform Your Analysis – Assess the information you have collected for overlaps, gaps, conflicts and / or strategic misalignment across initiatives or applications. A common way to visualize results like these is through a technique called “heatmapping” (i.e. a fancier word for color-coding). For example, a business architect might heat map the capability map by showing the capabilities planned to have the top-third of project spend for the next year shaded red, capabilities planned to have the middle-third of project spend shaded yellow, capabilities planned to have the bottom-third of project spend shaded green, and capabilities with no planned spend shaded white.
  • Step 5: Visualize the Results, Share Insights and Take Action – Finalize visuals, summarize insights and recommendations, and share with leaders (e.g. with portfolio leaders and planners for projects or with application owners, IT leaders and the CIO for applications). Work with the leaders and their teams to take action on the results.

What’s the fine print?

Good News: A minimum set of business architecture content is needed for the analysis, but it can be created within a relatively reasonable time frame, even for new business architecture teams. This means that using business architecture to help with project or application portfolio management decision-making can be a good place to start to prove its value within an organization.

Bad News: While business architecture may illuminate great opportunities—actually acting on them often takes a deeper level of organizational change, requiring leaders to work together across business units and think in a different way. It may take some time before the organization embraces a truly enterprise mindset and the type of cross-business unit decision-making and funding that it requires.

However, embedding business architecture into the project portfolio management process long-term is not only a great step forward for the discipline but will help the organization to make this shift to an enterprise mindset over time.

And of course here’s a handy summary of all of that for you.

Common Challenges

Project Portfolio Management

  • Redundant and / or conflicting project investments
  • Project investments that are not aligned with strategic direction and / or difficulty prioritizing project investments

 Application Rationalization and Portfolio Management

  • Redundant system applications which provide duplicate business functionality
  • System application investments made lacking business priority and / or difficulty prioritizing system application investments

Opportunties

Project Portfolio Management

  • Use business architecture to analyze and communicate potentially redundant or conflicting project investments before they are funded
  • Assess and communicate the degree of strategic alignment for planned project investments

 Application Rationalization and Portfolio Management

  • Use business architecture to analyze and communicate potentially redundant system applications
  • Assess the portfolio of system applications using a business lens to help prioritize decisions such as which to keep, replace, retire or consolidate

How We Do It

  1. Define Scope and Goals For Analysis
  2. Create or Leverage the Minimum Business Architecture Baseline Content
  3. Capture Additional Content Needed For Analysis (i.e. lists of initiatives or system applications along with attribute information and mappings to the business architecture baseline)
  4. Perform Your Analysis (e.g. to identify overlaps, gaps, conflicts and / or strategic misalignment)
  5. Visualize the Results, Share Insights and Take Action

Considerations

  • A minimum set of business architecture content is needed for the analysis, but can be created within a relatively reasonable time frame, even for new practices
  • Capabilities and value streams must be created at the enterprise level but other business architecture content may be mapped for the applicable scope only
  • Visualizing results and communicating insights are important to add value
  • While business architecture may illuminate opportunities, acting on them often takes a deeper level of organizational change requiring leaders to work together across business units

More Good Stuff

Business Architecture for Project and Application Portfolio Management Case Studies: Loads of great stuff to learn from your friends. These examples are from previous Business Architecture Guild® Summits where business architects have shared how they used business architecture for project and / or application portfolio management in their organizations.

The Art of Capital Allocation (BCG): Just in case you didn’t catch this one awhile back, there are some smart practices in here on how to allocate capital with an enterprise perspective.

6 Powerful Psychological Effects That Explain How Our Brains Tick (Buffer): Just for fun, six psychological effects that impact how we act and make decisions.

Are We in Control of Our Own Decisions? (TED Talk): More fun. Ted Talk by Daniel Ariely demonstrating that maybe we are not as rational as we think when it comes to making decisions.

Business Architecture In Action For Business Transformation

We’re starting a new series focusing on business architecture in action for common business scenarios, where we try to answer that “so what?” question that people like to ask about business architecture.

This post focuses on the significant role that business architecture plays in making business transformation a reality. (And by “business transformation” we mean the sort of enterprise-level changes that fundamentally shift the way an organizations operates. Not the detailed operational changes-but-we’re-going-to-call-it-transformation sort of business transformations. Digital transformation is a major focus for many organizations today, but the ideas here apply to any type of enterprise transformation.)

What’s the problem?

Many organizations are aspiring to transform, but they are not always good at it.

First, there is figuring out what the transformation is all about and why we’re doing it in the first place. Sometimes the strategy and objectives for a business transformation are very high level requiring a giant leap to translate them into steps that people can actually take to make them real in the business and IT environment. In addition, strategy diffusion happens (aka the “telephone game” for strategy where the meaning of it becomes lost as it is explained from one person to another across the organization).

It is also common for the (already unclear) business direction to be interpreted and acted upon separately by each business unit. Even with coordination, we know how this story ends. Potential gaps, redundancy, conflicts, and lack of integration in the resulting business and IT solutions—which doesn’t lead to a very good customer experience or efficient operating environment.

And then there is just the reality that organizations do not always know where to start or how to approach such a massive change, especially if they have not done anything like it before. As a result, some may focus on the IT aspects since they are more tangible or turn to vendors to bring in quick frameworks and solutions—but this can overlook some critical aspects of the change, especially from a business perspective.

How does business architecture help with all of that?

Integrating business architecture upfront in the strategy execution life cycle is a game changer for business transformation. With business architecture (and brainy business architects) we can:

  • Clarify and rationalize business direction right away, and communicate one common view across the entire organization of what the business and IT environment should look like when the transformation is done. This way everyone can see what they need to do.
  • Create the best solutions in the most efficient way because we collectively architect them for the whole enterprise scope (including all of the business aspects)—not piece by piece from each business unit’s perspective. Then we break the whole thing into initiatives in the right sequence with scopes that do not overlap.
  • Manage an extremely large scope because business (and IT) architecture gives us a view of the “forest for the trees” so that we can quickly get our arms around what the future organization needs to look like at a high level. Then we can expand into detail “just in time” at the initiative level as we go.

Got it. So how do we actually do this?

Big question, big answer, but this is StraightTalk, so we need to be brief. Check out More Good Stuff to learn more.

  • Step 1: Clarify Business Direction – Understand, rationalize, inform, refine and potentially detail the business direction (easier said than done).
  • Step 2: Identify Business and IT Impacts – Using the handy business architecture knowledgebase that you have created, catalog the pieces of the business and IT environment that will need to change like capabilities (within a value stream context), business units, products, etc. Once you know the capabilities impacted, you can follow them through to understand the full “butterfly effect” of how the operating environment will be impacted by the transformation including processes, system applications, etc.
  • Step 3: Analyze and Visualize Current State Architecture – See how all of those pieces work today. You might find redundancy and other challenges. Visualize them in a current state architecture picture(s) and tell the story to build a case for change.
  • Step 4: Design and Visualize Target State Architecture – Do the serious work of designing new pieces or redesigning existing ones to define your future organization to meet the transformation objectives. Visualize all of this in a target architecture picture(s) and tell the story to gain buy-in.
  • Step 5: Plan Initiatives – Scope and define all initiatives needed to achieve the target architecture and organize them onto a strategic roadmap. Each initiative should be defined from a business perspective, in terms of the architecture changes that will be made, and may result in one or more project later on. If you have multiple business transformations occurring simultaneously, synchronize the target architectures and strategic roadmaps across all of them.
  • Step 6: Obtain Approval – Obtain approval from business sponsor(s) / committee(s) and architecture sponsor(s) / committee(s). This will likely occur iteratively throughout Steps 3, 4 and 5. Then communicate the vision widely.
  • Step 7: Handoff to Execution Teams – As each project is ready to kick off, describe the changes it will make within an architecture context and communicate them to the execution teams. Work with business analysts as they translate the changes into requirements tied back to the architecture.
  • Step 8: Oversee Execution and Measure Results – Provide direction and oversight to execution teams as needed, to ensure that the results meet the architectural direction and ultimately the original business direction.

P.S. We’ve been focusing on the business architecture here, but starting in Step 2, this is an entirely collaborative process that requires IT architecture (and brilliant IT architects). We wouldn’t be successful without them.

Some of the steps sound similar. How is this different than what we usually do?

While some of the words may sound the same, most organizations do not approach transformation with this highly collaborative and holistic approach. There’s a different underlying premise here. We’re talking about driving the design and planning of a business transformation from a top-down, cross-business unit and architectural perspective. This is the opposite of what typically happens where each business unit dives into the details to figure things out and creates their own separate initiatives.

(Thinking fondly back to Post No. 3 on a new vision for strategy execution about now.)

What’s the fine print?

There’s a huge opportunity for business architecture to drive successful transformations in a new way, but the reality is that this scenario falls more in the advanced category.

There are creative options, but using business architecture for transformation typically requires a practice to be established within an organization—with some level of maturity. This includes having a business architecture knowledgebase in place (with at least a minimum baseline documented), experienced business architects deployed, integration with other teams across the strategy execution life cycle in place, and last but not least—adoption and buy-in for the discipline.

This one also requires business architects to act not just as architects, but as true leaders and change agents. It takes competence and courage. But, this could be the mission you’ve been waiting for, should you choose to accept it.

While using business architecture to drive business transformation might not be for the faint-hearted, doing so successfully will launch the discipline within your organization and you as an individual. It can be incredibly rewarding to lead change at an enterprise level and well, a transformational experience.

And here’s a handy summary of all of that for you.

 

Common Challenges

  • High level direction which may be difficult to translate into specific actions; strategy diffusion
  • Siloed strategy interpretation and execution, leading to redundant and conflicting solutions
  • Heavy IT focus and reliance on vendors for solutions
  • Challenge in knowing where to start and how to approach large-scale change

 

Opportunties

  • Clarify business direction; provide a common, actionable view of the future for the enterprise
  • Architect solutions from an enterprise perspective, leading to efficient design and initiative scopes
  • Drive transformation from a business perspective and create holistic business and IT solutions
  • Manage large scopes leveraging architecture’s high level view and then expand into detail “just in time”

 

How We Do It

  1. Clarify Business Direction
  2. Identify Business and IT Impacts
  3. Analyze and Visualize Current State Architecture
  4. Design and Visualize Target State Architecture
  5. Plan Initiatives
  6. Obtain Approval
  7. Handoff to Execution Team
  8. Oversee Execution and Measure Results

 

Considerations

  • Business architecture practice maturity is required
  • Integration with teams across the strategy execution life cycle is required
  • Sponsorship and buy-in from business transformation leadership is required
  • Visualization and story-telling techniques are important
  • Business architects must be prepared to act as leaders and change agents

Download Summary >

 

More Good Stuff

The Strategy Execution Metanoia (S2E white paper): Just in case you missed it, super helpful background on how business architecture enables a new vision for strategy execution. If you’re looking for more details on how business architecture gets involved in the steps described above, this will help.

Business Architecture for Business Transformation Case Studies: Learn from your friends. Here are a few examples from previous Business Architecture Guild® Summits where business architects have shared how they used business architecture to transform their organizations.

Business-Driven Digital Transformation (Cutter Business Technology Journal): A free download from Cutter Consortium which provides multiple authors’ perspectives on how to drive digital transformation from a business perspective—and using architecture.

How Enterprise Architects Can Help Ensure Success With Digital Transformations (McKinsey): Good one that makes the case for enterprise architecture to play a central role in reducing the complexity associated with digital transformations.

How to Build a Business That Lasts 100 Years (TED Talk): Ted Talk by Martin Reeves on how business can learn from biology to remain resilient and enduring.

 

Copyright © 2024 S2E Transformation Inc. All rights reserved.