Can Application Services have more than one Technical Service Offering?

[Erick18]

On the Application Service page, at the bottom there is a list collector for Business Applications, Technical Service Offerings, Business Service Offerings, and Parent Application Service? 

Can each of these areas specifically technical service offerings contain more than one value? What are the relationship rules 1 to 1 or 1 to many?

[scott_lemm]

Thank you @Stig Brandt for the use case.

In general, Application Services should NOT have multiple Technical Service Offerings. This is true in all use cases we have been provided. Here is why:

The use cases for multi TSOs can mostly be placed into 2 groups:

• I have many contacts
• I have many parts of the application

Your use case allows me to showcase both. 

1. I Have Many Contacts. This is 100% valid and in the old days of ServiceNow would result in several TSOs. BUT, since Rome we have introduced the concept of TEAMS as a related list to Application Service (or any CI). The primary purpose of this capability was to enable a simplified list of contacts with various roles to the related CI. We have longterm plans for this capability that includes direct ties to DevOps, SecOps, Licensing, and more. Until then, we have a capability that copies the OOB contacts from the referenced CI and allows the ability to add more (modify the role list to include DevOps, etc.). Thus, for the purposes of identifying many contacts, there is no need to create multiple TSOs or add custom contact attributes to CIs. We have the foundation of a capability that can help streamline a lot of actions.

2. I Have Many Parts of the Application: The O365 is a unique example that could be modeled several ways. I look at it with a dependency lens. In your example I would maintain adherence to the rule that an Application Service can relate to only one TSO by considering the following: from Application Service have a relationship to the Infrastructure as drawn AND a MS O365 Application Service. The infrastructure layer is self explanatory but the O365 as an Application Service below the existing App Services allows you to identify the external interactions with MS that makes these applications function. If entitlements or general issues are occurring that are inhibiting functionality of multiple O365 apps, then you have an object and the support teams identified to help. That TSO can be considered Vendor provided if desired. The point is that sometimes breaking up the Application Service into multiple Application Services is appropriate and valuable from a support and dependency view.

Hope this helps,

Scott

[Stig Brandt]

Thank you for making out the points @scott_lemm.

With regards to Have Many Contacts: Teams, long term plans are really not an answer, when supporting companies to implement CSDM that already have all different modules with different suppliers responsible for different functional areas - and support group synchronization from TSO to CI's is also a challenge here.

BR 

Stig

[Ed Laar]

Thanks Scott for your valuable comments. Isn't it a good suggestion to create a set of very practical implementation examples of our CSDM model? I know that multiple examples are already out there but looking to the amount of questions and different answers my conclusion is that it's not enough so a lot of struggling is going on.
The simple question: Can we relate multiple TSO's to an Application Service (for L1 and L2 support in the above example of Dylan) or to a single CI (for support to dedicated parts of the CI) or to a dynamic CI group so that all the CI's in that group are related to those TSO's as soon as they are in scope of the dynamic CI group needs in my opinion very clear prescribed solutions. It's always good to take the future/ upcoming capabilities in consideration in such cases so everybody knows that when they start to customize in order to solve the as-is requirements they know what to do in the future.
Why not starting creating such a CSDM operational implementation guidance?

Cheers,

Ed 

[Jim Zeigler1]

I'd like to correct a couple of misconceptions concerning the relationship between Business Applications and Application Services. In my experience, Business Applications should have an implementation(code/scripts) that resides in a source code control or they may be purchased from a 3rd party that provides instructions for installing the executables for their Business Application into any of the available infrastructure environments. These installed executables are modeled in ServiceNow as Applications (if running processes can discovered) or as Application Services.

Business Applications come in many forms. Some provide business specific capabilities while others provide shared capabilities needed by many different applications. For example, the SSO implementation that Enterprise Applications use to authenticate their users is a Business Application. It's not providing the primary Business Capability, but the libraries for SSO authentication are included with or referenced by most Business Applications. If SSO implementation libraries are included in the build process, this is an example where multiple Business Applications are deployed together and deployed to create one Application Service.

For a more complicated example, let's say the Business Application for SSO authentication is purchased from a 3rd party vendor like Oracle or IBM and is required to be used by the creators of a new portfolio of Business Applications for managing digital retail coupons that can be redeemed at any of the thousands of retail stores operated by the company.

Each retail customer needs an account to store the coupons they clip using a mobile or browser based application. In this example, the account is also used to track retail purchases made online or in person at a store.  With the shopping data, personalized coupons can be created that match the shopping habits of each customer. Coupons are a way of providing extra value in exchange for customer loyalty. Most retail coupons are controlled (with a quota) by the product manufacturers, but coupons for store branded products are commonplace and are easily customized by the company to help meet sales targets. The implementation is going to require sophisticated application code, highly available application and database stacks, a fast reliable network between retails stores and the data center or cloud. All the pieces of the resulting implementation will require the user to stay authenticated so their account and its data can be accessed at all times.

To build a mobile App or Browser-based Application for managing digital coupons requires a wide range of a capabilities that would most likely need to be developed internally to maximize the leverage the application will provide for increasing customer loyalty.  The architecture and target platforms are chosen.  Each internal development team will create and test their Business Applications that are only part of the Application Portfolio. Each application component with external APIs is assigned an Application code that is used to track it's code and components in a source code library and is added as a Business Application to the Digital Coupons APM portfolio.

