Modeling: Interfaces

📘

Important Information

This page is a modeling guideline for Meta Model v3. Updated guidelines for Meta Model v4 is available in the documentation.

General Interface Modeling

The main idea behind the Interface Fact Sheet is to take a business perspective. Typical questions raised are:

• How are Data Objects exchanged?
• How are Applications related?
• What needs to be considered within a Project?

Customers also use it for more technical use cases (e.g. which Web Services are offered), but often the business use cases are more prominent.

Dataflow vs. Provider / Consumer
An Interface in LeanIX is related to Applications in two ways:

• An Interface can have one Provider Application
• An Interface can have many Consumer Applications

Provider / Consumer does not refer to the direction of data flow. There is a separate attribute for this which is used in the Data Flow report. Instead, it typically refers to ownership and change management. Examples include:

• LeanIX is the Provider for the public LeanIX REST API (similar to any other public API). The API only changes if LeanIX is changed (e.g. updated to a new major version). Since this is a public API, there may be Consumers you are not aware of. In this situation, it is valid to leave the Consumers field blank.
• If a system is providing a web service, then the system is the providing Application.
  For other technologies (e.g. FTP), determining the Provider or Consumer(s) is not as straightforward. To deal with this, it is good practice to define clear conventions for your organization.

Why is there only one Provider Application?
Please see above. The Provider refers to the Application that owns the interface as well as connected Change Management process. Hence it makes sense to have only one "owning" Application.

How to model Interface technology?
There are two good ways to model technology for an Interface:

• As a Tag Group: The advantage is that it can be displayed very prominently on the Interface Fact Sheet.
• As an IT Component: This allows you to reconcile the Interface with IT Components and display the technology on the Data Flow report.

Interface Attributes

Interfaces have different properties which consist of the data flow direction, the interface type, and the frequency. For each of these attributes there are different characteristics that can be selected.

Data flow direction:

• Outgoing: Data flow from interface provider application to consumer application(s).
• Incoming: Data flow from interface consumer application(s) to provider application.
• Bi-Directional: Data flow in both directions between interface provider application and consumer application(s).

Interface type:

• Synchronous: Application immediately receives sent data (typically a single or a few instances of a particular data object) and responds back to the sending application.
• Asynchronous: Application receives sent data with a potential delay (typically a single or a few instances of a particular data object) and might not, or with a delay, respond back to the sending application.
• Batch: A large amount of data is transferred (typically multiple instances and even multiple types of data objects, typically in an asynchronous manner).

Frequency:

• Hourly, Daily, Weekly, Monthly, Yearly: Data is transferred once an hour, a day, a week, a month, a year.
• Real-time: Data is transferred from sending application to receiving application as soon as they need to, i.e. relevant parts of the data have changed.
• On Demand: Data is transferred on an ad-hoc basis, the transfer is triggered manually.