Conducting Business on the Internet:
Using Technology to Cross Organizational Boundaries

Executive Summary

Over the last several years, a variety of approaches have emerged for supporting electronic business activities across multiple organizations. Electronic Data Interchange, or EDI, was the first approach to be widely adopted. The Internet is now making possible a proliferating variety of business relationships and systems to support those relationships.

Business partnerships take many forms: multiple divisions within a single company, tightly integrated long-term partners functioning essentially as a larger virtual organization, loosely coupled trading communities. Systems and techniques that work well for support of activities internal to one organization don't apply across this entire range of cross-organization relationships. Instead, different systems and techniques are appropriate at various points in this continuum. In this white paper, we examine four different approaches to supporting cross-organization electronic business and six different systems and technologies utilizing those approaches, and analyze the applicability of each approach to the various types of relationships along the continuum.

Creating a system to support cross-organization relationships involves a variety of technical challenges. These include integration of heterogeneous systems, data representations, and processes; security and authorization issues as systems cross corporate firewalls; scalability issues; costs for setting up new relationships and doing the necessary customization and extension to support each new partnership; and the ability of systems to support ongoing evolution and change in business models.

Each of the four approaches makes a different set of tradeoffs in addressing these challenges, and thus each approach is suited for different kinds of cross-organization relationships.

Briefly the four approaches and their ideal points of applicability are:

EDI. A set of standard protocols and methodologies for business document interchange. Supported by a number of vendors. Best suited for loosely coupled organizations with long term relationships.
Classic Middleware. Products and technologies for building distributed business applications and integrating multiple enterprise computing systems. Best suited for enterprise applications within a single organization or across tightly coupled organizations with long term relationships. The classic middleware systems we examine are:

IBM SanFrancisco framework. A multi-tier Java framework for distributed business applications. Best suited for enterprise applications within a single distributed organization.
CrossWorlds Processware. A suite of products that integrates enterprise computing systems. Best suited for enterprise applications within a single distributed organization.
Extricity Alliance. A suite of products that automates cross-organization processes. Best suited for tightly coupled organizations with long term relationships.

XML Middleware. Uses interchange of XML documents over the Internet to integrate enterprise systems. Best suited for loosely coupled organizations with long term relationships. An example of this approach is webMethods B2B Integration Server and WIDL tools.
CBL. An XML framework developed by Veo Systems for describing an organization and its offer and for automating business interactions between organizations. Best suited for loosely coupled organizations. Supports dynamic and transient relationships as well as long term relationships. Also ideal as a platform for building other electronic business protocols.

Supporting Cross-Organization Business Relationships

As businesses have seen the benefits of applying information technology in their core business processes, it has become only natural to apply it to relationships between business. A variety of different techniques, technologies, and systems have been developed to support the kinds of transactions and relationships that take place between organizations. Making the choice of approach to electronic business can have a profound impact on a company -- comparable to the choice of enterprise software such as Enterprise Resource Planning (ERP) systems. It's thus very important to understand the consequences of these choices.

The original goals for cross-organization electronic business systems were to support distributed communication and to increase the efficiency of existing cross-organization activities while decreasing the cost of those activities. As companies introduced electronic business systems, they started to see new possibilities enabled by those systems. By more closely coordinating the work of suppliers and manufacturers, businesses see dramatic productivity and efficiency increases in manufacturing processes. As communication barriers and costs drop, businesses are able to engage in many more kinds of relationships. These new relationships open additional possibilities for distribution and supply partners, for participation in virtual trading communities, and for extending classic value chains to value networks.

When we look into these different possible business relationships, we discover that they are not all the same. Instead, they can be classified along several dimensions. Depending on where a particular relationship falls on these dimensions, some electronic business approaches are better suited than others for supporting the relationship. Some examples of business relationship patterns include classic value chains, value networks, and trading communities.

Classic value chains are characterized by a central dominant organization that controls product design, production and delivery, and works with a variety of business partners that make up the central organization's supply chain and distribution chain. Tight integration between the controlling organization and its partners in order to optimize process efficiency is a paramount goal. Partners tend to work exclusively with one central company. Partners and the central organization form long-term relationships and focus on investment returns over the lifetime of that relationship.

Value networks are similar to value chains, except that there is no central dominant organization and each member of the network may work with many other companies. High tech manufacturing today exemplifies value networks. Organizations such as semiconductor fabs and board assembly houses focus on one activity in a complete value chain and then partner with multiple other organizations in order to play a role in multiple value chains. Specialization of work and the ability to coordinate with value network partners are the paramount goals. A secondary focus may be on optimization of cross-organization processes, or it may be on cost reduction for each individual transaction. Partners form long term relationships and gain investment returns over the lifetimes of those relationships.

