Data, Not Language

Scott Francis
Next Post
Previous Post

Keith Swenson makes an (unnecessary but) persuasive argument that Doctors shouldn’t have to code or use BPMN (a two-dimensional graphing) approach to their processes.

He presents the straw man of:

  1. Graphical-only language, e.g. BPMN – and why he doesn’t think this is appropriate for a doctor.
  2. A two-language approach – one language designed for the Doctor or knowledge worker, and one designed for the system designers (graphical formal language): “At this point is looks like the two-language approach might work!  One language for the knowledge worker (simple check list) and another for the system designers (graphical formal language).”
  3. Why he believes the two-language approach doesn’t work.

And I agree with him.  A two-language solution doesn’t work.  He puts it this way:

Once the plan has be re-coded in the other language, a language that the knowledge worker does not know, then it is no longer able to be tweaked by the knowledge worker!
[…]That is the problem with a two-langauge approach.  Once a plan is moved out of the language of the knowledge worker, it becomes impossible for the knowledge worker to tweak.  It becomes “un-tweakable”.   What is needed is a “tweakable” representation of the plan.

It is a lot like the BPMN + BPEL discussion 5 years or more ago. 

Except for one little thing:  It isn’t two languages –  It is data, and language.  The Knowledge worker’s “checklist” doesn’t need a language-  it needs a data editor.  We’re not talking about a new modern day COBOL, we’re talking about storing a checklist (or the like). It’s data, not language.

When I started this journey years ago, this was not obvious to me either.  It is not intuitive.  One might expect a better language would always make things better, even if used only for parts of the system.  But, because of the adaptive, incremental nature of ACM, because of the way that knowledge workers needs to start with an approximation, and tweak it into appropriate shape, the conclusion is that the “best practice” example process plans need to be coded in less elegant — yet more accessible — form for the knowledge worker.  Since to allow them to be tweakable none of the process plans can be in BPMN/CMMN, one must surely ask the question why these languages are needed at all in an ACMS?

Actually it is pretty obvious and intuitive that a programming language isn’t the answer.  History is full of examples.  However, it should be obvious by now that when you need end-users tweaking the definitions, you need the tweaks to be data.  The success of end-user involvement is typically proportional to the extent to which you can transform something that is traditionally coded into something that is represented by Data.  (Think Excel spreadsheets versus the Fortran and COBOL programs that would have done those calculations in the past).

Data isn’t as sexy as “Language” to the computer scientist, but that’s how you address the knowledge worker.


  • Programs are data and programs generate/describe data.

    (sorry, thinking out loud).

    • Programs describe logic as well as data. To meet Keith (and ACM’s) objectives I think you have to eliminate language from the learning requirements.

      (so, while I agree with you, that programs are data, we’re missing the target with that line of thought)

  • If that gap between business and IT is to be closed there can only be one language business language! It can be done because business logic never changes so why code over and over – think about it! Many better experts than me have expressed concerns about BPEL and BPMN but they are not required. Try a “declarative” technique from the model… works no language to inhibit interpretation or performance!

    • Which declarative language would you use?

      And I’m not sure what businesses you work with that never have business logic change…

      A declarative language is still a language to be learned.

    • KDS

      “business logic never changes” – Odd statement. I don’t understand what it means.

      There are some experiments with declarative languages, yet this does not solve the problem: if the process plan say that “Joe must produce X” even if it does not say HOW to do this, it still eliminates the possibility that Joe produces anything else. When the world changes, and Joe needs to produce Y, someone has to change that declarative program. If that language is unfamiliar to Joe, the knowledge worker, he is in the same problem.

  • KDS

    Completely agree with jmettraux. Data and language are interchangeable. When I use any visual editor, I drag a box on the screen, I am really changing the data that is stored in the file.

    When I talk about a language, I am talking about how that data is presented to people. They don’t see simply ones and zeros. Like any user interface, it has to be structured according to a metaphor and provided with interactions that make sense in that context.

    I agree with most your post, which is the visual presentation and the interaction for knowledge workers will be more like a checklist, more like Excel. If you are not comfortable calling this a language that is not a real problem. I called it two languages, you called it language and data, but I think the result is the same: if the knowledge worker is using what you call data, and a programmer recodes it in a language, then it is no longer tweakable by the knowledge worker. I think we agree on this.

    • As long as the original data is preserved and interpreted by a run-time engine, you don’t have a problem. If I type some data that gets stored into a database, I may not care that you stored it UTF8 or some other format, but I do care that when I recall that data, it is still there.

      I think two “languages” implies the complexity of a software language. “Data” implies no such complexity to the typical reader. Pedantically, languages are stored as data. I don’t think that’s the point, unless your audience is only software programmers :)

      Other than that little disagreement over terminology we’re mostly in agreement. But because my notion of data makes the separation more clear – I can store a checklist as a checklist, and recall it as a checklist, with no loss of data or intent – there’s no two-language issue in my world when we implement “knowledge worker” solutions. And we don’t have to design a whole new language to implement and agree on as a standard :)