Understanding the Heirarchy

[kellyobrien]

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. 

[Christian Prob2]

Hi Kelly,

may I ask why you are looking for a Offering / Portfolio / Services hierarchy? My understanding is that for some elements - or example Application Service - a hierarchy does not really make any sense, but for others it may. A related question would be if you are truly looking for a hierarchy or more for a structure?

Christian

[melissahill]

Here is my understanding:

Portfolios: No Hierarchy, simply create a new portfolio when you want a new grouping of things

Business Applications: No formal hierarchy structure, but you can use relationships to create a hierarchy (you can see this in the CSDM documentation)

Services: No hierarchy. Period.  

Application Services: No Hierarchy.  It does not make sense - the application service is essentially an instantiation of the business service.  You do want a relationship to the business service.

[scott_lemm · Accepted solution]

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 🙂

[melissahill]

Hi Scott - I think this helps, but can you clarify the following for us?

What do you mean by hierarchy?  I see 3 ways to "relate" items to each other in ServiceNow:

• A field on the record that is a reference to the same record type - essentially a "Parent".  In my mind, this is the only true meaning of hierarchy.  And, as Kelly pointed out, Capabilities even goes so far as to assign level values to this type of hierarchy.  I don't see that on any other object type in the CSDM.
• A related list which typically references items of a different record type (class), but could reference items of the same type.  I guess the point here is that it is multiple records.  This is how Services and Service Offerings are related OOB.
• A relationship stored in cmdb_rel_ci.  This is how the CSDM guides us to relate Capabilities to Business Applications to Application Services OOB.  I think this is also how we would get from Service Offering to Application Service.  

What is the benefit of using each of the methods above in the platform?  When I am looking at value, I am primarily assessing the following:

• Roll up metrics - ex. # of incidents, # of SLAs breached, etc
• Filters or slicers for reports
• Visibility and navigating to drill into items from within a form

When  you say this: "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." I see that as cmdb_rel_ci relationships, and not data being managed on a record.  Is that correct?  Same for Business Applications....

I think it is very important for each type of relationship in the model that the CSDM is incredibly explicit about what "relationship" to use, and why.  If the benefits are for reporting or navigating in the system, etc.

I see there is another community post on Application Services and leveraging them in Incident and Change that will get into the modelling question that arises between how Business Applications and Application Services are modeled, so I will watch that post for greater clarification on how to actually model and use ServiceNow (for example) as a platform, with the various modules.