Business Architecture started emerging on the international stage as a formal discipline nearly 15 years ago. One of the questions I am frequently asked is what are some ways to demonstrate tangible value from business architecture. As the discipline continues to mature and more organizations embrace its use to help solve complex business challenges, the immense value that can result is beginning to be easier to identify and describe.
In this article I will outline a practical way to deliver value by harnessing the power of a business capability model while also generating interest and buy-in for your business architecture efforts. In her book Strategy to Reality – Making the Impossible Possible, author Whynde Kuehn identifies business capabilities as one of the core foundational aspects of an organization’s business architecture.1
Simply defined, a business capability describes what an organization does or needs to be able to do in order to achieve their desired business outcomes. Business capabilities are frequently organized into a single view of the organization. This view is often described as a business capability model. Kuehn also describes business capabilities as an effective method to connect different domains to each other. 2
Practical and Pragmatic Business Architecture Value – Application Portfolio Management
As you launch your business architecture journey, one of the more fundamental and practical examples of the value you can deliver is by using a business capability model (BCM) to create shared understanding. There are several ways in which your BCM can be used within an organization. One example is by connecting your IT application portfolio to business capabilities.
On average, it is common for businesses to allocate approximately 20-30% of their IT budget to software applications. However, software spend can frequently run higher than these averages as organizations look to take advantage of more modern technology and acquire new solutions often without retiring existing applications in their portfolio. If this practice is allowed to continue for too long without effective governance in place, organizations can find themselves needing to undergo an application harmonization or rationalization effort to curb their annual operating expenses.
Having a well-defined business capability model can be instrumental to a successful application rationalization business outcome. Consider this scenario as an example. A global company that I worked with had several different business units that frequently made independent software acquisition decisions. At the enterprise level, the company’s application portfolio had grown to four-to-five thousand applications, and was continuing to expand by double-digit percentages each year.
After establishing a working draft of an enterprise business capability model the business architecture team immediately began completing an application to capability (app-to-cap) mapping. This exercise started to provide the lens required to make it easier to answer leaders’ questions if that number of applications was truly required.
By aligning the IT applications in this company’s portfolio to the business capabilities that they enabled, the business architecture team began to uncover insight that was used to drive meaningful application rationalization / harmonization conversations. In this app-to-cap mapping effort, the business capability model established the business context to frame the conversation. Once the applications were mapped, the number of redundant applications that the organization was using across the enterprise to support a single business capability began to materialize. The team was then able to use this insight to drive business conversations to uncover opportunities to reduce costs.
In my opinion, attempting to perform this type of activity without a business capability model in place is like trying to find the proverbial “needle in a haystack”. I have seen others try to perform these activities without the proper business context in place and they often fail in their efforts.
Watch out for these common mistakes
As you embark upon the journey to map your IT application portfolio to your business capability model, you should be leery of these common mistakes that I have seen happen in organizations.
The first mistake occurs when the organization decides to wait until the business capability model is “perfect” to begin this app-to-cap mapping exercise. My recommendation is to avoid falling into this trap and begin this effort early in your business architecture journey. The insight that can be gained from this mapping helps create interest from business leaders in the effort itself as they begin to see tangible value quickly from the work the team is performing. Their interest can also be used to help “stress-test” your BCM to ensure it is written in business terms that are easy to understand.
The second mistake occurs when the organization chooses to only map those applications that the IT department actually manages and leave off applications that are managed within the business directly or by an external 3rd party. This action can result in an under-representation of the number of applications within the organization that are being used to support the same business capability. This is also a symptom that the business architecture work is being seen as an IT exercise only and is not fully recognized as common language that helps connect the entire organization across both business and IT.
If you find there is a need to differentiate the applications that are being managed by the IT department separate from those being managed by your business teams directly, I recommend using some type of meta-data to tag these applications differently. This approach gives you the ability to create separate views of the data if necessary, but still enables you to show the entire application landscape.
In conclusion, there are many practical and pragmatic business outcomes that can be realized from a mature, well-defined business architecture practice. Your goal should be to adopt an agile-mindset and identify business value that can be delivered quickly and incrementally. Connecting your IT application portfolio to the business capability model can help create excitement from leaders across the organization and generate momentum for additional value-add business architecture related activities over time.
Note: Business capability alignment is only one element of a business lens that you can apply to your application portfolio. Other dimensions in this lens include which business units are using an application; number of users; who supports/manages the application and more. Additional lenses/views can be applied to your IT application portfolio to contribute the required insight to make informed application rationalization business decisions.
How much detail does your Business Capability Model (BCM) need to drive meaningful application rationalization discussions?
It is a common practice is to decompose broad business domains (e.g. Finance, HR, Sales, etc.) into lower levels of detail when creating a business capability model. The result is to create a common understanding across the organization. Or as I like to say, help people understand what’s ‘inside the box’.
One question that is frequently asked is what level of detail do we need? When performing an application rationalization effort it is important that your business capability model (BCM) has been decomposed to the proper level of detail. A BCM that is too high-level will end up having too many applications aligned to a single business capability domain. On the other hand, a BCM that has too many levels of detail helps justify the need for IT applications to support each of the business needs.
In my experience, I have found that three levels of business capability decomposition provides the right amount of detail to drive meaningful business discussions and uncover cost savings opportunities.
Figure 1.1 – Sample Business Capability Decomposition
When aligning IT applications to your business capability model it is important to decompose your business capability model to the appropriate level of detail. This will help the organization to obtain a clear understanding of where you have redundant applications supporting the same business capability.
I have found that aligning your application portfolio to the 3rd level of detail provides the optimal results.
In this example, it is feasible that your organization might use different solutions to define the terms and conditions of your agreements (Manage Contract Authoring) than you use to determine if all parties are abiding by the agreed-upon terms (Manage Contract Obligations).
Mergers & Acquisitions (M&A) – Opportune Time to Perform App-to-Cap Mapping
I have found that completing this effort during a merger or acquisition is a perfect opportunity. It has two immediate benefits.
- Create Common Language Across Combined Companies. The ‘shared understanding’ that can be derived from a well-defined business capability model can be extended across the two organizations that are coming together providing an effective method for different teams to talk to each other in common language without the use of company jargon or the ever-dreaded TLA’s that often exist within an organization (TLA’s = three-letter acronyms).
- Identify Immediate Cost-savings and Synergy Opportunities. In M&A scenarios key stakeholders are often looking for cost efficiencies that can be gained through the transaction. Application rationalization is a core synergistic opportunity to maximize the benefits of the newly combined entities to work together in a harmonious way. Business architecture teams should help facilitate these conversations by using the enterprise business capability model to establish the business context to guide the way.
Your organization should consider establishing a business architecture knowledgebase that enables this application-to-capability mapping on an “ever-green” basis to be able to generate views on-demand that show application redundancy. Taking this approach will help you eliminate the “all-hands on deck” approach when leaders request the information to better understand application rationalization and cost savings opportunities.
References:
1,2 – Strategy to Reality; Making the Impossible Possible by Whynde Kuehn. © 2023. All rights reserved
