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:

I've done this in several organizations, hence my question. 
I understand the option of modelling in ArchiMate 3.2 notation, however that doesn't seem to actually add the desired relationships in LeanIX model/ database.

No worries, it is probably just more getting used to.

 

Hello all,
Following up on the post, I would like to add an alternative approach to obtain information and assistance. Could you please share insights on how to set this up in LeanIX? Please see the example, below:

Thanks in advance for your help in giving one direction to load interfaces with this structure.

Best regards,

Davidson IZEFLER.

Hey there,

I have a background and experience in a certain way, but still quite untainted when it comes to the topic of EAM and LeanIX. So I'm trying to approach the matter with logic and what seems reasonable to me.

Essentially, as far as I understood, there are three options:

• Option 1: “Turn up” the multiplicity in the meta model (SINGLE → MUTLIPLE)
   

  

   

• Option 2: Exclusively maintain consumer relationships
   

  

   

• Option 3: Maintain specific interfaces
   

  

   

When I try to "fit" this into my overall way of thinking, I tend toward Option 3. While this is more effort in terms of documentation, I will very often need this level of detail, as it reflects the process flow, not least.

In the end, it's also important that we document changes in the interfaces correctly. Changes in architectures should happen exclusively in a controlled and documented manner, which I would map at the ITSM / CMDB level and therefore I also need an asset (CI) that I can change and document accordingly. If I now can't maintain an interface as a CI because I, for example, "only" maintain the customer relationships, it becomes difficult.

How do you see this? Who with solid experience can say whether this is a sensible or less sensible approach? Am I on the wrong track or does that makes sense?
I know, that starting with less detail should be the way to go, but how less is enough? Especially in the context of lifecycle management of assets? 

Thank you very much advance!
Eric

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 ​@Thomas Schreiner ,

as far as I got you, you wouldn`t use interface fact sheets at all (option 2 in my picture up above)?
I totally understand, that this means much less documentation effort, but how do manage the lifecycle of your interfaces in context to the change management?

It seems for me, that this is a general question, on how deep you want to connect EAM with ITSM. Did you connect it? If yes, how do you handle changes on interfaces, if I may ask you?

Thx a lot in advance,
Eric    

We've decided to go use this conundrum as a business case to instill an interface management system to mimic the desired level of granularity.

That way provider can be consumer.

Hi mvanrooijen,

you mean like an ESB (Enterprise Service Bus) or the SAP Integration Platform? For centralizing the “Connector” of your interfaces, let`s say.

But was that the consequence of the “lack” of possibilities in EA documentation in LeanIX? No? 

BR
Eric

Yeah, like an ESB (I am trying to steer away from even more vendor lock-in with SAP).
And whilst it wasn't a direct consequence of the lack of EA possibilities it was a beautiful way to highlight the complexity interfacing without an Interface management system creates