In addition to the question, I have read the following thread which discusses whether or not middleware is modelled as an application or IT component. It is a somewhat related topic though I’m not sure quite addresses this question (maybe it does). We have currently gone down the path of defining application to application interfaces with the ESB as a supporting IT Component

Hi @mtren,

Playing the devil’s advocate here… 

In your example depicted above, if you define purely on the logical level with the ESB as the implementing IT Component, then would that be an interface between A and B or between C and B? And what if the ESB has data persistency/hub characteristics and tomorrow there comes D, which starts consuming data provided by A and or B?

Things can get complicated. That is in my view because we are trying to model the road and the trucks, but the most important logical thing that should be modelled is what gets transported in the trucks: The Data Objects being shared.

I know, not really providing a solution… ;-)

Cheers.

Thanks @Helder.Luz for the reply, certainly is a tricky scenario. I’d agree in that from a logical perspective the most important aspect we are trying to model is the relationship between A and B and the Data Objects being shared. For context, my role in our organisation is a Solutions Architect, not an Enterprise Architect. My reason for wanting to capture the dependency on App C in this scenario is for future state impact analysis - for example, if we decommission or replace App C in a future initiative I want to know that will impact the interface between App A and App B. One thought I has was to create a logical interface between App A and App B and have children “physical” interfaces representing the interactions with the other systems involved in the interface. At least this way we trace the dependencies.

Some other references within this topic:

Hi @mtren,

I usually model all data flows on the logical level, with the middleware being linked as an IT Component.

So your case would be clearly two interfaces for me, one that is A → B and the other C → B.

A great rule of thumb is to ask the question “What do we want to achieve? Why do we model interfaces after all?” And if the answer is “We want to understand the dependencies and data flows between our applications”, this would clearly be accomplished using the above approach. However, if the answer is “We need an accurate technical documentation of all technical interfaces”, then the ideal solution would probably rather have 3 interfaces, with the ESB in the middle.

For solution 1, as an icing on the cake, you could link the two interfaces with the “Requires / Required by” relation, and add a comment that the data is merged in the ESB and forwarded to B. This way, people will understand the scenario better when they see the fact sheet.

Another thing to consider when deciding on your approach for interface modelling is what the automatically-generated data flow diagrams will look like. If you expect your ESB to show up there, you need to move it up to the Application level. If you rather expect logical views, it’s fine to have it on the IT Component level.

@Thomas Schreiner thanks for the additional input. I do like the idea of modelling the interfaces on the logical level with the middleware as the supporting IT Component. The ‘requires’ / ‘required by’ is also something I will look into. I had considered modelling as two interfaces - another nuance to the scenario however is that there could be no data from App C is being transferred to App B. It is instead a lookup to a piece of reference data that would essentially determine if the data should be transferred between A and B. Anyway, appreciated the help, I think I have enough info to go on now. We are very early on in our LeanIX adoption so just trying to make sure we don’t go down a path that is going to create a rod for our own backs :-)