Hi Everyone!
A key focus in onboarding isn’t just importing your Applications, but modeling them correctly. One of the more frequent use cases we encounter has to do with monolithic Applications (Microsoft, Salesforce, SAP ECC, etc.), specifically when does it actually make sense to model them out using a Parent/Child hierarchy?
There are a few considerations we recommend taking into account when making that decision, with the first being…
Business Capability and Organization relations
- When it comes to making these relations in LeanIX, our rule of thumb is to always relate things to the lowest applicable hierarchal level.
- Take a common L1 application, like Salesforce, for example. We could relate BCs such as Marketing & Sales, Finance, etc. to Salesforce and that’d technically be true, but what information are we actually missing out on here? In the image below you’ll get an idea of what exactly we are talking about - being able to relate the Marketing & Sales BC to Marketing Cloud and Sales Cloud (L2 Applications) gives us a better idea of what specifically these Apps are doing for your business, as well as who is using them.
- Another key benefit here is traceability. By linking Business Capabilities and Organizational Units to L2 applications, you not only improve reporting accuracy but also gain greater insights into accountability and ownership. This ensures you know exactly which team is leveraging which part of a platform and how it contributes to business outcomes.
Tip: When in doubt, ask yourself: would a business stakeholder benefit from seeing the relation at a more detailed level? If yes, model at L2.
Our second consideration is when our Application modules may be purchased separately.
- While this isn’t something we ask you to consider in Onboarding, we recognize that cost reporting is an integral part of your LeanIX use cases and is something we want to be mindful of in the future.
- In the above example, it’d make more sense to understand the individual cost of each module, rather than just have the total cost of the parent (Salesforce) in your workspace. You can use this approach to compare cost vs. value across modules. For example, if Marketing Cloud is very costly but used by only a small team, that visibility may trigger a discussion about consolidation or alternative tools. Without modeling at L2, those insights would be hidden.
The last thing to think about is governance. Too much granularity too early can create unnecessary complexity and slow down adoption. Start small, focus on platforms that are widely used, expensive, or business-critical, and refine from there.
It’s also important to align internally on a clear naming convention and hierarchy guidelines. Without this, different teams may model L2s inconsistently, which could reduce the value of your reports.
We hope this informations helps everyone get a leg up early on Application Modeling! Feel free to express any thoughts below, and the Onboarding Team will be available at leanix_customer_success@sap.com to help directly with any questions.