A2A Integration between internet BSPs (business service providers)
April 7 2000
This paper addresses the following questions:
|Terms of reference:
What is the question?
Every BSP is highly conscious of their outward message, value proposition to SMEs, and customer feedback. Most BSPs are, themselves, SMEs. SMEs find increasing benefits on both the revenue and cost side, in subscribing to BSPs on the internet.
The quality and range of services available from BSP is improving very quickly. SMEs are also becoming aware of those services very quickly. DSL has been installed. As a result, subscriptions to services are beginning to increase geometrically, and will reach hundreds of millions of subscribers industry-wide, as internet becomes the primary business backbone for billing, payment and general business.
Clearly, many SMEs will have more than one BSP. This is indisputable if you are a BSP and you believe in the value proposition of your industry and your own service. If history is any guide, the desktop computing era resulted in a very large and diverse range of software, for specialized needs. This phenomenon will be repeated. Thousands of different BSPs, large and small will find audiences for their offerings, good or bad.
Some services require integration more than others. See this simplified example integrating six BSPs which may be rather commonplace in future years.
Below is a quick display of some of the connections displayed in the example:
|Urgency||From Location||To Location||Topic|
|high||WebStoreFront||Retail and warehouse||Changes in Item counts|
|Payments received; bank balances|
|high||Retail and warehouse,
(Accts Receivable System)
|Customer charges; credit limits|
Bills that have
|medium||Retail Store||General Ledger
(Accts Receivable System)
|Customer information updates|
So the question is not whether integration is necessary. Unless the BSP find a way to achieved shared access to certain tables (Customers, Inventory items, for example) the viability of the BSP model is in doubt. Yet, the notion of monolithic services evolving to meet the entire diversity of business needs is even more dubious. So, the only question is how BSPs will integrate.
A working definition of BSP Integration might be as follows:
BSP integration is similar in some respects, to both B2B (Business-to-Business) e-commerce, and A2A (Application-to-Application) Integration. Consider some differences in the messaging requirements between these three integrations; again this is quick and subjective, and not a complete model:
|Business-to-Business (B2B) commerce||Application-to-Application (A2A) integration (EAI)||BSP Integration|
|Bid, order, buy, sell, invoice, etc. with 3rd parties usually via trading hubs such as Ariba, CommerceOne, etc.||Interconnects disparate software within the same enterprise, to maximize usability, interoperability, etc.||Interconnect disparate software on unrelated BSPs for benefit of the same subscriber enterprise.|
|Overall risk of attack / theft||medium, where payments exist||relatively low||high, where both payments and control accounts and ledgers are on BSPs|
|Access security||Needed at party level||..at user level||...at subscriber and user level, and between BSPs for those subscribers|
|Digital signatures||Sometimes needed||not emphasized||Sometimes needed|
|Transaction logging||Sometimes needed||Sometimes needed||Always needed|
|Remote invocation of business logic||Low||High||Medium|
|Store-and-forward at later times||Sometimes needed||Usually not needed||Sometimes needed|
|Routing to single destination, multiple hops||Sometimes needed||Sometimes needed||Usually not needed|
|Routing to multiple tiers or parties||Usually not needed||not emphasized||Sometimes needed|
|Transactioning and rollback of multiple steps||Usually not needed||Sometimes needed||Sometimes needed|
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.)
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
based on events coming from elsewhere, and reports with month-to-date totals before and after all data entry processes are required to help the user check the BSP's recordkeeping (yes- small businesses do check.)
This is the default method for integration in 2Q2000. Ignoring the problem is not an option, at least for the subscriber. But this is not the time for elegant or over-engineered integrations in the small business market either. Integration costs money and time, and introduces rigidities. Any automated link will require strong security. BSPs will have daily overhead costs. You will have users calling asking for their passwords and security support. Whatever you implement will, anyways, likely be ripped out 12 months from now. The experience will not even yield knowledge. It will be a dead cost.
Control Totals workarounds enable the user to review detailed reports to their hearts' content on the originating BSP, including aggregates or totals, in a way that facilitates their approving them or posting them, somehow, into the destination system manually.
For example, assume a small subscriber who purchases office supplies or maintains employee expense reports through a BSP. This subscriber might be satisfied if the BSP provides a well-designed printout of a journal entry for manual entry in their desktop GL. Another example, small subscribers who have a well-functioning WebStoreFront on a BSP who maintains inventory, might accept manually keypunching the days' inventory changes from their local Retail/POS directly into the WebStoreFront screens.
The key to subscriber acceptance of workarounds based on Control Totals is planning and testing... an attractive facility including printouts should be designed for any economic event on your BSP that needs to be keypunched into another BSP or local system. Tutorials and training should be provided to coach the subscriber how to keypunch economic events into your BSP screens
Keypunching, batching, or mailing workarounds enable the BSP to shield the subscriber from some of the uglier parts of the new internet architecture. For example, if a Webledger provider notices that they have large numbers of subscribers in common with a particular payroll service, they could announce an integration partnership with that payroll BSP. Posting the payroll transaction to a General Ledger is a nuisance that might require 15 minutes of work by each of 100 subscribers, totalling 25 hours. A trained keypuncher could probably hammer them out in 3 hours.
It may be possible for some Webledger hosts to import these batches with some very primitive ASCII or comma delimited formats directly into the subscribers' GLs, in under an hour including all necessary crosschecks and financial totals controls at the Webledger site. These are not scalable solutions but they don't consume much IT resource on the BSP or payroll provider.
The classic example of a mailing workaround is an "electronic" bill-paying service which actually consists of a massive check-printing and mailing operation in rural North Dakota or someplace. BSPs should be alert to any business partner who also accepts traditional paper forms, such as a payroll provider, taxing authority, or catalog sales vendor. In some cases, the printing route is cheaper. In particular, banks often charge less both originating and receiving funds, via paper check. Crazy, innit?
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.
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
Information Week http://www.informationweek.com/search?queryText=eai
It turns out that BSPs are not the first software domain requiring generalized integration solution across many nodes, disparate systems. A2A integration between multiple applications in large enterprises is accomplished by approximately 100 vendors in EAI (enterprise application integration) hubs, message queues, XML servers, and various other middleware.
A survey of the EAI industry is outside the scope of this whitepaper; here are some links
Intelligent Enterprise http://www.intelligenteai.com/
EAI Journal http://www.eaijournal.com/Community/index.htm
Open Applications Group (OAG) is a large consortium of mostly ERP customers and vendors who have published hundreds of XML schema and other integration standards. June 2000, many of the ERP vendors will stage interoperability demo. The middleware components to be used to exchange OAGIS XML document-based messages between dissimilar systems will include the following (ranked by frequency of usage among the demos;)
Other wellknown integration solutions:
Tools for extended business webs such as customized webledgers,
which also support XML inter-BSP integration
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.