Enterprise Modelling to create Application Services/Service Instances

[SimonO375140483]

I hope someone can clarify whether I am doing something incorrect or just ServiceNow screwing with me.  I am attempting to model Business Application and a number of Service Instances (Application Services) using the Enterprise Modelling functionality.   This is currently in our Dev instance where we are running Zurich with Enterprise Modelling Common version 3.8.0 and Enterprise Modelling and Visualizing ver 6.8.0. 

When I add a new CSDM Application Services (Service Instance) item to the diagram and create a new item I fill in the prompted details (just name for speed).  As this is a new item the diagram needs to be Reviewed and Committed. Once committed the new Application Service is not created as an Application Service (csdm_app_services table), but as a Business Service (in the cmdb_ci_service table), we can change the Service Classification by this really has no effect as the Service is created in the wrong table AFAIAK.  Following this method, then blocks the creation of the Depends On/Used By relationship between these two entities. 

Can someone explain the difference between these two different 'Application Services', why we have two different methods of creating, and which type of Application Service should we be using. 

Is this a Bug in the Diagramming module or has something changed in how / where Application Services and now created since they have been reclassified into Service Instances. 

Thanks for your responses

Simon

[Johannes]

For those who want some technical insight:

csdm_app_services is just an alias for the table cmdb_ci_service_auto.
cmdb_ci_service_auto is the "real" table for Service Instance (formerly called Application Service). 
cmdb_ci_service_auto is an extended table of cmdb_ci_service, which is the base Service table.

"Service Classification" is an attribute/column on cmdb_ci_service and all tables extended from it. This attribute is mainly outdated, and was mostly relevant before the cmdb_ci_service table was extended. (Exception is Service Offering, which has still not been divided into separate Technology/Business Offering tables)

[mcastoe]

A little history as well.  The original data model (CSDM 1) for APM was Business Application Consumes "Service" i.e. cmdb_ci_service.  This was all before the expansion of Service into its behavior specific entity tables such Business Service, Application Service (now Service Instance) and so forth.   

When it comes to Service Instance, cmdb_ci_service_auto, you will now find many extensions of it as it is an abstract.    All of these variations such as Mapped Application Service, Calculated Application Service, Dynamic CI Group and also Network Service Instance are all possibly architecturally interesting.

Would it be of value to you as modelers to have these levels of Detail?   

[Mathew Hillyard]

Yes, the service classification field seems rather pointless now we have separate tables for every service entity. It also confuses customers no end. 

The main thing that doesn't work for me is not extending Service Offering. We have child Business and Technology Management Services but still a single table for Service Offering, which means we must look at the parent's class to work out what type of Offering it is - and this is despite showing separate types of Offering in the CSDM map. Service and Service Instance have extensions. One more thing that (IMHO) really needs to be fixed.

As an aside, I've not come across a single customer or peer who likes Service Instance as the replacement for Application Service. The reality is that a Service Instance is an instantiation of a Business Application - that is an Application Instance. Calling it a Service Instance makes people believe it is an instance of a Service, which is much more likely to be a Service Offering. Talk about confusing!