Why is it modeled like that? This question often comes up in CSDM workshops. This series of small articles will dive into some specific modeling practices related to not just CSDM but also Service Mapping.
With platform teams in larger companies there will eventually be a discussion around modeling a data bus - bei it TIBCO or WSO2 (or anything alike). For architects this modeling seems to be straight forward, but as with the last article, the CSDM way might be a bit unnatural.
The model
The first instinct of service owners and architects alike is usually to go a pretty straight forward route, based on connectivity:
And this model comes with a big issue:
What happens when one of the sources the bus is connected to has an issue? As per impact calculation now the bus will be impacted. And whenever the bus is impacted, all consuming services will be impacted as well.
But wait, that's not right. Most consuming services won't use all available sources of the bus, right? So they might just be fine. Exactly! And this is why the model I recommend looks different:
As you can see, the consuming services and/or application instances will relate to the data bus (for data consumption functionality) and - separate to that - to the datasources they connect to through the bus. This solves the impact issue, while making sure the model includes all the service relevant components.
The key principle
CSDM is not your IT architecture. It is there to visualize dependencies, but more importantly impact. This must be kept in mind when creating these models.
If you have any CSDM related example where you want insights on "why is it modeled like that?", feel free to drop a reply and I will look to add it to this series.
