Business Architecture In Action For Investment Decisions: How Business Architecture Facilitates Decision-Making for Project and Application Portfolio Management

Published

21 August 2017

Updated

30 May 2020

Published In

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

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.

Table with business-architecture-in-action descriptions

Business Architecture In Action: Project and Application Portfolio management Decision At-A-Glance

Downloadable Media

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. (See Business Architecture Guild®Public Resources page.)

  • Using Business Capabilities to Make IT Metrics Meaningful (United Airlines 2017)
  • Business-Driven Roadmaps, Initiatives and Funding (United Airlines 2015)
  • Capability-Based Approach to Enabling Strategic Initiatives (United Airlines 2014)
  • Business Architecture and Major Portfolio Initiatives (USPTO 2014)
  • Business Architecture at Chevron (Chevron 2016)
  • Architecture-driven Investment Planning (Mastercard 2015)
  • Business-Driven Roadmaps (Mastercard 2014)

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.