HI @KevinR , 

My usual guidance on the topic is that Software is usually something centrally hosted and that you most of the time have to install, while services are usually a “on-demand” type of case that you access, like a SaaS, or something custom developed like a micro-service. 

If you notice, once you link an Application to our SaaS Catalog, it creates an IT Component of the Service type. 

Does that help? Any examples in specific that you have in mind?

Hi @KevinR,

We define Service to be an internally built and deployed microservice, which aligns somewhat with the guidance from @fabiana.santos above.  However, we differ in that we define Software as an externally sourced component (either deployed internally or SaaS hosted), that can be linked to external lifecycle facts via the Lifecycle Catalog.

Our lens so far has been what is discoverable by other tools (like ServiceNow) versus what is not. This seems to align with what @fabiana.santos said. We would look at the discovery-enabled system as the source of truth for version and status (among other things) and send that information to LeanIX for capture as an ITC/Software fact sheet. Things that are not discoverable, like SaaS solutions (although this is arguable), would be ITC/Service fact sheets.

I may be adding to the confusion here, but there it goes nothing

My mental model is: business capabilities ← technology services ← applications ← technology components

So business capabilities are enable / automated by technology services which are provided by applications that are made by technology components.

But there is another angle on technology components: things you install and own, which typically have SKUs and are discoverable, and things provided by external entities you buy / subscribe to (e.g. security bulletins), which typically are not discoverable.

Thing is, “service” is such an overloaded term