Process Management Language reminiscing and thoughts
January 24, 2011 1 Comment
During my first career stint with IBM, I was working on Computer Integrated Manufacturing. I was in the role as thought leader as I had just finished creating several industrial automation projects for the Rockwell B-1B and Lockheed Skunk-works. One of the first concepts I put out –white paper (Body Enterprise) was terribly written, but the ideas still were valid enough to engage Bill Gates interest later was around dialects, domain/discipline specific languages, semantic mappings and transformations as the basic systems of an Enterprise’s body aka Digital Nervous System. In the paper I argued for several dialects or languages one being a Product Description Language, another one a Manufacturing Language, still another a Device Control Language, and yet more such as a Job or Process Control Language. [I have a diagram in my files somewhere I’ll get to scanning in some day]
The Process Language would have some basic control constructs (decisions and branching), however, you could define action classes and activities similar to how XML is being used to form dialects (one reason I’m hopeful a process language will emerge someday). The dialect family would have the same underlying base which would allow mixing the dialects to create an discipline specific language.
I brought this basic concept to ISO TC 184/SC4 when we started developing the architecture for STEP. Bill Danner, Jim Kirkley and myself started redesigning STEP around this framework pushing the ideas that the constructs in initial parts of STEP were constituents used to build a domain specific languages; in this case Application Protocols. In STEP we argued that basic constructs had limited semantics until you placed them into a AP Context that finished the semantic. This gave the entire system flexibility to grow as engineering needs grow. [Both Kirkley and I received a lot of heat on this for being “Too” object oriented from the DBMS faction in ISO working groups. I have a gag gift from PDES Inc. crowd for working in the architecture group call the “Mother of all Framework Awards” that I proudly display in my office]
A small offshoot of STEP created a Process Planning Resource Part and an AP. However, regrettably I and other were pulled off the project as no one at PDES Inc, IBM & DEC executive management saw any strong value in what is now workflow and process. Dr. Arno Smuckpfeffer (IBM Research) , Dr. Grossman (IBM Mfg Research), Dr. Steven Ray (NIST) and I continued on by ourselves for a while until it was clear we would not get any backing. Dr. Ray’s decision primitives I thought were excellent and pushed to get them included in Process Planning data models Some of the work that Dr. Arno Smuckpfeffer (IBM Research) I expanded upon into areas that enable me to analyze process efficiency and effectiveness. I had started a consulting practice around this at DMR however the timing wasn’t right as they were moving away from consulting into contract programming.
These components though are only the infrastructure to support process definition and execution; they are not the process (i.e., the model VS. reality issue I’ve discussed in other forums such as Enterprise Architecture Forum). This is why I make a distinction between Process Definition, Execution and the I.T. systems that assist in controlling and monitoring the process. Mapping from Definition to Execution Media is a fairly mechanical activity, a known quantity if you will. One could and eventually will take the time to create a complier to do such.
Creating the Process Definition takes time and effort as you are typically extracting the structure from human activities which often have hidden rules, inconsistencies, and capability limitations that cause others to approach the problem in an inefficient or ineffective manner. The MS Access application (process definition model) I built helps me capture the process content in a structured manner. It has been refined of the years but still could use some more work when I have time. However, it has made designing or reengineering robust processes much easier than the Visio chart approach most of the industry uses. Holosofx was getting close at one time, but veered off towards I.T. workflow applications.
Originally posted June 2009