Business Context

Business context modeling guidelines.


Business contexts describe on a more granular level what an organization does to achieve its business goals; they can be clustered and analyzed by, e.g., products, processes, customer journeys, and value streams.


The Fact Sheet type Business Context can be modeled for a more granular representation of an organization's business architecture and is indispensable for some use cases (e.g., ERP transformation).

Overview of all relations to/from Business Context:

Business Context Fact Sheet subtypes

There are four Fact Sheet subtypes available (plus one optional subtype) that you can choose from, which gives you the flexibility to align with the most common ways your organization typically structures its business and tasks:

  • Business Product: Business Products represent all the products or services a company offers to customers.
    Example: Life insurance

  • Customer Journey: Customer Journeys represent the complete lifecycle of a customer's interactions and experiences with the company. They reflect the experience from a customer's point of view.
    Example: Career Development Framework / Online Purchase Journey

  • Process: Processes show the different steps and interactions to achieve a specific task; they represent operational activities and workflows within the organization (and are more granular than value streams).
    In LeanIX, the Processes Fact Sheet subtype models how your applications help you to support your business goals. In contrast to capabilities, they focus on activities. A process in LeanIX is a container, as LeanIX is no dedicated process modeling tool.
    Example: Sourcing and Procurement / Create Purchase Order

  • Value Stream: Value streams are sequences of activities or steps required for an organization to produce a product or service delivered to a customer (inside-out view of what is needed vs. outside-in that would be represented by customer journeys). Value streams encompass the entire flow of value creation and aim to eliminate waste, reduce inefficiencies, and optimize the overall value delivery process.
    Example: Hire to Retire

  • ESG Capability (added via optional feature): ESG Capabilities are a best-practice representation of relevant ESG (Environmental, social, and corporate governance) areas.
    Example: Energy Efficiency Management

    Read this detailed documentation on the Optional Features: ESG Capability Fact Sheet for more information.


To keep the advantages of a lean Meta Model, yet have clear expressiveness for organizations with high maturity or deep demands around Business Architecture, LeanIX recommends using the Business Context Fact Sheet in addition to Business Capability & Organization.

For a step-by-step guide to create the Fact Sheet subtype, see Create Fact Sheet Subtype

Guidelines and Best Practices

  • When you start working with LeanIX, use the Fact Sheet type only when it adds value for your organization, or there is a clear expectation to reflect business contexts in your EA work. Keep in mind the maintenance effort.
  • Business Context is a vast category - it is recommendable to choose at least one Fact Sheet subtype that reflects the most common and known approach to structure the business in your organization. E.g., if you have a well-established business process management (BPM), use the Process subtype. The choice can also depend on the type of business, e.g., B2C businesses might tend more to customer journeys to reflect their business contexts than B2B companies.
  • Involve the right Business Owners to align on the subtype(s) and create/maintain Business Context Fact Sheet.
  • Choose two dimensions (Fact Sheet (sub)types) at most: Even if there is a perceived need to cover more, remember that the Application Owners must maintain the mapping. Getting one group right is better than having two or more incomplete or inaccurate ones.
  • Work backward and ask yourself: What would I want to see in the Application Matrix if I had to choose among those four dimensions?
  • Always put yourself in the shoes of Application Owners. What will make their lives easier? Ultimately, the more they can relate to your way of modeling, the higher your data quality is.
  • You can link different Business Context Fact Sheet subtypes if it makes sense to your organization (e.g., Value Stream and Process).
  • If your organization uses Signavio for BPM, leverage the out-of-the-box LeanIX SAP Signavio Integration to sync your data from SAP Signavio to LeanIX and vice versa.


In case you use the SAP Signavio integration, keep in mind that, at this point, mapping between SAP Signavio and LeanIX can only happen on the level of the Business Context Fact Sheet, and not the subtypes.

The examples below show the different modeling approaches for different archetypes of organizations.

Example 1: Product Architecture

