LeanIX - Product Documentation

Welcome to the LeanIX Product Documentation. Here you will find all the basic information you need to start working with LeanIX. We provide you with well-structured information on how to get more out of LeanIX, best-practices and use-case specific guidelines. Feel free to spread this product documentation in your company and use it as a common information source to answer your colleagues’ most urgent questions.

Get Started

Modeling Guidelines

In this section, we want to give an overview of certain modeling guidelines within LeanIX. Our target is to get you a clear idea how to make use of LeanIX structure and features in order to unfold its whole potential.

This page provides guidance on typical modeling questions within the LeanIX data model.

Full Modeling Example - LeanIX as Application

The following is a full-fledged modeling example based on the Application LeanIX. The diagram is created with the Visualizer Report right from the LeanIX workspace.

"LeanIX" is an obvious Application. It serves a business context, has business users and interfaces to other Applications.

The business context comprises all three dimensions:

  • What is LeanIX doing? It is supporting the Business Capability "Information Management", which is part of "Information Technology"
  • How is LeanIX being used? It is embedded in the standard project Process, within the substeps "1. Project Setup" and "4. Architecture Review"
  • Who is using LeanIX? Besides the "Headquarter", the User Groups "Australia" and "Brazil" are currently active

In the information and data context, an Interface to "Signavio" is implemented. It is provided by LeanIX and transports the Data Objects "IT Application" and "Process".

From a hosting perspective, two IT Components are modeled, both with a Provider and a Technical Stack

  • LeanIX is SaaS, so the provider "LeanIX GmbH" provides an IT Component of type service - "Application Hosting". It is grouped in the Technical Stack "Operations / Hosting"
  • SSO is implemented, so LeanIX depends on an IT Component of type software - "ADFS 4.0 - Windows Server 2016". The provider is "Microsoft", and it is grouped as "Middleware / Identity Management"

Finally, LeanIX is currently introduced in the scope of the Project "EAM Introduction".

General Guidelines

Tags vs. Attributes


Tags are available in all LeanIX editions. In order to work with custom attributes, please reach out to get your individual offer.

Both Tags and Custom Attributes are ways to bring more information to the standard LeanIX data model. They should always be used with care, as more information requires more effort to maintain it - so make sure that the outcome exceeds the effort for each new Tag or Attribute.

The following graphic summarizes the main properties of Tags and Custom Attributes and where to find them in the Fact Sheet.


Tags are displayed prominently at the top of the Fact Sheet.


Tags of related Fact Sheets are displayed at the relation.


Custom Attributes can be displayed at arbitrary positions.


Different data types can be used for Custom Attributes.

Both Tags and Custom Attributes share three other major properties:

  • You can access them via API and XLS (both read and write), and you can see them in the table view
  • You can filter for them (both in the inventory and in the reporting)
  • You can assign custom colors and use them as views in the reporting

When to use a Tag:

  • It is good practice to not use more than 5-7 Tag groups per Fact Sheet type
  • Use them for the most important and most prominent attributes, e.g. Strategic Fit or SLA
  • Use Tag Groups if they have a finite number of possible elements (<10)

When to use a Custom Attribute:

  • If you require other data types than a value list (e.g. a textarea)
  • If an attribute is only interesting for particular stakeholders, e.g. for Legal or GDPR, and therefore, you want to have it somewhere at the bottom of the Fact Sheet
  • If you want to limit access (read or write) to particular users

Relations: Parent / Child vs. Requires / Required by vs. Explicit relations

In LeanIX you will find 3 different types of relations between fact sheets:

Parent / Child relations allow creating distinct relations of fact sheets ("tree structure") within one fact sheet type (e.g. User Group). A child can only have one parent fact sheet, whereas a parent can have multiple children fact sheets. The result is a tree with different levels (top parent = level 1, children of top parent = level 2, children of level 2 parents = level 3, ...). Some examples of modeling in LeanIX:

  • User Group: Europe / Western Europe / Netherlands (Europe = Level 1, Western Europe = Level 2, Netherlands = Level 3) for building up a clear regional structure
  • Tech Stack: Database / Relational Database (Database = Level 1, Relational Database = Level 2) for building a clear structure of the Tech Stack


