ServiceNow and Epic Platform: Mapping all of the Epic Platform Components

[Ash30]

Hi All,

Continuing the CMDB, CSDM, and APM discussion... has anyone fully mapped all of the components of the Epic Platform in their ServiceNow instance? Has that work mostly been manual or was there some automation used? Have you been able to take advantage of Event Management after this implementation? Anybody willing to share their experience and learnings?

Background: We have been taking baby steps in our APM journey and have so far only been able to get to the crawl space by identifying all of our IS Owned Applications. We have discussed possible next steps with our Epic teams to set up the Application Services and then mapping for all the CIs (We do have Discovery running) but that still seems to be a LOT of work and incredibility complex setup. On an excel spreadsheet we have over 2500 servers (including all the citrix, hyperspace, storage, etc.) and 20 environments (PRD, TST, POC, etc.). That does not include all of the digital integrations, 3rd party applications, medical equipments, globalscape jobs, etc. that would encompass the entire Epic Ecosystem. 

Thank you,

Ash Razavi

Scripps Health, Information Services

[changeman]

Hey Ash,

We're still crawling too, without APM and with only basic Discovery (no Visibility, no Service Mapping), which is mainly constrained by limited resources to manage the configuration and associated processes.  So, our application modeling and mapping has been and for the near future will be mostly manual, though we're trying to build a case for ITOM Visibility in our organization.

We started originally with just the Business Application layer and now are adding Application Services while taking advantage of the Platform Host/Platform App relationship at the Business Application level (for the most part a Platform App has to be a part of a platform that can be purchased and managed on its own).  Since we're hosted by Epic, we have only created Application CIs (modules/processes that "run on" discovered hardware CIs) for the platform-wide functions we control: Bridges, RW, Clarity/Caboodle, etc.  Therefore you will not see Applications like Interconnect, ODB, etc. since they're managed by Epic Hosting.  We may add them eventually, but it's not the current focus. See the attached image.

The image does not include interfaces or APIs but we plan to model those as Application Services as well and then map them to the Epic core Application Service (e.g. Epic Prod) and the Application Services integrated with Epic via "Receives data from/Sends data to" relationship. Even though we use middleware to route and translate data transmitted by many of the interfaces, for simplicity's sake, we've decided to model them as objects connecting sending and receiving Application Service endpoints with the following naming convention: <format/protocol> <transmission type> from <sending system> to <receiving system>, e.g. HL7 ADT from Epic to Pyxis.

[Ash30]

Thank you for the response and information. Good to know we are not alone trying to figure this out... slowly!

In regard to the picture you attached, is that something you have created or a ServiceNow provided information? I have seen a similar PPT that has the Epic high-level Run and Fly but not the Crawl/Walk. Would you mind sharing the link if it is a newer version of the ppt. 

It is interesting how you have your Epic Bridges (as an example) at the Application level and how you will be using the APIs as Application Services. I would have thought that Epic Bridges would be a Business Application under Epic Platform (since it is an Epic Module similar to how Incident Management is a module/platform app under ServiceNow Platform host) and the APIs would be a Digital Integrations connected to Epic not an Application Service. Do you also have a separate application service (prd, tst, dev) for each of the Epic modules (such as Epic Prelude Prod, Test, Dev, etc.)?

I guess the complexity of some of these platforms (especially Epic for us Healthcare customers) creates a bit of a guessing game where we are trying to match information with CSDM data model. That is why I have been asking/hoping that ServiceNow and Epic can provide a template, so we are all using the same "mappings" that is somewhat consistent with "most" Epic customers. 

Thank you,

Ash

[changeman]

Hey Ash,

Excellent questions. Regarding the image, it's a version of the slide from the SN slide deck that you took a screenshot from, customized to our instance.  The latest version of the SN deck with the boatload of CSDM data model examples, plus comparisons of CSDM to other infrastructure and service modeling concepts, is stamped 07/18/23 and I don't know if there's anything newer.

Regarding Bridges, the reason I wouldn't consider it a Business Application and a Platform App referencing the Epic core Platform Host is that Bridges on its own won't do anything and would not be purchased on its own, similarly to other interface brokers or the Cogito stack (the SQL databases plus things like Nebula or Cosmos).  For us to consider a module a Business App/Platform App, it has to be relatively self-contained.

I also wouldn't necessarily consider Incident Management as a module of ServiceNow: to me it's a function of ITSM, which itself is a Business App/Platform App.

Digital Integration is not a CI Class I see in my CMDB instance, so you may be talking about an APM concept and we're not using APM just yet.  My decision to model interfaces, including APIs, as Application Services is based on a couple of webinars posted in the Digital Forum, with the most common approach being Application Services, also referred to as microservices.  I do agree that using the same CI for application environments and for interfaces might get a tad confusing, but I don't believe currently there is a better option, which has recently been confirmed during a CSDM/CMDB workshop that Lexi put together for us (which I would heartily recommend to anybody struggling to wrap their heads around any CSDM modeling concepts).  SN CSDM folks are working on an API CI Class but I'm not sure when it will be available.  There's also a difference between interfaces routed through middleware and APIs, with the latter being essentially direct connections between integrated endpoints, so I'm not sure the API CI Class will suit our HL7 v2 or FTP needs.

Regarding environments, yes, each Application Service is a fully deployed application stack per environment (keeping in mind the distinction between Platform Apps vs. Applications referred to as modules (e.g. Epic Ambulatory vs. Epic Bridges).  Our initial focus is on the Production instances of Application Services modeling both applications and interfaces, but eventually we do want to create non-Production objects as well.

Last but not least: while like you I would like to see a bit more prescriptive approach to CSDM modeling, I also recognize that the modeling concepts and objects need to stretch a bit or be vague to allow organizations to model their infrastructure in a way that makes sense to them.  I would never model the ServiceNow MID Server as a Business Application Platform App, but that's one of the organizations showcased in one of the Digital Forum videos actually did because it made sense for them to have it as a separate portfolio item (it had its own support, if I recall).  They also show some interesting use cases that drive a non-orthodox use of the CSDM domain colors: orange (manage technical services) vs. green (sell/consume), meaning traditionally technical objects were rendered as sell/consume because it fit their use of them.

One of my favorite quotes mentioned in a CSDM webinar video is: "all models are wrong, but some are useful" (George Box).