Modeling Guidelines

📘

Important Information

This page is a modeling guideline for Meta Model v3. Updated guidelines for Meta Model v4 is available in the documentation.

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

Full Modeling Example - LeanIX as an Application

The following is a full-fledged modeling example based on LeanIX as an application. The screenshot below was created in the Diagrams section of the LeanIX workspace.

"LeanIX Enterprise Application Suite" is an Application. It operates within a business context, has business users and interfaces with 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 sub-steps "1. Project Setup" and "4. Architecture Review".
• Who is using LeanIX? Besides the "Headquarters", the User Groups "Australia" and "Brazil" are currently active.

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

From a hosting perspective, two IT Components have been modeled, both with a Provider and a Tech Category.

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

Finally, LeanIX is included in the scope of the Project "Introduction of Enterprise Architecture Management".

General Guidelines

Tags vs. Custom Attributes

📘

Information:

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. Be sure that the outcome exceeds the effort for each new tag or custom attribute added.

The following screenshot summarises the main properties of tags and custom attributes and where to find them in the Fact Sheet.

Both tags and custom attributes share three other major properties:

• You can access them via an 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 colours and use them as views in the reporting.

When to use a tag:

• It is good practice to use no 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).
• Use tags if you want to depict a status that is rather temporary since it is very easy and convenient to add/remove tags and entire groups

When to use a custom attribute:

• If you require other data types than a value list (e.g. a text area).
• If an attribute is only relevant to certain stakeholders or use cases, e.g. for Legal or GDPR cases, and you want to place it near the bottom of the Fact Sheet.
• If you want to limit access (read or write) to specific 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 between 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 Groups to build a clear regional structure: Europe / Western Europe / Netherlands (Europe = Level 1, Western Europe = Level 2, Netherlands = Level 3).
• Tech Category to build a clear Tech Category structure: Database / Relational Database (Database = Level 1, Relational Database = Level 2).

🚧

Attention:

Use hierarchies with care. More details always require more 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 Fact Sheet types

• Within the same fact sheet type: For example, a server requires an OS (operating system). These are both IT Components but only the server is directly linked to the Application. Using logical n:m dependencies, however, the "Technology Risk" view allows you to extract the information that the OS is also linked, albeit indirectly through the server. However, you cannot see the indirect connection in the technology risk view of the application matrix report.
• 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.

🚧

Attention:

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. In other instances, however, 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.