Use Hierarchies with care - more details always require higher effort for maintenance. Start with low granularity and refine only where it makes sense.

Explicit relations are defined between fact sheet types based on the LeanIX Best Practice Data Model. If available for your use case we highly recommend using this type of relation. In some cases, these relations include certain attributes to specify the relation (e.g. "total annual costs" on the relation Application - IT Component or "usage" (CRUD) on the relation Application - Data Object)

Requires / Required by relations can be used to create further logical dependencies within one fact sheet type or between factsheet types

  • within the same fact sheet type: creating logical n:m dependencies between fact sheets (e.g. IT components: a server requires an operating system - this relation is important to use to enable a multi-step "Technology Risk view" and identify which IT components are (índirectly) connected to an application)
  • between fact sheet types: for documentation purposes, it might be helpful to show the dependencies between fact sheets of different fact sheet types (e.g. Data Object to Process). This relation cannot be visualized in any of the standard reports and is only available on the fact sheets and in the table view


Requires / Required by is a powerful concept which should be used carefully. There are use cases (e.g. Technology Risk) where using it will improve the data quality and insights that can be drawn out of LeanIX. At many other occurrences, using this relation might create more harm as it overloads the data model. Explicit relations should always be considered before opting for Requires / Required by.

Fact Sheet - Best Practices

Business Capabilities Modeling

In this section, we offer you a best practice business capability model to upload into your workspace.


The Business Capability Map is used to group Applications according to their functionality. The Business Capability model is rather stable over time. Although capability model reflects - to a certain extent - your individual business model, our generic Capability Model is the perfect starting point to plan your IT-Landscape. Just chose the Capabilities that match your needs. In the Poster below, we have included tips and best practices on what is important using Business Capabilities and to create a complete overview of your companies functions.

See a preview of the poster here:

For downloading the poster in high resolution follow the link below:

Best Practice to Define Business Capability Maps

Prefilled Best Practice Import

Uploading this standard model to your workspace will enable you to set up an Application Landscape quickly and get into use cases like Application Rationalization or Post Merger Integration.


Please reach out to your Customer Success Manager or [email protected] to get your pre-filled Excel that includes the Business Capability from the poster above.

User Group Modeling

The User Group Fact Sheet is one essential part of LeanIX's approach to representing the business architecture. Often, customers use it combined either with Business Capabilities or with Processes to obtain an Application Matrix report, which is perfectly suited to identify possible synergies or white spaces in the application landscape.

User Groups are intended to address who is using certain applications. The four major dimensions captured by LeanIX customers are:

  • Regional (e.g. countries or group of countries)
  • Divisional / Organisational Entities
  • Legal structures
  • User type structures (e.g. blue collar vs. white collar)

We see the following steps to choose the best way to model User Groups:

  1. Choose at most two dimensions: Even if there is a perceived need to cover more, remember that the Application Owners have to maintain the mapping. Often it is even better to get one dimension right instead of two only 50%.

Best Practice:

Ask yourself: What do I want to see in the Application Matrix, if I had to choose among those four dimensions.

  1. Flat vs. Hierarchy: If you have chosen one dimension, the only question is the number of levels in the hierarchy. Often, two levels is a good compromise between expressiveness and maintenance effort. Remember that you can always get more granular later on if required.

If you have chosen two or even more dimensions, your major design choices are:

a) Flat: Separate the different dimensions by tag (e.g. Country and Organisational Entity), and let the application owner assign User Groups of both dimensions. This has the advantage that you can choose in the Application Matrix which dimension you want to see but requires good guidance for the Application Owners.

b) Hierarchical: Combine the dimensions, e.g. Level 1 is Organisational Entity and Level 2 is Country. This is often preferable as it is easier for the Application Owner to maintain, even if it might mean that you sacrifice some expressiveness.


  • Org Entity A
    • EU
    • APAC
    • US
  • Org Entity B
    • EU
    • APAC
    • US

