"Concept Typedefs", the Holy Grail of BPM and Closing the Gap Between Business and IT

  • Article

A typedef is a keyword in both C and C++ used to introduce new names for existing types.  A simple typedef declaration lets you define your own names that can be used in place of type specifiers such as int, float, and double. Surprisingly, some people have started applying typedefs to well-understood concepts, resulting in confusion and debates about the very concepts they are trying to explain.

Jason Bloomberg from ZapThink recently published a briefing entitled "Process Isomorphism: The Critical Link between SOA and BPM".  Anything being positioned as a critical link between two trendy yet poorly understood topics is probably worth learning about, right?  Imagine my surprise when I realized that "process isomorphism" is nothing more than "process reification", a concept that has been with us for many decades. Process reification refers to the transformation (or "reification") of an abstract process into a concrete or executable process.  John Zachman wrote about the concept of process reification during the mid-1980s in his classic paper "A Framework for Information Systems Architecture".  Zachman's framework consists of a six by six matrix with the columns representing stakeholder interests and the rows representing views of the architecture.  Moving from the uppermost abstract views (Scope, Business Model) to lower, more concrete views (System, Technology Model) is sometimes called reification.  Zachman himself used this term to explain the relationship of the upper to lower layers when I met him many years ago.         

Zachman Framework

As stated earlier, process reification is the transformation of an abstract process into an executable one.  Process reification is one of the Holy Grails of BPM and has existed long before SOA became a popular acronym.  The ebXML Business Process group developed a methodology for process reification that later evolved into UN/CEFACT's Business Collaboration Framework (BCF) (BCF later became the foundation of the UN/CEFACT Modeling Methodology (UMM)). Its important to realize that all these frameworks have one fundamental concept in common - process reification. 

The concept of process reification also appears in the Business Process Execution Language standard (BPEL).  The original intent for BPEL was to provide a standards-based approach for communicating public (abstract) and private (executable) processes.   When I was co-chair of the BPEL group at OASIS there seemed to be much confusion over the concept of an abstract process.  I tended to explain the concept using three scenarios:

  1. The 800-lb gorilla in the value chain (e.g. Wal-Mart) dictates to  its suppliers how to interact with it using an abstract BPEL template.  Suppliers import the abstract BPEL and map their private (executable) processes into it. 
  2. An industry standards organization (e.g. a RosettaNet or HL7) could provide BPEL templates to its members as a set of "best practices" to ensure they implement the standardized process properly
  3. A distributed organization like a  bank could provide abstract BPEL templates to its branch offices, showing how the branches should interact with the corporate office for a given process.  (This is much like #1 except its within a single organization)

The biggest challenge we faced with BPEL was that it was not expressive enough to model a complex business process.  This is the reason that most of today's tools treat BPEL like a programming language instead of a tool for process reification.   While some tools attempt to map standards like BPMN to BPEL, the mapping is a lossy effort due to limitations in BPEL itself.  BPEL is missing some fundamental concepts and many vendors have extended their implementations in a proprietary manner to support more detailed business process scenarios.  This fact is surprisingly overlooked and leads many people to falsely believe that a BPMN modeling tool can generate executable BPEL that fully complies with the original process model.  If business uses one modeling standard for process design and IT uses another for implementation the gap between business and IT could grow wider, especially if we rely on technology alone to close the gap. 

The solution to narrowing the gap between business and IT is a complex one and will never be solved by technologies, standards, vendor-specific tools or open source.   Narrowing the gap between business and IT is a people problem that requires collaboration, visibilty and accountability to eliminate miscommunications and reduce risk.  The scope of such an effort is far beyond the capabilities of any modeling tool or process standard.  

Whether its called process reification, "process isomorphism" or some other new term, the concept of using standards to transform an abstract process into an executable one has yet to be fully realized.  Despite ths fact there are some promising efforts emerging (most notably BPMN 2.0 and XPDL). 

PS: Don't miss out on a chance to see John Zachman speak - he's quite entertaining and very informative. 
PPS: JP recently wrote a wonderful blog entry about why SOA and BPM are not necessarily related here: https://www.jpmorgenthal.com/morgenthal/?p=103