For many of our software-oriented clients, a relation exists between Applications and the Business Product Fact Sheet subtype - we at LeanIX internally track our LeanIX Enterprise Architecture as both an Application that we provide to internal users and a Product we offer on the market. For more complex product architectures, multiple applications can form one product to showcase all the different ways a business product comes together. Example of a product architecture:

Deep-dive with view: Applications related to Business Products

A good report to get relevant insights would be an Application Landscape Report filtered to Business Context, showing all Applications related to the different Business Products with Lifecycle as the selected View.

Another frequently used report is the Matrix Report, which lets you get a quick overview of Applications clustered, e.g., by Business Capabilities and Business Context. Note that you need to change the information in the Report Settings to get that specific view in LeanIX. Check the documentation on Reports for more details.

Example 2: How to model Business Architecture with Value Streams and Processes (manufacturing company)

The example company is a traditional company from the manufacturing industry that focuses on improvements around business process efficiency, e.g., by Lean methodologies, which require understanding what to deliver to customers via value streams and how to deliver this (business processes).

In this scenario:

  1. The analysis of specific (Business) Value Streams, for example, "Source to Pay," aims to understand how value is delivered to external or internal customers. Typically this involves modeling a sequence of high-level cross-functional (across different capabilities) activities and measuring key metrics at each step.
  2. The need to also model Business Processes (can also be the same value chain as value Streams, e.g., Source to Pay), whereas in this case, the focus is more on the detailed step-by-step activities describing how it is undertaken. Measuring attributes such as Process Efficiency, Process Variance, and Level of Automation may all be interesting here.

Both 1. and 2. may also cater to different roles, e.g., EAs may focus on value streams. In contrast, Process Owners, Business Analysts, and Business Architects may think more in terms of business processes. Integrating BPM solutions, e.g., SAP Signavio, makes sense for more advanced use cases.

Example 3: How to model Business Architecture with Customer Journey and Business Products (digital bank)

The example company, a digital bank, focuses more on building products for its customers. The focus is not on creating an extensive repository of business processes and ways to increase efficiency but improving customer satisfaction. In this case, it makes sense to model both Business Products and Customer Journeys.

In this scenario:

  1. A distinction between Business Applications and Business Products would usually be required (although for SaaS products, this may not be the case), as the latter is more focused on the specific commercial offering to the customer. Unique attributes of the Business Product may include the type of pricing metric, for example.
  2. The need to analyze how the customer perceives this offering via the modeling of Customer Journeys. Customer Satisfaction can be measured via NPS or other surveys here. There might also be a dotted line between the Customer Journey and the Business Product.

Ultimately, the focus in terms of Organization here is on your Customer, whichever way they have been defined; in scenarios like this one, using Personas is a common approach.


This section addresses antipatterns involving ineffective or counterproductive ways of modeling Business Context in LeanIX.

  • Don’t mix Business Context (or subtypes) with Business Capabilities. Business Capabilities define on a more abstract level what your company does to achieve business goals, independent from the organization’s structure, even if there might be overlaps between, e.g., Business Product and Business Capabilities regarding the terms used.
  • Don’t mix up your Business Capabilities (the abilities your business possesses) with other reference capabilities, even if they use the same term (e.g., ESG).
  • If you need to model your business processes in more detail, you should not use LeanIX Diagrams but instead a tool like SAP Signavio. LeanIX Diagram is a great feature to model your enterprise architecture and visualize relations on a logical layer, but it is not designed as a comprehensive tool to draw complex business processes.

Applicable Use Cases

Application Modernization and ERP Transformation: Usually, Processes are one of the critical elements organizations look at when doing large modernization and transformation projects.

Insights from Business Context Fact Sheet

  • Show Applications mapped to Business Context (e.g., Process) leveraging the Application Landscape Report.
  • Map Customer (Fact Sheet subtype) to Business Products using the Landscape Report.
  • Show Applications mapped to Business Context and Business Capabilities via the Matrix Report.

Further Resources