The LeanIX platform offers a flexible data model which can be configured to the needs of the customer. Mostly, customers benefit from the out-of-the-box best practices, but often it's important to understand the options to adapt the model once maturity is growing.
This section intends to clarify the terminology used by our team to avoid misunderstandings.
Fact Sheet: The entities represented in LeanIX are called Fact Sheets, to resemble the notion that they should make all information for an entity easily accessible in the inventory.
All Fact Sheets have common functionality:
- Hierarchy (per default up to level 3, can be extended up to level 10)
- Subscribed users incl. role
- Linked documents
- Audit Trail
Fact Sheet Type: Each entity has a type. On type level, connection, attributes, access and much more is defined. They are the basic building block of our data model.
Display Name: Is the name of the fact sheet that is displayed on the top of the fact sheet. It can simply be the name or a combination of name, hierarchy, version numbers and many other fields.
Section: Is the major section of a fact sheet which consists of one or several subsections. All the information stored in LeanIX is organized in sections. Sections are usually used to organize different information blocks on a fact sheet.
Subsection: Is the minor section of a fact sheet which consists either of fields or relations and is always part of a section. Subsections serve the purpose of dividing sections into more readable smaller blocks of information.
The LeanIX data model can be configured based on adapting the following internal models:
The Data Model allows adding new Attributes (e.g. Text, Number, Single Select, Multi Select), Relations, Fact Sheets, External IDs and Validators. Standard functionality is available for all new Elements (Filter, Table View, Import / Export, Survey, Dashboard, Accessibility via GraphQL API).
The View Model allows changing the appearance of each single Fact Sheet Type by fine-tuning the look of existing and new elements (e.g. assign symbols and colors to Single-Select Fields, control per attribute whether it is included in completeness calculation).
The Translation Models allow individualizing help texts, label, section names, report names and more. Different languages are supported - currently EN, DE, ES, and FR in the standard model.
The Authorization Model allows to fine-tune existing roles (e.g. make a certain attribute only editable by an Admin) or creating an entirely new role with certain privileges.
The Reporting Model allows changing the menu structure for existing and of custom reports, as well as configuring own Matrix, Landscape, World-Map or Roadmap reports.
For more detailed information regarding Configuration including, how to create a Configuration request, please see the Configuration Overview in the User Documentation.
Some example adoptions of the Enterprise Architecture Data Model are shown below.
Next to role-based authentication, LeanIX also offers Virtual Workspaces for read- and write-segregation.
Per default LeanIX has three authorization roles: VIEWER, MEMBER, ADMIN. These roles can be adjusted and new roles can be added.
The following adjustments are possible:
Adjustment on a per fact sheet type level: READ, UPDATE, CREATE, DELETE, IMPORT, EXPORT for a certain fact sheet type
Adjustment on a field or relation level: READ, UPDATE, CREATE, DELETE fields or relations for a certain fact sheet type
Adjustments on relation field level: READ, UPDATE, CREATE, DELETE fields on a particular relation for a certain fact sheet type
Subscriptions: READ, UPDATE, CREATE, DELETE subscriptions.
Tag Groups and Tags: READ, UPDATE, CREATE, DELETE complete tag groups and individual tags.
Bookmarks: READ, UPDATE, CREATE, DELETE bookmarks per bookmark sharing type (private, published, public)
To add new roles to the authorization model requires some preparation. Since the LeanIX only supports the three base roles, any further roles require an SSO setup with externally managed roles.
In case you are considering to adjust the authorization model, please discuss your use case with your CSM or CSE.
Please see Authorization Model for more detailed information.
In order to fully leverage the capabilities of LeanIX's platform offering, it is important to understand how the range of different LeanIX EAM objects fit together. Below you will find the core entities, we call them Fact Sheets, and their relationships, as well as detailed descriptions below.
The following table contains definitions of the out-of-the-box Fact Sheets:
Provider is used to capture who is responsible for hosting, maintaining and changing your applications. For this purpose, they are linked to IT components and projects to manage provider costs and relations.
IT component represents the technology your applications depend on. They can provide information on both development & operations. IT components are grouped into services, software & hardware. They are used to model operating costs as well as technological risks.
Tech Category fact sheets are technical domains and allow to classify the IT components by technical characteristics. This classification can be used to govern your IT-landscape from the technical side, e.g. by analyses via the IT component landscape report.
Data objects represent a business view on major data entities used, e.g. customer, employees or contracts. Data objects are transferred or managed by applications. They help to identify redundancies & for data security or analytics questions.
Applications are the central entities in LeanIX as they provide the link between business and IT. An application is used by a user group in a business context (capability / process) and is developed & operated based on IT components.
Interfaces are connections between Applications. They transfer data objects and are implemented via IT components.
Projects groups activities which change the application portfolio over time. They allow to make dependencies, schedules and costs transparent, e.g. synchronized with a PPM tool.
User groups model who uses your application. By relating them to capabilities and processes, you get powerful business support output. User groups can be modelled among different dimensions,
Business capabilities (also called domains) model what your applications do in order to support your business goals. Business capabilities are typically nested to allow analyses at different granularity level, e.g. with the application landscape report.
Processes model 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 modelling tool. Out-of-the-box integrations, e.g. to Signavio, are provided.
Updated 16 days ago