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

[s4scott]

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. 

[Daniel Carvalho]

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

[Declan Kenny]

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"

[Daniel Carvalho]

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