Best Practice:

Always set yourself in the shoes of the Application Owner. What makes their life easier? In the end, the more comprehensive it is for them, the higher your data quality.

Depending on this, Org Entity / Country might be more appropriate than Country / Org Entity, or vice versa.


A configuration of the data model allows you to introduce a separate Fact Sheet type, e.g. Organisational Entity. See https://docs.leanix.net/v4.0/docs/configuration for more information, but use with care as extending the data model might influence usability.

Data Object Modeling

In this section, we offer you a best practice Data Object model to upload into your workspace.


Data Objects are used in LeanIX to provide an overview of general Data that is processed and exchanged by certain Applications. The Data Model itself is rather stable at this level. It can be further classified into personally identifiable data (e.g. to cater a GDPR use case) or according to its security needs. Also, the definition of CRUD operation on certain Data Objects and their related Applications is a vital use case to prepare migration projects. In the Poster below, we have included tips and best practices on what is important for using Data Objects.

For downloading the poster in high resolution follow the link below:

Best Practice to Define Data Objects

Prefilled Best Practice Import

Uploading this standard model to your workspace will enable you to set up an Application Landscape quickly and get into use cases like Integration Management or GDPR Compliance Management.


Please reach out to your Customer Success Manager or [email protected] to get your pre-filled Excel that includes the Technology Stack from the poster above.

Visualize Your Data Objects

Best Practice

The factsheet map report allows you to build out and discuss your data object hierarchy in a visual way.

Interfaces Modeling

The Interface Fact Sheet addresses the Integration Architecture Management use case and can be used in combination with the Interface Circle Map and Data Flow Report. Learn more about the basic use case here:

Integration Architecture Management in LeanIX

The main idea behind the Interface Fact Sheet is to take a business perspective. Typical questions raised are:

  • How are Data Objects exchanged?
  • How are Applications related?
  • What needs to be regarded within a Project?

Customers use it also for more technical use cases (e.g. which Web Services are offered), but often the business use cases are more prominent.

Dataflow vs. Provider / Consumer
An Interface in LeanIX is related to Applications in two ways:

  • An Interface can have one Provider Application
  • An Interface can have many Consumer Applications

Provider / Consumer do not refer to data flow (there is an extra attribute, which is also evaluated in the Data Flow report), but typically to ownership and to change management. Good examples are:

  • The public LeanIX REST API (similar to any other public API) would have LeanIX as providing Application. The API is only changed if LeanIX is changed (e.g. updated to a new major version). Depending on your context, there could be consumers - but since it is a public API it might be also valid to leave the consumers empty as you don't know all
  • If a system is providing a web service, then the system is the providing Application.
    For other technologies (e.g. FTP), it is not as straightforward to argue about provider and consumer - here it is good practice to define clear conventions for your organization.

Why is there only one Provider Application?
Please see above - the Provider relation refers to the Application where the Interface belongs to, and to which Change Management process it is tied. Hence it makes sense to have only one "owning" application.

Middleware - Application or IT Component?
A typical design question for Interfaces is how to handle middleware (e.g. an ESB like SAP PI or webmethods). It is good practice to regard a middleware not as an Application, but as an IT Component, for the following reasons:

  • Business View: Often, customers want to see the direct connection between two application, e.g. if they are exchanging account data. The middleware as application makes it harder to execute analyses like this, e.g. with the Data Flow report
  • Consistent definition of an Application: A good rule-of-thumb whether a system should be an Application in LeanIX is whether it has a business user and a business capability it supports. Arguably, both are not true for a middleware. Hence, including a middleware as Application blurs the consistency of your Application list.

How to model Interface technology?
There are two good ways to model technology for an Interface:

  • As Tag Group: The advantage is that it can be displayed very prominently at the Interface Fact Sheet.
  • As IT Component: The advantage is that you have the opportunity to reconcile it with other IT Components, and to display the technology in the Data Flow report.

