Modelling System Integration Middleware

[BenAvdicevic]

Hello HOPEX community,

Curious on best practices to model system integration middleware.   For example, 

• Message middleware (MQ queue)
• File transfer middleware (ie. TIBCO Mailbox)
• Events middleware (i.e. Kafka topic)

In an Scenario of Application Environment flows diagram- If you want to show that Application A  sends data to Application B   (e.g. batch file transfer via MFT) - do you need to show the TIBCO application "in the middle" A and B ?

Same for event architecture, where application A publishes a topic and application B subscribes to the topic.   In an Application Environment diagrams (structure or scenario of flows)  - do you need to model the middle layer (Enterprise Events platform) as being "in between" the two applications?

Another approach is to consider middleware as internal components of the Applications.  For example,

• TIBCO mailbox can simply be modeled as an Application "interface" , and therefore can be modeled as IT Service of Application A
• Kafka topic can also be modeled as an "interface" of the application A and modeled as IT service.   

Curious how others have addressed this in HOPEX?

See this as an example of from LeanIX modeling tool:

https://docs-eam.leanix.net/docs/modeling-middleware-and-apis

[covterence]

Conceptually the components didn't really change. In today's architecture when most things are exposed through microservices there is typically an anti-corruption layer that is basically the Translator that can be implemented as a component within the application or as an independent service. What would be helpful is that Hopex can link the Translator to an application/component or microservices, not just some text description as separate objects.

[PBessodes]

Yes, this feature will stay. It may be improved as we plan to work on communication layer in the future (link between communication service and application/microservice/IT Service, platform concept ...). 

[BenAvdicevic]

@PBessodes Another thought on this.

I think it would be helpful to have a blog or forum post on this topic.   Similar to LeanIX post.   Give us some concreate examples using HOPEX, so its easier to understand the pros and cons of the approaches.

[BenAvdicevic]

@covterence   Same here.   The notation is new to me too and there is a bit of a learning curve.

It's based on work:  https://www.enterpriseintegrationpatterns.com/patterns/messaging/FileTransferIntegration.html

Not sure how current this thinking is in industry.  Is this notation still "relevant".   Are other orgs using it?   We'll take a cautions approach on adopting that.

[BenAvdicevic]

@PBessodes Can I take your comment that the Communication Systems function as well as the Enterprise Integration Pattern notation will reman in the product roadmap?

We were not sure if we should promote usage of this feature - as it was not covered in ITA V5 module training.  In other words - we weren't sure how future proof it was.

[PBessodes · Accepted solution]

Hello,

Hopex principle  is to separate functional view from technical fulfillment. This is why Scenarios of Flows shows only data transfer (a content from a source is sent to a target). The technical view implies to identify and/or describe the flow/content with a Software Communication Chain (that can be modelled, but it is not mandatory).

A Software Communication Chain is under the responsibility of a Communication System ("TIBCO production" for example) and specifies the way a data is transported (a Content that can be generic or specific). If user wants to go further and describes steps of the communication chain, he can model it with a diagram using the Enterprise Integration Pattern notation (Enterprise Integration Patterns ).

[covterence]

Anyone follows the suggestion from Hopex: https://doc.mega.com/hopex-v5-en/HITA/HOPEX_ArchiDiag.Using_communication_systems.html. Was trying this at one point but gave up as it felt overwhelming at the beginning. Might give it another go and see if this is better than the separate application that I mentioned earlier.

[covterence]

I'm very new to Hopex. Going through the exact same thing currently. Not finalized but leaning towards having the middleware as a separate application because of the following:

• Other than the middleware infrastructure, there are code and dependencies that translate the payload or respond to an event. That in itself is an application that has its own life cycle. Although Hopex allows us to have components within components. Having too deep a hierarchy seems to be asking for trouble.
• Operationally we plan on linking Hopex Applications to ServiceNow. It is easier for us to track, assign costs and ownerships if the integration is a separate application object.

Curious to see what others do and the rationale. We're not set on anything yet. There are just too many ways to model something in Hopex and we're still trying to figure it out.