Modeling Business Capabilities by Combining Services with Communication Patterns (4)
In my previous post I looked at the communication patterns supporting the mutual interactions and coordination between services. Here we'll take a brief tour of the DEMO methodology [RD99] which, as we heard previously, builds upon Searle’s Language/Action Perspective and introduced the important concept of a business transaction communication pattern.
For more information about an approach that advocates the use of communication patterns for business process decomposition and service identification, refer to the article "Business Process Decomposition and Service Identification using Communication Patterns" [GG04]. This article discusses a methodology called Dynamic Essential Modeling of Organizations (DEMO) which assumes that to provide automated support for business processes it makes sense to decompose business logic according to the same patterns that occur in a purely human world.
The fundamental premise behind the DEMO methodology is that by identifying the recurring communication patterns between people and describing how these patterns combine to form business processes one is able to provide a stable foundation for business modeling. This in turn is key to better understanding the usefulness of workflow-based implementations of service capsules and will help answer one of our earlier questions, "How can these conversations be modeled robustly and reliably to support both human and software services?" The following series of diagrams and side-by-side explanation will attempt to add further light to this statement.
Thus DEMO recognizes that organizations are made up of cooperating people who use communication to align their actions to deliver value to their business, i.e. produce goods or deliver services. With DEMO, you decompose business processes into elementary business transactions where each business transaction identifies a business role that operates as a miniature supply chain providing a well defined service to other business roles. The business roles referred to by DEMO are conceptually equivalent to the capabilities identified by MSBA.
So I'll close this section of the article be reiterating my proposal that one can use the insights behind communication patterns to properly implement a capability as a service, or indeed, as a service capsule! I firmly believe the resulting capability implementation will have the most appropriate level or type of conversation model matching the role(s) and task(s) that the capability participates in - whether they're about making business decisions or judgments (at the ontological/enterprise level); or reproducing, deducing, reasoning, or computing information (at the infological level); or simply storing, transmitting, copying, or destroying information (at the datalogical level).
[GG04] G. Geurts and A. Geelhoed, Business Process Decomposition and Service Identification using Communication Patterns, Microsoft Architecture Journal, Issue 1, January 2004.
[RD99] V.E. van Reijswoud, J.L.G. Dietz, DEMO Modelling Handbook Volume 1, Delft University of Technology - Department of Information Systems, Version 2.0, May 1999.
I'll develop this topic in more detail in subsequent posts. Please come back or subscribe to my RSS feed.