This section of the paper reviews eBusiness fundamentals – the “nuts and bolts” of what is required in electronic exchange of information.
The importance of processes cannot be overstated. The most basic perspective of a process is that it’s doing stuff and a company must do stuff to make money. Furthermore, process is critical to effectively implementing eBusiness systems. So often implementers want to jump right to the message (e.g., purchase order, invoice) without fully understanding individually, within a company, and among a set of trading partners what the process is in which a message sent. Messages are not exchanged in a vacuum. Messages are always exchanged in the context of a process. They’re sent in support of doing stuff.
There are two ways of thinking about processes: activity flows, and states and transitions. Activity flows are simply an ordered set of activities (or actions). The process starts. “A” happens. Then “B” happens. Then “C” happens. Then the process is complete. Flow charts are likely a familiar way of expressing activity flows. A key characteristic of flow charts is conditional flow. If condition “X”, then “D” happens; otherwise “E” happens.
A states and transitions view of a process considers the process as always being in a particular state. Events occurs that change the process state. While thinking of entire processes in terms of states and transitions is not common, it’s quite common to think of specific points of a process in those terms. What’s the status of ...? Processes as states and transitions can be expressed in diagrams and prose. We’ll examine these approaches in the next section: eBusiness Standards, Guidelines, and Implementation Technologies.
Messages, or documents, are frequently the most identifiable aspect of eBusiness. It’s natural to converse in terms of purchase orders, inventory reports, and invoices.
Message Name: The name of a message is important in that it is the term used in conversation among people within a company and between companies and their trading partners. When processes are documented, message names anchor the message in the context of the processes in which they occur. Often message names are bipartite (e.g., OrderCreate) with one part referring to an object (e.g., Order) and another part referring to an action (e.g., Create). More on this in section on standards.
Message structure refers to how message data is organized and possibly tagged. Often messages have a header with information that generally occurs just once, and a body with repeating information. Some message syntaxes (notably XML) include tags that identify the data that follows. Some messages include envelope information. eBusiness standards experts are divided in their opinions on what envelope-related data should be specified at a message level versus at a transport and routing level. We’ll touch on enveloping in the Message Transport & Routing section, and address it in more detail in the eBusiness Standards, Guidelines, and Implementation Technologies section.
Identifiers identify stuff. That’s obvious. But let’s break that down a bit. A reason that something is identified with an identifier is because it would be tedious to communicate all the data required to otherwise identify the referent. That means that identifiers must be unique within a given scope, that the scope is clearly understood by all systems that process the data, and that the authority for identifier creation and assignment is clear.
While people intuitively understand that an identifier refers to a single thing, many people don’t appreciate that a thing must have a single identifier, or alternatively have a way to indicate that two or more identifiers refer to the same thing. (A common pattern for addressing this is by declaring a master identifier to which other identifiers are related.)
As a general rule, the characters in an identifier should not have semantics beyond the identity of the referent. For example, using a person’s mobile phone number as their identifier, while seemingly convenient, can lead to negative consequences. Phone numbers change. The consequences are that a process must be put in place to change the person’s identifier (leaving a disconnect to historical data) or leaving the identifier unchanged resulting in broken processes that depend upon an employee being able to call a person using their identifier.
A consequence of a clear identifier scheme, and authoritative identifier creation and assignment process is that two things can unequivocally be determined to be the same or, equally important, different from one another. This concept is critical within an enterprise and within a trading-partner community.
Message transport and routing addresses the part of the eBusiness process whereby messages are delivered from one system to another. For simple eBusiness implementations, this could be a directory accessible to both the sender and the receiver through FTP. More robust systems require standards-based solutions, which are discussed in the eBusiness Standards, Guidelines, and Implementation Technologies section.
Envelopes: Message envelopes are sometime regarded as part of a message itself and sometimes regarded as part of the message transport and routing layer. Message envelopes may provide such information as:
The term envelope stems from use describing message contents as being wrapped by or inserted in an envelope. One might also hear the term message metadata or message header although with the latter one must be careful to distinguish between transport and routing header data and message contents header (i.e., the header in the common header/detail message structure pattern).
Basic principles of security include:
Circumstances dictate which combination of the five security components are required, and how they are to be implemented.
Data ownership and privacy: The term data privacy is often used in the context of one party providing data to another party for a narrowly specified purpose. For example, one party may deliver data to another party for the purposes of transforming the data into an industry format and passing it on to a final recipient. Another example would be a pool of data owners providing data to a service provider for the purposes of receiving benchmarking reports.
In many cases, many kinds of data are owned by the sender; what intermediaries and final recipients may do with that data must be explicitly permitted by the data owner through written agreement. It is beyond the scope of this paper to break down types of data (in a privacy/ownership context) and the nature of agreements between data owners and other parties. These are first and foremost legal and business-relationship matters. Technology plays a role in enabling secure data flows.
The steps in the message creation process are straightforward:
While processes among trading partners are usually documented at a bird’s-eye view of the interactions between firewalls, such documentation should provide useful references to which internal message-creation triggers can point. For example, low-inventory order triggers are critical to clearly understand within your own business, including understanding how such an internal process integrates with the order-to-cash process as shared between you and your trading partner. While discussing the internal triggers and activities with a trading partner may help round out a conversation, such things are usually irrelevant to the day-to-day eBusiness operations.
The process and ease of creating/retrieving data varies widely across companies and across business processes within companies. In some circumstances the data may be entirely contained within the system producing the message and conveniently available. In other circumstances the data may be strewn across several systems and geographies. For some companies it’s not a big deal. For other companies it’s a major ordeal.
Formatting data in a format agreeable to your trading partner of course implies that such an agreement is in place. More on this topic in the eBusiness Standards, Guidelines, and Implementation Technologies section. Once data has been created/retrieved, formatting the data in the agreed-upon format depends on a number of factors:
Usually delivering messages to business messaging servers is straightforward. However challenges can arise due to real or perceived process incompatibilities among trading partners and/or industry segments. For example, trading partner X might demand that the technical details of a process must be implemented in a way that’s incompatible with what trading partner Y requires.
Finally, systems must respond appropriately to business acknowledgments. For example, an order was accepted, an order was rejected and for what reason. Given that such acknowledgements are messages themselves, it might seem out of place to mention them here rather than in the Message Consumption section, but it’s important to understand that creating and “putting a message on the wire” is not the end of the story for the message.
Message consumption is the process of receiving a file and processing it. Steps include:
As with message creation, the level of effort to ingest message content varies widely across companies and across business processes within companies.
< Back to White Paper Home Chapter 1 Chapter 2 Chapter 3 Chapter 4