A single Application Service built within multiple systems

[Joseph Lighthal]

I'm trying to determine how best this is modeled within the CSDM.

Consider this, I have code in separate systems, let's say system A, B and C. The code integrates A, B and C together through custom or out of box REST API calls. I considered this complete entity, across various systems, a single Application Service, called App Service X. One team also develops and supports App Service X too. It is an Application Service that is an integration of multiple systems. Here is what I'm considering on how to model.

Does this make sense? Does anyone have something describing such a thing in possibly more detail?

Business App A -> App Service Prod X
Business App B -> App Service Prod X
Business App C -> App Service Prod X

Business App A -> App Service Prod A
Business App B -> App Service Prod B
Business App C -> App Service Prod C

App Service Prod X -> Depends on::Used by -> App Service Prod A
App Service Prod X -> Depends on::Used by -> App Service Prod B
App Service Prod X -> Depends on::Used by -> App Service Prod C
App Service Prod A -> Depends on::Used by -> App Service Prod X
App Service Prod B -> Depends on::Used by -> App Service Prod X

[Vikram Reddy]

Hi @Joseph Lighthal,

Give App Service X its own Business Application record instead of hanging it off A, B and C directly. Model it like this:

Business App "Integration X" (owned by the team that builds/supports it)
  -> Uses::Used by -> App Service Prod X

App Service Prod X
  -> Depends on::Used by -> App Service Prod A
  -> Depends on::Used by -> App Service Prod B
  -> Depends on::Used by -> App Service Prod C

Business App A -> Uses::Used by -> App Service Prod A
Business App B -> Uses::Used by -> App Service Prod B
Business App C -> Uses::Used by -> App Service Prod C

This isn't a style preference, it's a hard constraint in the model. An Application Service (what CSDM 5.0 calls a Service Instance) can only ever be instantiated from one Business Application. It's not a governance rule you're choosing to follow, it's baked into how the parent/child relationship works, the same way Workday Production can't also be an instance of Salesforce. If A, B and C all point Uses::Used by (Consumes::Consumed by if you're still on CSDM 4.0) straight at Prod X, you've technically broken that one-to-one assumption, and every downstream thing that relies on it, cost allocation, lifecycle, Service Mapping discovery reconciliation, starts producing garbage. You already told us one team owns and supports X independently, so give it the Business App record it's clearly entitled to and let Prod X be that app's single service instance.

Once X has its own app, the rest of your structure holds up well. A few things worth double-checking as you build it out:

• Depends on::Used by between Prod X and Prod A/B/C is the right call for the operational layer, that's the relationship Event Management and impact analysis actually walk, and it's meant to answer "what breaks," not "how do these systems talk to each other."
• Fix the reciprocal links, in your example A and B show the Used by side pointing back to X but C doesn't. Probably just a copy-paste gap, but a missing reciprocal will quietly break upstream impact calculations on that leg.
• Don't try to force the relationship type to say more than "depends on." Some teams reach for something like Sends data to::Receives data from to be more precise about the integration, but unless you've got the governance to keep that consistent across the CMDB, you're usually better off staying with the standard Depends on and pushing the extra precision elsewhere.
• If you want to document the actual REST contracts, endpoints, auth, payload shape, that's a separate CI layer entirely. The CMDB CI Class Models app ships cmdb_ci_api (and cmdb_ci_managed_api for versioned APIs) specifically for that, related to Prod X but kept out of the Depends on chain so it doesn't add noise to every impact assessment that touches A, B or C.

Thank you,
Vikram Karety
Octigo Solutions INC