Using Technology to Cross Organizational Boundaries, part 3

Classic Middleware

Whereas EDI supports electronic business by automating existing processes and enabling electronic document exchange between separate organizations, a number of other systems approach electronic business by trying to create a single virtual organization. These systems use middleware, a layer of integration code and functionality that allows multiple diverse and distributed systems to be used as though they were a single system. Using these middleware tools, business applications can be built that transparently access the multiple backend systems.

Because the goal is to create a single unified view of a virtual organization, classic middleware systems typically involve tight binding between the systems and processes at the various organizations. By closely coupling the organizations, classic middleware systems are able to provide rich functionality, but require expensive initial deployments and carefully coordinated ongoing deployment management. These systems are thus most appropriate for use in a single distributed organization or across long-term and closely coordinated business partnerships.

To understand the tradeoffs implicit in a classic middleware approach and the applicability of systems using this approach, we look at three systems in detail. These systems are IBM's SanFrancisco framework, CrossWorld's Processware suite, and Extricity's Alliance suite.

IBM SanFrancisco

IBM's SanFrancisco framework is a multi-tier Java development framework for building distributed business applications. The SanFrancisco framework contains standard components that provide basic business application functionality and that integrate with backend systems. Using this framework, developers can build products, such as order management systems, that span multiple sites and organizations, integrate with the backend systems at those sites, and provide unified functionality across the diversity of sites and systems.

IBM began work on this framework after surveying its customer base and looking at their needs for distributed applications. IBM discovered that systems analysts and other business developers were having trouble building such applications, especially as they began adopting the object oriented tools and methodologies that best support distributed applications. IBM identified the three primary barriers facing these developers as:

Training requirements to begin using object oriented technology
Risks associated with moving from traditional business development environments and techniques to object oriented tools
Lack of infrastructure and the consequent need to build a lot of low-value but expensive infrastructure

To address these needs, IBM began development of the SanFrancisco project. Application developers make use of SanFrancisco by building additional components or extending components in the framework and by providing additional backend server integrations. These components and servers can then be strung together to provide a complete distributed business application. Based on the initial applications developed using SanFrancisco, IBM estimates that approximately 40% of the code in the finished application comes from the framework and the remaining 60% is custom development for the particular application. The architecture of a typical SanFrancisco application is illustrated below:

Figure 2. Architecture of typical SanFrancisco application.

SanFrancisco was initially intended for use by independent software vendors. IBM wanted to enable these vendors to more quickly produce new distributed systems. However, IBM has found that internal corporate developers are actually responsible for the majority of downloads of the SanFrancisco software and the majority of projects under development using the software. This is not surprising, as we can see when we look at the tradeoffs made in SanFrancisco relative to the electronic business issues we have identified.

First, SanFrancisco assumes a tight coupling model. This applies both to the integrations with backend systems and to the client applications. Backend systems and Clients integrate with the distributed framework using the APIs and object models exposed by the Business Process, Core Business Object, and Foundation levels of the architecture. While Clients are insulated from the APIs of the backend systems, they are tightly bound to the SanFrancisco APIs.

This design choice has two implications. First, by using object binding as the interaction technique as opposed to document exchange as used in EDI, SanFrancisco applications must be adopted at once by all participants in the cross-organization relationship. And upgrades to backend systems, the SanFrancisco framework, and the business application must be coordinated across all participants.

Second, because of the tight binding, security issues are a major factor. Objects running in the SanFrancisco application at one company must be able to communicate directly with objects running in the SanFrancisco application at a partner company. For good reason, IT staff are reluctant to allow object access across corporate firewalls. This poses a significant barrier to adoption in cross-organization environments.

Next, the SanFrancisco framework does not provide a complete solution, but instead serves as the starting point for developers to build applications. By building on the framework, developers can more quickly complete applications and leverage the code in the framework that takes care of many of the mechanical details needed for a successful distributed application. This is ideal for corporate developers who are already accustomed to doing significant custom programming.

Together, these choices make the SanFrancisco framework most appropriate for deployment inside a single company that needs to link multiple distributed divisions or sites. Such a company can plan for a unified deployment and can afford the integration and customization work. And a single company can deal with the security and firewall issues internally without opening potential security hazards to the outside world. Indeed, as we noted above, the majority of SanFrancisco deployments are taking place inside single enterprises.