IT Components / Hosting Modeling

Modeling the hosting of applications is a typical question for Enterprise Architect of all maturities and industries. While you can spend years to discuss the 100% right model that captures all corner-cases, this section gives you a step-by-step guide, depending on what you want to manage.

The starter way

Especially in the first weeks, less is more when it comes to the effort you need to invest. Start out with the following simple approach:

  • Create a tag group Application Hosting, and assign values On-Premises / SaaS / PaaS / IaaS
  • Assign the colors in relation to your IT strategy. If you have e.g. the paradigm to go "cloud-first", make On-premises red
  • Assign the tags to your Application Fact Sheets, e.g. with a simple XLS upload
  • The Application Landscape and Matrix report give you an immediate overview when choosing the view "Application Hosting"
  • Filter the Application Roadmap report by the tag group, e.g. to show all lifecycles on On-Premises applications in case you want to get rid of them

The pragmatic way

The starter way gives you an overview, but leaves out the details. In the next step, often the following questions occur:

  • Which kind of hosting services do I have?
  • Who is responsible for it?
  • What kind of services do I want to keep, what do I want to get rid of, and how?
  • Which costs and SLAs are assigned to hosting services?

To answer this questions, assign one IT Component of type "Service" to each of your Application. Again, this can be done easily via XLS. Group the IT Components by summarizing those with shared responsibilities and lifecycles. You might end up with e.g. the following list of IT Components:

* SLA Gold On-Premises Application Hosting
* SLA Silver On-Premises Application Hosting
* SLA Bronze On-Premises Application Hosting
* SaaS 1 (e.g. "LeanIX SaaS")
* SaaS 2 (e.g. "Signavio SaaS")
* ...
* PaaS 1 (e.g. "force.com")
* PaaS 2 (e.g. "ServiceNow")
* IaaS 1 (e.g. "Amazon EC2")
* IaaS 2 (e.g. "Microsoft Azure")

Best Practice:

At that stage, try to keep the number of IT Components as low as possible. You might want to summarize e.g. all On-Premises hosting services into few IT Components to keep maintenance effort low.

Assign a responsible, a support lifecycle and a value of a tag group (Strategic / Tolerate / Eliminate) to each IT Component. If ServiceNow is still on an old release, the lifecycle might be already "phase-out". Assign all IT Components to a Tech. Stack. e.g. "Hosting". You now have:

  • An IT Component landscape to access the degree of cloud adoption (hint: color-code "Eliminate" with red)
  • The option to filter the Application Roadmap by hosting type (e.g. show me all applications hosted on EC2)
  • The option to do a high-level impact analysis (e.g. what happens if force.com has a downtime), e.g. in the visualizer
  • The option to allocate costs to the IT Components and to use the Application Landscape with view "IT Component Cost" or the Business Capability Cost Report to get an overview on the distribution of run costs

Best Practice:

Despite the IT Components, consider keeping the "Application Hosting" tag group on the Application Fact Sheet. Although redundant, it keeps the hosting prominent, e.g. in the Application Landscape and Matrix.

The full-fledged way

If you want to look into further details, you now need to distinguish between hosting options and introduce IT Components of type Software and Hardware.


The lifecycles of Hardware and Software IT Components can be obtained and maintained comfortably via our Technopedia Integration - see https://docs.leanix.net/v4.0/docs/technopedia-integration.

a) On-Premises
Typical questions for on-premises hosted software include:

  • Who is responsible for SW development and maintenance?
  • What SW versions are used, are they imposing technical risk?
  • What HW versions are used, are they imposing technical risk?

Typically, one Application is linked directly or indirectly to more than one IT Component of type SW and HW, e.g. to a database running on one type of hardware, and an application server on the second.

