Business applications vs locations

sylvainbarr
Tera Contributor

7 hours ago

Good morning, I am currently working with a customer that is on ITSM Pro. We are deploying Incident, Change, Request... the customer is decentralized, meaning that there are 20 seperated divisions (BUs) spreaded globally. We have imported their Business application registre, was in SharePoint, and the customer wants to be able to quickly indentify which division is using what BA, a BA can be used by several divisions. I would like to get your thoughts on the matter. I am trying to stay away from custom tables, but I am starting to think that I might not have any other options. Also, customer is currently looking into EA capabilities, not sure if this would facilitate this.

I was thinking of creating an application service per location and create a relationship with the BA.

 

Thanks for your help

0 Helpfuls
  • 97 Views
1 REPLY 1

Itallo Brandão
Giga Guru

2 hours ago

Hi Sylvain,

You are definitely on the right track! Steer clear of custom tables—that is the best decision you can make, especially since your customer is considering EA (Enterprise Architecture) capabilities (Application Portfolio Management - APM) in the future. APM relies heavily on the standard CSDM table structures.

Your idea of creating an Application Service per location/division is actually a standard CSDM (Common Service Data Model) pattern for this scenario.

Here is why your approach works and how to structure it:

1. The "Design" vs. "Run" Distinction

  • Business Application (The "Design"): This record represents the software globally (e.g., "Workday"). It should remain agnostic of location.

  • Application Service (The "Run"): This represents the deployment/instance. This is where you connect the location.

2. Why "Application Service per Location" is the right move for ITSM: If you create App Service: Workday - North America and App Service: Workday - APAC:

  • Incident/Change: When a user in France reports an issue, the Service Desk selects the European App Service. This gives you immediate, granular reporting on which division is having issues.

  • Support Groups: You can map different Support Groups to each App Service (e.g., the APAC team supports the APAC instance).

  • Mapping: You relate all these Application Services to the single parent Business Application via the Implement/Instantiates relationship (cmdb_rel_ci).

3. The "Service Offering" Alternative (The "Fly" Phase) If the infrastructure is exactly the same for everyone (e.g., a single global URL) and you only want to track "Who consumes it" without creating fake CIs, CSDM suggests using Service Offerings.

  • Structure: One global Application Service -> Multiple Business Service Offerings (e.g., "HR System Access - Division A").

  • Pros: Keeps the CMDB technical map clean.

  • Cons: Slightly harder for Service Desk agents to select the correct Offering vs. selecting a CI (App Service).

Summary Recommendation: Stick to your plan of Application Services per Division. It is the most pragmatic way to handle decentralized ITSM reporting and support routing without needing custom development. It creates a solid foundation for APM later (APM will calculate costs/scores based on the aggregated Application Services).

If this response helps you, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,
Brandão.