共用方式為

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

  • 發行項

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

Comments

  • Anonymous
    September 21, 2009
    John, Maybe I'm missing something.  Isn't this the problem that EDI solved 30 years ago?  Business partners need to agree on a transaction set (a process or protocol) and an implementation (or typedef). It seems to me that we are just changing the labels and the technology.  But the core concepts are the same.

  • Anonymous
    September 22, 2009
    Thanks for commenting on my Process Isomorphism ZapFlash, which can be found at http://www.zapthink.com/report.html?id=ZAPFLASH-2009915 . Yes, Process Isomorphism is a specific example of reification, but reification is a broader term. What I'm talking about is a particular design principle that aligns Service compositions with processes in a particularly seamless way. In other words, I'm saying that if you handle process reification by creating a process isomorphism, you end up with an equivalence between the process and its supporting composition that can lead to clearer alignment between BPM and SOA in certain situations.

  • Anonymous
    September 22, 2009
    Hi Jason - thanks for commenting.  I modified the post to link to your report.  I didn't originally include a link because I didn't want people to think I was bashing ZapThink.   I had two concerns with the report: process isomorphism sounded a lot like reification and the idea that business and IT use the same standards to avoid gaps during reification.  There is no easy way to ensure the implementation of a given process is in full compliance with the original process model.  This is again due to BPEL only supporting a subset of something like BPMN.  I agree that alignment of a process and its supporting composition is a good thing and, as you state, its a fractal model - a process may also be a set of service compositions.  The challenge remains in the implementation since I'm not aware of any tools that can easily transform a complex business process model into a set of executable bits in a lossless manner.

  • Anonymous
    September 22, 2009
    Dan, EDI solved the problem from a document exchange perspective but not from a process perspective (flinging documents at each other is not a process).  The problem is that EDI captures the process in an EDI implementation guide. The EDI implementation guide is a human readable doc and can be easily misinterpreted, leading to faulty support for a given trading partner.  Web service standards enable us to capture both the business documents and the SLAs and additional rules/business protocols used to exchange and process the documents.