Parent/Child Service Offerings?

[CMDB Whisperer]

I understand that the parent field on Service Offering should be filled in with the Technical or Business Service according to CSDM, and that Business Services themselves should not reference other Business Services as a parent.  However, there may be a case to be made for Service Offerings having child Offerings.  The use case is for an IT department which is globally distributed, which has a global owner for a given primary offering, but has regional owners for the regional offerings.  Each offering can be owned separately, can have different relationships to different app services or dynamic CI groups for each region, and different Subscriptions and Catalog relationships specific to the region, but ultimately all roll up to a single Service Offering.  Should this model be used for that scenario, and if not how would you define this?  I could see just defining adjacent Service Offerings at the same level and having the Technical Service be the point of rollup, but that presumes a level of granularity that might be more specific than you really want to define at that level.

[Kristine Naess]

Hi Paul,

I see your point. We have almost the same situation, and have looked at some examples from the CSDM 2.0 primer for inspiration (I haven't found these to be outdated):

In the above scenario there's a common business service covering all offerings. But in our case, I guess like in yours, there are multiple departments placed in various countries with their own cost centers involved. So we have ended up a bit more like this (using Service portfolio with taxonomy nodes): 

This year we will start adding product models to the structure, so that the HP Service Manager in this case would also be a Software Model following a certain life cycle with a related Application Product Model (version agnostic). 

To address the support and SLA regime we will add Service Models, so that the support on HP PROD NY and HP PROD Europe in this case would be referencing the "Gold" or "Platinum" Service Model, whereas the non-prod instances would be referencing the "Bronze" Service Model. 

The need to roll up information can then be done in different perspectives:

1:From the Business services you can see all offerings that are governed by the same part of the organization (filtered on IT Department)

2: By using Service Portfolios with taxonomy nodes you can also map together services and offerings across your company/group that have the same purpose.

3: From the Technical services you see who's in charge of the Infrastructure and Platform offerings supporting your instances, and if you use the service models you can even see if these are compatible with the service model on the application instances. 

4: From the Business application you see down on all CI's that makes up the architecture of the application, and how many instances there are. If you add the software models you can also see what versions the various instances are on. 

So we have managed to avoid parent-child relationships on service offerings. We have to invite stakeholders to look into the relationship view to explain things, and it takes a lot of time coaching service owners on how to navigate these, but I think it's worth it. 

Cheers,

Kristine