5 new CI classes? RPA, Microservices, Integrations, Sub-Modules & Underlying Tech

[Daniel Carvalho]

Hello there!

I am wondering how you folks might have already addressed those needs below (if by new custom cmdb tables or what OOB tables):

• Robots (RPA bots) CI
• Microservice CI
• Data Integration Service CI
• Sub-Module CI (within a main enterprise application or a major Module of a enterprise application)
• Underlying support technologies (CI ??)

Here my takes on them:

Robots (RPA bots) CI

• Great candidate to be related on automatic event and incident management. Probably managed by change in production environments, therefore I think they should be in the CMDB.
• In my point of view, they should not be “at the same level” as an enterprise application in the CMDB (such as CRM, SAP or even SAP-FI, for examples).
• Robots can easily grow their use base in the company and quickly there can be more then thousand of then “polluting” tables and relation MAP views.
• I would usually expect a company to adopt a/one major RPA vendor/provider/platform (UiPath, Automation Anywhere (AA), Blue Prism etc.); so I tend to comprehend this adopted RPA “platform” as an Application Service under CSDM (cmdb_ci_service_discovered) with their respective deployed environments (“RPA-Plat”_PRD, _DEV, _UAT). So, it´s bot´s wouldn’t reside in the same place.
• I perceive Bots as being almost equivalent to Batch Jobs. Those do have their own table: cmdb_ci_batch_job.
• My proposal: create a custom cmdb_ci_robot (extending cmdb_ci, in the same way batch jobs does).

Microservice CI

