Software Processes, Puzzles, and Pyramids

Before introducing the ebXML architecture and the associated process flow, we need to see how this architecture and process flow complement today's business systems. Of course, from a user 's perspective, we would hope that ebXML implementations would only need to provide a control panel or dashboard and hide all the internal software "wiring" underneath. However, we need to introduce important concepts to help you understand the overall architecture of ebXML.

From a software perspective, ebXML doesn't present any new and previously undiscovered system. Any of the larger companies participating in the ebXML work could have developed the functionality provided by ebXML, and in fact some tried, such as Hewlett-Packard and its "e-Speak" work (see www.hp.com/espeak). However, each of these efforts to create an overall e-business architecture represents just one company's creation of a proprietary solution to solve some immediate and specific need. What sets ebXML apart is its goal from the beginning to write a global standard designed to work across vendors ' products, and therefore provide a methodology and technology independent of any particular supplier's solutions.

To achieve this goal, ebXML based its development on commonly held software principles and a blend of emerging good business practices and design ideas. One of these basic principles is businesspeople expressing their needs, relationships, and operations in strictly business terms, and letting the technology implement from there. ebXML lets businesses capture and preserve business knowledge, but express it directly as technology, which makes it stand out among most e-business standards.

Figure 2.1 shows how business product or service interactions can be expressed in real-world business terms. Relating these terms directly to the software development process can lead to the accurate representation of those business needs in real working software. The terms we develop here are explicitly those used by ebXML itself, and we present more detailed discussions of these terms later in the chapter. We introduce the terms here to show how they relate to each other, and more specifically their use in actual business situations.

Figure 2.1. Business as a set of steps.

The numbering in the diagram represents the sequence in which this scenario unfolds, starting with step 1, where the actual product, service, or product/service combination is defined by the company providing it, and ending up at step 8. At that point, the overall process starts again, using feedback from real-world implementation, market forces, and customer demands.

From Figure 2.1, we can analyze each step, and, as ebXML has done, represent in the specifications those pieces that relate to each step. These steps then become the business processes that describe in detail each of the many pieces that go into making electronic business work. At this point, we still use generic terms and haven't yet descended too far down into the layers of systems engineering. Figure 2.2 shows how these pieces relate to a physical business product or service system model.

Figure 2.2. Business language and processes.

The bottom of the diagram shows a timeline with explicit events that happen during the process. This is not a complete set of all events, but a fragment of an overall timeline to show the processes conceptually. The boxes marked Agent represent some software component acting in a predetermined role on behalf of the company to direct and orchestrate the electronic execution of the physical business process. The pipes along the top connecting Company A and Company B represent the Internet network that controls the delivery of messages by the transport, routing, and packaging software components .

Next we can structure these pieces and group them together by purpose. In the ebXML work, this step was critical to providing the overall technical architecture. Notice that ebXML could not define architectures for every conceivable business process, but instead focused on the most common repeatable and sustainable model on which to build global electronic business. Figure 2.3 therefore shows how these items can be grouped logically, which then form the basis of the ebXML methodology.

Figure 2.3. Business language artifacts.

Next, ebXML must also provide a means to classify, associate, and manage these items through the use of a common dictionary registry. It needs as well a labeling scheme to provide a consistent global base of these terms, and can therefore ensure consistent interpretation and interoperability across geographic and industry boundaries (see our later discussion of Bizcodes, used much like bar codes for this purpose).

The use of the pyramid shows how an overall electronic business collaboration is structured and fits together. Layer 1 of the pyramid contains the pieces of data needed to deliver information electronically between businesses. Layer 2 has the control mechanisms. In Layer 3, the information itself is grouped and organized into discrete messages that relate to the overall workflow and business process steps in Layer 4. The top layer has the business contract that governs the interactions between the parties and ultimately defines how the messages are delivered.