In the SOA literature, often the car example is cited to illustrate the way a software system is composed out of its parts. However, it's quite interesting to push this analogy a bit further and imagine what place process-like interactions take in this picture to illustrate their semantics.
To start with a simple question: what is a car? For the purpose of this blog, it suffices to say that a car is about a lot of parts fitting exactly together. Each of the parts has a specific function. Fulfilling its function, it may be (re-)usable in very different contexts within the car, depending on the level of abstraction. A nut may hold the tire here or the seat there in the same car, while the engine might be (re)usable in different type of cars. The better reusable the parts are, the better for the manufacturer, the better for the customer.
Now, what are cars good for? Where do cars get their purpose from? It's traffic. At least to me it doesn't make much sense to buy a car and not to use it to go somewhere. And therefore the next question is: what's traffic? On the same abstract level, we can say that traffic consists of behavior of traffic participants, prescribed by a set of rules.
Interestingly, compared to the complexity of a car, the set of traffic rules is negligibly small and therefore the requirements imposed upon traffic participants by traffic rules actually - and fortunately - underspecify the participants by far. Thus it comes to no surprise that cars - as well as their drivers - do not look very uniformly. The cars may have 2, 3, 4, 6, 10 or any number of wheels, they may be black, white, green, yellow or any other color you like - they may even be no cars at all. Taking part in traffic is also allowed for pedestrians, bicycles, you name it.
In traffic, each participant is involved in many interactions at once, many of them of comparable importance. Usually, none of these many interactions will determine a participant's behavior exclusively. Actually, none of the others is allowed to make use of a participant's car functionality. Quite in contrast, all participants are allowed (and actually encouraged) to make their own decisions, where to go, when to overtake, how fast to accelerate or brake - in other words to behave nondeterministically with respect to their many interactions - as long as they obey the traffic rules!
What's the most important difference to the process-like interactions we know, e.g. from B2B? Process-like interactions are also about comparably simple rules underspecifying the behavior of the participants by far. They are also about many different interactions at once. They are also about remaining in charge of control over the owned (business) system, despite the many interactions by avoiding the exposition of its core functionality directly to others.
First, I think it is the language type. The language, all participants have to speak to communicate and cooperate effectively in traffic is a simple sign language. The traffic lights shows red, yellow and green, the cars indicate their direction change with the direction indicator, we have a lot of traffic signs, most of them are grammarless. In B2B, interactions are in a sense more complex, so that we have to state much more structured details in our B2B messages. In our modern times, it's no longer possible to achieve successful business interactions by a pure sign language, which is the reason, our B2B messages have a grammar.
However, the most important difference seems to me the common goals of collaborations. In traffic, each car goes by its own, the fewer others are on the street, the faster one can get. In a business collaboration, participants usually are partners. A seller cannot reach its goal without a buyer and vice versa. As business partners depend on each other, they have to rely on each other. However, it seems still some way to go, to fully harvest these long hanging fruits - perhaps beyond the end of the day.
