A2A Integration between internet BSPs (business service providers)

Todd Boyle 
April 7 2000  

This paper addresses the following questions:

Terms of reference:

Small and Medium-sized Enterprises (SMEs) 
Application Service Providers (ASPs)  
Business Service Providers (BSPs) 
Subscriber vs. Customer  

 Monolithic BSP
Component BSP

Example integration scenario of six BSPs



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
high Bank General Ledger 
Payments received; bank balances
high Retail and warehouse,
General Ledger
  (Accts Receivable System)
Customer charges; credit limits
medium Bank General Ledger 
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
Authentication emphasized not emphasized emphasized
Non-repudiation mechanism emphasized n/a emphasized
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, 

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.

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

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 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.)

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.

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

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
Information Week http://www.informationweek.com/search?queryText=eai
Internet Week http://www.internetwk.com/search?queryText=eai
Software Magazine http://www.softwaremag.com/archive/2000feb/EAIProducts.html

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.