Business Service vs Technical Services (Delivery vs Management)

[Ashvini1]

Hello CSDM Experts,

We are trying to adopt to the definitions of services as provided in the CSDM v4 Data Model.

Business Services - Services exposed to business users, which could have user subscriptions

Technical Services - Services exposed to technology consumers.

If we overlay TBM taxonomy on CSDM, we get Business Services are services provided to External Users and Internal End Users. And Technical Services are like Platform, Infrastructure, Security (IT Services).

All of this makes sense.

Now within Technical Services, there could be two types of services we can provide to technology users.

1. Technical Outcome - Provide Compute, Open Firewall, Provide Identity Management Services, Provide Application Security Services, Enable Application Monitoring etc.

2. Management - managing of the tools and apps and infra that  is used to deliver a service.

In a true devops world, both the services are provided by the same team.

So how do you differentiate between a Technical Outcome type of technical service vs management type of technical service in CSDM.?

Do you create a additional field to differentiate the two?

Do we categorize outcomes/capabilities under Business Service?

Do we usually say IT only manages a tool or infrastructure, and it actually doesnt provide an outcome?

Some insights on this would be helpful

[Daniel Carvalho]

Hi Ashvini1

This matter always felt to me as very complex. I do not wish to deny your interpretation, but hoping to help, I will present my interpretation bellow.

By already having the CSDM4 diagram in mind, I would 1st recollect the tree structure from cmdb_ci_services and below:

• cmdb_ci_services (still SADLY called Business Service, could be renamed OOB to "BASE Services" or something like it)
• cmdb_ci_services > cmdb_ci_service_business (ALSO called Business Service)
• cmdb_ci_services > em_sla_configuration (I am not going to comment on this table called SLA Configuration)
• cmdb_ci_services > service_offering (Service Offering)
• cmdb_ci_services > cmdb_ci_service_group (Service Group)
• cmdb_ci_services > cmdb_ci_service_technical (in my view unfortunately called Technical Service)
• cmdb_ci_services > cmdb_ci_service_auto (questionably called Monitored Service)
• cmdb_ci_services > cmdb_ci_service_auto > cmdb_ci_query_based_service (VERY SADLY called Dynamic CI Group)
• cmdb_ci_services > cmdb_ci_service_auto > cmdb_ci_service_discovered (bad table name, good label name: Application Service)
• cmdb_ci_services > cmdb_ci_service_auto > cmdb_ci_alert_group (Alert Group)
• cmdb_ci_services > cmdb_ci_service_auto > cmdb_ci_service_manual (Manual Service)

All that remembering just to bring forward 3:

cmdb_ci_query_based_service (Dynamic CI Group) this data repository (table) USED to be called Technical Services about 3 years ago.

cmdb_ci_service_technical (Technical Service) this table/concept was created when the previous "lost" it´s original name, creating major confusion, for 2 reasons, in my view, DynCI is not good on communicating what it stands for in "daily business perspective", also created some insecurity on what someone is trying to say, when using the term "Technical Service"? Is it about the older approach or the current state?

cmdb_ci_service_discovered this table represent application instance/tenant/deployment, no much discussion around that, but it is key in terms of setting the "tone" on the level/layer of the data entry input, under the cmdb_ci_service tree, by comparison. An instance like "CRM - Production" would be stored 2 levels below cmdb_ci_service then.

That said, if you were to setup a CI for "Guest WIFI - Production" where we would fit it? It is not a biz app stack...

cmdb_ci_service_technical is not 2 levels below cmdb_ci_service, not under "Monitored Service" as feels like it should be.

So, my approach to this is to setup "Guest WIFI - Production" as the "old concept of technical service" THERFORE as cmdb_ci_query_based_service.

Note: in my prod instance I renamed cmdb_ci_query_based_service label to "Other Services (DynCI)", to make it more understandable to the common user.

Additional reasoning: all bellow "Monitored Service" is enforced by me, in the ORG I work, as services provided BY MACHINES (applications, printing, DHCP, wifi, biometrics etc.). I do not look at this by the angle of to whom it is being offered to.

Then, what is left for cmdb_ci_service_technical? Also not looking to whom it is being offered to; I understand this as services provided BY HUMANS. E.g. Database Administrators, End User Services/Helpdesk, etc. Specialized TECHNICAL manpower at work.

Is all this very perfect under the view of all CSDM guru´s from ServiceNow? I don´t know and I would guess there is a reasonable degree of divergence. But in defense of this, it seems very crystal clear to make sense of.

And what about cmdb_ci_services? I would not recommend it to be used directly, as well as it is not recommended to use cmdb_ci directly. Also If I am not mistaken, to prevent exactly this is why ServiceNow issued OOB the cmdb_ci_service_business extension.

To close up: what to do with cmdb_ci_service_business? In my interpretation, that is where you should find "higher level" services definitions, in business-driven terms. E.g.: a Mobile Phone Telco company has a post-paid signature plan. If a pre-paid customer wants to migrate into post-paid, a CREDIT ANALYSIS must occur. The proper department must CONSUME a business service of "Credit Check - Production". This Business Service may rely on several children of "Monitored Services", such as, per example, 02 Application Services (CRM-Prod, ERP-Prod) and 02 DynCI (Site-to-SiteVPN-Prod, which links the Telco to a Credit Bureau; and CreditBureau_EXT-Prod as an external solution to return data on credit risk).

Here, it is more clear to have a look on who consumes the service, since the HR department folks should not be linked to the business service of Credit Check.

Best of luck!

Daniel