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

@Kristine Naess I agree with you that opening up the parent/child capability for Business/Technical Services is another worthwhile discussion, in addition to parent/child Offerings.  Having both of these available does make it much more flexible to build out a portfolio that has the appropriate level of granularity to meet the needs that are ultimately dictated by the size, structure, and maturity of the company.  Choosing a rigid structure that doesn't allow for this flexibility is an impediment to adoption and that just doesn't seem like a good business choice.

That said, like you I have considered possibly extending the Taxonomy itself to try and compensate for this.  My thought was rather than using just Service Types and Service Categories from TBM, one could extend the Service itself to be a Taxonomy Level, which would allow you to (as needed) break down those Services by function/component/etc., as you would normally do at the Offering level, and then further break each down into separate Offerings.  But that seems like a hack that would introduce more cognitive dissonance than it would solve problems.

Just chiming in on an architectural principle I have adopted over the years that I tend to apply in answering this question: 

Don't mix the taxonomy with the entity you are managing.  

For the specific question, what does a child mean?  Does it mean, decomposition, or is it a dependency?  You need to be specific in order to effectively manage things.  

I discuss this situation in an APM blog a long time ago, applying the same principle works here just as well.

@markbodman I think that is the key question, and as I mention in my comment, since there are a variety of possibilities for distinguishing Offerings from one another (by function, by environment, by SLA, by location, etc.) the parent/child justification could be any one of these.  I provided an example where I use the TBM taxonomy to define the services for Backup and Archive, and then define Service Offerings based on function, but then if I want to have different treatments for those offerings managed by different regional service owners using different technologies, I am left in a lurch.

I do agree with the principle of keeping things as flat as possible, but with the addition of "as deep as necessary".  I think this is where the conversation needs to happen.  How to allow for the flexibility of going down a level if needed, rather than adopt a rigid model that only allows for a single flat layer.  There are clear scenarios where some level of depth is justifiable.

Hello again @markbodman @scott_lemm,

Thanks for good advices on this. I agree that parent-child-relationships between services is not a good idea. 

After having discussed this with several stakeholders the last three months, I have the following suggestion:

What if ServiceNow detaches the TBM taxonomy nodes from the service portfolio structure (table), so that we can maintain these as two different structures? This would remove our needs for having parent business services, and other remediations to be able to handle reporting in an understandable structure.

In the IRM module, the Risk Taxonomies are separate from the other structures such as the ones that link Authority Documents -> Citations -> Policies -> Control Objectives. So why shouldn’t this be possible in the SPM module as well?

If the TBM taxonomy could have a separate structure, the ways of reporting could be more user friendly for various stake holders:

For Business Continuity Management stakeholders, the organisation structure based (Responsibility Roll-up) reporting is the most crucial. This makes use of a service-to-department responsibility mapping. People and tech together. Contracts, SLAs and service mapping are crucial parts in this. In this case the risk managers and BCM stakeholders want to filter on departments to see the totality of each department’s achievements and readiness.

For day-to-day management of service life cycle activities, and for charge back to subscribers of those services, the Charge back structure would be the most useful. This shows cost related to delivering IT as a service to transfer pricing units.

Whereas for financial controlling and cost optimisation, the “cost archetype” (Bench mark Roll-up) structure is the best. This focuses on what similarities there are between what’s being delivered, and how well comparable companies are performing when delivering these.

Sometimes the levels in these structures match, but far from always. I have used dotted lines to suggest a mapping between services/service portfolio structure and the department structure to show that this is optional. In our case, the business/technical services often cross TBM taxonomy nodes on Category level, so there’s only a dotted line here.

In our case we charge back to both transfer pricing units that are separate legal entities (with their own records having unique DUNS numbers in the core_company table) and some the business units within the mother company.  Therefore we need to be able to report on tax and other figures on a company level as well as a business unit level.

All in all, we really need to do something about the too close relation between the TBM taxonomy structure and the Service portfolio structure. Today we have removed the nodes and follow up on our custom, though TBM inspired, portfolios. That’s the only level that matches our needs.

Is that a possible way going forward?

Regards,

Kristine