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

[Daniel Carvalho]

Time is great medicine: What I learned since the post, for Microservice CI:

• 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.

Specially if we will be considering service mapping and/or event management, we will have to leverage both Application Services table with it´s respective endpoint´s, considering the internal development scenario.

For the external, WebService is still a possibility, but for the sake of keeping equivalency on the CMDB, my personal preference would still be the Application Services Table.

• My proposal: still without one – waiting for CSDM V3.0.

CSDM 3.0 did not solve it. But SRO plug in did set the tone (may we be happy or not with it). SRO creates microservices as application services.

So, Application services it is, to respect general compatibility with products and plugins.

Regards

[PerV]

Daniel, thanks for the information. I have also tried to figure out how to map microservices in a good way. This finding of yours does though require the installation of the SRO plugin(s), which from what I can see are free of charge. However, the plugins for SRO requires Event Management to be installed and that requires a license, so the new table(s) are not available without cost if I understand correctly. 

How is your situation, are you also using Event Management?

Edit: Another question, I installed the plugins in my dev instance, and it worked fine without installing Event Management first. I tried to determine how SRO classifies Microservices, but I can´t find a specific attribute or sub-class for that.

BR /Per

[Daniel Carvalho]

Hi there @PerV !

Let me interject that the proposed scenario does not *require* Event management, nor the SRO plug in. 

As of My knowledge, the SRO plugin should make it easier to create new micro services, but since the plug in itself do not change the CMDB tables layout & infrastructure, you can / should be able to very well do the use of the proposed microservices model (that, by-the-way, is pretty much the application model + your own added attributes for organization sake) without the need to have both installed (event management nor SRO plug in) but keeping compatibility to them, for 2 reasons:

- Maybe you can purchase Event Management licenses in the future

- Even if you do not purchase, those intrinsic dependencies make this "data model" hard to be changed in the future by the software maker (ServiceNow) therefore, you will be less in "possible problems" in terms of upgrade routines, new functions compatibility etc.

And yes, I do use EM.

Expanding this thought, I will have for each MSVC:

