Top 5 Use Cases for Business Capabilities to Transform an Organization

The first and most common use case of applying business capabilities is to provide a generic, easy to understand, and holistic view of an organization that can be used to map IT components, such as applications, data, or technology to it. Understanding the As-Is and To-Be landscape of the application layer, the data layer, and the technology layer is at the heart of Enterprise Architecture Management. Business capabilities can be the linking element, located in the business layer, that IT can map components to, and that business is able to understand easily.

Before the start of a landscape assessment, have a clear picture of what you want to do with the data after you gathered it (and hence what you actually want to assess in detail), how you want to store it, share it, and how it should be governed and updated over time.

This use case requires that projects identify the business capabilities that they support and that the result is centrally collected before the beginning of the demand and portfolio process. This also requires that there is a business capability map in place for the whole organization and that there is an indication of the strategic relevance for every capability. This can be done by breaking down existing business strategies and understanding what those strategies actually imply.

Consider this example: If your company wants to increase digital sales, your e-commerce capability would probably be of high strategic relevance. If your organization collects the data for this use case, it would be able to show the strategic importance of business capabilities based on the underlying projects — depending on which capabilities they enable. The resulting analysis could help to decide whether a project should be funded or not.

A very popular use case is to support the demand management process of your organization. Unfortunately, it is also one of the hardest to implement. In order to add value to the demand management process with the help of capabilities, you need to have a detailed capability map in place, as well as a very good As-Is transparency of your landscape mapped to it. Your As-Is landscape might consist of applications and their functionalities, of systems and supported technologies, or even of ready-to-use solution bundles.

If you gather all this information, you could map incoming demands (e.g. a business-drawn user journey) to business capabilities and identify whether you already have that capability in your map or not. If it already exists, you can analyze the IT components mapped to it. You can also evaluate whether they might be suitable to meet the described demand or if you really need to develop something new. The result of this exercise would most likely be a reduced set of capabilities and hence functionalities that need to be developed from scratch or purchased, while you can maximize the re-usage of existing IT components and therefore reduce costs and required resources, enhance stability through tested components, and reduce time-to-market.

Yet, this approach often stays theoretic, because it cannot be applied in areas in large applications cannot be separated into its single capabilities. Therefore, they do not allow to use single parts of it for new demands. Also, the As-Is landscape is often not described in enough detail to allow for such an approach, so that there is a lot of upfront effort required.

Some organizations have thousands of applications. Applying business capabilities to cluster them according to the business abilities they enable makes it much easier to optimize the application landscape. The goal is to have such a granular business capability map that no more than 5 to 10 applications are mapped to one business capability.

This allows to analyze the applications per independent from each other per business capability cluster. This can for instance be done by applying a TIME analysis, which assesses the business fit and the IT fit of each application and allocates it on a matrix. The business fit could be the result of business value added, business criticality, number of users, departments, countries using the application, or allocated revenues. The IT fit could be the result of the support of the underlying technology, the application security, availability of the source code, response times, issues etc. There are many indicators that you could think of and you should evaluate which ones your organization can assess and are helpful for your goal.

If you put the business fit on the x-axis and the IT fit on the y-axis, you will create the following quadrants:

1. Top Left, Tolerate: Those applications have a low business fit, but their IT fit is high. You can therefore keep them in your organization as they do no harm.
2. Top Right, Invest: Those applications have a high business fit and a high IT fit. You should further strengthen them and further invest in them, as they are the best category of your applications.
3. Bottom Right, Migrate: Those applications have a high business fit, but a low IT fit. You probably need their functionalities, but the underlying technology is not optimal. You should consider changing the provider, migrate to a new server or do something else to enhance their IT fit.
4. Bottom Left, Eliminate: Those applications have a low business fit and a low IT fit. You do not need those applications and they have no suitable IT foundation. The best option for them is to be eliminated to reduce the number of applications and to drive down costs.

Originally published at https://www.digitalroadmap.management on November 20, 2020.