Skip to main content

What is the best practice for naming interfaces? I’m new to using interfaces in LeanIX and how they are used in diagrams. Could you please recommend some best practices? For example, the ones that your company uses.

In the Interface Modeling Guidelines, the only recommendation mentioned is:

“Define self-explaining naming conventions. Establish clear conventions within the organization to determine ownership and change management responsibilities for Interfaces, promoting consistent modeling practices (e.g., Provider, Publisher/Subscriber)”

I also found that in the documentation, they name it “App1 to App2”. However, I find it not suitable if the interface is bi-directional.

I would appreciate some practical examples. Thank you.

 

​@raisasalsabil there is really no best answer for this, so many will have different opinions, but we tend to go with a format like:

Have to use “to”, “from” or “-” for direction as arrows “->”, “<-” or “<->”are not allowed in the name.

Hi,

I automatically rename our interfaces automatically in the following way:
ProviderApplication->{ConsumerApplication1+ConsumerApplication2...} - [DataObject1+DataObject2...]
e.g.: SAP S4HANA->{SAP CPQ} - [Material]

Usage of -> in this approach is no issue in our system:
 

The Provider Application is defied at our system as the data providing application (anyway if there is an exchange in both direction we use the technical provider). We model middleware as component.


Renaming is done as soon at least each of the relation is available. The initial name is moved to the alias field, which is made read only all except the accountable subscriber.

The disadvantage is that you sometimes get long names, the advantage it that you can easily find duplicates.


Best regards,
Carsten

Hi ​@raisasalsabil,

We have done quite a bit of thinking/evolving wrt this topic and have been using the following naming standard for quite a while now:

<app>-<style>-<nn>

where: <app> = name of the Provider application (exactly as named in LeanIX)

            <style> = abbreviation of the Interface Style, either API or E/M or FT or DC or MAN

            <nn> = sequential number (starting at 01 for each Provider/Style combination and incremented for each unique combination of the other key properties such Data Flow Direction or the related IT Components involved)

Note that we’re only modelling interfaces at the logical level (not individual APIs etc) and are mainly concerned with the style of interface with a preference for API or E/M (Event/Message) based as opposed to FT (File Transfer), DC (Data Connection) or MAN (Manual).  We continue to add multiple consumers to a particular interface if the key properties are the same but need/use the sequential number if they’re not (e.g. diff IT Components involved between app A and B as opposed to between A and C).
At the end of the day my view is that it’s just a name to (hopefully) aid easier visual recognition etc and all the key info should/must be in the fact sheet itself.

FYI - There is a standard automation in LeanIX Automation Platform where you can configure your naming scheme and it will automatically(!) name your interface fact sheets according to your convention.

https://www.aronis.de/expertise#details

Hi,

I automatically rename our interfaces automatically in the following way:
ProviderApplication->{ConsumerApplication1+ConsumerApplication2...} - [DataObject1+DataObject2...]
e.g.: SAP S4HANA->{SAP CPQ} - [Material]

Usage of -> in this approach is no issue in our system:
 

The Provider Application is defied at our system as the data providing application (anyway if there is an exchange in both direction we use the technical provider). We model middleware as component.


Renaming is done as soon at least each of the relation is available. The initial name is moved to the alias field, which is made read only all except the accountable subscriber.

The disadvantage is that you sometimes get long names, the advantage it that you can easily find duplicates.


Best regards,
Carsten

 

 

Hi ​@Carsten , I would like to know what automation method you are using for interface naming.

Reply


Terms & ConditionsCookie settings