CSDM abstractions overload

[MitchMcln]

I am new to SN and struggle with CSDM 4 domains and multiple levels of abstractions. I can understand Business Application and its link to technical services that consist of CIs.  I am lost when Sell \ Consume domain is added with separate Business Service offering - Business Service  - Request Catalog and Service Portfolio.😶

Why need all of those and how are they different?   

Would be great to have a walk through based on simple scenario, like HR or some digital customer service how those domains help.

[Barry Kant · Accepted solution]

hi @MitchMcln ,

I use some tweaked models to make this easier to explain/understand:

There is a split in:
Plan/Build    - This is the Conceptual layer -->  these are not real solutions (yet) and therefore these objects do not play a role in eg ITSM transactional data. 
Deliver/Run - This is about real solutions. This data is what is managed and offered for consumption.

I made a split here in the orange domain as in:
the Run is a realization of a conceptual Business Application were the Application is the deployment on a Business Application. All of the below is needed to make it a solution. 
The Managed section is how we manage/support the part in the Run section. (Internal and External)
The Consumed section is how we offer the Run section for consumption. (Internal and External)

If you offer an application solution to the internal audience (eg a traditional on-prem application) the the consumers know this by eg App ABC. The solution might depend on :
Application support running via webserver (apache?) a DB (oracle) on a host (linux?). Meaning on the managed section you have :

• Application service
• Apache service
• Oracle service
• Linux service

If the Application is eg a SAAS solution then it is a more flat model of the solution (might be only Application support). 

If it is a modern solution then it also might be more flat as the managed service supports the vertical stack. 

Still the concept of the lower part of the model is the same:
I have Solutions that I offer for consumption and that needs to be managed/supported. 

Note:
were sometimes this is discussed on the standard output I tweaked it for this reason ( so these are my versions of the model to make it 'easy' )


Hope this helps. 

Barry

[MitchMcln]

Thanks Stig, some of that starting to make sense.

Why do you need to split green into bus service and bus service offering?  

Application offering is consuming Application service: what would be a good example to illustrate that? 

[baig]

Lets take example of PING which is platform application used to authenticate logins. 

End user has an issue with login one the application, and needs to report to PING Support.

End user goes to portal and search for Business Service which should be business friendly name like Identity Services, based on the selection of Business Service, the routing of ticket will happen by the Business Service Offering associated to Business Service, as the support group is on BSO.

Further BSO is linked to an AS, which is a CI. 

On Incident form, you have AS as a CI selected, BSO as Ping Support and Business Service as Identity serviced and assigned to Service Desk.

[Barry Kant]

hi BAIG,

not sure how the end user is registering a ticket. By portal record producer or VA the Service (Offering) are not always an option to select. Neither the CI level. So it depends. 

If there is a Service Offering in the record producer then in my opinion the Service Offering is sufficient as that can be limited by subscriptions. 
A Service Offering like PING Support is in my opinion more a Technical Offering. 
The Service could be Identity Service and maybe there are multiple ways to Identify then PING could be a Service Offering. In general Authentication is an underpinning service. Eg:

If a ServiceNow solution using PING as an authentication solution would the end user raise a ticket an ServiceNow or on PING (do they know the authentication is done via PING in that case?)?
In such scenario I would make PING AS a depends on relation to ServiceNow AS so it shows the dependency ( --> if PING has an issue ServiceNow authentication will fail). 

The routing on incidents is done by assignment rules mostly and that logic can be done by ticket content. Checking the most detail information (in this case the CI --> does that include a support group then assign it to that group if not then check Service Offering --> does that include a support group then assign it to that group if not then check the Service --> does that include a support group then assign it to that group if not then assign to a Service Desk. 

Something like this is what we see regularly. 

It can be combined with Category. EG:
If Service is ServiceNow and the Category is authentication. then it could potentially look at the depending Service Offering for Authentication Service and lookup the support group from there. 
This requires a more complicated lookup logic. 

so in the end it depends what an end user is able to register (sometimes it is just a description field then AI might be smart.)

Hope this helps a bit.

BR,
Barry

[baig]

Hi,

Great nice view.

What happens if i have multiple Application Services linked to a Business Application and one Business Service offering linked to all AS.

My question is - How the routing of ticket will happen?

End user selects the Business Service to report an issue, which gets assigned to Service Desk as part of BSO, what will be the CI selected on the Incident as the BSO is linked to multiple AS.

How to handle this situation? 

[Barry Kant]

Hi BAIG,

so if 1 AS is impacted it always shows impact to the Service Offering right?
Does it matter if the DEV AS is impacted or the PROD AS?
Would you like to communicate the the users of the DEV AS or broadcast to everyone?

from an end user point of view they mostly are aware of the AS level and not the CIs below. Unless it is about assets. So the CI is one of the AS records. (9 out of 10 the PROD AS as most people do not use other AS levels).

BR,

Barry