• Good discussion already on going (https://community.servicenow.com/community?id=community_question&sys_id=69bdc9b81b745010a59033f2cd4b...)
• Could be, but IMHO maybe shouldn´t be, considered/confused as an Application Service under CSDM (cmdb_ci_service_discovered); nor perhaps a WebService (cmdb_ci_web_service) nor even an Endpoint (cmdb_ci_endpoint_manual).
• Here I mean “internal” microservices (developed inhouse). Those from third-party or even from parent companies I do believe should be represented differently.
• My proposal: still without one – waiting for CSDM V3.0.

Data Integration Service CI

• Considering two main cases of integration (as cited here https://community.servicenow.com/community?id=community_question&sys_id=81e1cbf61b255050ada243f6fe4b...) one that relates directly 2 CIs for implicit specific purpose (such as SSO, authentication, log shipping etc.) and other scenario where 2 main enterprise applications (each one holding great data diversity) talk to each other, and where you can´t simply understand the business purpose of the integration by only having them both only linked/related. “Something” would need to exist in between to expose the meaning and the objective of that specific dataflow.
• My proposal: To mainly go along with @CasperJT (link above) concept of having a subclass of Application Service called 'Integration Service' (but using a new CMDB Class called Data Integration Service, cmdb_ci_data_integration_service, that expands cmdb_ci_service).

 Sub-Module CI (within a main enterprise application or a major Module of an enterprise application)

• CSDM´s CMDB literature states that at the Business Application level there can sustain a Parent relationship. This allow us to “breakdown” some very big application scopes into more manageable pieces.
• One of the classical examples I guess would be SAP. It can be sold/bought in pieces, therefore it can be installed in pieces;. Usually even in a hipotetical complete unique installation (where all pieces are present), it is normal to have different application support teams as being responsible for of those different pieces. So, a unique CI called “SAP” wouldn´t nicely fit at all.
• Using parent, we can then have a primary “SAP” CI that features as top layer to the following examples “SAP-FI”, “SAP-MM”, “SAP-CO” etc.
• We even might have conceptually called the SAP CI as an “application” and SAP-FI children CI as an “application module”. So far so good.
• But what if, it is important (let’s say to my Service Desk and to application support” to have the screen or main function that the user is complaining about (in SAP it could be the TRANSACTION, but I will call it Sub-Module, as it is more generic)?
• In witch table should I be storing SAP-FI´s “MyImportantSubModule-A”, “MyImportantSubModule-B”, “MyImportantSubModule-C” and “MyOtherSubModules” CI´s and then relate them to the SAP-FI CI?
• My proposal: create a custom cmdb_ci_app_submodule (extending cmdb_ci).

 Underlying support technologies (CI ??)

• This subject can be so vast that I will bring just one example:
• Please consider a scenario such as:
  • Business Application “MyImportantBizApp”
  • Application Services: “MyImportantBizApp_PRD” and “MyImportantBizApp_NonProd” instances
  • Application: All the required technical deployments of my inhouse developed source code so that those instances can run just fine and also their relationships.
• But I must register (and here we have decided to do it so on the CMDB) that “MyImportantBizApp” not just only is “made” mostly in Phyton, but it relevantly relies in the PANDAS library of Phyton (at this point we are not even dealing about library versions).
• This is a simple example without technical preciousness regarding specifics of software compilation, deployment etc.
• Observe that this topic regards less (or nothing) about licensing (SAM) nor required components installation (such as .NET framework or SQL Server) and much more about what was “took in” my Application´s code when building it.
• So, should PANDAS be created under a CI Class specific to hold Underlying Technologies and then related to the Business Application?
• My proposal: create a custom cmdb_ci_underlying_tech (extending cmdb_ci).

Thanks in advance for all /any insights!

Cordial

Daniel

[Alex_Dundon1]

@Daniel Carvalho,

For identifying micro-service specific applications, we added a custom field for app type and indications if it were a batch app, traditional monolith, micro service, etc. We found that to be the easiest way. I'm pretty sure there is OOB field for app type, but we had this app type field prior to (I think it was Madrid?) that the cmdb_ci_business_app table came out of box.

I can see where you are coming from with regards to the pain of having to manage not only the business applications but also the underlying instance and how the instances grow exponentially. I too would love to see greater integration and automatic syncing occurring between the two tables. It would really help cut down on effort needed to keep the business app and related instances in sync. That said, we did develop a script to automatically update the Support and Approval group fields which has helped. I think there is also new functionality with Madrid that helps to automate syncing between Services and their Service Offerings (inheriting the "owned by", "Service Classification" and a few other fields). I would imagine similar functionality could be re-used for syncing the Business Application record and the Application Service. We call the Application Service the Application Instance or Run time to help reduce confusion.

My interpretation of the CSDM is that the Application Service (cmdb_ci_service_discovered) is the top level table for all individual run times of the application, discovered or not. There are child tables underneath that indicate whether it was manually defined or defined via tag based vs some other mechanism.

You're making a lot of sense with the RPA Robots treated like a batch job. For example, robot1 has a prd, dev and qa version of it, we would see robot1 (prd) with the new environment field = prd, robot1 (dev) with environment = dev, and robot1 (qa) with environment = qa with a dependency between the individual app instance and the robot that it is using.

Now to add some complexity to the whole situation:

There is significant interest by our senior leadership in tracking the availability and performance (think Service Portfolio Management) of these micro-services. Now per the CSDM, that information is tracked at the Service/Service Offering level. Per ITIL, a service is what is provided to an end customer for consumption, and the offering is the stratification of that service based on localities in which it was consumed, or different Service Level Agreements (SLA's) for that service (gold/silver/bronze). Based on my interpretation of the CSDM, we would not only need the micro-service as a business app record, the application instance (runtime) records, but also the service offering. But is this really where the industry is headed?

Is there industry interest in tracking the availability and performance of micro-services or is everyone more focused on the higher level service that is being provided such as authentication, trading, shipping, etc?

[Alex_Dundon1]

Daniel, Looks like ServiceNow confirmed our thought process on micro-services: https://youtu.be/C6d568OJOOs

[Daniel Carvalho]

Hi Alex

Indeed! If the SRO set the tone, this video on examples made cristal clear.

Microservices, for all due effects, are applications, just small. But keep track on new doubts I will present Mark. Once those are posted, I will link them here.

Cordial

[Daniel Carvalho]

Following on: https://community.servicenow.com/community?id=community_question&sys_id=7885f26a1b683c50fc3233bc1d4bcbae

[Daniel Carvalho · Accepted solution]

11 months later, now closing-up this thread, at least for me:

• Robots (RPA bots) CI - will probably come OOB, Rome or later. For the moment new custom table alike "Batch Jobs" table.
• Microservice CI - Application services pure view. See Mark Bodman examples video.
• Data Integration Service CI - New custom table for me, extending from cmdb_ci.
• Sub-Module CI (within a main enterprise application or a major Module of a enterprise application) - Userd Biz_App Architecture Type field, submodule got "Platform App", Application itself got the value "Platform Host", created a new value for "Application Family/Ecosystem".
• Underlying support technologies (CI ??) - No CI! Finally decided to use Product Model (specially Application Product Model) with bunch of new attributes!

Hope you reading this enjoy!

Daniel