Interface

📘

This modeling guidelines is for the Meta Model v4. Here, you can access the Modeling: Interfaces for the Meta Model v3.

Definition

Interfaces are connections between Applications. They model how data exchange happens between Applications.

Description

In LeanIX, we apply a business-oriented view of Interfaces, and they are between Applications. The Interface Fact Sheet addresses fundamental questions about how Data Objects are exchanged and how Applications are interconnected. It relies on IT Components (software, hardware, or service) to function. Interface Fact Sheet states data flow directions, type of transfer, and frequency.

This business-oriented view enables organizations to gain valuable insights into their technology landscape and understand how different components interact.

The following visual shows the relations between the Interface and other Fact Sheet types:

You may model middleware (integration platform), Enterprise Service Bus (ESB), and APIs using the Interface Fact Sheet by implementing relations between the Interface and the IT Components or Applications.

Interfaces are implemented via IT Components, Data Objects, and attributes on the Fact Sheet.

Interface Fact Sheet subtypes

In LeanIX, there are two Fact Sheet subtypes for different categories of interfaces:

• Logical interface: Logical interface provides a clear and conceptual view of how data, services, or information flows between various components, applications, or systems within an IT landscape. It defines the methods, protocols, and communication patterns used to exchange data or services without specifying the actual physical connections or technical implementation. So, in conclusion, logical interfaces are used to define communication between Business Applications, focusing on the interactions and data flow. Example: LeanIX to Signavio.
• API: APIs provide functionalities accessible to external applications, enabling communication and integration between different systems, such as microservices. Example: Metrics API, Import API
  There is an explicit many-to-many relationship between the logical interface and API subtypes. Multiple APIs can be related to one business interface. LeanIX recommends to:
  • Either do a business data flow using logical interface subtype, then you connect Application and Interfaces.
  • Or, do a technical data flow using the API Fact Sheet subtype and then connect microservices and APIs.

📘

Please refer to Create Fact Sheet Subtype documentation page for a step-by-step guide to create the Fact Sheet subtype.

Guidelines and Best Practices

• Interfaces should have one provider Application and multiple consumer Applications.
• Understand why you want to capture the interface. Interfaces can help you identify risks by providing a clear view of the data flow between Applications or IT Components.
• Focus on the business perspective. Identify and document the Data Objects exchanged and the relationships between Applications to understand the impact on the organization's operations.
• 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)
• Clear and Concise Specification: When defining an Interface, ensure the specifications are clear, concise, and well-documented. This clarity aids in better understanding and implementation by various teams and developers.

How to model Interface

• To describe the integration between Applications, LeanIX makes use of the Interface Fact Sheet.
• The relationship between the Applications and Interfaces will be considered from a business point of view and less from a technical point of view.
• The information that is exchanged will be classified by the use of Data Objects.
• The IT Components and Interface relationship shows which technology supports which Interfaces.

This resulted in the visualization of Interfaces with Data Flow Diagram and Interface Circle Map Report with:

• Overview of the complexity of identifying Interface-clusters
• Filter by Interface attributes or relations, e.g., by a certain Data Object
• Filter by Application attributes or relation, e.g., by a certain User Group (e.g., Region)
• Diagrams allow you to include more Interfaces, change the labels or layout, or add additional elements like boxes

Using the Interface Circle Map, you can see all the Interfaces and their relationships between Applications.

How to model Middleware

Modeling middleware, for example, integration platforms such as MuleSoft and Dell Boomi, in LeanIX lets you gain the following insights:

• Ability to understand which Interfaces depend on their integration platform.
• Ability to identify which connection methods (e.g., FTP, HTTPS, etc.) are being utilized.
• Ability to specify a different connection method for the same Interface for each Application connected to the Interface (e.g., FTP for Application 1 and HTTPS for Application 2).

There are two different approaches you can choose that fit your organization best:

1. We recommend following this approach:
   • Add a "Connection Method" attribute on the relation between Application and Interface Fact Sheets.
   • Create an Interface and the necessary Application relations.
   • Model the integration platform as an IT Component attached to the Interface.
   • Specify a connection method for each Interface-Application relation.

Here you can see the data flow between the Application: AC Management and HR Admin. You can see that application AC Management and HR Admin share Data Object: Customer, using the Interface: AC Management to HR Admin via the IT Component: ESB.

2. This approach creates two Interfaces to accommodate a different connection method. You would model the Interface this way because two different applications might require two different data flows.
   • Add a "Connection Method" attribute on the Interface Fact Sheet (under the "Data & Technology / Properties" section).
   • Create, e.g., two Interfaces, one for each connection method.
   • Model the integration platform as an ITC attached to each Interface.

Similarly, here you can see that the data flow between the applications is differentiated by the Interface: AC Management to HR Admin and HR Admin to AC Management.

How to model REST API

Similarly, you can follow the recommended practice to model REST API using Interface.

Here you can see how the data flow between Microsoft Power BI and LeanIX through REST API.

Using the Interface Circle Map with the filter on the API, you can have the same view as the Interfaces for your API.

How to model an Enterprise Service Bus (ESB)

This approach helps you model the Enterprise Service Bus and the microservices. LeanIX recommends modeling this always from the business perspective. However, you can always model this in much more detail with the caveat that you need to manage more data. As you can see, the approach is similar to how we model Interface for the middleware.

Then, you can introduce more complexity and information in the modeling to have a more detailed view of the technical interface and data flow.

Antipatterns

This section addresses antipatterns involving ineffective or counterproductive ways of modeling Interfaces in LeanIX.

• Don't try to reflect the full technical complexity of the Interface, but focus on the business question that you are trying to answer. LeanIX Diagrams, etc., are built with a business perspective in mind, focusing on the logical layer rather than on a technical-physical layer.

Applicable Use Cases

• Interface Fact Sheet can help you get transparency and make it easier to understand how different applications interact with each other. Therefore, having accurate and up-to-date interface information can aid in making informed decisions about architecture changes, system upgrades, and integration strategies.

Insights from Interface Fact Sheet

• Interface Circle Map to show the integration architecture.
• Data Flow Diagram to show the data flow between Applications.
• Matrix Report showing the Interface between the Provider and the Consumer.

Further Resources

• Data Object Modeling Guidelines
• Application Modeling Guidelines