As you know (hopefully) from our previous articles (Technology Portfolio Management - Getting Started), automation of TPM will require that your application services have been “mapped”. However, Service Mapping can be a tough ask for customers to take on with several thousand Application Services. The good news is that fro TPM purposes, these Application Services do not need to be fully Top Down Discovery Pattern-based Mapped. Any form of Application Service and mapping method is supported by the new TPM automation functionality.
Lets review of the types of applications services:
- Mapped Application Service [cmdb_ci_service_discovered] – this type of application service is the one used by top-down discovery methodology to create a robust, multi-tier application service map.
Also, per CSDM best practice, this is the type you should create if you are building “manual” Application Services. You may manually define end points / CI associations therefore building the service map a CI at a time. Typically this results in a single “layer” map. This is just fine for our TPM purpose as is the fully tiered map.
Pattern-based discovery creates precise and complete application services that represent the service-centric view of the IT infrastructure. It creates a high-fidelity map that is well suited to managing mission-critical application services.
In addition, it provides visibility of cloud-native services such as compute, load balancers, and API gateways. You can use service entry points such as AWS S3 buckets, AWS and Microsoft Azure API gateways, AWS Lambda functions, and Microsoft Azure functions to map services. It can also detect Lambda to Lambda calls and Lambda to RDS connections to build dynamic service maps.
Top-down method maps VMs on-premises and in public clouds. However, it requires these VMs to be fully discovered for the top-down discovery to determine which applications are running in the VM. If a VM isn't fully discovered, use the tag-based method to bridge the gap (see later in this document). Tag-based mapping also maps containers, that you cannot map using the top-down discovery. - Calculated Application Service [cmdb_ci_service_calculated] – this is a “Dynamic” or calculated application service which will take CI Relationship [cmdb_rel_ci} and converts then into them into Entry Point mapping in Service CI Associations.
You can't edit a dynamic application service by directly adding or removing CIs from it. Dynamic application services are updated automatically to reflect any change to CI relationships in the CMDB CI Relationship [cmdb_rel_ci] table. When you add a relationship to a CI that is contained in a dynamic application service, then that service automatically updates to reflect the addition of the relationship and the associated new CI. In a similar manner, a dynamic application service automatically updates upon the removal of a relationship and its associated CI from a CI within the service. - Dynamic CI Groups [cmdb_ci_query_based_service] - Dynamic CI groups which act as application services. The members of the CMDB groups that is associated with the dynamic CI group, populates the application service. A dynamic CI group is a dynamic grouping of CIs, based on some common criteria such as the location of all web servers in Detroit or all Oracle databases in Boston. After creating a dynamic CI group, it can be used as a group offering in IT Service Management. If created from the Application Service wizard, the service classification is application service, and if created from the legacy Event Management UI or Service Mapping UI, the classification is technical service.
- Tagged-Based Application Service [cmdb_ci_service_by_tags] - A tag is a label that consists of a key-value pair. Your organization may use tags to categorize its assets, to enhance query and reporting capabilities. Discovery and Cloud Provisioning and Governance can discover tags used by all major cloud providers and container ecosystems. Once the tags are discovered, Service Mapping can create application services based on these tags. For example, you can use tags to map all application services your organization uses in the production environment in the EMEA region. Tag-based application services have the service classification of application service.
- Manual Application Service - see Mapped Application Service
Each of these Application Service types will populate the Service Configuration Item Associations [svc_ci_assoc] table as part of mapping. It is this table that Technology Portfolio Management (TPM) and other ServiceNow solutions, such as Impacted Services in Incident and Change, are using to identify the particular CIs associated to an Application Service (or visa versa).
With the new TPM automation capabilities and even the original TPM’s “Fetch Technology Models” capability, the automation looks for the hardware CIs in the Service Ci Associations table.
Typically, the term Service Mapping would imply the Top-down Discovery Pattern based mapping. It is of course a fantastic and valuable method of identifying the tiers and associated infrastructure of the Application Service. Top-down Service Mapping can be quite difficult though and for TPM purposes, it is not always a necessary. Tag-based, Dynamic and the other methods are all acceptable.
Often customer, might start off with a Mapped Application Service that are “empty” because the Service Mapping team has not had time to do the mapping. Application teams, CMDB or others may just connect Servers via CI Relationship and then use the “Update with changes form CMDB” related link on the Application Service. This provides a minimum mapped service for TPM use.
It is fairly straight forward to write a script that will run the Update with changes from CMDB on a schedule so users don't have to click the related link. Of course, you should always coordinate with your platform and service mapping teams before doing any such thing.
Converting Service records to Application Services
Prior to CSDM and in the CSDM 1.0 days, APM allows you to create Service [cmdb_ci_service] records and use then as Application Services. This is no longer a best practice under CSDM and APM. According to CSDM, Business Services should be in the cmdb_ci_service_buisness table and all application services should be in one of the application service tables described above.
We understand that legacy customer will possibly still have this situation. In order to take advantage of TPM, we recommend you convert your old Service Records (and their CI Relationships) to Application Services.
The APM Application Service views, both list and form, have a convenient Convert to Application Service button. This action allows you to easily convert those old Service records. in List view, you can convert multiple record en masse.
hope this helps...
