As part of the release of the standardized Solution Guide for Business Capability Modeling (BCM) and Business Capability Realization (BCR), we have included a pre-configured metamodel with a scope designed to give you a quick time to value.
Content
Business Capability Modeling Scope
The Business Capability Modeling Solution Guide, helps you answer the following key business questions:
What are the business capabilities of my organization?
What does my enterprise do? How can performance be measured and analyzed so it can be improved?
What capabilities are differentiating for my organization?
How mature are my capabilities?
Who are the experts in those capabilities?
BCM Metamodel
The primary purpose of the Business Capability Modeling Solution is to establish a viable business capability model that resonates with your organization. This metamodel also supports identifying who the experts are for your capabilities which will allow for the collection of some of your capability metadata.
The Business Capability Realization Solution builds upon what was done to further enrich the enterprise architecture.
Business Capability Realization Scope
The Business Capability Realization Solution Guide, expands on the scope of BCM and answers the following key business questions:
How are my capabilities implemented?
Do the most important capabilities have the right investment to succeed? Are we depending on critical roles, applications, or technology that are old or overleveraged?
Who is responsible for our critical capabilities and who helps realize these capabilities?
How interconnected and complex are these capabilities?
How mature is our ability to realize a critical capability and what is the desired maturity?
What areas of the organization need investment or improvement?
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.
BCR Metamodel
With that in mind, let's look at the key concepts of the metamodel:
The metamodel is broken down into several workspaces and components with references connecting them:
Business Capabilities
Applications
People
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.
Business Capability Workspace
The Business Capability workspace is a flexible model with a few component types but we will be focusing on:
Business Capability
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:
Reference Type | Description |
Is Realized By | This reference can be used to connect the Applications, or other components in your architecture that help realize the Capability. |
For information on which fields are used to describe a Business Capability, please see the Fields section.
Business Capability Fields
There are many fields included in the solution 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.
Lifecycle & Governance Fields
Now we need to capture those Lifecycle properties we’ll use as the basis for managing our business capabilities.
Field | Field Type | Description | Definition |
Live | Date Range | A date range from when an application “went live” to its discontinue date |
|
Lifecycle Phase | List Field | A field used to classify where an application is in its lifecycle |
|
Additional Optional Lifecycle Fields:
Evaluation (Date Range): Optional
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.
Development (Date Range): Optional
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.
Mainstream (Date Range): Optional
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.
Governance Fields
Field | Field Type | Description |
Approved | Checkbox | Used to indicate whether a component has been reviewed and acknowledged as being accurate and complete |
Review Date | Date Field | Used to indicate the date at which a component was reviewed and acknowledged as being accurate and complete |
Strategic Evaluation Fields
Complexity (Calculated Number):
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. See the gremlin query here.
Market Differentiation (Number):
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:
( 1 ) Commodity: The capability provides no competitive or market advantage and can be provided or consumed as a standardized service (i.e. “everybody does this the same - there’s no advantage in reinventing the wheel”)
( 2 ) Market-adapted: The capability may be adapted to provide a marginal market advantage (i.e. “we can adapt to market requirements but the difference to our performance is small.”).
( 3 ) Market-competitive: The capability is tailored to meet the upper norms or expectations of a market (i.e. “investing in this capability makes us a credible player.”).
( 4 ) Market-leading: The capability is optimized to provide a competitive advantage against competitors with similar capabilities (i.e. “if we do this better than our competitors we outperform them.”).
( 5 ) Market-disruptive: The capability provides a decisive competitive advantage through being unique, innovative, or unable to be reproduced by competitors (i.e. “if we can do this and our competitors can’t we change the game.”).
Maturity (Number):
Following the US DoC ACM Model from TOGAF, the maturity field is used to measure the maturity of a component on a 1-5 number scale:
( 1 ) Initial
( 2 ) Under Development
( 3 ) Defined
( 4 ) Managed
( 5 ) Measured
Cost Fields
Cost fields can be applied to the Business Capability but are optional in Modeling and Realization. The topic of IT cost can be immense. For an in-depth description of IT Cost Management in Ardoq, please see our IT Cost Management Metamodel article.
Misc. and View Modifier Fields:
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.
Capability ID (Text):
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.
Component Level (Calculated Number):
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. See the gremlin here.
Component Order (List):
This field is used to control the layout of the Capability Map view.
Applications Workspace
The Application workspace is used in a variety of Use Cases; for example, the Application Lifecycle Management Use Case, Business Capability Modeling and Realization Solutions, as well as IT Cost Management and Application Rationalization, utilize Applications as a primary component to achieve the wanted outcomes.
This workspace has several component types:
Application Group
Application
Application Module
Interface
Data Store
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:
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.
People Workspace
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:
Person
The workspace also comes pre-configured with two Reference types:
Reference Type | Description |
Owns | Used to capture official ownership of Applications, Organizational Units, Data Entities, etc. |
Is Expert In | Used to capture expertise in Capabilities, Applications, Products, etc. |
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.
Gremlin Queries
This section provides the gremlin queries for the calculated fields for the solutions.
Component Level
g.V(ids).project('id', 'name', 'value').
by(id).
by('name').
by(
emit().repeat(
out('ardoq_parent')).
count())
Complexity
calculate = __.out('Is Realized By').hasLabel('Application', 'Organizational Unit').count()
g.withSack(0).V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(emit().repeat(__.in('ardoq_parent')).
sack(sum).by(calculate.sum()).
sack().sum())
Document Version
Version | Date | Responsible | Rationale |
1.0 |
| Jon Scott | Published |
1.1 | 7/26/24 | Jon Scott | Revised definition of the Maturity field |
1.2 | 10/15/24 | Leart Kollqaku | Updated lifecycle phase list. Removed Mainstream, Evaluating and Review. |
1.3 | 12/17/24 | Leart Kollqaku | Updated metamodel diagrams |