In addition to SSO authentication, there will be Business Applications to manage updates to the user's profile, manage the rewards program, manage coupon creation and deployment, database applications for managing all the databases, functions for display and clipping of the coupons, and a messaging infrastructure to send the latest clipped digital coupons to the store systems used at checkout. The code developed for all these Business Applications will be combined together by the build process that create executables for deployment.

The resulting executables are deployed and tested using multiple Web, Application, and Database stacks in lower environments before being promoted to the production environment. These deployed executables are the Application Services that will be running concurrently in the Dev, QA, Test and Prod environments. 

The end users get mobile (iPhone and Android) and browser implementations of the retail shopping application for each store brand. Some of the Application Services in the portfolio have URLs that appear as entry points on the service maps being used to manage operational availability. Many have only internal applications APIs (e.g., REST services) that are called when one of the Application Services needs to use capability provided by one the other Application Services. There will be a lot of shared services so a single Application Service may be comprised of application code from many different Business Applications in the portfolio.

• Within the Portfolio there will be groupings of related Application Services (Application Service Groups). Each group may have its own dedicated Application Stack to make it easier to manage deployments. The development team for each group of Application Services will be managing multiple versions of their Application Services. A different version could be running in each infrastructure environment (Dev, QA, Test , and Prod) in the pipeline. When they are deployed, system functional testing and performance testing begins.
• The Digital Coupon Management Portfolio of Business Applications is now deployed and running on application stacks in each of the infrastructure environments. The Portfolio of Services is represented in ServiceNow as an Application Service Group that includes all of Application Service Groups and Application Services that it depends on. It may be part of a larger service group that represents all the Application portfolios that support the Retail Operations line of Business. When you take all of these services together, they make up the Service Hierarchy for Retail Operations would most likely be at the top of the service hierarchy just underneath the Service groups for production, Test, QA, and Dev (see the attached slide).
• Under the covers, Discovery and Service Mapping were used to connect all of the portfolio CIs to the infrastructure CIs they depend on.
• The highly available Infrastructure Stacks(or PAAS cloud implementations) that provide Web Services, Application Services, Database Services, and Messaging Services (they are all Infrastructure Services) are all represented in ServiceNow as Dynamic CI Groups (Application Services populated using Query-based Mapping). Pattern-based mapping (referred to as top down discovery) can't be used because there are no OOTB patterns for discovering application stacks. The Portfolio's Application Services and Application Service Groups depend on these Infrastructure Services to be highly available for their Application Services to operate without interruption. The CMDB stores all these dependencies as relationships(if created and managed by Discovery) or Service Configuration Item Associations(which are maintained by Service Mapping).
• The above example describes how multiple Business Applications are being bound together during the build process to create Application Services. This is the Business Application "Used by::Uses" or "Deployed to::Uses" Application Service relationship which ServiceNow currently labels as Business Application "Consumes::Consumed by" Application Service(someone please fix this). Business Applications are usually deployed to multiple environments (Dev,QA,Test, Prod) as running Application Services so the relationship is many to many, not one to one.

• All the Application Services and Service Groups in the Service hierarchy(see attached) are all operational. They have a running status based on real time monitoring of Application Service Entry points(URLs and service APIs) and discovered CIs the Application Service depends on. When monitoring alerts arrive, they are assigned to CIs by the ITOM Event Management Application and are immediately propagated upward through the Service Hierarchy.  This lights up the Operator Workspace and its Service Maps used by Operations teams.
• If you open a change on any of the CIs used by the Digital Coupon Management portfolio, the impacted services tab will show you all of the Applications, Services, and Service Groups that may be impacted by the change. This capability is supported OOTB by ServiceNow ITOM applications.
• The ITOM Services described above don't depend on or require use of SPM "Services" (Technical Services, Business Services or Service Offerings) to be created because a Service Catalog for Digital Coupons is not needed. I have found that most of my ITOM clients use APM but do not install SPM in their instances.
• If the infrastructure team decides to create a service catalog for standing up new servers and Application Stacks, they might create a service catalog for automating the build processes. This infrastructure service catalog of workflows and orchestration still does not require uses of SPM unless the IT organization needs to charge its internal or external users for for these services and track those costs in ServiceNow. Most customers who automate their build processes use platform specific tools to manage the orchestrations needed to build new infrastructure. If customers need a service catalog for this purpose, they would use ServiceNow Cloud Management or industry standard orchestration tools(with REST calls to ServiceNow as needed) instead of using SPM.

My intent is not to offend anyone using SPM but is instead intended to enlighten people who haven't used the ITOM Services for modeling all of their operational Services. CSDM documentation currently does not describe how ITOM Services are used. 

I'd like to see the gold quadrant populated with something like the attached diagram that better represents ITOM services. I will volunteer to help update CSDM documentation with guidelines for how and when to use the various types of ITOM services. I think most customers expected the CSDM documentation to include this.

Jim Zeigler

[Kristine Naess]

Hi,

I think these examples are good: 20 steps to align to CSDM - ServiceNow Community.

Here you can read about what types of service offerings an Application Service typically are related to (Tech Service Offerings and Bus Service Offerings). As you can see, there may be multiple BSOs, but usually (if I haven't overlooked any) only one TSO, as in this example: