question 5 new CI classes? RPA, Microservices, Integrations, Sub-Modules & Underlying Tech in Common Service Data Model forum

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

Daniel Carvalho — Fri, 24 Jul 2020 21:56:55 GMT

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=69bdc9b81b745010a59033f2cd4bcbe0)
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=81e1cbf61b255050ada243f6fe4bcbea) 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

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

s4scott — Sat, 25 Jul 2020 02:05:08 GMT

A couple of observations:

RPA - Cannot be a single class. In the various tools I've worked with, and the tool my org eventually settled on there is an Account CI, the robot, representing a pool of service accounts that can run the process automation and the process automation itself. They are related but decoupled. Thus, two CI classes are required. The "Robot" is a pool of service accounts that can run one or more Process Automations. Additionally, the Process Automation may interact with a single application or multiple applications.

Data Integrations - similarly you cannot get away with a single class. Most integrations are a string of integrations not just a single monolithic code base. A better approach would be to leverage two CIs such as an Interface and Integration model. The Interface would describe a high level interaction between two application services, with each individual API, ETL or Direct integration enumerated within the Interface as an Integration CI. This support a Dev-Ops model where different teams focus on different APIs within the Application to Application interface.

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

Declan Kenny — Mon, 27 Jul 2020 19:38:11 GMT

Daniel

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

This use-case is addressed in the CSDM 2.0 whitepaper.

In the New York release of ServiceNow, the “architecture type” attribute on the business application
contains the choices “platform app” and “platform host”. These architecture types help represent
platforms as one type of business application and related business applications which depend on the
platforms separately.

In the SAP example, we would model the SAP platform as a business application with an architecture type of "platform host" and then model the individual, functional components (A/c payable, General Ledger, etc) as separate related business applications with an architecture type of "platform app"

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

Daniel Carvalho — Mon, 27 Jul 2020 20:43:28 GMT

Hello @Declan Kenny

Thank so much for the input!

I got to say that I did read this paragraph before and (perhaps due language barriers) it´s meaning hadn't sunk in to me.

As I do perceive app architectures, I would have the following example structures:

SAP ERP >> SAP-FI >> FB01 Transaction

Oracle EBS ERP >> Oracle EBS PO >> Purchase Request

So.. for both examples I was already considering their top levels (SAP ERP >> SAP-FI and Oracle EBS ERP >> Oracle EBS PO) under Business Application Class, and now with the attribute “architecture type” as this parent-child relation: “platform host” >> “platform app”.

(even though these expressions "platform host” and “platform app” both fail to get me passionate to them)

But my quest is really about the level of the "FB01 Transaction" and "Purchase Request" items.

It could be shortness of sight from my part, but I would struggle to consider those latter as “platform app”; as well it would be hard to me to see both to levels as parent-child under the same “platform host” sticker.

Back to CSDM 2.x relations map, Business Applications, when "platform app", would nicely relate to their "Application Service" under the concept of instances. I do make instances (Prod, Dev etc.) for the Module (Oracle EBS PO for example). But I feel that one can´t single out "Purchase Request" (submodule / function) to instantiate just it.

Am I that stray from the concept you brought from the whitepaper?

Cordial

Daniel

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

Daniel Carvalho — Mon, 27 Jul 2020 20:52:54 GMT

Hi @s4scott

RPA - nice take! Service accounts do make huge part of it. This control requires a greater maturity level / control appetite though.

Data Integrations - I see what you mean. You held "Data Integration" as a major sense while I was really placing it at inteface level. To my specific short-term need Data Interface would probably be enough, but later on we would certainly miss the bigger view.

Cordial

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

Daniel Carvalho — Thu, 13 May 2021 09:56:00 GMT

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

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

pellesnurr — Mon, 17 May 2021 07:46:11 GMT

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

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

Daniel Carvalho — Mon, 17 May 2021 18:02:27 GMT

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:

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

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

Alex_Dundon1 — Mon, 17 May 2021 19:33:12 GMT

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.

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

Daniel Carvalho — Mon, 17 May 2021 21:22:22 GMT

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

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

Alex_Dundon1 — Tue, 18 May 2021 16:56:50 GMT

@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?

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

Alex_Dundon1 — Sat, 05 Jun 2021 21:47:52 GMT

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

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

Daniel Carvalho — Mon, 07 Jun 2021 18:58:45 GMT

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

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

Daniel Carvalho — Tue, 08 Jun 2021 03:45:39 GMT

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

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

Daniel Carvalho — Tue, 08 Jun 2021 03:53:45 GMT

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