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

[Joseph Lighthal]

Thanks @Vikram Reddy this is very helpful. This relationship, App Service Prod X -> Depends on::Used by -> App Service Prod C, not being the other way for App Service Prod C was intentional as C does not depend on X.

Also you mentioned the relationship, Uses::Used by (Consumes::Consumed by if you're still on CSDM 4.0). From what I have gathered the relationship between a Business App and App Service is Consumes::Consumed by. The CSDM 5.0 white paper does show in the picture of relationships Uses:Used by, however within the paragraph below it states Consumes. You can also see in the script include, CSDMAppServiceHelper, the Consumes relationship is used. Unless I'm missing something or not understanding what you put there.

I had seen the API tables to but steered away as those look like they are to be auto populated. I did not want to pollute them with manual data that later may be inaccurate. I had recently heard of "Digital Interfaces" through EA and that (for my lack of further explanation) that would be the place to store some of this data.

Regardless this is helpful. Thank you @Vikram Reddy!

[Mathew Hillyard]

Hi @Joseph Lighthal 

What do you mean by "code in separate systems"? This could be many different things. If it is a genuine standalone system with its own stack, development and upgrade path, then that entity should be a Business Application. However, Business Applications enable Business Processes and/or Business Capabilities. How do A, B and C fit in with this description? If they don't enable either processes or capabilities and they don't reference their own individual Application CIs, maybe they're just Application CIs themselves?

Be very clear on what your "system" is and what it is not, and apply that information to the description of a Business Application or a Service Instance in the white paper. This should normally get you the answer you need.

If you believe they are separate Business Applications, then multiple "systems" can be brought together under one umbrella then potentially you could look at a Platform Host/Platform Application scenario (X is the Host, A, B, C are the Platform Applications).

If you are looking to integrate between Business Applications and you have Enterprise Architecture then consider Digital Integration Management - much more real-world useful .

Finally, CSDM 5.0 is out but the platform has not been updated to match it. So if you're implementing or working with CSDM, by all means use the new terms (Service Instance, Technology Management Service etc.) but for the Business Application to Application Service relationship, stick with Consumes::consumed by until ServiceNow gets round to fixing this in the several different platform areas that have not been updated (CSDM Data Foundations, App Service Wizard, Query Builder, Enterprise Architecture et al).

I hope this helps?

Mat