SOA is dead, long live BNT! Ups, but BNT - now, what is that?
As Henning Kagermann has formulated in the last employee meeting of SAP: Agility unfolds only in a world of 'And'. Only if we succeed in embracing seemingly antagonistic requirements we will reach our desired level of agility as a company. For Hennig Kagermann, this means embracing both excellence in processes and user-centricity in SAP's application architecture. SAP products need to be both powerful and simple; its portfolio delivered on promise and in situations of unforeseen demand. The company's business model must be fit for complex systems and for volume business; its growth strategy accommodate organic growth and acquisitions. Finally, SAP must instill both an engineering and an entrepreneurial culture.
The network paradigm of process interactions
Now, what has that to do with BNT?
What is true for enterprises seems to be true for our business software and - as I would like to add - as well for our daily lives. If we look at even the most simple (business) processes, we see that they have to coordinate several - often conflicting - interactions at once: A seller (process) has to sell, interacts with a stock, with a reseller, with the bank, etc. A hospital is involved in treating patients, billing them, ordering goods, paying the personal, etc.
So, I would state, that it is one of the hallmarks of a (business) processes to interact with several other (business) processes on an equal semantic level within a network of interactive relations! This picture is very different from the strict hierarchical graph of unidirectional functional relations, characterizing the inner structure of software components.
The interaction does not determine the action
To make coordination of all these different interactions feasible, none of them should determine the behavior of an actor, in the former example a seller or a hospital, completely. In other words, each single interaction relation is supposed to provide a certain freedom of choice and therefore is supposed to be non-deterministic. This means that the interaction between the interacting parties in general does not determine the actions of either of them. Actually, the more freedom each interaction allows, the easier the internal coordination of the interaction probably becomes. The required freedom of choice implies that the decision about the action to be taken to process any input data is private and in general out of reach of the sender of the data
As the exchanged data in such a network of collaboration does not represent "commands" in the sense that the recipient is supposed to do what the sender has said, a simple consequence arises: from the perspective of the sender it is not sensible to describe the single interactions within these collaboration networks by computable functions. Thus, a description of such interactions by means of a "distributed object model" is not sensible - obviously along the line of our daily SAP experience, where object models denote reusable functionality and therefore have local character: a seller has his "sales order" and the purchaser has his "purchase order", etc.
Linguistically, "commands" are denoted by verbs: do this, do that, create this, delete that. The non-command character of the interactions is documented by the non-verb denotation of the interaction entities. Instead of verbs, nouns are used like "order", "advanced shipment notification" or "bill", etc.
Another simple consequence of the recipient's legitimacy to decide about the to-be-taken action is: the recipient also has to decide about what to do when exceptional circumstances arise. The automatism of remote method invocation, where exceptions have to be transmitted back to the caller, becomes invalid. No seller would tell its purchaser if an order cannot be processes because some internal error has occurred, for example because its internal systems are currently not working.
If we nevertheless try to describe the interactions by synchronized products of send and receive actions, we will create a lot of actions like sendOrderData(), sendInvoiceData(), all with the same semantics: receive and persist and possibly technically validate and acknowledge the sent/received data. None of these actions would determine the processing of the data and all of them would provide the same (technical) exceptions. From my point of view another obvious reason for separating serialization and sending functionality (The necessity to separate serialization and sending functionality for electronically represented bus...) in process interactions.
Non-deterministic rules provide freedom of choice
What is a collaborative interaction if it is not described by verbs but by nouns? What distinguishes such an interaction from a typed function call?
A typed function call can be described (specified!) by a relation between its input and output which has a special property: there is a unique mapping between input and output (+possibly unique internal state mapping).
In contrast, a collaborative interaction in general is essentially not supposed to be described by such a unique mapping. All we can state are certain rules. For example an order is allowed to be sent. It may result in a positive confirmation, in a negative confirmation or even in no confirmation at all. Or: if something has been ordered and is not been confirmed or sent within 8 days, the purchaser can assume that no contract has been established. Or: someone is allowed to spontaneously send a booklet and if one of the recipients orders something within the next 14 days with referral to this booklet, the original sender is obliged to sell this item. Etc.
If the description of the interaction rules explicitly does not specify a unique mapping but just a relation between state transitions and input and output, it obviously leaves room to complement, to take a possibly otherwise determined action by making effective internal decisions.
I have already provided an example of the relation between rules and freedom of choices in my blog on traffic (Traffic and cars: the essence of process-like interactions.) "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. " - leaving much room for individual decisions where to go and how.
The competent interactor becomes the center
Call the coordination of the different interactions "process" or "orchestration" and the interactions "protocols" or "choreography". We achieve a separation between the internal coordination of actions (or functionality) and the externally visible choreography of interactions and therefore a decoupling between actions and interactions.
The network paradigm of interaction actually moves the competent (inter-) actor into the center. It becomes THE core competence of the actors to be able to find their way through a network of possibly conflicting and parallel issued needs and wants of others and itself. The more freedom the actors have, the better they can accomplish their coordination goal. Now - at least to me - this smells already a tiny little bit after introducing the notion of subjects into informatics, since the analogy to our daily life is so obvious: We work, we have a family, a husband, we are members of a union or of party, etc. All these interactions have to be coordinated successfully under considerations of the needs and wants of all the others and ourselves.
As we all know, people who always want to command others or who want to be commanded by others are pretty hard to integrate into such networks of collaborations.
The transformation aspect
Now, why Business Network TRANSFORMATION? Obviously, the requirements for the interactions are ever changing. Every new communication medium has created enormous possibilities for new forms of interactions: telephone, fax, email, to name just a few. As we all know, businesses reorganize then and now, legal requirements change, etc. The reasons why business networks are changing or transform from one configuration into another are manifold.
And here comes possibly the most important reason to separate interactions from actions: It is possible to keep a single interaction pretty stable - that is, keep the rules - and at the same time change other interactions dramatically. The way to sell books remains virtually invariant against the way the seller organizes its stock or its relation to its bank. The way a patient is treated remains almost invariant against the way the hospital interacts with the health insurance or with its personal.
However, almost doesn't mean completely. And in fact, as I have pointed out in my blog "who poses the requirements of business documents" (Who poses the requirements for business document content? ) the essence of collaborative interactions might even be that although only "loosly" coupled in some sense, these interactions don't seem to be as much semantically separable as different function calls into different business objects are.
In the illustrated example below, the ordered goods are now delivered directly from the stock to the customer, requiring changes possibly in at least three interactions between buyer and seller, between seller and stock and between stock and buyer.
Certainly, their coordination within buyer, seller and stock has to be changed too. The main issue for buyer, seller and stock will be to be able to adapt to the new requirements as fast and with the least effort as possible.
Although formally alike, not all interactions will have the same stability properties. There are a lot of reasons, why some interactions might be more stable than others. From a business perspective, the prospects to change external interactions is by far smaller than to change internal ones.
The role of standards
There are at least two distinct strategies to cope with the costs of change. Either we can try to minimize the amount of changes or we can try to change most effectively, reducing the costs per change.
Standardization is at the core of both approaches. From a content point of view, it is probably a good idea to take the extra mile and agree on a standard for certain interactions which are supposed to be sufficiently invariant. "Sufficiently" does not mean completely. As is pretty obvious, there will be no interactions, which will not evolve somehow over time. Thus, standardization cannot freeze any interactions against all changing requirements, it can just remove or impede any unnecessary changes, which would occur if no standardization were undertaken.
However, standardization is also pretty useful if we want to change more effectively. From a methodological point of view, we would gain much efficiency if we could separate the action and the interaction view from each other. A well engineered standardized way to describe the effective rules of a business process interaction would make its implementation and orchestration with other interactions probably much easier.
Any organization would be seriously impaired, if any simple change somewhere in the network would invoke an avalanche of changes throughout the whole network. Thus, in summary, agility in a world of 'AND' can simply be seen as the ability to separate the quick from the slow changing interactions as far as possible by means of a process-based view of the world.
2 Comments