My two-bits on the use of an intermediary for integration (none of them are wM specific). Whether the interaction is batch or not wouldn’t seem to matter, IMO.
Pros
A point where flexibility can easily be leveraged. If the exchanged data needs to go to more than one place, the intermediary can do so without impacting the end points. Basically, a place to accomodate change.
A change in one of the end points (communication, format, etc.) can be insulated from the other end point(s).
A common exit/entry point for all applications. They don’t talk to each other directly. They talk only to the intermediary. This provides a degree of decoupling for the apps, at least at the communication layer.
Can decouple the data format from each end point. The intermediary knows how to translate between them, and the end points have no idea. A COBOL program can do that too but typically it’s lumped in with the rest of the “application,” at least logically. Thus, the “application” has dozens of interfaces that the app team has to support, instead of a few. The app teams should strive to keep the number of interfaces they have to a minimum–and the ideal goal would be to have but one interface that communicates to the intermediary. The integration team handles the rest.
A location to record the exact contents of the data submitted by or transmitted to the partner. This can help with troubleshooting and may be needed for business/regulatory purposes (non-repudiation). I can’t remember if you guys ended up with TN, but it’s a good place to keep exactly what was sent, in either direction.
Auditing the interactions can be consistent and simplified.
Common error, monitoring and reporting facilities are more likely.
A well-known place where all integrations are “done.” Thus, analysis of change impact can be simplified.
Governance of solution design and implementation can be easier.
The intermediary insulates end points from outages by the other end points. In the strictest sense, using an FTP server to exchange data between 2 apps is using an intermediary–but people don’t usually think of an FTP server that way. (Plus, it doesn’t provide format decoupling.)
If the use of an intermediary is part of the integration architecture (don’t know if that’s the case in your circumstance), then it would seem that not using the intermediary would be the exception. Thus, justification to not use the intermediary would need to be compelling, rather than needing to justify the use of one. This falls in line with the notion of consistent implementation approach.
The intermediary as focal-point for integration development provides a better opportunity for code reuse. Have a service in IS that parses that intelligent account number? Use it in all 10, 100, 1000 integrations. If an intermediary isn’t used for translation, then reuse can be a bit more difficult.
Cons
For some integrations, point-to-point is just fine. The need for flexibility may not be there. The amount of code that could be reused, minimal. If the data is very specific to one app, and the processing of it needs to be atomic (all data succeeds, or none succeeds), then point-to-point is probably a better approach.
If the transformation requires lookups or sophisticated translations then it may be simpler to implement a point-to-point solution, where the end-point may have “better” access to the needed data. The intermediary may not have ready access, and thus the solution can become more administratively complex, or run-time intensive, than the benefits it brings.
Using an intermediary generally means more hardware. More administration.
For using IS specifically, knowledge of FLOW is far more scarce than COBOL or PL/I or Natural.
When using Broker, the communication mechanism is proprietary. One can now use the JMS interface but that isn’t as integrated with IS as the “normal” IS-Broker communication.
The intermediary is often a misunderstood, mysterious black box. It becomes the scapegoat of many, many issues, even when the error didn’t occur there. It’s often the victim and reporter of issues in other systems, but gets the blame because the data “didn’t get there.” This can be a huge distraction for both the integration team, the app teams and prod support.
Bottom-line: IMO, the characteristic of being batch doesn’t alone indicate the use of an intermediate or not. All of the factors above should probably be considered.