Built something you're proud of? Tell the story. A quick G2 review of App Engine or Build Agent helps other developers see what's possible on ServiceNow. Share your experience.

How to modulate O365 in CSDM - OOB and Simplified version

Henrik Jutterst
Kilo Sage

Friday - last edited Friday

I'm looking at the alternatives to modulate Office 365 in ServiceNow CSDM. The company that is about to use CSDM is centralized and does not have a complex data structure.

 

I'm looking at the suggestion from ServiceNow regarding O365 and I think it's clear purpose with separate Service Instances for each Business Application.

 

The purpose of setting up CSDM is to have a better view of ITSM processes, so start using Service Offerings in Incident and Change records for example. But since the company is on it's first way info CSDM, and not that complex data structure, I'm wondering if it's possible to simplify CSDM for O365...

 

So, please share your reasons for the "pros" and "cons" with this approach.

(-)
One negative thing might be that all INC/CHG/... will end up on the same Service Instance, and that might making it hard to see detailed info on what/where we have ITSM-tasks.


(+)
Other then that I almost only see positive sides of a simplified version, since we don't have to have:
One Business Application for Teams, one Service Instance for Teams and one Business Service Offering for Teams and we still fulfill ITSM needs of linking to Service Offering.

 

Here are original slide and my simplified version.

0365_OOB.png

Original



0365_Simplified.png
Simplified

 

Kind regards

0 Helpfuls
  • 447 Views
2 REPLIES 2

Mathew Hillyard
Giga Sage

Friday

Hi @Henrik Jutterst 

Wherever possible, try to reflect the reality of how items in your service connect. How is Office365 actually built in your organisation? To me, your simplified version is missing essential elements of what might be deployed (I assume you have deployed Teams, SharePoint and Exchange?)

 

Is the issue that you are unable to get approval/ownership from the business to create the other objects (i.e. the Business Applications), or that you don't have the necessary information to populate such records?

 

Only you can decide what works best for your organisation but this is not a complex diagram so I would advice going for reality, and building out the full map instead of something you're only going to have to change in (the near?) future. Either way you would need to change the technology management services section as Azure AD and Exchange Admin should not contain Office365 - they're not directly related in the main diagram for a good reason.

 

I hope this helps!

Mat

0 Helpfuls

ErikW_Gardner
ServiceNow Employee

Monday

Hi Henrik!

Thanks for contributing to the CSDM community. 

 

Here are some of my thoughts:

 

(-)

  • In a CHG, when requestors chooses the “O365 SaaS” Service Instance in the SImplified model, you will always get all three Business Offering and Services as Impacted CI/Service, since there will be no granularity for the different applications. So even though you are planning a CHG only affecting Teams, Sharepoint and Outlook will also be singled out as Impacted which might be incorrect.
  • Only one Business Applications for all three applications will make it hard for Enterprise Architects to review and evaluate ex. the Teams applications against other collaboration tools that might deliver the same functionality for less cost. There will be no singe Business Application for Team sto collect info on and run assessments on.
  • As you’ve stated yourself, any reporting/KPIs based on Configuration Item will suffer since you won’t be able to differentiate which application is causing Incidents, Changes, Problems etc. 
  • All three application will have to share Business Criticality since they will be represented by one Service Instance. In Event Mgmt you’d probably want to have a different response depending on whether it’s Exchange of Sharepoint going down.
  • In the Simplified model you’ve connected both the Active Directory and Exchange Offerings to the same Service Instance. I believe the recommendation is to only connect one Tech Mgmt Offering to a Service Instance in order to have clear path on Support-, Change- and Approval Group. Agents will have to spend extra time on analysing ex, Incidents in order to route correctly.
  • If these were non-Saas Service Instances, you would need to connect all infrastructure for all applications to the same service instance. That will be messy and incorrect.

 

(+)

  • Less admin. Fewer service instances will require a bit less admin
  • Keeping the differentiation on the Business Service side will let you separate tickets on the Service and Service Offering attribute
  • You can always expand the model when the need arises. But experience tells me its always more difficult to do this at a later stage after the model is “set” in the organisation.
0 Helpfuls