Skip to main content

Hi All, 

We have a couple of challenges, one of them being that an interface can be both a provider as wel as a consumer at the same time. this is how that works:
An application provides a dataset through an interface, this is consumed by another application. That data set is edited in the second application and provided back to application one who then consumes it. At certain points in time that interface also communicates the dataset directly to another interface.

Any advice on how to model that would be greatly appreciated. My preferred solution would be to change the multiplicity from Manty to one to Many to Many relationships on provider as well as Consumer interfaces by the way.

 

 

Hi ​@mvanrooijen 

I would advise against changing the multiplicity of standard relations, as you might break your compatibility with standard features. If you still want to go down that road, feel free to get in touch with LeanIX Support, and they might be able to change the multiplicity manually for you.

Personally, I would model this interface on a much higher level. I would do it like this:

  • Provider Application: App 1 (assuming that the data originates there, and that App1 “triggers” the interface)
  • Consumer Application: App2 and App 3
  • Data flow direction: bi-directional

If you want to do it in a more detailed way, you need to be aware that this extra level of detail will provide only very limited benefit. If you want to use LeanIX for data flow management and data tracing, you will have to go into a higher level of detail anyway. Maybe like this:

  • Provider App1 → Interface1 → Consumer App2
  • Provider App2 → Interface2 → Consumer App 1 and Consumer App 3
  • And in the interface description, you describe exactly how the data flow is orchestrated, so that people will understand it. In complex scenarios. free text is still more powerful than the best model :-)

Good luck with finding the right approach.

Thomas


Thanks Thomas, 

To bad this is the approach LeanIX has chose, with limited adherence to common architecture language and relationships.

 

It is what it is.

I'll see how I can make this work.


You can do it on any level of detail that you want, also with LeanIX ArchiMate diagrams if you like, and LeanIX will not stop you. It’s just that I doubt the benefit of going so deep in using the inventory for expressing detailed complexity, as in my 8 years of LeanIX work I have never seen anybody doing an inventory analysis or an inventory report that covers this kind of input data. I guess that this would rather be a case for LeanIX diagrams with ArchiMate or a similar modelling approach.

If you want to check if this works for you, go to the Diagrams editor and then press “More Shapes” on the bottom left:

 

 


Reply