In the world of automation, the ambiguous can be a beautiful thing or it can be a nightmare. To those responsible for delivering a solution, ambiguity leads to missed expectations, higher costs for delivery, and delays in completion. To those providing solutions, ambiguity leads to opportunity.

One of the most overused and ambiguous words in the IT industry today is transaction. Over the years, the transaction has come to mean so many different things depending on whether you have a business perspective or a technology perspective. Recently, however, the business and technology perspectives have begun to coincide at management levels. This makes the goal of communicating the vision and goal of a project even more difficult and complex than previously.

Let's look at some of the different uses of the word in the enterprise world and isolate a few distinctions in its meaning that we'll be able to use downstream to ensure clear delivery of intent.

Exchange Transaction
From a purely business perspective any exchange of goods or merchandise constitutes a transaction. If you purchase a new pair of shoes from the store, the purchase itself is a transaction. If you purchase the shoes with a credit card, there are actually two transactions (although they look like one): the exchange of money for shoes between the customer and store and the financial reimbursement to the store from the credit card company.

Database Transaction
ACID is the acronym for atomic, consistent, isolated, and durable. Atomic means that the transaction is unitized and encompassing. Consistent means that the data from the transaction is kept valid, by either completing successfully or terminating and returning the data to its original state. Isolated means that the data from the transaction is protected from corruption by any other transaction. Durable means that once the transaction has executed, it is permanently recorded.

This definition tends to be most closely associated with the properties of transaction management with regard to database management. However, I think that ACID captures the intent of any transaction, whether it occurs in the database or over the Web.

Compensating Transaction
Compensating transactions effectively undo transactions that have already occurred. For example, when a customer returns merchandise to a store, the store has to return the merchandise to stock (or to the manufacturer or distributor) and return money that was already booked. The interesting thing about such transactions is that they often need to be coupled with the original transaction in order to gain insight into transaction patterns.

Transactional Messaging
As data moves from one location to another, we often use the word transaction to characterize that it does so in a guaranteed manner. Transactional messaging leverages the principles of ACID to ensure that a message is delivered to its intended recipient or that a proper level of exception is created so alternative processing can occur. Transactional messaging also ensures that a message is delivered once and only once, which is critical for proper message handling. It would be problematic if two messages to remove $1,000 from your bank account resulted from the same, single ATM operation.

Transaction Processing Monitor
The TPM is actually a poorly named piece of software that has responsibility for ensuring that processes are scalable and running. Most often TPMs will watch for a process to fail and then restart that process. TPMs do use the concepts of ACID-ity to manage the processes, which is why the word transaction is associated with them.

As you can see from the above definitions, it's possible to classify transactions for purposes of setting proper expectations. If you're developing system requirements and want to represent that the transaction is initiated by the user purchasing merchandise in the store, it would be best to call it an exchange. Likewise, if you want to represent the credit portion of that transaction, you might identify that as an ACID or transactional message, depending on whether it's with the store's back office or directly with the credit card company.

Clarifications like this may seem rudimentary and overly basic, but between those gathering requirements and those implementing the solution I've seen confusion mount quickly because the terms weren't defined explicitly.

In one very poorly defined situation, the system requirements described what amounted to an exchange transaction, which led the implementers to believe they could build their system against the executed transactions in the database. One month before expected completion of the project, the misunderstanding surfaced and the team realized they were a good two months away from completion because they hadn't built the mechanism to record the transaction in the database the point of sale.