Organization

📘

These modeling guidelines are for the Meta Model v4. For Meta Model v3 guidelines, see Modeling: User Group.

Definition

Organizations represent the users/owners of Applications that can be modeled within different dimensions to create hierarchical structures.

Description

The Organization Fact Sheet type is an essential element to represent your organization’s business architecture in LeanIX; it should be used from the beginning as it allows you to get some basic views to understand synergies and gaps in the application landscape across different parts of the organization.

Overview of all relations to/from Organization:

Organizations Fact Sheet subtypes

Organizations are intended to address who is using certain applications. In LeanIX, you can use the following 5 Fact Sheet subtypes for the five major dimensions that LeanIX customers typically capture:

• Business Unit: Business Units are distinct divisions within a larger organization.
  Example: Retail
• Customer: Customers represent customer groups/segments with similar needs.
  Example: Buyer Persona
• Region: Regions represent geographical divisions within a larger organization and/or business unit.
  Example: Europe, Europe / France
• Legal Entity: Legal Entities are organizations recognized by law as distinct entities.
  Example: LeanIX SARL
• Team: Teams are groups of users/owners that are typically part of specific Business Units / Countries.
  Example: Team Igniteus

📘

For a step-by-step guide to create the Fact Sheet subtype, see Create Fact Sheet Subtype.

Guidelines and Best Practices

• Start by thinking: How do you want to structure your organization in LeanIX? What is the most meaningful structure?
• Work backward and ask yourself: What would I want to see in the Application Matrix if I had to choose among those four dimensions?
• Ideally, you can align on one dimension (Fact Sheet subtype) to keep it as simple as possible. Large organizations often look at two dimensions.
• Choose max. two dimensions (Fact Sheet subtypes): Even if there is a perceived need to cover more, remember that the Application Owners have to maintain the mapping. Getting one group right is better than having two or more incomplete or inaccurate ones.
• Flat list vs. deep hierarchy: In most cases, two levels are a good compromise between expressiveness and maintenance effort. Remember that you can always get more granular later on if required.
• Always put yourself in the shoes of Application Owners. What will make their lives easier? The more recognizable the structure is for them, the more likely they will contribute and ensure the high quality of your data quality.
• Depending on your conclusions, Legal Entity / Region might be more appropriate than Region / Legal Entity, or vice versa.
• As a general rule of thumb, stay within 5-10 items on level 1.
• If you need to model developers or development teams, projects, or the community. We recommend modeling this using the Team subtype.
  • To accommodate in the Application Fact Sheet, you may want to add a new value for the Organization relation to the Usage Type field, e.g., Developer. Please refer to the Meta Model Configuration to add a new value in a field.

How to model Organization organized based on Regions and Business Units

In this example, we used LeanIX Diagrams (Free Draw) to create a visualization that shows an overview of regions and business units with Applications linked to those:

How to model Organization structured by Regions only

For this example, looking at the Application Matrix Report is helpful to see which Applications are used for which Business Capabilities in the different regions. This will help you understand, e.g., rationalization potential if other regions use various applications for the same capabilities:

Antipatterns

This section addresses antipatterns involving ineffective or counterproductive ways of modeling Organizations in LeanIX.

• Data centers should not be modeled as Organizations but as IT Components in LeanIX.
• Don’t try to reflect your fine-granular organizational structure to avoid failing because of complexity. It is always a trade-off between the degree of detail and data maintenance. E.g., going down to such detail as teams might be well thought through since teams might merge/split/change names often.
• Don’t confuse organizations with subscriptions. Subscribers/subscription roles are not modeled as a Fact Sheet type but maintained as an attribute of the Fact Sheet.

Applicable Use Cases

LeanIX recommends using the Fact Sheet type Organization for all use cases, including the initial Application Portfolio Assessment.

Especially for large transformation cases (e.g., Application Modernization or ERP transformation) in which you would use the LeanIX Architecture and Road Map Planning, Organization is a central Fact Sheet type to reflect the planning and rolling out of technology changes to various Business Units or Regions.

Insights from Organization Fact Sheet

You can leverage Matrix Report to see how the organization structure you modeled utilized your applications. This can be useful to identify application redundancy in different locations of your organization. This will be beneficial for your Application Portfolio Assessment initiatives.

Further Resources

• IT Component Modeling Guidelines
• Objective Modeling Guidelines
• Business Context Modeling Guidelines