Hi Angelita,

You are correct in that the Provider fact sheet is meant to be related to IT Components, not to Applications directly.  Applications should be related to IT Components, and IT Components to Providers.  As such, there is an “indirect” relation between the Applications and the Providers, through the IT Component.

I am pasting below a response from a similar post in our community, from another customer of ours, which is in line with our best practice:

“This is generically the approach we take:

1. Each service provider/business partner is defined as a Provider.
2. Each service that they provide is defined as Service ITC, related to the Provider.
3. If there is an interface between one of our Applications and the business partner (eg, they send us a file at some interval) which we would like to capture, we then do:
   1. Define an “umbrella” application (we call it *EXTERNAL-SERVICES) and use it as the Interface provider/consumer. We do not really care what “application” the provider has, since no one in the business interacts with it.
   2. Link the Service ITC (see 2.) to the interface.

This gives us all we need, including any service costs against the *EXTERNAL-SERVICES “application” and the Provider.”

Aside from the above scenario, I have also seen a case where a customer has created a new fact sheet type to add to their meta model, which they referred to as “Vendor/Contractor” and they ultimately established a relation between the Vendor fact sheets and the Applications. 

I would recommend talking this through with your Customer Success Manager or your Customer Success Onboarding Manager to review specific use cases that pertain to your org, so that we can talk through all the pros and cons.  Noting that the biggest con I tend to see in creating a new fact sheet type is the maintenance of the new type (its fields and relations) and also the education internally of the new configuration.  Let us know if this helps! :)

Hey Angelita,

Thank you for the question, our best practice approach is that every Application should have an IT component whether it is SaaS or On-prem, this serves multiple purposes around cost management and tech risk use cases. Providers are always linked to IT Components, this is a consistent approach across all of our recommendations and features (e.g. catalogs). This is why we recommend not to directly link Applications to Providers, for more information on this from LeanIX side, feel free to check our documentations: https://docs-eam.leanix.net/docs/provider-modeling-guidelines.

In the past, in my own workspace, I experimented with adding a relation from the application fact sheet to the provider.
This allowed for filtering the Provider by application and then working towards a cost aggregation for that provider.

I’d recommend experimenting in your sandbox environment to prove out the details regarding total provider cost.
IE - Microsoft (Provider): Apps and ITCs aggregated to achieve the most accurate spend for Microsoft products/Yr.
I also collected license type/Count/cost on the application, and then used that for license rationalizations and a more itemized cost breakdown at the Provider level.
Feel free to ping me if you’d like to chat more on this topic.  (IE potential rationalization of chargeback to Business Units/Departments, etc)
Thank you / Vielen dank,
Rob Roff