All three integrations are difficult because the platforms are actually executing business transactions with unrelated 3rd parties.   BSP integration is categorically different from other integrations however, which require passing additional data structures between BSPs.  To cite a few examples, 

• the BSP has large numbers of subscribers, and must firmly identify and bind every transaction to one of its  subscribers on a legally binding basis.  

• each BSP must ensure that the subscriber the other BSP is talking about, is the same legal entity as the subscriber bound within his contract.

• contracts must exist for every category of transaction involving 3rd party BSPs where any type of execution authority is delegated to them, or reliance is placed upon their data, authentication, etc.

• None of the BSPs necessarily have any information about, or influence over, the identity or nature of the subscribers' customers or vendors or the subscribers' contracts with them, this is not about B2B commerce. 

Because the BSP industry is new, it is useful to study A2A integration methods, EAI products, EDI, etc.  However, the way things are actually done varies across numerous dimensions making most of the existing solutions irrelevant for internet BSPs.

• Level of granularity (document based, coarse XML/RPC/SOAP, or fine RPC/DCom, RMI etc.)

• Volume and scale

• proprietary vs. interoperable

• age/lifecycle of the technology (EDI, Client/Server, etc.)

• cost

• feature depth of the application itself, etc.

Research into solutions reveals many challenging issues.  These issues raise interconnected issues that require highly skilled developers, security and internal control people, network architects, web and database performance gurus, etc.  These problems and issues are sufficiently deep and interconnected to prevent any BSP from any timely self-designed solutions and even if they succeeded, there may be nobody at the other end of the connection with the same solution.

What are the primary business objectives?

BSPs' priorities depend on their cost and revenue models.  Most models are fatal without large subscriber count.  Accordingly, all planning and design activity in the operations side will be aimed at subscriber count, which in turn is driven by subscribers' perceived value proposition.  

Subscribers' perceived value is decomposed into subscribers' costs and benefits. The cost savings is the predominant element driving the BSP explosion, more than the increasing subscribers' sales.   It is absolutely essential that the subscriber reach an overall efficiency and cost savings from using BSPs.

For example, BSPs who provide electronic payments services are far more valuable to users if they are integrated with the Accounts Payable systems.  Any payment system that doesn't integrate with A/P is basically broken and correctly, is being rejected by the business community.

Users require an extensive set of tools for managing incoming bills, identifying items within invoices within statements, and clearing and matching, cash forecasting etc.  The benefits of online payments in isolation, are far less than the labor costs they would cause if not integrated with AP.  In other words, online payments without AP integration have a negative value proposition.

BSPs will attempt to maximize the overall value proposition in two ways: by building integrated, horizontal modules into their own platform or by building efficient integrations with other BSPs.  There are intense efforts going on to provide single-sign on, and integrated user experience for these independent components.

What levels of integration exist?

Print the diagram and lay it on the table.  

Pragmatic / Workaround

Batch

There will be many circumstances, perhaps more numerous than any other single category, where  periodic batch transfers of transactions from cooperating services will be the right solution. These can be transferred by any practical means and there is no reason to shun this approach in 2Q2000.  It scales very very well into large transaction volumes.  The key to this approach are management and control of financial totals and numerous types of financial risk- this is all about professional execution.  Database administrators and developers should design efficient loaders, with thorough validation.  Loading should require at least two separate stages for approvals by more than one manager, if financial amounts are material. As with the Workaround approach, the responsibility for each possible transaction type that can result from the data (in either direction) should be explicitly defined by contract, and legally reviewed. Payments grade security and bank-quality legal structures should apply: you must assume that numerous actors will make determined efforts to break into these systems. 

Exporting the problem by selection of partners

This is by far the preferred method for any BSP, wherever it can be achieved.  Place yourself in the shoes of any of the six BSPs, and imagine scenarios where the other five BSPs or 3rd parties handle your integration.  If you're a web store, find a G/L provider who is deeply integrated with inventory. That's one less integration for you.  If you're a Payroll provider find a Bank who is integrated with the G/L provider.  If you're a G/L provider find a Payroll provider who is deeply integrated with a bank and an HR and benefits provider, etc.  If you're a marketplace, integrate with a payments provider who provides integration paths for its customers.

Exporting the problem by drawing upon partners' designs

Every BSP in the marketplace will be at a different stage in understanding and implementing integration links.  Furthermore, for the time being, integration solutions will be diverse, and often, incompatible.  When two BSPs begin a dialog about integration, often, the decision will be that one partner selects the the message transport mechanism, XML formats, and associated processing requirements.  Consider selecting integration partners with an integration solution that works painlessly for them, and who have the experience and resources to wire it into your server.

Shared data repositories

Some small numbers of BSPs are appearing on internet as dedicated reference databases serving multiple clients for Customer or "parties" lists, catalogs or "items" lists, and even transaction archives or histories.  These can make a lot of sense for some situations where multiple clients need high performance read/write services but it is not economic for any one host to provide them.  This may arise in SCM, trading communities, or other circumstances of unrelated party sharing.

Maintaining data in shared repositories instead of multiple redundant tables on each trading partner's systems is the key element in eliminating reconciliation differences and achieving automatically reconciled books against all external AR, AP and Banks.  But it is like the cure for cancer, i.e. a long way off.

Supply Chain

Due to the intensity of integration efforts in the manufacturing and distribution industries, it is highly likely to spill over and influence the basic infrastructure under the SME's dashboard provided by BSPs.  

Everything physical (inventory, materials, suppies, equipment, etc.) that needs to be bought by a Subscriber (or their customer) will come from a source.  Every source has a supply chain behind it.

Older, paper based, relationship based, traditional supply chains are systematically higher cost, and systematically less automated, and less accessible to a BSP electronically.  Thus they are irrelevant.

Newer supply chains are undergoing rapid, disruptive changes involving all kinds of complicated message passing, demand signals, contractual changes, new vertical portals, markets like Ariba and CommerceOne, etc.   What is crucial for the atomic BSP is knowledge of how to participate in these marketplaces effectively on behalf of their Subscribers, and their Customers.  Thus the BSP becomes a consultant and portal if they can ever figure out how to participate in supply chains as consumers. This should be easy.  We are customers. They will explain their interfaces to us.

Now, everything Subscribers of a BSP will want to sell, generally will be sold by the channels chosen by Subscribers.  The webledger provider needs only to measure subscriber feedback and implement the most-requested channel integrations, in an orderly, sequential process.  It is not an open-ended problem like supply chain.

MOM and middleware

Conclusion

There is no immediate, standard, or low cost solution for integration between BSPs at this time. The only prospect on the horizon will require some type of XML vocabulary, and secure transport as a minimum. 

The ebXML website is a good roadmap into many of these issues, and lengthy presentation of possible future solutions, but appears to be about a year from completion.

BSPs should study closely the solutions of OAG, smbXML, and other schemas that are "here today".  If those solutions are not usable, individual BSPs should communicate loud and clear to those organizations for the necessary improvements.  If those organizations will not support your work processes, then BSPs should develop their own XML schemas in loose association with their integration partners.

If neither standards bodies nor collaborations with integration partners can be created to undertake a new XML  integration standard, individual BSPs should build their own document level XML interfaces and publish them  unilaterally.