Skip to Content
Although Noam Chomsky is now known mainly as a political persona, there was a time (pre-Vietnam) when he was better known as one of the people who laid the formal language-theoretic groundwork for the notion of “compiler” as we still know it today (e.g. ask yourself why ABAP requires spaces between “words”.)  The story of what happened to his concept of “transformational-generative grammar” contains a cautionary tale for those attempting to express “business semantics” in BPEL.  Here’s the story.   The Story.    From 1956 to 1969, Chomsky’s theory of “transformational-generative grammar” (TGG) was the standard model for research into natural languages (e.g. English, German, Hindi, Farsi), and the “context-free” component  of this theory provided the standard model for construction of any “syntax-directed” programming language (i.e. any compiled language Lp whose compiler checked your code for well-formed statements according to a context-free grammar of Lp.)  In the version of TGG promulgated before 1969, “meaning” was supposed to be a function of “Deep Structure”, e.g. if two “Surface Structure” sentences mapped to the same “Deep Structure”, then they had to have the same meaning.  Around 1969, folks began to point out that this model of semantics was inadequate, and hence the field of “Generative Semantics” (GS) was born.    But although the Generative Semanticists did have valid criticisms of Chomsky’s original TGG model when it came to semantics, the stuff they developed to remedy the inadequacies of TGG was just terrible (perhaps because their research may have been done after they had licked their pinkies once too often, if you know what I mean.)  Nonetheless, the GS onslaught against TGG fundamentally altered Chomsky’s own thinking on natural language, and in some people’s opinion (e.g. mine), not for the good.  Although Chomskyan linguistics still contains some remnants of what was good in his original theory of TGG, these remnants have been overlaid with all kinds of mechanisms which have no basis in formal language theory, but are merely there to try and catch the elusive butterfly of meaning.  (Wasn’t that a TERRRIBLE song?)    Here’s the Cautionary Tale.   The Cautionary Tale.    Assume that:    1) BPEL is capable of encapsulating the semantics of business functions – any piece of BPEL declares a “meaning” or ‘intent” (we can take “meaning” as synonomous with “intent” for the sake of this discussion.)    and that:    2) any language such as ABAP or JAVA is capable of encapsulating the syntax of business functions – any piece of code in such a language declares how “intents” are to be achieved.  (This kind of makes sense, because you can automate any business function in a variety of different programming languages, just as you can express any thought (pretty much) in any natural language such as English, German, Hindi, Farsi.)    OK – then under these two reasonable assumptions, where is the empirical justification for the assumption that you can separate out the semantics of business functions from their syntax?  This doesn’t happen in natural language – none of us can express a thought in our native language “L” without wrapping the syntax of L around this thought.    Furthermore, the failure of GS and Chomsky to develop a language-neutral model of “meaning” indicates that it may not be possible IN PRACTICE to separate natural language syntax from natural language semantics.    And if so, why should we assume that the syntax and semantics of business functions are separable ???
To report this post you need to login first.

