Great topic! We went live with LeanIX EAM about 9 months ago, and this was - and continues to be - a struggle for us. Because we knew that it would be a challenge to get owners to maintain their fact sheets, we made the conscious decision to NOT dual-model. I think that was the right decision for us at our current state of maturity. But that either/or mentality of App or ITC has its challenges. FWIW, here are our definitions. I look forward to seeing what others have done!

Hi @KevinR,

This is a great topic, one that we have struggled with over time as well. Our definitions have room for improvement.

I like the approach @BrianK took, providing characteristics of each and some examples. 

Thanks for raising the topic.

This topic also continues to be a challenge for us.  The definitions we’re following:

What also comes into the decision about whether something is an app or ITC is whether or not the “thing” can be related to a business capability OR a technical category.    @KevinR I like the idea of the decision tree and would love to see that.

This decision tree addresses both what types of fact sheets to create and how to model them.  I hope this spawns some good conversation. I’d appreciate the opinions of the smart people on this forum to make it better.

This decision tree addresses both what types of fact sheets to create and how to model them.  I hope this spawns some good conversation. I’d appreciate the opinions of the smart people on this forum to make it better.

 

I think it works for me Kevin, thanks for sharing!

If I may, have you consider cases such as security bulletins (our security team subscribes to a few of them)? They incur in costs and provide a service, so curious how you’d model them?

Thanks

Roberto

Thank you all for sharing your definitions and knowledge on this topic. We’ve incorporated parts of your definitions and examples into improvements to our user documentation. The update will be published soon.

@KevinR In case you might be managing the multiple instances of applications (mentioned in the decision tree) in a CMDB/ServiceNow and do see value in having those visible in LeanIX EAM, you could consider introducing our recommended subtypes of Applications to model Deployments.

What are the approaches for modelling shared/common/platform components.  For example, we have a custom-developed Identity & Access Management service which is used by many of our applications.  The IAM service itself has a tech stack (IT Components) that it is built with.  We’re currently “double modelling” it - once as an application with relationships to the underlying IT Components (Okta, PostgreSQL, etc.). and again as an IT Component, which has relationships to all of the Applications which are using it.

Interested in other approaches.

Just sharing with the community our attempt at trying to distil the difference down in a simple diagram. [v0.9 :) ]

Thanks for the information and ideas from this and others post around this subject.

Thoughts and comments welcomed.

Great topic, and it took me a few years to establish the model that is in use today.

I will use the following example to illustrate that model.

Background:

We are a true global organization with multiple instances of SAP around the globe. Each of those instances have their purpose, localizations and unique identifier but they all run on the same foundation application - SAP ECC 6.0, provided by SAP.

So this is how we have them organized on LeanIX.

• Each of these instances is identified with an Application Factsheet with identified Business Capabilities, User Groups, and Application Owners assigned.
• SAP ECC 6.0 is identified as one of the IT Component, with other assigned IT Components being the Server, the OS and Database it is hosted on.
• SAP is identified as the Provider.

I hope this helps.

Regards,

NikG

Fully agree with you @NikGee - We have a catch for that exact scenario.  In your case, your SAP ECC is both an Application, so ‘ERP Europe, ERP USA, and an IT Component: ‘SAP ECC 6.0’
 

Jacques