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.
Updated 8 months ago