Provider/Vendor Design

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.

​@Mohamad Alsughiar Are there any recommendations regarding how to capture costs for products like SQL Server or Windows Server licenses. Our use case is as follows:

1. We have a single line item for Windows Server licensing in our agreement. Say 500 licenses for $200,000 annually.
2. Several applications are reliant on different Windows Servers - different versions. Not all 500 licenses are in use. 
3. There is no desire and requirement to split and allocate the Windows Server costs across these applications. Just tracking it at the product level (Windows Server) and rolling up to Provider (Microsoft) is sufficient.

Per my understanding, the costs are captured on App > ITC relationship. We would like to avoid creating a dummy application for Windows Servers. Where / how can this cost be captured without creating custom fields?