Skip to Content

The issue

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.

The consequences

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. 

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. David Halitsky
    Hi Johannes –

    Another thought-provoking post that ties the “everyday” to the “abstruse” (parent-child relations and “state-transitions). Wonderful stuff, as always.

    But a really dumb question which I’m sure you can answer and therefore “unconfuse me”.

    Suppose we have your P = (p0,p1,…,pi,…,pn) where P is a sequence of processes and pj depends on at least one pk for k < j.

    Then your point about each process pi seems to disappear if we simply say: “No, no – there is actually a super-process “P” whose state transitions are determined by the state-transitions within its sub-processes pi (0<=i<=n)”.

    Well, maybe not disappear, since someone can come along and say: “Ah, but there is:

    P = (P0,…Pi,…,Pn)

    where our original “super-process” P is some Pi in the “super-super-process” P.

    And in this case, your point is valid again at the “P” level, though not at the “p” level.

    But surely, there must be some real-world business processes where the potentially infinite recursion terminates, and we have a fully-determinate “super*-process” P*.

    As I said, it’s a dumb question, to which I’m sure you can help me to see the correct answer.

    Best regards

    1. Johannes Reich Post author
      Hi David,
      according to my understanding, your question rests on the assumption that a super-process does exist. To substantiate this assumption, you would have to say, which composition rules processes follow. As long as these rules are not defined, your question seems to be not well enough posed.
      Regards, Johannes
      1. David Halitsky
        Hi Johannes –

        I think the question you’re raising is the same one which De Marco raised some years ago in the context of DFD’s (“data flow diagrams”).

        In particular, he and his colleagues suggested that DFD’s could be “levelled” whenever a large and complex process had subordinate large and complex processes, which in turn had large and complex processes, etc. 

        So at each level, a complex process at the next-lowest level is represented by an empty “black-box” bubble, and for information on the detailed process inside this “black-box” bubble, you have to go to the DFD for the next-lowest-level.

        I’m not sure that the question you’re raising differs from the question he raised, although the relevant technologies have certainly advanced from the time when systems analysts drew DFD’s using the straight-edge and circular cut-out of a flow-charting template.

        Ah well – I lost my last green plastic template years ago … but I still have some coding pads. The reverse side of the pages are all blank, and very useful for sketching out preliminary designs.  (Just kidding!)


  2. Anonymous
    Hello, first of all it is good to see how Business Process can integrate an institution like you say where big companies have to be conected because they loose contact as it gets bigger. Efforts are coperative production is multiplied.
    There are other environments of high productivity where cooperation may contribute to balance work, act better and generate short term strategies to reach mentioned goals.
    Documents should be converted to input applications so communication is from one step to another without wasting time in filling forms.
    I think its better contribution is to manage stress free environments.
  3. Anonymous
    I think when you start thinking of managing a high level process you should be thinking in communication after you think of integrating those small processes into a big one there are high level strategies that may you get to your point such as making a desition on a state change where if you could program it you could say if this happens then i exit the loop or other strategy. For expample you could have a watch dog to take care of time outs in one single sub-process.

Leave a Reply