- 1 Business Application entry (instance-agnostic, the registry of the concept of this "micro-application), for me it will be an "platform host" type. I already customized an additional "architecture type" called "application ecosystem", as upper level parent figure

(

thinking such as: ecosystem > Application itself (main stack) > major subfunction

as the types: ecosystem > plaftorm host > platform application

or on real life: SAP > SAP-CO > Transaction KAH2

).

Therefore, I am having a new generic ecosystem called MSVC (microservice abbreviation) as ecosystem for all Microservices. 

Ecossystem: MSVC (maybe one day I migh want to bundle then on "HR MSVCS" and "FIN MSVCS" not looking for this now.. )

Application (platform host level): MSVC-0078-CreateCustomerCRM

- 3 Application services for each microservice-specific instance (DEV/UAT/PRD) & it´s respective endpoint URL.

Named: MSVC-0078_DEV, MSVC-0078_UAT, MSVC-0078_PRD (in my case, I already created a new field on (cmdb_ci) called u_alternative_name (so, for microservices, "CreateCustomerCRM" I will only use on the Alternative name (searchable) field, not on the official/native field Name of the CI for Application Services).

Regarding:

Edit: Another question, I installed the plugins in my dev instance, and it worked fine without installing Event Management first. I tried to determine how SRO classifies Microservices, but I can´t find a specific attribute or sub-class for that.

I did install it on DEV as well, but I had Event Managent there. I can not speak on inner dependencies within them. I would you recommend you to formally obtain a response on this from ServiceNow support on HI portal. SRO as far as I seen, do not add extra classifications. So, if you manage do clear your use of SRO with ServiceNow support, in terms of technical dependencies or licenses implications, it would still be up to you the creation of attributes to dintinguish normal application instances from microservices instances, under Application Services. That is what I take so far!

Cordial

[Alex_Dundon1]

Daniel,

Great questions and we're having similar conversations regarding the robots and micro-services.

One of the various demos/ask the expert type session I attended a few months ago outlined where I think Scott Lemm and company were headed on micro-services. My understanding (and I wish I could find a slide deck or remember which specific session it was for evidence) was that internally developed micro services would have a Business Application record that represented all environments of the micro-service and the individual instances (prd, dev, qa) would be in the Application Service (cmdb_ci_service_discovered) table.Like has been mentioned in other threads on this topic, if these micro-service were supporting a specific monolith (ex SAP or even ServiceNow) you could indicate the dependency using the "Architecture Type" field. However, specific call outs in the CSDM wouldn't appear until after the Rome release.

For the Robots, we had a slightly different approach. We thought of it more as a Service/Service Offering. We would have the service of "Automation" with each specific robot being a Service Offering. Reason being the service they provide is automation, and there are different ways to consume that service of automation. Each Service Offering would be supported by the Business Application: Blue Prism for example. Now obviously as the number of robots explode, I wonder if the offering table is truly the right place. I think I like your approach of looking at robots akin to batch jobs in terms of functionally what they do.

[Daniel Carvalho]

Hi @Alex.Dundon 

I am very glad we (many people I have talked to) are going into the same direction.

Making a long story .. (quite not that) short:

Applications that are ran on the organization, be that something like SAP-CO or even an Zabbix, representing Business Application (not the SN table) or an IT Application should exist on Business Application table (as for being official the existence of it´s concept; Application Lifecycle Management - ALM) as well as under Application Services (and it´s end-points, expecting Service Mapping) for a instantiated approach (SAP-CO_DEV, SAP-CO_UAT, SAP-CO_PRD, Zabbix_DEV, Zabbix_UAT, Zabbix_PRD; on all applicable to each company).

That said; Microservices are being seen as applications, just as well... but small. Applications nevertheless. So, all above is and will still be applicable!

Buuuut..  for the sake of organizing your workspace (matters already out of CSDM worries) you (we) will need to find out manners and approaches to separate "full applications" from microservices. No much of "final recipe" or definitive silver bullet here. Be creative on new attribute fields or reuse OOB ones.

Other pain point I, and someone else in a community post I commented on - do not remember who-, am very concerned is the multiplication of Application Services (table) entries. 1 new business app = 3 new appservices. Business apps do not fall from the tree in much quantity every week. But microservices can be born twice or even at a rate of 5x a week. 5 new microservices = 15 new application services (if you only have DEV/UAT/PRD declared environments). I really hope you do not use 5 declared environments! With 3 I already get the "killer" instinct of creating a business rule on the BizApp table, with a "IF" on "I am a Microservice flag" attribute, just to automate the management of the Application Services entries.

And then Robots and Integrations come into the picture.

OOB CMDB has a cmdb_ci_batch_job table. It does not extend cmdb_ci_services nor any of it´s child´s (including Application Services). Therefore, a JOB is not *mandatorily* instantiated (since we assume, by the intent of keeping application services compatible with event management and service mapping, that application services are ALWAYS instantiated).

If you use Control-M as system por corporate job scheduling, Control-M is a Business Application (entry on this table), under some sort of "IT App" attribute value to differentiate it from SAP-CO, CRM etc. It is possible that you have Control-M instances (Control-M_UAT, Control-M_PRD). 

So, for example, for change management purpose, you could have CR - Change Requests that are instance/environment-aware, by positioning that change "against" the scheduling platform CI (Control-M_UAT or Control-M_PRD); but for specific impacted "component" adding the JOB CI (instance-agnostic) as additional CI. So, you could cmdb_ci_batch_job as a non-instantiated list of names of Jobs, preventing the multiplication of entries to be managed. Also, Jobs probably do not have URLs and would not be great candidates for Service Mapping.

My take on RPA robots is, as of now, exactly the same as this I described for Jobs. I think it as new custom table for RPA Robots, extended from cmdb_ci (just as same as how the Jobs table is), and allowing a Robot CI to relate to all Application CI´s it really interact to perform it´s mission, as well as to the Business Application (table item) of the RPA platform (depends on). Also, if you have a table for "service accounts/credentials" (without passwords or secrets of any sort) you might create references to them as well and offer your community a pretty complete documentation.

And finally, Integrations. I envision 2 kinds of systems integration. My e-commerce app sends data to ELK. My e-commerce app talks to Zabbix. My e-commerce app talks to my Radius service. Knowing a little about My Company inner workings, all already mentioned suffices for a person to understand what happens: 1) log shipping, 2) monitoring, 3) authentication. At first no further explanation is due, it is just Business Application CI linked to other Business Application CI. (Important: not ever at Instance level, only at "concept" (cmdb_ci_business_app) level). Also, usually people do not worry "as much" on "how do Zabbix talks to my application" - there is a sense of "default communication means" implied into that connection, not so many flavors of communication means available for those use cases, normally.

But, for the other nature of integration, things are more blur. My SAP-CO talks to my e-commerce app. In an imagined drawing diagram, there is a dotted line between this two Business Applications (CIs). It is not self-explained! What dataflow runs there? Client data? Pricing? Taxes? How this data flows? SOAP? DbLink? Via an ESB (which itself might also be a Business Application (CI) as well.

So, we go and create a new table for this entity of a "Data Integration Service". But if we extend Application Services for this, it would be implied to be mandatorily instantiated. And there goes more one thousand integration x3 (or x5).. So at this point we just reject this path, and decide to expand cmdb_ci (just like Jobs and RPA Robots) and create a non-instantiated Data Integration Service table to log up all your company´s dataflows, linking the CI´s of BizApp on the side A of the communication to the CI of the BizApp that is the side B (exchanges data with, kind of relation), you label this new CI as something formal and YET informative (DIS-0099-ReportSellTaxToERP) and finally link the Integration to whatever CI represents The communication tunnel (depends on), like "Oracle Enterprise Service Bus".

That wraps up the 3 bellow, in a single thinking stream:

• Robots (RPA bots) CI
• Microservice CI
• Data Integration Service CI

Cordial

Daniel