Application Service Configuration

DonD
Tera Contributor

Hi

I am looking at configuring following 02 items.

Business Applications

Application Service

 

Question is whether do I have to configure the  Business Capability, Technical services, Business offering....etc. 

Can I configure those 02 tables now and configure other tables at a later stage. Trying to understand sequence of implementation

1 ACCEPTED SOLUTION

EricDohr
ServiceNow Employee
ServiceNow Employee

Don

This is an excellent question! Ultimately, you want to right size it to meet your organizational needs and remember that it can grow over time.  I like that you are thinking beyond the record, but more of how do we use this record and who is involved.  

First some other material specific to those topics to help out

YouTube | CSDM Example Series: Platforms

Mark Bodman has some great videos speaking on various topics related to CSDM.  In this video, he actually focuses on SAP as an example. 

NowCreate | CSDM Data Model Examples

Here are some scenarios and supporting PowerPoint including an SAP example

Let’s break up your question into a few focus areas

  • How would I represent Business Applications
  • How would I represent Application Services to understand my environments
  • How would I represent Services and Offerings for when customers call the help desk

How would I represent Business Applications

First, Business Applications are more of a strategic record than operational (use with the incident, change, etc).  You will also likely not have one Application Owner or Business Owner of all your SAP products.  In addition, each product may fulfill different Business Capabilities, used with one or many Business Processes and varying Information Objects.  AKA, we need to have proper representation.

With a Platform, you can create a foundational Business Application record and note it as a Platform Host (architecture type).  Corresponding Business Applications can then be associated with this record by using Platform Application (architecture type) and referencing the Platform record that is the host. 

How would I represent Application Services?

Anytime you have an environment, you want it represented as an Application Service.  Note, you may have environments that are not only concepts such as Prod, QA, and Dev, but maybe also by region.  For instance, you may have SAP ERP – US [prod] and SAP ERP – EMEA [prod].  Each one of these records would be correlated to a Business Application via a CI relationship.  A Business Application can have a one to many relationships to Application Services.

A benefit of doing this is as you start to consume functionality like Digital Portfolio Management, you may be able to start aggregating KPIs as well as useful information for assessments.

Application services also would have relationships to the underlying infrastructure.  If you have Service Mapping, this is a huge win as it provides top-down discovery. 

With the Application Services, you can also then associate them with Service Offerings both from Technical Services and Business Services.  This way if you have challenges with the underlying infrastructure that impacts that System, you can have visibility into your customer or service owner impact.

AKA, server XYZ has high CPU, you have an alert and create an incident.  You now know from your CI relationships that this is impacting SAP ERP Prod – EMEA impacting EMEA Accounts Payable (as an example).

How would I represent Services and Service Offerings?

You nailed it, you would not expect a customer to be able to tell the help desk

  • Server XYZ isn’t working
  • SAP ERP Prod isn’t working

In the event that they were to call in that way, given you have Application Services and underlying CIs, you always could open the incident related to those items.  

Typically they say things like “I cannot process invoices.”  This is where you would focus in on your Business Services and corresponding offerings.  For example, with Manufacturing Mgmt, you could have an offering of Inventory Mgmt that is dependent on the application service SAP Manufacturing Prod.  This way the help desk can create an incident against that Service Offering/Service and route it to the appropriate teams.  The appropriate team may be able to see that the underlying infrastructure or the app service has alerts and incidents leading to a bigger issue. 

You can of course relate Business Services to a Business Capability via a CI relationship, but this is a mature concept.

As mentioned above, focus on maturity.  Nail the Business Applications, Application Services, and underlying CIs first.  Then grow to Technical Services and Offerings into later more mature concepts.   Not all records need to be matured at the same speed.  You would want to focus on business-critical concepts first to map out versus a big bang.  Nothing limits you from building this out for the SAP platform where as other concepts may be more in the crawl state.

 

 

View solution in original post

4 REPLIES 4

EricDohr
ServiceNow Employee
ServiceNow Employee

If you have not already, definitely check out the material on NowCreate that includes a maturity approach.  There are two primary methods of approaching CSDM with one being Services and the other Application. 

For example, typically in the Crawl phase you are focused on topics like Business Applications, Application Services, and your Configuration Items via discovery/service graph.  Later you would grow to include Technical Services and Service Offerings with relationships to those Application Services.

CSDM Whitepaper

CSDM Workshop

find_real_file.png

find_real_file.png

find_real_file.png

DonD
Tera Contributor

Thank you

In fact I have read both of these documents few times, but still one thing is not clear. If you can help me I would really appreciate.

