Modelling interfaces with multiple integration layers (middleware)

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.

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.

Hello,

interesting topic…

In our case, apart from having multiple middlewares, that we have solved by linking the interface to multiple IT components that represent the different middleware types, things get more complicated when you have multiple consumers and those consumers :

• might use a different middleware / it component
• use different technololgy ( Sftp, API’s...) and therefore different frequency, dataflow direction and interface type

To resolve this we have created ( actually copied) all the fields within the “Data and Technology” section from the interface Factsheet and add them to the “interface consumers”  section as well so we are able to define per consumer application all these details.

This is one of reasons we decided to make interfaces only 1 to 1 relations.
Since the main goal is the Diagram functionality we avoided this by forcing unique consumers.

Hi!

This is a really interesting Topic. We have as previously mentioned, separated a Logical and Technical Layer. we have added some extra Sub categories of IT components like API and Integration Component.

On top of that we have Integrated LeanIX with Azure using Azure resource manager where we import all “important” Integration components such as Functions, Logic Apps, Event Hubs etc etc. 

For other Components we only use generic IT components such as SFTP, Blob Storage etc.

So when it comes to re-use of Integration components like APIs, as we connect them to the interface we can se where the component is re-used and not. We can also use LeanIX to start our investigation and then move on the Azure Dev-ops as we also import the URL for the component.

On top of Separating the Logical layer with the technical, we also have decided that the Adapter or system API is not part of the Interface rather part of the application. 

The Down side is as mentioned above, we do not automatically get the sequence. We would have to use Diagrams to draw that. But we try to see that as a part of the Solution Architecture process.