📘

Important Information

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

Middleware

There are a number of different definitions of middleware. Most commonly, middleware is defined as a software that enables communication and management of data in distributed Applications. It can also be described as the software layer that lies between the operating system and applications on each side of a distributed computing system in a network, i.e. enterprise application integration, data integration, message-oriented middleware (MOM), object request brokers (ORBs), and enterprise service bus (ESB). Database access services such as transaction processing monitors, ODBC, and JDBC are often considered middleware as well.

How to model middleware in LeanIX

Please refer to the section Application vs. IT component if you do not have a clear understanding of the differences between both since this is essential for the following guidelines on how middleware can be modeled.

1) Modeling middleware as an Application:

Pros:

• Provides visibility on most LeanIX reports, as they are application-centric.
• Enables application rationalization modeling through Interfaces.
• Enables data flow diagrams within LeanIX.
• Enables the Business Capabilities and User Group relations view in reporting.

Cons:

• Does not allow for a clear view on IT landscape reports, unless double-modeled (see below).
• Visualizing data flow between 2 applications becomes challenging.
• Needs to be double-modeled as an IT component as well in order to enable Technology Matrix and
  Landscape reporting within LeanIX.
• Not efficient when using Fact Sheet count.

👍

Best Practice

Modelling middleware as an IT Component as shown below is the LeanIX best practice approach

2) Modelling middleware as an IT Component

Pros:

• Enables IT Landscape, Roadmapping and Matrix Reporting.
• Allows for a direct link to the Applications connected to the middleware without having to
  double-model it as an Application that provides a cleaner IT landscape.
• Enables Free Draw modeling and limited Data Flow Diagrams.
• Provides a clear view of the IT landscape and relations between Applications and IT Components.

Cons:

• Does not allow for robust Application integration architecture modeling using Data Flows.

• Limited to IT landscape reports and without a connection to the business aspect of the organization
  (Business Capabilities and User Groups).
• In the below view, we are able to see that the Applications are red and exposed to Technical Risk, but the underlying link to the ESB which is causing this is missing.

APIs

Application programming interfaces (APIs) are software intermediaries that allow two applications to talk to each other. They let your product or service communicate with other products and services without having to know how they’re implemented.

How to model APIs in LeanIX

• APIs can be modeled as an Interface, as APIs often belong to one application (Interface Provider) and communicate to other applications (Interface Consumers).
• Each API can have underlying IT Components and assigned Data Objects.
• In the following we show an exemplary structure for LeanIX APIs.

• Open APIs can also be modeled with Interfaces as shown below.

🚧

Be aware

If more detailed and intensive API modeling is needed, make sure to contact your CSM for further discussion
(e.g., modeling of APIs as endpoints with IT Components)