I have chosen to go with Application Focused approach. We have SAP ERP in our business. SAP ERP is an echo system with SAP ECC + SAP PO + SAP Portal....etc.

Question is what should I create as a "Business Application" and "Application Service"

Option-1

Busines Application = SAP Enterprise System

Application Services = SAP ECC PROD + SAP ECC DEV + SAP ECC Test + SAP PO PROD + SAP PO Dev + SAP PO Test + SAP Portal PROD + SAP Portal DEV + SAP Portal Test

OR

Option-2

Business Application1 = SAP ECC

Application Services = SAP ECC PROD + SAP ECC DEV + SAP ECC Test

Business Application2 = SAP PO

Application Services = SAP PO PROD + SAP PO DEV + SAP PO Test.

When end user ring Helpdesk they complain "SAP is not working"...End user will not have any idea about SAP ECC or SAP PO or SAP Portal...they simply say "SAP is not working"...

My preference is to go with Option-2, but struggling to associate this approach with Helpdesk scenario. Can I tie "Business Service' in this approach, and mark "Business Service = SAP Enteprise System

EricDohr
ServiceNow Employee
ServiceNow Employee

Don

This is an excellent question! Ultimately, you want to right size it to meet your organizational needs and remember that it can grow over time.  I like that you are thinking beyond the record, but more of how do we use this record and who is involved.  

First some other material specific to those topics to help out

YouTube | CSDM Example Series: Platforms

Mark Bodman has some great videos speaking on various topics related to CSDM.  In this video, he actually focuses on SAP as an example. 

NowCreate | CSDM Data Model Examples

Here are some scenarios and supporting PowerPoint including an SAP example

Let’s break up your question into a few focus areas

  • How would I represent Business Applications
  • How would I represent Application Services to understand my environments
  • How would I represent Services and Offerings for when customers call the help desk

How would I represent Business Applications

First, Business Applications are more of a strategic record than operational (use with the incident, change, etc).  You will also likely not have one Application Owner or Business Owner of all your SAP products.  In addition, each product may fulfill different Business Capabilities, used with one or many Business Processes and varying Information Objects.  AKA, we need to have proper representation.

With a Platform, you can create a foundational Business Application record and note it as a Platform Host (architecture type).  Corresponding Business Applications can then be associated with this record by using Platform Application (architecture type) and referencing the Platform record that is the host. 

How would I represent Application Services?

Anytime you have an environment, you want it represented as an Application Service.  Note, you may have environments that are not only concepts such as Prod, QA, and Dev, but maybe also by region.  For instance, you may have SAP ERP – US [prod] and SAP ERP – EMEA [prod].  Each one of these records would be correlated to a Business Application via a CI relationship.  A Business Application can have a one to many relationships to Application Services.

A benefit of doing this is as you start to consume functionality like Digital Portfolio Management, you may be able to start aggregating KPIs as well as useful information for assessments.

Application services also would have relationships to the underlying infrastructure.  If you have Service Mapping, this is a huge win as it provides top-down discovery. 

With the Application Services, you can also then associate them with Service Offerings both from Technical Services and Business Services.  This way if you have challenges with the underlying infrastructure that impacts that System, you can have visibility into your customer or service owner impact.

AKA, server XYZ has high CPU, you have an alert and create an incident.  You now know from your CI relationships that this is impacting SAP ERP Prod – EMEA impacting EMEA Accounts Payable (as an example).

How would I represent Services and Service Offerings?

You nailed it, you would not expect a customer to be able to tell the help desk

  • Server XYZ isn’t working
  • SAP ERP Prod isn’t working

In the event that they were to call in that way, given you have Application Services and underlying CIs, you always could open the incident related to those items.  

Typically they say things like “I cannot process invoices.”  This is where you would focus in on your Business Services and corresponding offerings.  For example, with Manufacturing Mgmt, you could have an offering of Inventory Mgmt that is dependent on the application service SAP Manufacturing Prod.  This way the help desk can create an incident against that Service Offering/Service and route it to the appropriate teams.  The appropriate team may be able to see that the underlying infrastructure or the app service has alerts and incidents leading to a bigger issue. 

You can of course relate Business Services to a Business Capability via a CI relationship, but this is a mature concept.

As mentioned above, focus on maturity.  Nail the Business Applications, Application Services, and underlying CIs first.  Then grow to Technical Services and Offerings into later more mature concepts.   Not all records need to be matured at the same speed.  You would want to focus on business-critical concepts first to map out versus a big bang.  Nothing limits you from building this out for the SAP platform where as other concepts may be more in the crawl state.

 

 

DonD
Tera Contributor

Thank you for taking the time to answer my question.

You answered all my questions.

Best answer.

Thank you