Is Depends on the only relationship type for Application Service to Application Service?

[Robert Campbell]

When reviewing CSDM 5 documentation it shows a relationship type of Depends on::Used by between application services/instance. In the text below, it mentions that the relationship type is specific and necessary between business application and it's instance for functionality such as TPM risk assessment to function. Is there the same type of restriction for application service/instance to application service/instance?

 

For many use cases, the relationship can be translated to depends on such as, if an instance receives data from another, you can argue that's a depends on relationship. However, if it doesn't receive that data, the instance still works, it just works with old data. There's likely a reason the data isn't being sent by the other application and that should cause an incident which could trigger a change on the other instance so there may be some impact but maybe not.

I think the best relationship type would be Receives data from::Sends data to or maybe even Uses::Used by but it definitely doesn't depend on it. The questions are

• Do I have to use Depends on::Used by for instance to instance relationships or is this just an example of what could be used? 
• Will functionality be impaired by using Receives data from::Sends data to or Uses::Used by or Exchanges data with::Exchanges data with

for instance to instance relationships? While making updates, we would like to get in alignment rather than coming back and doing them later.

[Fabian Kunzke]

Hey,

So this is a principled question. I really like it. And to be honest, there is no real answer to this.

The operational domain (the orange part) is boiling down to impact relationships. These relationships are not in place to determine how something impacts another thing, but rather what impacts what. The idea being that you'd otherwise would need to go into detail on how everything impacts everything else in operations as well, resulting in multiple relationship types being needed in some cases.

In short: In operations the depends on::used by is there to show what is impacted, not how.

However, the data exchange is indeed something you'd be interested in. In a perfectly modeled world, this is done through the API CI class. It does describe the impact between very specific CIs.

And this is where there is no real answer. At the end of the day, these recommended relationships are bound to very generic classes. Not every application instance will provide data. Still, we need to recommend some relationship type - in this case the most generic one.

Further, with governance we report on the basis of these recommendations. Which is why we ideally follow one recommended relationship type (to make it less confusing for everyone). But sometimes we miss accuracy with that.

Where am I going with that?
Well, no-one prevents you from using more specific relationship types. It's not like its against some artificial law and everything breaks down. Just remember that more specific recommendations require more specific governance. And adding specific governance to general objects is just running into the risk of being inconsistent.

My recommendation: If you have the strong need to highlight data exchanges between instances on the operational level, do it.

Even better: start modeling APIs according to the model. This is the specific section for this exact specific requirement. However, this may need more effort than you would like.

As a CSDM advocate my official stance on this:

Prioritize impact based modeling. Detail relationship types only whenever you have detailed CI types.

My not-so-official stance:

As long as the relationship types are used consistently and you can govern the use of it - go ahead [ONLY IF IT HELPS YOU IN ANY PROCESS!]

Regards

Fabian

[Robert Campbell]

So that I'm clear, are you saying we should show the what and the how or I should only show the what? There is a desire to have the how and pushback on the what "because it isn't accurate".  If adding both is necessary and beneficial, I can do that, I just have to justify having both relationships.

[Fabian Kunzke]

Personally I would reduce the relationships on impact (Depends On).

If you have a strong requirement & can enforce the governance behind it, use any relationship type you deem to be reasonable. If it leads to a situation where you would need to maintain multiple relationships (because there are multiple types for one dependency) i'd advise against it. From my experience it becomes way to cluttered.

Keep in mind: There is a best practice to highlight data exchange within CSDM. It's either in the Design area (which does not reflect the operationalized world) or between API CIs and Application Instances (which i highly recommend to look into as it is even more accurate).

In short: The recommended relationship types are "just" recommendations. Before you use different types, ask yourself:

1) Do i have a strong need for it?

2) Can i enforce governance around it?

3) Is there an alternative way i could use?

If you are sure, based on your answers, this is the best way to move forwards, do so.

Regards

Fabian

[fknell]

Hi @Robert Campbell,

Additional products may introduce new relationships to the CSDM baseline. For instance, enterprise architecture will add the ones you’re mentioning as an example; an 'interfaced by' relationship from business application to itself will be added. Digital Integration Management will give you the possibility to specify the integrations and APIs used to exchange data.  

Below you find a comparison of all relationships baseline vs. after installing EA.

@Fabian Kunzke is outlining very well the concept of the operational domain and why the particular relationships are used. What you are looking for is a more abstract view of the business applications, how they are linked together, which business capabilities they provide, and which business process they're part of. This is typically done in the 'Design & Planning' domain.

Hope this helps!