Imagine, you have to specify a typed method. How do you know, what this method and its signature are supposed to look like? There is a simple answer to that question: just look at the semantics of the method definition, i.e. at its specification. As long as a method is supposed to be a mapping between two states, it is logically a function and thus can be specified relationally. Lets have a look at business document content specification. Here the world is quite different. As I explained in another About Electronic Documents, Business Documents and Messages, documents can be viewed as documenting state transitions of business processes in a way so that their content is useful for accomplishing further transitions in other business processes. What happens, if the information exchanged within one business interaction are motivated only by the needs of other business processes, which depend on the information of the original process and so forth? Sounds wierd? Look at this simple example: A patient becomes admitted to a hospital, where he has to provide his or her insurance card. Why? This is not because this information is needed in the treatment interaction between patient and hospital but it is needed in the billing interaction between hospital and insurance. So, it seems to me that such a constellation is more the rule than the exception.
Now, what are the consequence? They seem to be quite far reaching. One consequence is that there is no once and for all generic way to state an event intended for observation by a peer. We all know that from our daily life: there is no once and for all way to tell your childrern to do their homework, there is no once and for all way to tell your partner you love him or her. A state transition intended for observation by a peer has to be stated so that the recipient gets all the information it needs for all the other interactions the recipient is additionally involved in, to achieve the mutual goal. If the hospital says, that it treats the patient only, if it can bill its costs subsequently to the patient’s insurance, then it is in the patient’s interest to provide this information. As a result, standard business documents guarantee the support of standard business processes only. Viewed from a different point of view, it’s trivial that we can prohibit the success of certain third party processes by withholding exactly the information they would need. Trivial as it is, it’s the essential idea behind data protection. However, I think in general it is not possible to say a priori what kind of process can be supported by a given piece of information. Practically and quite importantly, we cannot deduce the content of business documents by looking only at the interactions they are primarily involved in, but we also have to look at the other processes, which depend on content, provided by the original process. Technically, any business interaction standard has to be extensible with respect to its document specifications, otherwise process owners will not be able to locally and flexibly innovate their business processes as perhaps desired. Finally, a simple consequence is that a designer of business processes and their interactions has to have a broad knowledge about business process semantics. We cannot design a document, indicating a patient admittance, without having a clue about all the other processes, a hospital is involved while treating a patient. Breadth versus depths: The question remains, how much in depth knowledge such a process designer needs and where the delineation against an application developer becomes effective. My guess is that the business process expert still has to understand the most abstract level of application functionality, while the developer has to know the algorithms, i.e. the way the functionality is implemented. It seems that the nature of business interaction design is predisposed to become itself a collaborative effort, mirroring in the social sphere the necessities of the business semantics one.