Customers typically apply one of two scenarios:
a1) IT-Services: Link the Application Fact Sheet to only one IT Component of type Service, e.g. "Application 1 Hosting & Maintainance". Link used Software and Hardware via "required" to this service. Keep the cost only at the service by aggregating it manually. By this, you keep the life of the Application Owner simple, you can analyze and consolidate the provided services while still using the Technology Risk and Cost views in the Application Landscape / Matrix
a2) Direct linkage to Application: Link the Application Fact Sheet directly to IT Components of type Software and Hardware. This increases the expressiveness of the Application Fact Sheet, but also the amount of work for the Application Owner to collect data initially and keep data quality high.

Best Practice:

In case of doubt, start with option a2) to simplify the task of the Application Owner. Move only to a1) if it adds concrete value.

b) SaaS
In term of managing hosting, SaaS is the easiest. As you get the entire service from one vendor (e.g. LeanIX), it is best practice only to model one IT Component of type Service. To this, you can attach lifecycles, responsibilities, costs or SLAs.

c) IaaS and PaaS
For IaaS and PaaS, you typically manage two aspects: The IaaS / PaaS provider (e.g. force.com, Amazon EC2) and the deployed software. A best practice set of IT Components for one Application includes the following:

  • an IT Component of type SW to manage the deployed version (incl. link to Technopedia if available)
  • an IT Component of type Service to manage development & maintenance, which is linked to an internal or external provider
  • an IT Component of type Service to manage hosting

In contrast to case a), the number of IT Components is in most cases limited to these three. Further, these questions are typically well-answerable by an Application Owner. Hence, direct linkage is a good practice combining expressiveness and maintainability:

|_ Software
|_ Hosting Service
|_ Development & Maintainance Service


Be careful when using interlinkage within the three IT Components. This often creates more confusion than value. In many cases, linking Software to Hosting Services via Application is more than sufficient.

Best Practice:

Consider keeping the "Application Hosting" tag group on the Application Fact Sheet or tagging the Hosting Service IT Components similarly. Although redundant, it keeps the hosting prominent.


Q: Why to use "requires" instead of "parent/child" to relate IT Components with each other?
A: The "requires" relation is evaluated in the Technology Risk view. It also allows you to capture n:m relations which is not possible with parent/child.

Q: In case of IaaS / PaaS with multiple hosting options (e.g. the same software is provisioned via Azure and via AWS) should different IT Components be used?
A: Only use different Fact Sheets if it adds concrete value. If it's the same software version, it should be one Fact Sheet (as a rule of thumb).

Q: Should I model instances of IT Components?
A: Generally, it is often good practice to stick to classes (e.g. "Oracle DB 11.2" as Software, instead of "Oracle DB 11.2 hosted on AWS instance xyz". The effort to maintain instances is much higher. In case there is a concrete business case, consider to use Configuration (see https://docs.leanix.net/docs/configuration#section-configuration-add-ons), e.g. to create a new Fact Sheet Type "Instance" to keep expressiveness high.

Technology Stack Modeling

In this section, we offer you a best practice technology stack model to upload into your workspace.


The Technology Stack is used to group IT Components into different categories of Technology. This could be e.g. a Database, an Operating System or a Web Server. The Technology Stack model is rather stable over time and independent from a specific industry.
Whether you are in the banking industry, insurance industry, automotive, or logistics, our generic Technology Stack is the perfect starting point. In the Poster below, we have included tips and best practices on how to get started with Technology Stacks to create a complete overview of your technology landscape.

See a preview of the poster here:

For downloading the poster in high resolution follow the link below:

Best Practice to Define Technology Stacks

Prefilled Best Practice Import

Uploading this standard model to your workspace will enable you to set up an IT Component Landscape quickly and get into use-cases like Standards Management or Technology Obsolescence Management.


Please reach out to your Customer Success Manager or [email protected] to get your pre-filled Excel that includes the Technology Stack from the poster above.

Updated about 3 hours ago

Modeling Guidelines

In this section, we want to give an overview of certain modeling guidelines within LeanIX. Our target is to get you a clear idea how to make use of LeanIX structure and features in order to unfold its whole potential.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.