Meta Model
This page gives you an overview of the core beliefs related to the LeanIX Meta Model and basic concepts.
How to navigate:
- Check our General Modeling Guidelines and the guidelines for each individual Fact Sheet to learn the LeanIX modeling best practices according to v4. The Delta page is not relevant to you at all.
- If you are a customer who is using Meta Model v3 (or individual configurations based on v3): Check the Delta to Model v3 page if you want to understand what the key differences are.
Overview of the LeanIX Meta Model
LeanIX EAM has a predefined Meta Model that provides a fast time-to-value to start and maintain organizations' enterprise architecture work with LeanIX. It includes best practices and knowledge from our work with more than 1,000 customers and gives clear guidance on documenting all elements of your organization's enterprise architecture.
The LeanIX Meta Model is prescriptive: Our core belief is that using this Meta Model as a standard will provide maximum efficiency and long-term success for companies' Enterprise Architecture practices. Adopting this Meta Model will ensure the smooth realization of all LeanIX-recommended and -supported reporting and use case scenarios.
Although the Meta Model is fully configurable (explained in detail below), any modifications to the Meta Model will affect all your LeanIX modeling practices, reporting, etc. This may result in limitations for future use cases that might not be resolved standardized and efficiently.
Overview of the LeanIX Meta Model with examples
Information
Please note that LeanIX has updated its Meta Model v3 and is rolling out the evolved Meta Model v4 to workspaces for new customers. Existing customers who are using the Meta Model v3 are not obliged to migrate, but can decide proactively to use the Meta Model v4. Read this page for more background information on the changes and the delta between the Meta Model v3 and the Meta Model v4.
You can identify if you are leveraging the Meta Model v3 or the Meta Model v4 by the names of certain Fact Sheet types. If your workspace has Fact Sheet types such as User Group, Project and Process, it's based on the Meta Model v3.
Key concepts: Layers, Fact Sheets, Fact Sheet types, and subtypes
4 Layers of the LeanIX Meta Model
The LeanIX Meta Model v4 consists of 4 layers relevant to end-to-end business and technology transformations. However, you won't be able to find any references on the layers within our product. It is a mental model that helps you understand the context and value of the EA elements and how everything is connected in LeanIX:
- Strategy & Transformation: Contains Fact Sheet types Objective, Platform, Initiative
- Business Architecture: Contains Fact Sheet types Organization, Business Capability, Business Context
- Application & Data Architecture: Contains Fact Sheet types Data Object, Application, Interface
- Technical Architecture: Contains Fact Sheet types Provider, IT Component, Tech Category
Fact Sheet types
The fundamental building blocks of the LeanIX Meta Model are called Fact Sheet types. The 12 different Fact Sheet types in the Meta Model v4 are detailed below. On the type level, relations, attributes, subscriptions, tags, access, and more are defined.
The relation between the Fact Sheet types is reflected in the graphic below. It is essential to understand the relations when you are working with LeanIX as the relations predefine which Reports and insights you will be able to generate with LeanIX:
Fact Sheet subtypes
Subtypes are categories of Fact Sheet types used to group similar concepts. Subtypes share properties with other subtypes but have unique properties, e.g., attributes, relations.
Not all Fact Sheets types have predefined subtypes.
If a Fact Sheet has predefined subtypes, it is best practice always to use one (even if technically n/a is also allowed).
This overview shows the predefined subtypes in LeanIX:
Important
Please note that there are optional Fact Sheet subtypes of the Fact Sheet type Application that are not shown above that allow you to specifically model deployments of applications or microservices that are considered applications. For these, the following restrictions and terms need to be to considered:
- Deployment can only be added as an optional feature.
- Microservice can only be added as an optional feature. We recommend to use LeanIX VSM to document Microservices and integrate LeanIX VSM with EAM for automated aggregation in EAM.
- Business Application can only and should be used if Deployments/Microservices are used as well and will help to distinguish applications from deployments and microservices.
| Title | Layer | Definition |
|---|---|---|
| Objective | 1. Strategy & Transformation | Objectives capture the main strategic drivers affecting the architecture. |
| Platform | 1. Strategy & Transformation | Platforms are groupings of strategically relevant capabilities, applications, or technologies that drive simplification and help IT focus on business benefits. |
| Initiative | 1. Strategy & Transformation | Initiatives capture all types of changes in the architecture. |
| Organization | 2. Business Architecture | Organizations represent the users/owners of Applications that can be modeled within different dimensions to create hierarchical structures. |
| Business Capability | 2. Business Architecture | Business capabilities (also called domains) model what your applications do to support your business goals. |
| Business Context | 2. Business Architecture | Business contexts capture the core business dimensions to cluster & analyze by, e.g., processes, value streams, or business products. |
| Data Object | 3. Application & Data Architecture | Data Objects provides an overview of general data processed and exchanged by specific applications. |
| Application | 3. Application & Data Architecture | Applications are the central entities in LeanIX as they link business and IT. An organization uses an application to support business capabilities and contexts and is developed and operated based on IT components. |
| Interface | 3. Application & Data Architecture | Interfaces are connections between Applications. They transfer data objects and are implemented via IT Components. |
| Provider | 4. Technical architecture | Providers are external entities that deliver or provide IT Components. |
| IT Component | 4. Technical architecture | IT Components represent the technology or services your applications depend on. They can provide information on both development & operations. They are used to model operating costs as well as technological risks. |
| Tech Category | 4. Technical architecture | Tech Categories are used to group IT Components into different categories of technology. |
Best Practice
Since a Tech Category can be seen as a relatively stable structure, it will look similar for different companies. To start classifying your IT-Components using a Tech Category, you should look at our Best Practice Technology Stacks.
Please refer to Create Fact Sheet Subtype documentation page for a step-by-step guide to create the Fact Sheet subtype.
Is it possible to configure the LeanIX Meta Model?
Yes, the LeanIX Meta Model is fully configurable. However, we recommend that you work with the 12 provided Fact Sheet types as they have been proven across industries to represent an organization's enterprise architecture best and support standardization, collaboration, and simplification - which LeanIX stands for. Using the out-of-the-box Meta Model will help you implement best practices for lean Enterprise Architecture Management, saving you time and making internal documentation and enablement in your organization easier. Especially for organizations with lower EA maturity, it is recommended to stick to standards and best practices to streamline efforts and ensure a less disruptive EA journey. If you plan to customize your Meta Model, seek the support of LeanIX to get guidance on how to map the Meta Model best to suit your organization's requirements.
Check out the Configuration Overview for more detailed information on the options to configure the Meta Model.
Are Fact Sheet subtypes configurable?
We're refining several roadmap items, which aim to bring the current configuration capabilities on Fact Sheet types to subtypes. Examples include configuring conditional fields, configuring subtypes, configuring the authorization model for subtypes, and supporting the renaming of Fact Sheet types.
Is moving from the Meta Model v3 to the Meta Model v4 necessary?
You do not have to do anything if you use the LeanIX Meta Model v3. As LeanIX customers, you own your Meta Model and can decide whether to adopt the Meta Model v4 (or parts of it). With the support of your CSM, you can decide whether re-using the new predefined subtypes is the right approach from now on, in which case the new subtypes can be created / or simply by changing the Fact Sheet labels.
The Meta Model v4 has some advantages and will provide better clarity on modeling topics (e.g., Platforms, Products, and Business Architecture).
Check roadmap items and provide feedback
If you do not find a specific feature or functionality you expected regarding the Meta Model, please check and vote on our roadmap & let us know what is most important to you.
Updated 11 days ago