From ground to interstellar – how to expand EAI to multiple organizations? – Live Discussions

We will use this blog for live discussion, Q&A during and after the session. Inappropriate questions will be removed.

Author: Sriram Hariharan

Sriram Hariharan is the Senior Technical and Content Writer at BizTalk360. He has over 7 years of experience working as documentation specialist for different products and domains. Writing is his passion and he believes in the following quote - “As wings are for an aircraft, a technical document is for a product — be it a product document, user guide, or release notes”.

  • Kent Weare

    How do you see API Mgmt solutions participating in these types of architectures? Do they reduce the friction in on-boarding new partners to your service?

  • Hi Kent,

    Yes they do. When you are combining EAI with B2B, you will in many scenarios end up with a service where one end is custom-built (integration to your back-ends) and the other end is pretty much standardized, connecting to a number of different organizations that vary from each other only slightly – something that can be handled with parameterization.

    In these kind of cases the onboarding of external endpoints should be made as easy as possible. Possibilities include at least creating simple, customized on-boarding user interfaces for this specific solution – a bit like what BizTalk Trading Partner Management is built for. However, this can be made even simpler for specific scenarios.

    The other kind of easy on-boarding is then made with APIs. As a tangible example, we have several partners who are using our iPaaS for connecting their SaaS software with pre-defined external endpoints such as banks, trading partners etc. In these cases the integration solution itself is completely invisible to their end customers.

    When the end customer clicks on something like “connect your account to bank X”, our partner’s SaaS applications sends a couple of API calls to our system; the first one is “create a customer account A” and another is “provision integration service B to customer account A, with these parameters”. After this, our partner’s SaaS application can operate the integration service (again through API’s) in the newly created customer’s context.

    The end user does not even need to know how the integration is carried out. In my presentation I suggested that integration is becoming more and more of an utility in the future – I think this is one example of this. All it takes is a little bit of API configuration work and that’s it – provisioning of an integration solution is pretty much automated.

    Of course this doesn’t apply to all integration solutions, but there are surprisingly many cases where such standardization can be carried out.

Back to Top