Is the Prescribed Relationships Exhausted?

[Robert Campbell]

If we use some different relationships than this, will it "break" CSDM or have a negative impact in any way?

I believe there should be some more relationships, especially from application instance to application instance (service instance). Some instances uses another instance. It doesn't depend on it because to me, depends on means if the one it depends on is down, this app is down and that isn't the case. Some functionality may be down. The desired operation may not work but there are likely some workarounds in place to handle it unlike those applications that go down and now you're dead in the water. For instance, many apps may use an authentication app for it to be functional for anyone but if that authentication app is down, the other app still works, you may not be able to access it because authentication is down. It may also still run all of it's background services, it's just the user interface portion is unavailable.

Will using Uses::Used by in this scenario cause a problem?

And since I mentioned it, why is it called a service instance rather than an application instance? Isn't it supposed to represent an instance of the business application? I'll leave that for another post.

[Mark Manders]

Have you checked the new v5 CSDM course? A lot of explanation is done in there.
To your question: I think you are correct, but a lot of things can be seen in multiple ways, depending on your definition. Because the fact that the authentication app is down and I can't log in to the application because of that, means that it's not working for me (yes it runs, but it's not accessible and to a user it doesn't matter the reason, he can't use the application). So in that way, the app is depending on the authenticator app to work. There is a 'possible' impact. A workaround (other app, email, one time password, whatever) can revert it, and because of that 'uses::used_by' makes sense, and will also give servicedesk agents and issue resolvers the insight in a workaround/possible solution, but somewhere a standard needs to be set. And I think CSDM has chosen one, but as long as you define the relationship in a uniform way, you could pick another one. As long as you don't use both, because that doesn't make sense.

A database server can contain all the data my application is using to show me progress. If that application is down, the database server can still be running. I just have no way of checking the progress. My application still depends on the database server. Just not in a 'does it run' capacity.

[Johannes]

"Will using Uses::Used by in this scenario cause a problem?"

You can not "break" CSDM, and if you do this purely to the visual representation of the usage, that is perfectly ok.
However, ServiceNow explicitly ties product features to the expected tables/relationships/-types; deviating means you potentially won’t get full value OOTB from ServiceNow applications and workspaces you are using. (This can be remediated though by adding these relationship types to dependent rules.)

You can however possibly solve your use case and still be "CSDM compliant" by separating the different functionality/modules of the application into multiple ASs/SIs, (and possibly also have multiple Offerings related to these if needed), and then have those dependent on other ASs/SIs (or the SOs dependent on other SOs).