- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello fellow CSDM navigators,
In my organization, several business units leverage RPA processes or "Bots" to automate manual processes. Today some are represented by a Business Application record and others have been relegated as "Components" (not SDLC Components, a custom class introduced by the third party UPMX application by in spi). I've seen other companies model bots as application services within a Business Application.
Where I see problems with the use of Components is that it doesn't fit in to the CSDM model and it obfuscates the cost of each bot. Also, from an operations perspective, some of these bots are big enough that they have dedicate infrastructure and again, we'd be breaking CSDM by adding that infrastructure directly to a Component or by relating an Application Service that contains that infrastructure to a Component. SDLC Components with related child Application Services containing infrastructure could actually work with this model, but doesn't address the cost issue.
Where I've seen bots represented as Application Services under a parent Business Application representing the bot "platform", we still have the cost obfuscation issue.
Has anyone modeled bots as Business Applications with the Architecture Type "Platform Application" and the bot platform Business Application designated as the platform host? There's some concern from stakeholders with this model because our BCM process treats all Business Applications equally and the application teams don't want to have to perform a BIA for every BOT, but I feel like we should be able to filter out platform applications from the scope of the BCM process to alleviate that and perform the BIA against the Platform Host containing the bots.
Am I making sense at all here?
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
So I haven't been to the same level of detail you're looking for here, but my pointers would be:
- Infrastructure clearly stays within the infrastructure classes, and if you need to model dependencies between those to a Robot, your Robots need to go to the cmdb_ci_rpa_robot (IIRC) class.
- If you need to identify the health of an entire service, you'd then need your Application Service rollup containing all those infrastructure CIs and your Robot(s).
- If that is the case, you've likely got enough to justify putting that Application Service downstream of the Business Application.
For Business Applications, I'd definitely imagine you'd have a "BluePrism" or "AutomationAnywhere" Business Application. To get to the next level which would answer "what are we actually building on these Platforms?" you might look at a "Platform Application" type Business Application beneath it, indicative of the Bot-Solution built. That would be the BA upstream of your Application Services.
All that to say - I think you're making sense!
Sam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
So I haven't been to the same level of detail you're looking for here, but my pointers would be:
- Infrastructure clearly stays within the infrastructure classes, and if you need to model dependencies between those to a Robot, your Robots need to go to the cmdb_ci_rpa_robot (IIRC) class.
- If you need to identify the health of an entire service, you'd then need your Application Service rollup containing all those infrastructure CIs and your Robot(s).
- If that is the case, you've likely got enough to justify putting that Application Service downstream of the Business Application.
For Business Applications, I'd definitely imagine you'd have a "BluePrism" or "AutomationAnywhere" Business Application. To get to the next level which would answer "what are we actually building on these Platforms?" you might look at a "Platform Application" type Business Application beneath it, indicative of the Bot-Solution built. That would be the BA upstream of your Application Services.
All that to say - I think you're making sense!
Sam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Glad to hear I'm making sense! In many cases, the bots are on infrastructure that is shared among many bots and consist of code, so I'm imagining a hierarchy of Platform Applications to Platform Host in the Business Application table, and child application services representing the bots that show a dependency to the Platform Host's application services that contain shared infrastructure, or possibly a technology management service (Technical Service pre-CSDM 5) that contains the infrastructure for bot hosting. SDLC Components could represent the code artifacts for each bot, as well as the infrastructure patterns used by the platform if we're really going crazy! So many options on this one with CSDM I can see why there's not a single approach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday
All great ideas. The only tip I'd give here is: remember to be led by value. Each of the data entities you've mentioned there has a certain function (IE, they exist to meet the need of a Product). If you're using ITSM, you'll almost certainly see value from the TMS/Offerings - but potentially not the SDLC Components. They would be more beneficial in the EA (I assume) space alongside the Business Applications.
My North Star for CSDM (when I am implementing) is: "As little data as is necessary".