Trading communities bring together a variety of vendors and potential buyers. The community may be organized around a common product or service offered by the vendors, around a common interest among the buyers, or around bringing together vendors who address portions of a business problem. Trading communities often feature a "market maker" organization that creates the virtual space for the community and does the work to bring buyers and vendors together. The primary focus in trading communities is on efficiency of transactions and maximization of value per cost of each vendor's offer. Organizations may participate in the community only briefly or they may be long term members. Relationships between buyers and vendors tend to be short term. Thus investment returns must be gained over single transactions as well as over the time span of community participation.

Examining these examples, we see the important dimensions that characterize different types of business relationship:

Lifetime of the relationship. Trading communities feature short lifetimes, while value chains and networks feature longer relationship lifetimes. This dimension also determines the timespan over which investment returns must be achieved.
Degree of integration between partners. Tightly coupled value chains that function essentially as a single virtual organization exhibit high process integration between partners. Loosely coupled trading communities are at the far end of the spectrum and show very low integration between partners.
Focus on process efficiency vs. focus on per-transaction efficiency and value. As we saw above, partners that work as part of a larger virtual organization focus on achieving overall process efficiency. Partners that work on a per-transaction basis need to focus on achieving efficiency and value within the individual transactions.

Regardless of the type of business relationship a cross-organization electronic business system is intended to support, implementing the system isn't necessarily easy or successful. As a company implements such a system, it sees changes to existing processes and structures as well as changes in its relationships with partners. In addition, there are a number of serious challenges that companies must face to achieve success with these systems.

Any cross-organization electronic business system must:

Scale to the required volume of transactions and the number of relationships in the trading network
Integrate heterogeneous systems, data representations, and processes
Accomplish transactions with appropriate security and authorization
Evolve over time to support emerging business requirements.

Each electronic business approach makes specific tradeoffs with respect to the challenges and is thus appropriate in different circumstances. When making technology and system choices, it's very important to understand these tradeoffs and choose the most appropriate system. We discuss the challenges below and then look at a variety of different systems to illustrate how the system tradeoffs play out.

Scalability

When considering scalability, people often focus on ensuring that a system can support large volumes of data and transactions. This is important: companies need to ensure that any system they introduce will be able to handle the full quantities of data and transactions that the system will ultimately face. In large distributed organizations and when working with tightly coupled partners, these requirements can be intense. All the approaches we examine here address large scale performance issues and, with appropriate deployment choices, are able to handle enterprise and cross-enterprise performance needs.

However, scalability is equally important at the low end. Initial deployment cost and effort and the cost to support new business relationships can limit the applicability of electronic business systems. Ideally, a system can be deployed initially in a small scale environment and proven there. Then over time, the size and range of the deployment can seamlessly be increased.

In addition, some emerging Internet business opportunities require that entering into a new business relationship be inexpensive and fast. These opportunities include virtual trading communities where a variety of vendors and buyers come together around a common interest, virtual buying groups where a group of buyers band together and solicit bids from vendors to meet the collective needs of the buying group, and other more transient and dynamic relationships. To support these opportunities, a system must necessarily provide payback over a short timeframe, possibly just a handful of transactions, rather than requiring long term relationships to see returns.

As we examine the various approaches, we will see wide variation in their scalability at the small end. In some situations, this will not be important. Partners in a large virtual organization, such as high tech manufacturing partners, can count on large volumes and long timeframes. These partners can also tightly coordinate their activities and system evolution. Scalability at the small end is not of great concern to these organizations. However, other organizations, especially those hoping to capitalize on emerging dynamic Internet business opportunities need to be concerned with small-end scalability.

Finally, it is important to realize that scalability applies over many dimensions. You need to assess your situation and understand what parameters you will need to vary and then assess the performance of each system across the possible values of those parameters. For electronic business systems, at least three scaling measures need to be considered:

Data and Transaction Quantities. What volume of business data and transactions can the system handle? Will it be able to support the interactions you undertake between divisions and between yourself and your partners?
Relationships. How many business relationships can the system support? Is it hard to set up a new business relationship? Is work required from both partners every time a new relationship is entered into? Can the work you do to support one partner be reused as you establish new partnerships?
Tightness of relationship coupling. What types of business relationships does the system support? Can it support tightly coupled relationships where many business activities are closely coordinated between the partners as well as more distant arms-length relationships? Can partnerships evolve from loosely coupled to closely coordinated?

Heterogeneous Systems, Data Representations, and Processes