6 Comments

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

  1. Tony Van Der Linden
    Interesting stuff David. Well no, I don’t think you can describe/convey meaning without syntax, it’s the “describe” part of the task as far as I’m concerned. The synta is the vehicle for conveying meaning. I guess the challenge with BPEL is to change the syntax to something more friendly, or which is more technology agnostic.

    I’ve seen this over and over again in computing, with products claiming to take the programmer out of the loop. These tools may reduce or eliminate the actual “coding” required, but they simply use a different syntax, often using graphical symbols to represent it. You just hope then that it has the same features that it would if you were “coding” instead (i.e. that it is a complete language).

    The idea is to widen the user base to business types, and perhaps it achieves that to a degree, but I think there is more to this than just ease-of-use. It is useful to describe business process in a way that is not tied to their implementation technology, but, regardless of what language/syntax you use, you need to think about these things in a logical way. 

    The attraction of these tools for many, I think, is simply that they’re not code, but it doesn’t mean that they’ll necessarily be that much easier to use, or that you won’t need to think about describing the process in a fairly strict and logicl way, just as if you were coding.

    So in short, yeah I think BPEL is just another language for representing a business process, but I think the intention is that it’s the Esperanto of business process syntax. That it’s all of the other langauges and none of them. You just need to hope the speaker is fluent.

    Not sure where I went with this, just some thoughts, thanks for provoking them.

    Tony.

    (0) 
    1. David Halitsky
      Hi Tony –

      I hadn’t thought about it that way, but you’re absolutely correct.  BPEL can be viewed as a type of stenographic “shorthand” for the concise abstract expression of business process syntax. 

      Or alternatively, as a kind of “sign-language” parallel to those sign-languages whose use is strongly encouraged (over lip-reading) by the hearing-impaired.

      And when viewed in that light, my theoretical objection disappears because BPEL need no longer be interpreted as some kind of syntax-neutral model of business “semantics.”

      So thanks much for providing a very worthwhile alternative perspective on the question of what BPEL is trying to accomplish.

      It is, of course, up to BPEL proponents to decide how to describe what it is that they are actually doing: semantics or shorthand.

      Best regards

      (0) 
  2. Alan Rickayzen
    Hi David,
    When we started the BPEL podcast series that you originally referred to it was indeed partly done to publicise some useful terminology and ‘short-hand’ techniques.  I wouldn’t say that BPEL is capable of encapsulating the semantics of business functions because I always like to distinguish between functions (what is done) and processes (how it is done) but I’m glad you recognize the value of this.

    It also shows the value gained when SAP influences the standards instead of just implementing them.

    Best regards,
    Alan

    (0) 
    1. David Halitsky
      Alan –

      Thanks very much for taking the time to reply.

      Your observation about the need to distinguish between functions and processes is like a cool drink of water to a pilgrim in the desert.  The confusion over these two categories started when the “Business Process Re-engineers” hijacked the term “process” several years ago, and unfortunately, the term “Business Process Expert” doesn’t do anything to help alleviate the confusion.  (Please forgive me, Marilyn!)

      So since we’re in agreement on the need to distinguish between “functions” and “processes”, consider this distinction in relation to my post here:

      Blueprinting and Enterprise SOA

      concerning SAP blueprinting in the age of SOA.

      (Please hang in with me here – I promise to show in a moment why the above post is so very relevant to the usefulness of BPEL in disambiguating function from process.)

      The reason why standard SAP blueprinting is a vestigial dinosaur from the pre-ES(O)A days is because it forces new SAP clients to conceptualize business functins in terms of SAP “transactions”.

      But clearly, “transactions” belong to the domain of “processes”, not “functions” (according to your own succinct definition of the two), so the entire SAP blueprinting process is actually inconsistent with SAP’s ES(O)A vision.

      And this is where I see an important role for BPEL or something like it. 

      Imagine if SAP blueprinting was not “transaction-based” but based on something like BPEL schematics, where each schematic represented a function that could be realized by a variety of processes –  a transaction, an xapp, an SOA “service”.

      Then SAP would be making very clear to clients how “functions” differ from “processes”.

      But I fear that as it proceeds into the ES(O)A age, SAP will make the same mistake it made when it decided to base blueprinting on transactions.

      In particular, what we’ll see is merely a new blueprinting process based on ES(O)A services instead of transactions (where the transactions will be buried within the services.)

      And then all we’ll wind up with is a new way of confusing function and process …

      Anyway, I do want to mention also that I was playing a little bit of the “devil’s advocate” in suggesting that folks working on BPEL should remember how hard it is to actually do “semantics”.

      I think that in restricted domains, like Supply Chain functions, it probably is possible to encapsulate semantics to a much larger degree than is possible in unrestricted domains such as the world of experience which natural languages must describe. 

      But nonetheless, semanticization must be undertaken with a great deal of humility (knowledge of past failures) in order to have a chance of success.

      (0) 

Leave a Reply