Not sure you’re going to get a simple/single answer here, but I can say how we’re doing it. Firstly, we’re only modelling interfaces at a logical level based on the type/style of interface and the IT Components involved, not specific/physical APIs or File Transfers etc. For multi-hop interfaces like this one we just decide/model the primary type/style based on what is most important to us and then use the Description field to describe the hops which may well have different properties, e.g. for this example we might model it as primarily a file transfer (named along the lines of ProviderApp-FT-01), with Middleware1 and Middleware 2 mapped as ITCs. We don’t include the consumer in the name since this restricts re-use of our logical interfaces, e.g. there might be another consumer with exactly the same hops/ITCs involved. We could just as easily represent/name it as API style since we will still have the detail described for the various hops, so what we choose as the primary style isn’t that important. If we have a similar interface that also involves Middleware3 then we would model this as a separate interface given the ITCs are different. I’m not sure how else we could do it, without modelling the middleware as Applications which we don’t really want to do as we really only care about the interfaces between “real” applications. Hope this helps.
Hello,
This is something that has troubled me too. I have a mediocre fix for this, which is the best I could do without ruining the diagrams and without creating numerous application/microservice fact sheets just to capture an interface:
Create new relations in your Interface fact sheet metamodel, so you would have one, two, three, or more IT component relations named "middleware 1," "middleware 2," "middleware 3," etc. In these relations, you can add fields to represent the different properties of each interface. You can later see this via labels in diagrams to some extent.
What worries me though is this,
capturing the business logic and dependencies with interfaces might not be enough when asked about system complexity or when providing technical diagrams to solution architects.
This is a huge pain point for me, and I believe it's caused by missing functionality in the tool. I think that considering capturing the technical aspects of an interface an "antipattern," according to LeanIX's documentation, is unwise, considering we purchased licenses for a tool with the purpose to help with transparency in our IT landscape.
While capturing interfaces using both perspectives and separating them via subtypes is an option, capturing the technical implementation of an interface is often ambiguous, not because it inherently is, but because of the current functionalities limitations.
You can bypass some ambiguities by setting rules and making assumptions (e.g., setting the provider in file exchange interfaces by xyz conditions), but in cases like yours, the tools to represent this seem unavailable.
A colleague and I discussed creating an application subtype or using the microservice subtype to represent these kinds of interfaces. We would connect each {microservice/other subtype} fact sheet to each other and group them by aliases or another field.
This would kind of work, but it isn't what we want. The option to represent middleware and add multiple middlewares to an interface would be the most convenient solution. But I don’t think this is currently being addressed as an issue.
We concluded that the Interface fact sheet would be much more flexible if we could embed interfaces inside it, define properties and data for each one, and make the embedded interfaces endpoints IT components instead of only applications. That way you could add as much interfaces you need under the same roof, until you represent what you want.
It goes without saying that after this, the Data Flow diagrams would be adjusted accordingly showing something close to the diagram you uploaded.
This would allow both technical and business capture of interfaces and provide critical value to solution architects and other people running assessments, like business analysts.
Maybe we should suggest this on the roadmap page. I've had countless discussions about the technical aspects of interfaces with clients and colleagues and the value they could provide.
Sorry about the long read.
Hello,
This is something that has troubled me too. I have a mediocre fix for this, which is the best I could do without ruining the diagrams and without creating numerous application/microservice fact sheets just to capture an interface:
Create new relations in your Interface fact sheet metamodel, so you would have one, two, three, or more IT component relations named "middleware 1," "middleware 2," "middleware 3," etc. In these relations, you can add fields to represent the different properties of each interface. You can later see this via labels in diagrams to some extent.
What worries me though is this,
capturing the business logic and dependencies with interfaces might not be enough when asked about system complexity or when providing technical diagrams to solution architects.
This is a huge pain point for me, and I believe it's caused by missing functionality in the tool. I think that considering capturing the technical aspects of an interface an "antipattern," according to LeanIX's documentation, is unwise, considering we purchased licenses for a tool with the purpose to help with transparency in our IT landscape.
While capturing interfaces using both perspectives and separating them via subtypes is an option, capturing the technical implementation of an interface is often ambiguous, not because it inherently is, but because of the current functionalities limitations.
You can bypass some ambiguities by setting rules and making assumptions (e.g., setting the provider in file exchange interfaces by xyz conditions), but in cases like yours, the tools to represent this seem unavailable.
A colleague and I discussed creating an application subtype or using the microservice subtype to represent these kinds of interfaces. We would connect each {microservice/other subtype} fact sheet to each other and group them by aliases or another field.
This would kind of work, but it isn't what we want. The option to represent middleware and add multiple middlewares to an interface would be the most convenient solution. But I don’t think this is currently being addressed as an issue.
We concluded that the Interface fact sheet would be much more flexible if we could embed interfaces inside it, define properties and data for each one, and make the embedded interfaces endpoints IT components instead of only applications. That way you could add as much interfaces you need under the same roof, until you represent what you want.
It goes without saying that after this, the Data Flow diagrams would be adjusted accordingly showing something close to the diagram you uploaded.
This would allow both technical and business capture of interfaces and provide critical value to solution architects and other people running assessments, like business analysts.
Maybe we should suggest this on the roadmap page. I've had countless discussions about the technical aspects of interfaces with clients and colleagues and the value they could provide.
Sorry about the long read.
Interesting angle, thanks for sharing. We’re deliberately trying to keep things at a high/logical level (that we can maintain relatively easily), with most of the interface detail held/maintained within our integration platform repos/tools, but adding extra/dedicated relationships for capturing multiple middleware layers/tech is something we hadn’t considered.
hi all,
juste to bounce on the previous comments, we have decided in leanIX to document the logical view (from provider application to consumer applications).
We also link the IT component representing the middleware used for that interface, but the technical documentation of the interface is supposed to be hosted outside of leanIX (including any diagram being the technical representation of that interface)
