Not exactly sure what you mean by a technical application ​@Prabha, but perhaps you are referring to the fact that IT Components can’t be the provider or consumer of an Interface? We’re still evolving how we model interfaces, but I’m focusing first on modelling data flows between applications using the logical interface sub-type (Application to Interface to Application), and then roughly following the How to model an ESB guidance by showing the IT Components that the applications and interfaces are implemented with. This doesn’t give you the direct relationship between the IT Components on either side of an API, but you can do that with microservices. Hope that helps!

Hello, Prabha

If the interface has no business meaning maybe you shouldn’t capture it.

See also: 

As ​@MartinNZ said, providers and consumers of Interfaces are Applications, not IT Components because LeanIX captures data flows at a logical application level, not technical level. An IT Component simply represents the technology or services necessary to realize Applications. 

So, to model an integration between a provider and consumer, you need to define both of them as Applications linked through Interfaces. These applications can then be related to the corresponding IT Components implementing them if required. You can also link the Interface directly to the IT Component supporting the integration (e.g. a middleware component, message broker, data processor or other technical component). 

Also note that you can classify your applications. The classifiers depend on your architecture content and use cases. You can use, for example, the role of an application in the value chain (primary, support), the leading capabilities supported by an application, or the processes processes/services supported by the application. This would allow to classify applications as “core business”, “support” and “technical” for example.