Understanding the Heirarchy

kellyobrien · ‎05-22-2019

I understand that the Business Capabilities can have a hierarchy (1.0 - 6.0) and that there can only be a single layer of Service Offerings, but is there any restriction on the other classes?

For example, can I have a portfolio for Supply Chain (1.0) and then a 'sub-portfolio' underneath that as a 2.0 before I break into the Service layer?

The same question applies to the Business Applications, Services (Technical and Business) and Application Service.

scott_lemm · ‎05-23-2019

Hi Kelly,

Beginning with New York we will no longer recommend a hierarchy in Business Service. In the past we often built hierarchies with Business Services. Too often these hierarchies were more about Capabilities or an Org structure. And largely they were for reporting purposes rather than actual impacted Business Services. So we have eliminated those use cases by providing Business Capabilities as CI's (in Kingston) and Portfolio's as CI's (in New York).

Additionally, we will be introducing some fancy reporting on the Business Service inherited from their Service Offerings. This data roll-up has a technical limitation that Service Offering data can only roll up to a single Business Service. Thus no more hierarchies of Business Service.

Portfolio's may have hierarchies

Application Services may have hierarchies - we have a use case of a Platform Host and their various Platform Apps. In this use case the Platform Apps depend on the Platform Host. Thus a hierarchy.

Business Applications, based on the platform use case above, can also have a hierarchy. We also use ServiceNow as a use case where the different modules (HR, Discovery, SAM, APM, etc.) are Platform Apps dependent on the Platform host of ServiceNow.

At this time Technical Services are a single layer, no hierarchy, and I suspect will stay that way.

Hope this helped! If not, you know how to reach me 🙂

View solution in original post

scott_lemm · ‎05-24-2019

Good question.

My references to hierarchies are entirely "A relationship stored in cmdb_rel_ci" that then displays in a Dependency Map and used to crawl up for Incident, Problem, and Change. In most cases, IPC will not have visibility into hierarchies built using parent attributes or related lists.

Hope this helps!

melissahill · ‎05-24-2019

Super helpful -

One last question then, where OOB the system uses related lists for Services to Service Offerings, would we be better off simply focusing on creating relationships in cmdb_rel_ci for those?

Thanks!

scott_lemm · ‎05-24-2019

The theory of CSDM says it should be a relationship. In practice the Service to Service Offering should be a reference/related list. We have found Service Owners not appreciating ALL the relationships, down to everything that can be discovered/mapped, being painted on the Business Service form. Thus, in practice, the reference/related list being best for Service to Service Offering.

dwilcher · ‎06-20-2019

Hi Scott,

Wondering if you could offer a bit more clarification for me. This was a slide from a Service Catalog session at K19:

I believe I'm following what you're saying in this thread, but just want to confirm - would that mean in the above image the top tier Business Service of "Collaboration Services" would instead be replaced by a Portfolio in SPM?

bhopkins · ‎02-10-2020

Hey Scott. Great info. Do you know any official document that expresses this viewpoint? We prescribe to the CSDM as closely as possible but are still implementing and are now following the 2.0 changes. I know that the next document after 2.0 is supposed to have updated use cases. We were always under the impression hierarchies were allowed in Services and just built out our Technical Services in this way.

I do understand when you say they are often used as Capabilities but we thought the delineation was for Capabilities to be what your actual Business provided to customers or to support customers with Technical Services being those things that IT provided to support the Business.

One of our Technical Service hierarchies looks like: Infrastructure Service > Database Services. If we are to use flat records, would we just put some type of category field on these to help organize?