Service offering as parent to another Service offering

[Amit6]

How it is possible to have Service offering as parent to another Service offering.

I could see this relationship exist in PDI instance in demo data. Could not create one.

Please check below. Any help is appreciated.

[scott_lemm · Accepted solution]

@Amit6  It is not advised to have a Service Offering be a Parent to another Service Offering as there are several capabilities between Offering and Service that depend on a singular/flat layer.

When the Service Portfolio Management team rewrote functionality in/around 2017 they purposely created a single layer of Service (Parent) with a single layer of Offering (child). The reasoning was for the automation and reporting tied to Offerings and rolled up to their parent Service. Additionally, this automation and reporting are rolled up into the nodes that make up the Service Portfolio. The desired reporting was only possible by restricting the hierarchy. That is why the parent attribute is restricted to Service (also, you can not have offerings to an Application Service).

Functionality within Service Owner Workspace and Digital Portfolio Management would be severely impacted if a hierarchy of Offering is introduced. Additionally, some "better together" functionality between ITOM and ITSM may be impacted. 

I would recommend reaching out to the Service Portfolio Management team and investigate a feature request that would allow an Offering hierarchy in the future. Because of the many dependencies on the flat hierarchy, a thorough review would be needed. 

Sorry this doesn't solve your ask but I would not want you to make a customizations that resulted in a loss of functionality. 

Thank you,

Scott Lemm

[CMDB Whisperer]

@scott_lemm Thanks for the definitive response on this.  I asked this same question a while ago in a similar thread and have ultimately come to the same conclusion that, for now, a flat list of offerings is best to avoid impact to other capabilities such as DPM.  But there wasn't a definitive response on that post, so thanks for being ultra clear here!

A bit more about my use case, which you can read more about in that thread.  If you look at the different criteria for differentiating offerings of a service, there are multiple criteria: geography, business unit, product, environment, infrastructure, SLA, availability, function, etc.  But if you have a global environment with regionally owned service offerings, it would be good to have multiple layers to derive those offerings specific to that location while also having global oversight. 

For example, if I define Backup & Archive service (as per TBM), and split it up into different Offerings by function as follows:

• Disk backup
• Data Domain
• Tape backup
• Optical backup
• Off-site storage

With a centrally managed service, this will work fine and I can define my appropriate relationships to the relevant Application Services, Dynamic CI Groups, and Catalog Items as per CSDM.  However, if we want to use this as a standard taxonomy while also allowing different global business units to create their own variants of each of these offerings, with dependencies to a different set of Application Services, Dynamic CI Groups, and Catalog Items, there doesn't seem to be a good way to represent this. 

Here are the options I see:

1. Customize and allow parent/child Service Offerings.  I don't like this for all of the reasons you mention.
2. Have a flat list of Service Offerings and use the Name, Subscriptions, Commitments, etc. to distinguish them from one another, even though they are different services with different owners that roll up to a globally managed service.  Then possibly create relationships in between the Offerings to show that one derives from another.
3. Split this at the portfolio layer, and define different portfolios per region/country, and duplicate the same service taxonomy and services for each portfolio so there is still a standard global service taxonomy with identical Services, but those Services and Offerings are specific to that region/country.

I am in a toss-up between Option 2 and Option 3.  Something about Option 2 seems like the obvious solution, while Option 3 seems to provide more capabilities in DPM.  Curious to know what you and @Mark Bodman and others have to say about this use case.  Appreciate your insights!

[scott_lemm]

@CMDB Whisperer We are in solidarity!

I brought up a similar scenario back in 2017 when the Service Portfolio Management team hard coded the single layers of Service and Offering. A growing organization that evolves from a singular hierarchy into a need for stratified Offerings due to regionalization (or similar) can not expect to move their Service hierarchy "up a level" to accommodate a new Offering layer within the limited Service Portfolio -> Service -> Offering taxonomy. 

Within your use case, we agree Option 1 is NO. 

Both 2 & 3 suffer from a point-in-time model that does not allow for either to evolve while maximizing value. Each include a lot of setup work that forces said hierarchy to a near permanent use. I really like Option 3 "IF" an organization wants to see these services organized and managed by Region vs understanding total cost and opportunities for efficiency. 

The reality is that none are great solutions. The real solution would come from the Service Portfolio team and a realization that an Offering can be stratified. I'm not saying creating a hierarchy of Offerings, but we should investigate how an Offering may be further broken down is specific instances such as Regionalization and Product Features.

Message me directly and we can team up with a request to the Service Portfolio team. Additionally, if you are attending Knowledge, let's make sure to meet up. 

Thank you,

Scott Lemm

[Isabelle Thomps]

Option 3 is 100% where my mind is. We've tried Option 2 and it gets messy quickly. 

[Kristine Naess]

Hi Scott,

I received a similar request from a stakeholder in our Group Architecture department. He doesn't see any other options but to allow for some Business/Technical services to have a parent Business/Technical service. This goes for the services that are covering such a broad spectrum that one looses sight of the scope of them if there's not a level between the service and the offering. For example our Open API families who cover a large number of offerings related to microservices they provide, but where it is important that they are able to see all at once, but also group them in suitable scopes. 

I really don't want to introduce this for the same reasons you describe, but haven't been able to provide them a good option. Our Service portfolios and TBM taxonomy nodes are used for Transfer Pricing and cost modeling, and are therefore cross-org-entities whereas the parent services they need should be strictly aligned to our org structure, as we are a product oriented company. I have noticed that there's a 

Service to nodes performance weighting logic, but not possible to add multiple nodes to the same service, as would have solved my problem. So a service is "stuck" with the cost relevant node and not the org./micro service relevant one. 

We have introduced Business Capabilities for our services, but these are also cross-org/service scopes.

So my question is: do we have to solve this by using portfolios and taxonomy nodes for something else, thus restucturing them totally? Or is there another option I haven't thought of?

Best regards,

Kristine