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.
LeanIX EAS Data Model
The following table contains definitions of the out-of-the-box Fact Sheets:
Providers are 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 components represent 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.
Technology stack 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,
e.g. organizational entities, locations or customers.
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.
LeanIX CI Data Model
A Cloud Component is any service that can be provisioned from a Cloud Vendor (AWS, Azure, GCP), e.g. a Virtual Machine, a storage bucket, an API Gateway or a machine learning service
The Technology Business Management category represents an independent, best practice grouping
The mapping of Cloud Components to categories is automatically imported
The Cloud Service represents the vendor-specific category (e.g. AWS S3 for storage)
Relations to Cloud Component and TBM Category are automatically imported
Represents where the Cloud Component is hosted
Represents the technical ownership of the Cloud Component
Can be multi-level & vendor specific, e.g. Organization + Account for AWS, or Folder + Project for GCP
Represents the business context of the Cloud Component
Maps to Application / Microservice in the EAMS world
Does not contain full Application information in Cloud Intelligence, but rather links to EAMS
Captures security, availability, performance and other warnings, and link them to the respective Cloud Components
LeanIX MI Data Model
Domain is a representation of a logical clustering of managed Microservices. LeanIX gives the flexibility of representing a technical domain such as the front end or backend, or representing a business-drive domain such as some domain related to a business capability that tracks what the Application does in order to support your business goals.
EAS (if Business Capability)
Application is the representation of the business applications that are served to the end user. They are connected to and often come from the very applications defined in a LeanIX Enterprise Architecture workspace, being implemented with the help of 1..n Microservices. See the end result of combined Microservices together in the Application fact sheet.
Team is the responsible development team behind the application. By being related to the domain at the same time, you have a combined view over the organization supporting your Microservices.
Microservice is the central entity in Microservice Intelligence as it provides a link to the business organization on one hand while simultaneously giving you oversight on the underlying technical infrastructure of the microservice. By placing the microservice at the center of the model, you now have a holistic view over what your development organization is building. The microservice fact sheet is a representation of a service itself, not the deployments that are instances of the service. For this view, please take a look at the deployment fact sheet in Microservice Intelligence.
Kubernetes (e.g. via namespace, via label)
API covers the offered and consumed APIs of the microservices. Understand what is the data flow amongst the API and the microservice. Or have a top-down view to see what's the architecture that runs under your APIs.
Various - can be discussed in detail
Data Object is the object that is being transferred from an API, e.g. a survey result from a polling API. By having your Data Objects in the workspace, you have decreased redundancies across the organization while maintaining a secure hold of your data.
Deployment is the fact sheet which shows the way in which the Microservice specified under the Microservice fact sheet (e.g. on a certain Kubernetes Cluster) is being served to the end user. This allows you to see all the deployments under a given Microservice.
Custom integration (e.g. to Application Server)
Compute Environment shows the environment in which deployments are ran, e.g. a Kubernetes Cluster. Understanding the surrounding environment of your microservice allows you to take decisive actions from the start instead of gathering this information every time you need to troubleshoot. Potential linkage to Cloud Intelligence
Custom integration (e.g. to Application Server)
Library contains the software libraries used by a certain microservice deployment. They help reduce your software footprint and standardize what's being used to create microservices. Reduce risky dependancies and proactively update them with the knowledge gained from this fact sheet.
Technical Components is thought of as the set of dependencies captured outside of the library fact sheet, e.g. a Kubernetes CRD or Volume. Model a complete overview of underlying technical risk with the technical component and library fact sheet combined.
Custom integration (e.g. to Application Server)
Violation Types are the classes of security or other violations that are raised in a hyperscaler or security tool. Knowing what topics to focus on decreases deployment times of critical fixes to the microservice.
Violation is the concrete instances of violation types, including the mitigation state. Take active control of your pressing risks and raise awareness to the entire organization.
Updated about a month ago