Data, Not Language

  • November 20, 2012
  • Scott
  • 7 Comments

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.

Related Posts
  • November 15, 2018
  • Joe
  • 0 Comments

Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...

  • November 8, 2018
  • Larry
  • 0 Comments

[Editor’s note: This guest post is the ninth in a series from Larry Taber, BP3’s Digital Strategy Officer ...

  • November 6, 2018
  • Joe
  • 0 Comments

Editor's note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...