Business Service Offerings - Relationships to other CI

[Richard W]

Hi, when I look at the CSDM 4 whitepaper it explains that Business Service Offerings should depend on Application Services. That makes sense, however, when I look at the online documentation about creating a Business Service Offering using Service Builder it mentions the "depends on" relationship to an application service but it also mentions creating a relationship between the Business Service Offering and other Business Service Offerings. Why is that not in the CSDM relationships table diagram as an option?

My reason for asking this is that so far I have built many application services prior to offerings being a type of CI and I have related application services to other application services to show where there is dependency. If we assume I create a business service offerings that depend on an application service should I be considering migrating the existing relationships between application services up to relationships between business service offerings? 

I notice that the agent workspace and service owner workspace shows offerings and specifically has a widget showing offerings that this offering depends on as well as application services that this offering depends on but it only goes one level down so any 2nd or 3rd level dependencies do not show in the workspace. Is this a reason to change the relationship types as mentioned in the paragraph above?

[Barry Kant · Accepted solution]

Hi Richard, 

the depends on Service (s Offerings) is originated from Service Portfolio Management. 
If I am correct the idea is that Business Services depends on Technical Services. or Business Offerings depends on Technical Offerings. However recently we also got questions here if Technical Offerings can depends on other Technical Offerings (technically yes). 
In that context it is a decomposition of Service (s Offerings) it shows the underpinning services. Sometimes called the Supply Chain. It is indeed not visualized in CSDM. 

BR,
Barry

[Richard W]

Thanks, Barry. So just to confirm I have understood. If I were modelling a business service offering I would show a depends-on relationship between it and the application service providing it because that's the actual tech running the application. However, let's assume a user cannot access the application without using single sign on which would require active directory to be operational. If that were the case I would show by service offering as depending on the User Authentication Technical service - AD Offering as well. The logic being that if AD was unavailable then the business service offering would also be unavailable even though the application service providing it was actually up and running?

or have i missed your point?

[Barry Kant]

That is a valid scenario indeed.

[JoelatNow]

Great example, @Richard W . How would you avoid creating dozens of relationships to infrastructure offerings (e.g. cloud PaaS, DNS, network path, authentication, vpn for remotes) for every business offering? I'm thinking there should be a common set of infrastructure stacks captured as application service(s). This infrastructure stack is underpinned by the relevant tech service offerings. So the business offering could be underpinned by the specific app stack + a representative infrastructure stack (app service). 

@Barry Kant - what do you think? Should I prefer one or more application services to underpin business offerings, versus a tech offering? It seems app services are more precise regarding affected services as compared to an entire tech offering. When is a tech offering unavailable versus a single implementing stack (app service)?