Modeling: User Group
The User Group Fact Sheet is an essential part of LeanIX's approach to representing 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 gaps in the application landscape.
Important Information
This page is a modeling guideline for Meta Model v3. Updated guidelines for Meta Model v4 is available in the documentation.
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 territories)
- Divisional / Organizational Entities
- Legal structures
- User type structures (e.g. blue collar vs. white collar)
Here is how you can model User Groups:
- Choose two dimensions at most: Even if there is a perceived need to cover more, remember that the Application Owners have to maintain the mapping. It is better to get one group right rather than having two or more that are incomplete or inaccurate.
Best Practice
Ask yourself: What would I want to see in the Application Matrix if I had to choose among those four dimensions?
- Flat vs. Hierarchy: If you choose more than one dimension, you need to determine the number of hierarchy levels. In many cases, 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 choose two or even more dimensions, your major design choices are:
a) Flat: Separate different dimensions by tag (e.g. Country and Organizational Entity) and let the application owner assign User Groups to both dimensions. This allows you to choose the dimension you want to see on the Application Matrix but it also means Application Owners will need in-depth guidance.
b) Hierarchical: Combine dimensions, e.g. Level 1 is Organizational Entity and Level 2 is Country. This is often preferable as it is easier for the Application Owner to maintain, even if it means that you sacrifice some expressiveness.
Sample:
- Org Entity A
- EU
- APAC
- US
- Org Entity B
- EU
- APAC
- US
Best Practice
Always put yourself in the shoes of Application Owners. What will make their lives easier? In the end, the more comprehensive it is for them, the higher your data quality is.
Depending on your conclusions, Org Entity / Country might be more appropriate than Country / Org Entity, or vice versa.
Information
A configuration of the data model allows you to introduce a separate Fact Sheet type, e.g. Organizational Entity. See https://docs-eam.leanix.net/docs/configure-name-and-definition-of-a-factsheet for more information but use with care as extending the data model might influence usability.
Updated about 1 year ago