As part of the release of the standardized Use Case Guide for Business Capability Modeling (BCM), we have included a pre-configured metamodel with a scope designed to give you a quick time to value.

The Business Capability Modeling Use Case Guide, helps you answer the following key business questions:

While the metamodel is all you need to start answering these key business questions, you still have the full flexibility to expand, contract, and change the model in any way you see fit to better suit your business needs.

With that in mind, let's look at the key concepts of the metamodel:

The Metamodel is broken down into 4 workspaces with references connecting them:

Within these workspaces, we have smaller metamodels consisting of Components, References, and Fields. We will go through these per workspaces, and then define the fields, which are often shared, separately.

The Business Capability workspace is a flexible model with just one Component type:

This enables you to create nested capability models as deep as you see fit without the need to argue the nuanced differences between defining a level 3 and level 4 capability.

The workspace also has only one Reference Type:

For information on which fields are used to describe a Business Capability, please see the Fields section.

The Application workspace is used in a variety of Use Cases; for example, the Application Lifecycle Management Use Case, Business Capability Modeling and Realization Use Cases, as well as IT Cost Management and Application Rationalization, utilize Applications as a primary component to achieve the wanted outcomes.

This workspace has just 4 Component Types:

The flexibility enables you to model applications that might have modules, separate instances, or services that you would like to identify as unique. An example could be:
​

This workspace also includes one Reference to be able to capture integrations:

For more information on applications in Ardoq, see our Application Lifecycle Management article. If you're curious about how to document integrations and data landscape, please see our Application Integration Metamodel and Data Lineage Metamodel articles.

These Fields and References can be further expanded upon to include more technical definitions, or you can implement our Application Integration Management Use Case for more granular definitions and functionality for when the details of the integrations are necessary to achieve the business goals your team has set out to accomplish.
​

The People workspace generates a repository of people (employees, consultants, etc.) who have the responsibility, ownership, or expertise necessary to capture. People are also used in the Application Lifecycle Management Use Case and can be built upon for better impact analysis and incident resolution.

The People workspace includes only one Component type and is also a flexible model:

The workspace also comes pre-configured with two Reference types:

By using these reference types, you can identify domain expert networks and run impact analysis to understand who might be impacted by a change or issue and also who to talk to if expertise is needed for issue resolution.

The Organization workspace is also a simple flexible model with only two component types. This can be used to capture your organization's Departments, groups, business units, or however you define domains or teams. In doing so you will be able to Capture which Departments you depend on to realize a capability.

The component types included in this workspace are:

The workspace also includes one reference type:

Check out the Organizational Modeling Metamodel document to learn more about the Organization workspace.

There are many fields included in the best practice module for Business Capability Modeling. Not all are necessary to use to answer key business questions, and you can choose to expand, simplify or update at a later time. Many of the Application-specific fields are more relevant to Application Portfolio Management, which is tightly coupled with BCM.

For the sake of better explaining the purpose of these fields, we have grouped them into categories. This grouping has no impact on where they can be applied, how they are defined, or their importance.

Within this module, we have only used fields on Components, but they can be added to references if that is valuable.
​

The topic of IT cost can be immense. For the purpose of the Business Capability Modeling article, the fields are described - for an in-depth description of IT Cost Management in Ardoq, please see our IT Cost Management Metamodel article.

This list field can be applied to anything which you would like to create roadmaps and manage lifecycles. The list of phases (in order of time) includes: Evaluating, Development, Live, Mainstream, Phasing Out, Retired.

Use this date field to plan an Evaluation phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers.

Use this date field to plan the Development phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers.

Use this date field to plan the Live phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers.

Use this date field to plan the Mainstream phase and visualize it in the Timeline View. Mainstream is a sub-phase of Live and relates to the period for which the component is in a 'steady state'. For example, before an application is Mainstream it may be ramping up its use, and after it is Mainstream it may be ramping down. This phase includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers.

Complexity is a generic measure of the 'connectedness' of one or more components. It works by counting the number of references of one or more types for any given component. Its precise meaning depends on the type of reference being counted. In this case, the calculated field counts the number of applications and departments that realize a capability. The more components connected, the more complex the capability is, with multiple applications and departments performing the same function. You can find the complete query under the reporting menu found on the left bar.

The extent to which the capability provides a competitive advantage in one or more markets. Use Numbers Ranging from 1 - 5 where the numbers correlate to:

The extent to which processes, systems, and skills that realize this capability are complete, reproducible, optimizing, and adaptive. Use Numbers Ranging from 1 - 5 where the numbers correlate to:

These fields are added to either improve the import of data from Excel or to be used in some of the visualizations to control the layout or filtering.

This field is used as part of the standardized excel import template that accompanies the BCM best practice. If you are not using the excel importer to collect and update data in Ardoq, you can remove this field.

This field is added to capabilities in order to create simple filter sets. An example is when this is valuable is when you would like to create a view that does not include any Level 4 or lower capabilities.

This field is used to control the layout of the Capability Map view.