One of the main challenges faced by enterprise computing systems has been the diversity of information systems in use at an organization. This problem only gets worse when multiple organizations are involved. Any cross-organization electronic business system is faced with integrating with the complete range of enterprise systems, data representations, and processes in use at the various partner organizations.

All of the approaches we consider introduce a common layer that spans the participating organizations. In some cases, this layer is made up of middleware: software that runs on top of all the various enterprise systems and provides common data representations and access to those systems. In other cases, the layer consists of a common set of messages or documents describing the interactions that make up the cross-organization processes.

In either case, this common layer must be integrated with the enterprise systems in place at each organization. These systems include ERP systems, accounting systems, purchasing systems, shipping management systems, and manufacturing information systems. The integration involves coupling the electronic business system to the enterprise systems so that, for example, purchase orders received via the electronic business system can be entered into the manufacturing planning system.

Because the common layer spans multiple organizations, it is important to build the common layer on open, non-proprietary standards. In certain relationships, a set of partners may be able to standardize on a single proprietary technology. However, in many more relationships, the partners must be prepared to support a diversity of vendors and implementations.

At the same time, disparate data representations between the systems must be dealt with. For example, it is likely that two business partners will have different database records to describe the same products. Not only are the part numbers likely to differ between the partners, but the data stored and the structure of the part records are likely to be different. Integration will require mapping these disparate representations onto the common layer's representations. In this process, it is very likely that the common layer's data representations will be extended and customized. Depending on the degree of customization, this work can add significantly to the cost of setting up a new relationship.

Finally, supporting cross-organization processes will require changes to existing internal business processes. For example, approval and review cycles may differ between organizations and these may need to be adjusted to implement the electronic business system. Ideally, an electronic business system can be introduced without forcing big changes to current practices, and then over time, these practices can evolve to take advantage of the system capabilities and realize productivity and efficiency gains. Systems that require tight coupling between organizations will increase the need to coordinate processes and the evolution of processes between the organizations. Systems that support looser couplings allow organizations to make fewer changes to their existing processes and to evolve those processes independently.

The work to integrate systems, data representations, and processes can be quite costly and time consuming. And the bulk of the work consists of getting the technical and business process mechanics in place in order to conduct business, rather than in developing competitive differentiation and advantage. When evaluating a cross-organization electronic business system, it's important to examine where the integration effort will be spent. Will the work consist of low-value mechanics or will it focus on higher-value activities? Can the work done to set up one relationship be reused in setting up additional relationships?

Security and Authorization

Any cross-organization electronic business system must address security and authorization concerns. These systems necessarily cross corporate firewalls and security systems in order to access partners' enterprise information systems.

Some systems, especially those built using a middleware approach, assume that the middleware objects can make remote calls directly to the various partner information systems. This means that corporate firewalls must be made aware of these systems and opened up to allow this access. In some cases, this is not practical. Where practical, it increases initial deployment costs as well as ongoing system maintenance costs. This is only justified when the partners will be working closely together over the long term.

Other systems work purely on the basis of document exchange. The documents encapsulate business requests and can be exchanged across corporate firewalls without security risks. Once inside the firewall, internal systems can validate and process the exchanged documents. These systems support more loosely coupled relationships and decrease deployment and maintenance costs.

Business Evolution

Over time, any business relationship will evolve. Some of this evolution comes from internal needs and changing business requirements. Some of it will be driven by the ongoing impacts of the global economy and the Internet on ways of doing business. It is important to consider how electronic business systems support this ongoing evolution.

Since cross-organization electronic business systems interoperate with enterprise systems, it is important to consider the effect of upgrading or replacing those enterprise systems on the electronic business systems. All of the electronic business systems we examine here provide a level of independence between the electronic business applications and the backend enterprise systems. But, depending on how tightly the systems are integrated with the backend systems, you will see varying impacts when those systems are changed. And remember that you need to consider the impact of system changes in both your organization and your partner organizations. Upgrading or replacing a backend system may force you to redo the system integration work done during your initial deployments.

Another source of change is the development of new Internet business opportunities and protocols. In the last two years, there have been a number of proposals for Internet business protocols. In order to take advantage of these new opportunities and protocols, you need an electronic business system that is flexible enough to support them. Alternatively, you may be faced with replacing or augmenting your system with the corresponding deployment and maintenance costs. In general, systems that focus purely on the automation of existing processes won't be able to adapt as well to evolving requirements. Instead, systems that provide a foundation of standard building blocks that are then assembled to support specific organizations and protocols will be better able to support future needs.



		Next: Cross Organization Electronic Business System Approaches