Integration Challenges in B2B Commerce

Integration Challenges in B2B Commerce

Integration Challenges in B2B Commerce

In class exercise

E-commerce, i-commerce, B2B - these are among the new buzzwords we use to describe transactions that occur electronically. No matter what it's called, we all agree that the number and complexity of e-commerce applications is increasing exponentially. Nearly every industry trade magazine contains an article about the explosion in the number of companies, transactions, and dollars involved in e-commerce applications.
E-commerce has several titles and meanings. This article focuses on Business-to-Business (B2B) e-commerce, which occurs when systems of two or more businesses exchange information that, directly or indirectly, results in a transaction. Typically, the exchange involves aggregating information from and/or distributing information to multiple organizations as part of a transaction. A transaction includes traditional purchases and other events such as fulfillment, bids in a real-time auction, inventory replenishment, establishing new accounts, account lookup, and account maintenance. The transactions themselves are typically real time; the aggregation and distribution of data across companies may or may not be real time, depending on the transaction requirements.
As the number and dollar value of B2B transactions increases, the technology infrastructure supporting the applications will become more complex. It's already common for an application to involve disparate systems from several business units in the same organization. Moreover, applications involving systems from more than one organization are beginning to crop up more often and will soon become the norm. Many of these applications could evolve into complex architectures that might encompass auction formats or industry trading networks.
Complex networks such as these present a difficult integration challenge for companies participating in e-business. The technologies to integrate are virtually guaranteed to be heterogeneous with a variety of software, hardware, operating systems, and programming environments. Integration might involve mainframe data in one company, a large packaged Enterprise Resource Planning (ERP) application in another, and proprietary in-house applications in a third. As the number of companies participating grows, the complexity of the integration challenges increases exponentially.
Performance
When the application requires real-time aggregation or distribution of information across dozens or hundreds of companies, performance is critical. Typical examples include shopping cart applications for a retail Website - where only items in inventory at a third-party fulfillment house are visible, and the system processes and acknowledges orders in real time. Other interesting examples might include trading networks for the utilities industry - where power is bought and sold in real time based on rapidly changing prices and availability.
In examples such as these, it's easy to see why an architecture must provide real-time performance. Even delays of only a few seconds could result in participants losing significant sums of money or damaging their brand by disappointing their customers.
Security
To further complicate the matter, B2B participants' concerns about security will continue to grow as B2B commerce requires more data sharing across companies. The systems involved in the B2B application will contain sensitive data companies don't want to share, even with partners.
The integration solution must allow for encrypted, authenticated data transfer, while protecting the data and systems that form the application foundation. Participants in a B2B commerce application shouldn't have to open their firewalls to incoming connections from other participants. Ideally, the corporate firewall should prohibit any incoming connections.
Ease of Integration
While participants in a B2B application often have shared business goals, the solution must be relatively easy for each player to implement. Architectures that demand certain platforms or programming languages, or require substantial amounts of hardware, won't be well received.
An integration solution should be based on open protocols and standards. It must be platform and language independent to let each player leverage their existing Information Technology (IT) infrastructure. Additionally, programs that are non-intrusive, with relatively small footprints, will be more attractive to participants.
Flexible Architectures
If coordinated change among all participants is necessary to deploy an application, sophisticated B2B applications would probably never get past the functional specifications phase. Integration solutions that enable B2B commerce must be loosely coupled. Tightly coupled architectures require compiling distributed components against each other, typically using Interface Definition Language (IDL). In a tightly coupled environment, if one component changes, you must update every other component in the system that uses the changed component and recompile. Otherwise, the system won't work properly.
In a loosely coupled architecture, the system can tolerate incremental change. Most loosely coupled architectures are based on an asynchronous messaging infrastructure. Participants can be added or deleted without breaking the flow of the architecture.
While not required, the use of XML further enhances the architecture. Let's assume we're exchanging information using XML documents and we add a new data element. Other components that receive the enhanced XML document, but don't know about the new data element, will continue to work properly. We can update these components later, or leave them intact if the update isn't necessary.
Case Study
To better illustrate the technology issues involved in complex integration, consider a consortium of hundreds of financial institutions. The consortium provides consolidated financial information about individuals to business users who are evaluating account applications. The business user needs to see the aggregated information in real time. This real-world integration initiative is enormously challenging. The hundreds of financial institutions involved use almost every imaginable technology, ranging from flat files on mainframes to relational databases on UNIX and Windows NT, and a wide array of languages (e.g., Visual Basic, PowerBuilder and C++). The need to aggregate information in real time makes performance a critical success factor. While all the companies are partners in the consortium, some also compete with each other. The low level of trust between competitors increases security requirements. Data encryption isn't sufficient - the consortium needs a solution that deliveres real-time performance without requiring members to open up their firewalls to end users or other members. Privacy for each transaction (such that members could not view requests to or responses from other members) is also required. With so many companies involved, coordinated change is impossible - a loosely coupled architecture is essential. Finally, the architecture has to tolerate systems that are not highly available.
Let's examine how this application actually works. When administrators need to evaluate an application, they go to the consortium's Website and enter information about the candidate and the type of account, and send it to the server. The consortium server analyzes the type of request and broadcasts a request to an appropriate subset of consortium member servers. After a configurable period of time (currently, 5 seconds), the consortium server consolidates the responses it receives and responds to the administrator.

TASK: Generate a diagram proposing a solution for the architecture described above.

This case is just one straightforward example of how even the simplest B2B commerce application can involve multiple systems, technologies, and participants. As these types of applications become more common and mission-critical, organizations will have to select solutions that let them address the inherently complex integration challenges.
Conclusion
Cross-enterprise applications will continue to grow more complex as organizations realize the business benefits of integrating directly with partners, suppliers, and customers. While this may seem a daunting task initially, available tools and technologies can ease implementation. The solution should provide the performance, security, ease of integration, and flexibility essential for successful B2B commerce. Remember, technology should be an enabler, not an obstacle, to achieving business goals.