CrossWorlds

CrossWorlds Software Inc. produces a set of products it describes as Processware. The Processware line shares many design choices with the SanFrancisco project, but, rather than being a framework, provides a completed applications addressing distributed enterprise business application needs. CrossWorlds began its efforts after observing that many enterprises have multiple ERP, front office, and other enterprise computing systems, and need to provide additional applications on top of those systems. The legacy systems were brought in to solve single departmental needs or were obtained as the result of corporate acquisitions. However, no single system meets all the needs of the enterprise, and new enterprise applications need access to the data stored in multiple systems.

To address these requirements, CrossWorlds built a distributed middleware framework spanning multiple backend systems and a set of applications running on top of that framework. The applications were built by analyzing common business needs and then finding ways to meet those needs regardless of the actual installed backend systems. This allows organizations to deploy CrossWorlds on top of their existing systems and begin using the CrossWorlds applications. The backend systems can then be updated or replaced without perturbing the CrossWorlds enterprise applications.

The CrossWorlds system has four main components:

CrossWorlds InterChange^tm Server: a distributed server that provides the execution environment for the other components
CrossWorlds Collaborations: components that support the specific functionality of CrossWorlds applications. These components sit above the actual backend systems and do their job irrespective of those systems.
CrossWorlds Connectors: components that connect to specific systems and enable access to those systems from the Collaboration components. Specific supported systems include ERP systems such as Baan, JD Edwards, Oracle, PeopleSoft, and SAP and Front Office systems such as Scopus, Siebel, and Vantive.
CrossWorlds Designer: an extension environment that allows customers to create new Connectors in order to access legacy or custom backend systems and to customize and extend Collaborations to provide customer-specific support.

As can be seen from this description, CrossWorlds is fundamentally intended to meet the needs of a single distributed enterprise. It shares many characteristics with IBM's SanFrancisco that limit its applicability cross-organization, including the tight-binding model, the consequent deployment and security issues, and the need to do per-relationship customization.

Extricity

Extricity Software, formerly CrossRoute Software, produces Alliance, a suite of products aimed at business-to-business process integration. Similar to the other middleware systems we've discussed, Alliance provides a distributed framework that can access multiple enterprise systems and supports unified and transparent access to those systems. However, unlike CrossWorlds or SanFrancisco, which focus on data integration between systems, Alliance focuses on process integration between distributed business partners. Alliance is thus designed from the start to support cross-organization deployments.

A set of business partners begins implementing Alliance by determining the processes that they will engage in together. The partners use the Alliance process implementation environment to model their common processes. Each partner then uses additional Alliance tools to model its private processes as they support the shared processes. Separating the definition of shared and private processes allows partners to update their private processes independently. Coordination is only needed when changing the shared portion of a cross-organization process.

At the same time as the cross-organization processes are defined, partners model the data they exchange during those processes. Alliance uses a document exchange model, which decreases coupling of the partner information systems. The documents exchanged are defined starting from templates provided with Alliance and using information modeling tools included with Alliance. This customization is analogous to the implementation conventions required to implement EDI solutions.

Finally, Alliance provides tools for integrating to a variety of backend systems, including the standard ERP systems. As part of developing the shared processes and the exchanged documents, an implementor maps the shared processes and documents onto the backend systems.

Because Alliance uses document exchange between organizations, it avoids many of the security issues that limit the applicability of SanFrancisco and CrossWorlds in cross-organization deployments. However, other design choices in Alliance increase deployment costs and make it most appropriate for long-term, stable, and closely coupled business relationships. For example, because cross-organization business processes must be modeled across all the participating partners and then implemented in concert, partners must coordinate their deployments. And during deployment, significant customization and integration work is required so the system can interoperate with each of the partners' enterprise systems. This means that each new relationship takes significant work to support.

Alliance is thus most applicable to virtual enterprises: groups of business partnerships that while independent, function essentially as long term parts of a larger virtual enterprise. These virtual enterprises can afford the deployment cost of an Alliance solution and can look for returns over long periods of time.



Previous: Cross Organization Electronic Business System Approaches		Next: Approaches: XML Middleware