As part of the release of the standardized best practice module for business capability modeling, we have included a pre-configured meta model with a scope designed to give you a quick time to value. 

While the meta model is all you need to start answering 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 meta model: 

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

  • Business Capabilities
  • Applications
  • Departments
  • People

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

Business Capability Workspace

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

  •  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:

  • Realized By

This reference can be used to connect the department, applications or other components in your architecture which help achieve the source Capability. 

Applications Workspace

The Application workspace is also a flexible model and shared with both the Application Portfolio Management best practice and the Business Capability Modeling best practice. 

This workspace has just one Component Type

  • Application

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

This workspace also includes three References to be able to capture integrations. 

  • Integrated With: A generic integration type to use when the details of direction are not available. 
  • One-Way Integration: A directional integration type starting from the "source" application towards the "target" application. 
  • Two-Way Integration: A bi-directional integration type starting from the "source" application, typically the application which initiates the process, towards the "target" application which in turn replies. 

These can be further expanded upon to include more technical definitions, or you can implement our Integration Management best practice 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.

People Workspace

The People workspace is used to generate a repository of people (employees, consultants, etc.) which have responsibility, ownership or an expertise which is necessary to capture. People are also used in the APM best practice 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: 

  • Owns: Used to capture official ownership of Applications, Projects, Processes, Data, 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.  

Department Workspace

The Department workspace is also a simple flexible model with only one component type. This can be used to capture your organizations 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 type included in this workspace is: 

  • Department

The workspace also includes one reference type: 

  • Owns: To be used to map ownership over Applications, Processes, Projects, or even Products. 

Fields

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 into 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.

Cost Fields

Total Direct Cost (Number): 

This field is used to capture cost wholly attributable to a given component. An example of this would be the license cost of an application. With all cost fields, we recommend that you standardize the currencies across your organization.

Total Allocated Cost (Calculated Number):

This is a calculated field that distributes the direct cost of a component to the components it is connected to. For example, if one application realizes two capabilities, then its "Total Direct Cost" field is divided equally and allocated to those Capabilities' "Total Allocated Cost" fields. You can find the complete query under the reporting menu found on the left bar.

Lifecycle Management Fields

Lifecycle Phase (List):

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

Evaluation (Date Range):

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):

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. 

Live (Date Range):

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. 

Mainstream (Date Range):

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. 

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. You can find the complete query under the reporting menu found on the left bar. 

Market Differentiation (Number):

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

  • 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”)
  • Market-adapted: The capability may be adapted to provide marginal market advantage (i.e. “we can adapt to market requirements but the difference to our performance is small.”).
  • Market-competitive: The capability is tailored to the meet the upper norms or expectations of a market (i.e. “investing in this capability makes us a credible player.”). 
  • Market-leading: The capability is optimized to provide competitive advantage against competitors with similar capabilities (i.e. “if we do this better than our competitors we outperform them.”). 
  • Market-disruptive: The capability provides 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):

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: 

  • ( 1 ) No Capability: The organization has no systems, processes or skills to realize this capability. 
  • ( 2 ) Limited Capability: The organization has processes, systems or skills to realize this capability but they are immature or hard-to-reproduce. 
  • ( 3 ) Developing Capability: The organization has stable or reproducible processes, processes or skills to realize this capability although they are not yet efficient. 
  • ( 4 ) Mature Capability: The organization has stable, reproducible and performance-managed processes, systems or skills to realize this capability.  
  • ( 5 ) Optimized Capability:  The organization has reproducible, efficient and continuously-adaptive processes, processes or skills to realize this capability.

Functional Fit (List):

 This field is used as part of the calculation of Business Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best fit are used to grade the functional fit of the application. This follows the TIME methodology. Summarized by the following questions: 

  • Does the application provide all the functionality required of it? 
  • Is it necessary to supplement it with other applications, tools or manual workarounds? 

Availability and Quality (List):

This field is used as part of the calculation of Business Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best are used to grade the availability and quality of the application. This follows the TIME methodology. Summarized by the following questions: 

  • Is the application: Easy to use without unreasonable training; reliable and available when needed; a trusted source of information and analysis?

Business Strategic Fit (List):

This field is used as part of the calculation of Business Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best are used to grade how well the Application fits our business strategy. This follows the TIME methodology. Summarized by the following questions: 

  • Does the application support the business strategy or the ambitions of its user base? For example, movement into new markets, or digitization/automation of products and processes. 

Business Fit (Calculated Number): 

Business Fit is the overall calculated score based on the current and future business value of the application. (Derived from Functional Fit, Availability and Quality, Business Strategic Fit) 

Technology Integrity (List):

This field is used as part of the calculation of Technical Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best are used to grade the technical integrity of the application. This follows the TIME methodology. Summarized by the following questions: 

  • Is the application built from approved or current technologies? Does it support standards-based interoperability with other applications and technologies? 

Maintainability and Agility (List):

This field is used as part of the calculation of Technical Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best are used to grade the maintainability and agility of the application. This follows the TIME methodology. Summarized by the following questions: 

  • Is the application easy to maintain; fix upon failure, and change in response to new requirements? 

Technical Strategic Fit (List):

This field is used as part of the calculation of Technical Fit. Although it is a list field, numbers ranging from 1 - 5 where 5 is the best are used to grade how well the Application fits our technology strategy.  This follows the TIME methodology. Summarized by the following questions: 

  • Does the application support the technical ambitions and objectives of the IT Department? For example, does it expose APIs or microservices, is it suitable for migration to the cloud? Scale 1-5

Technical Fit (Calculated Number):

Technical Fit is the overall calculated score based on the current and future technical value of the application. (Derived from Technical Integrity, Maintainability and Agility, Technical Strategic Fit.) 

Strategic Rating (Calculated List):

Based on the Gartner TIME methodology, Applications are placed in a quadrant. This is determined by the end results of the Technical and Business Fit calculations. 

  • Tolerate: High Technical Fit and Low Business Fit
  • Invest: High scoring fit in both technology and business. This is where you can confidently continue to invest and have alignment. 
  • Migrate: Low Business Fit and High Technical Fit, might be worth looking to migrate to a better solution which satisfies the business needs.
  • Eliminate: Poorly scoring in both business and technology. Opportunities for removal or replacement. 

Operational Fields

Service Level (List):

 A list field with four typical classifications of the level of service and support for an application. Typically they have a correlation with up-time, quality, performance and stability. These can be easily updated to reflect your organizations classifications. 

Hosting Type (List):

 List field designed to easily capture the type of hosting for an application. Options include: 

  • On-premise: The application is hosted on physical servers owned by the organization.
  • SaaS: It is an off-the-shelf web application hosted by the software provider and delivered via a consumption-based charging model.
  • Cloud: The application is hosted on third-party web-enabled infrastructure delivered via a consumption-based charging model.
  • 3rd Party: The application is hosted on physical servers provided or owned by an external organization.

Technical Review (Date Time): 

The date of the next technical assessment or audit of the application to ensure it has the appropriate technical strategy.

Contact Email: 

The email address of the person in question.

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 (Number):

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

Component Order (List):

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

Did this answer your question?