How can you edit the multiplicity of interface relationships

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