Skip to Content
In a thread here: If IT really is a “profession”, what is our “pro bono” contribution as IT professionals? Zal Parchem and I were bantering about the attitudes of IT-folk toward business-folk. Although this was only banter, it made me think of the old German proverb “Der Mensch denkt und Gott lenkt” and its English translation “Man proposes, God disposes”. But what if we replace “man” and “god” with “business” and “IT”, or vice-versa? Should it be: “Business proposes and IT disposes” or: “IT proposes and business disposes” ? And does the advent of BPX and Enterprise SOA change the way we should look at this question in the first place. My own feeling is that before BPX and Enterprise SOA, the accepted paradigm was the second version above: “IT proposes and business disposes” That is, it was up to IT to propose solutions and up to business to decide whether these solutions were acceptable and worthwhile. But with the advent of BPX and Enterprise SOA, maybe it’s more the other way around: “Business proposes and IT disposes”. That is, if business is empowered by BPX and Enterprise SOA to think up its own solutions, maybe IT becomes the limiting factor determining which of these solutions are feasible in real-time, given certain limitations on hardware and software which will never go away. Maybe the right proverb should be: “Business and IT can propose all they want, but queueing theory disposes”.

To report this post you need to login first.


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

  1. Marilyn Pratt
    Queueing Theory, according to Wikipedia, “is often too mathematically restrictive to be able to model all real-world situations exactly. This restriction arises because the underlying assumptions of the theory do not always hold in the real world”
    That certainly would be a BPX challenge: namely, avoiding creation of models that don’t properly reflect the way things are really done. Wonder how often that occurs in our brave new world.  In such a case it isn’t then a question at all of whether there is a supporting technology or whether IT disposes…when the blueprint is wrong, it won’t ever even get to the stage of checking IT limitations because the problem will be that the blueprint simply doesn’t reflect…reality… the way business is really done.  If the design and model aren’t accurate, it little matters whether or not you could build according to those faulty specifications.
    It would be interesting to hear real Enterprise SOA experiences of how Business Process Architects take models that accurately represent their business and successfully transform them.  I’m eager to see that kind of activity here beyond theoretical debate.
    1. David Halitsky Post author
      Hi Marilyn –

      Either way, SDN should be a place large enough to have room for discussion of relevant theoretical questions as well as communication of real-world experiences.

      For example, in my intro webflow class yesterday, I asked an obvious question just to make sure I got the obvious answer: the SAP webflow engine does take care of swapping containers out of memory to disk and back again as the need arises. 

      Hence, two queues constantly exist inside the engine: containers waiting to get back “in” and containers waiting to be put “out”.

      I am certainly not enough of an expert to know whether these queues can be reasonably well-modelled by queueing theory, or whether some simulation approach would be better (like that suggested by the Wiki article you cite.)

      But I do know that some “problems” never change.

      In 1992 (not that long ago), I had customers writing applications which required the swap-engine of a MUSASS (multi-user single address space) to continually swap 750K chunks of code and data in and out of memory.  (These were on big blue iron.)

      But even with the biggest bluest iron, no swap-engine can handle more than a certain amount of swapping involving large chunks.  And in fact, in this situation, it was advisable never to force the swap-engine to deal with chunks larger than 180-200K (if you had more than a trivial amount of chunks that had to be handled.)

      Since the days of IBM CICS (which I believe was SAP’s first TP monitor, or at least one of them), the rule was always a variation of KISS: “Keep it small, stupid.”

      I personally can’t believe that hardware and software have gotten so good that considerations such as the above are now irrelevant.

      And if SAP has either queueing theory analyses of its webflow engine or simulation-based analyses, then I think discussion of such analyses does belong at SDN.

      Anyway, thanks for taking the time to reply.


      1. Marilyn Pratt
        “Either way, SDN should be a place large enough to have room for discussion of relevant theoretical questions as well as communication of real-world experiences.”
        Is there any doubt there is and it is?  Thanks, for the learning about queueing theory, by the way.

Leave a Reply