Should End-user services be recorded as Business services?

[Robin Chytil]

HI Mark and all,

Quick question that I have not seen clearly explained neither discussed in this forum (let me know if I missed it):

At a customer, we try to align as much as possible to TBM and CSDM. We defined Business services for the Business divisions (Finance, Sales&Marketing, R&D, etc.).

I am clear on defining Technical services such as "PC support" (or even "Laptop support" and "Desktop support" if required), "Compute hosting", "Cloud hosting" or "Service Desk", which are Support, Delivery and Infrastructure services provided by IT in the background (and supporting Business services).

But what about services provided directly to End-users (called "End-user services" by Gartner and "Workplace" in TBM), such as "Office PC", "Video conferencing" or "Email". Should they be considered as Business services or Technical services (consumed by "Technology Consumer" as depicted in the CSDM v4.0 schema)?

I would tend to advise to keep them as Business services, can you confirm?

Robin

[Mathew Hillyard]

I watched this discussion too and both these videos and this thread seem to pose more questions than answers.

For me there is a gap in the CSDM, which is that there is only one relationship between Manage Technical Services and Sell/Consume - an Application Service, which has a very specific definition (deployed stack of software and hardware - basically the CIs that support some form of installed application provided as a service that users access via an entry point URL). 

What about services that business users (subscribers) consume where it is not supported by an Application Service? If an Incident is raised by an agent, what do they enter in the Service offering and Service fields? I can be persuaded that for CSDM to make sense, they should be the Technical Service offering and hence Technical Service (e.g. Laptop Support), but they're still functioning as a business service consumer. 

Then the Incident gets created. Which commitments are the service desk fulfilling to respond/resolve this Incident? It should have one or more SLAs, which come from the Service Commitments of Type = SLA on the Business Service Offering. But this is not on our incident anywhere, nor is there any way to relate it to the Incident from a Technical Service Offering.

I've talked this out with a fellow architect and I can see only 3 possibilities:

1. Add a direct relationship between Technical Service Offering and Business Service Offering
2. Treat Dynamic CI Groups as any other Application Service (which is what they are - Query-Based Services) and relate the Dynamic CI Group directly to a Business Service offering
3. Change the definition of Application Service, decoupling "Service" and encompassing anything that could potentially link a technical catalog or group of CIs and a unique commitment to deliver a service (Business Service Offering). 

Option 1 seems the easiest and most logical as it's simply a (many to many) relationship with no changes to any structure or terminology within CSDM.

Option 2 is possible but would both look strange on a diagram and I suspect rather tricky to explain.

Option 3 looks like it may happen (I understand there is an intention to replace Application Service with System) but it would require changing quite a bit of the existing CSDM structure, which again would probably result in more confusion than clarity.

Some clarification would be very helpful.

[Jim Zeigler1]

Most customers I've worked with don't need or use SPM (they don't have IT Services that they "Sell" within the company), so they create ITOM Services that follow the approach in the attached slide.

• All their infrastructure Services are implemented using Dynamic CI groups that have a table and filter that identifies all the CIs included in the Service. I provide them a starter set of Infrastructure services and service groups that they can customize in a few days time.
• They all start out asking for Mapped Application Services until they realize the specialized skills, time and money it takes to get all the credentials working to complete horizontal discoveries for all the CIs, go through the process again to add and debug all the applicative credentials needed to get TD pattern based mapping to build a complete map that can be released.
  • If the service has any CIs that can't be discovered or TD discovery fails to complete, the resulting map is incomplete and can't be released into production.
  • Within a few days I can mentor them to build a query-based map that has the functionality they need.
  • After a few days of mentoring they don't need much additional help to build all their service maps.
  • My last customer created almost 1000 new Query-based Services that support 50+ locations in 10 weeks.
• If their CMDB is not very mature (e.g., they have no event management), Mapped Application Services are overkill because you can get the same functionality from query-based services for a fraction of the cost.
• After they build out the ITOM Service hierarchy above the lowest level Application Services, they get the full benefits from having their services mapped because they can use the refresh impacted Services UI action to show what services will be impacted by a change to a low level CI.
• All the services they created show up in the Event Management Dashboard and the Operator Workspace Dashboard.
• Incident forms reference Operational Services and CIs as recommended by ServiceNow.
• I would like the CSDM documentation to focus more on ITOM Services that are easier to understand and deploy than SPM services. The Gold "Run" quadrant should only contain operational CIs and SPM Technical services should be in the Green quadrant because they are not needed to model operational services.

[Mathew Hillyard]

Your suggested approach for mapping application infra seems very usable and I take your point about the difficulty building service maps (with or without Service Mapping) - I am increasingly looking at Dynamic CI Groups and Query-Based Services (which are themselves just sibling child tables of the parent Application Service table) as a quicker route to value. What is clear is that manual mapping of Application Services without Service Mapping is at best awkward and very time consuming (and the platform assumes you are using Service Mapping so the user interface doesn't really work). With Service Mapping there is of course the benefit that it is "in-platform" but again I take your point about applicative credentials, undiscoverable items etc.

I further agree that a bit more detail in the Manage Technical Services domain would be a worthy addition to the CSDM as the existing draft document is a little flat and would benefit from a more 3-dimensional description. ITOM is of course a huge element of both the CMDB and CSDM, as well as operating business processes, and as you've described there are better ways to achieve this at scale.

However, I'm not sure that has any impact or relationship to what gets populated in SPM - it's fairly quick and easily to create portfolios, taxonomy layers are very likely to already be described within an organisation, and the services are also going to be there on the platform. The map of services in TBM that @Barry Kant posted above is the kind of document many organisations want to see at an executive or service management level.

I'm not sure that "sell" is the right way to look at the green quadrant (sell/consume domain in CSDM). It's the front end exposed to business and technology consumers and the portfolio is critical for business stakeholders to have a landscape view of their investments. If it's not done in ServiceNow it'll be done somewhere else. The ability to link catalog items to service offerings (and therefore Services and Portfolio) to subscribers is very powerful. This also feeds directly into the Design domain (blue quadrant) for technology portfolio/risk - so ignoring the portfolio side risks rendering large parts of the CSDM redundant. It's also worth bearing in mind that ServiceNow is moving towards a digital product/digital portfolio model, something which most medium/large enterprise are at the very least investigating, if not pursuing strategically, and the medium-term future of the CSDM as a whole.