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.

DEMO

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.

	In this conversation fragment one actor is simply asking another for information. Researchers have long asked if it is possible to canonically represent the way people communicate? In other words what rules relate the intent of a message to its content and form.
	This simple conversation can be deconstructed into two communicative acts. The first being to ask for information and the second to state it. Real-world conversations are of course much more elaborate and consist of several different kinds of communicative acts that convey different intentions resulting in the performance of different actions. Intent is an essential concept to grasp as all structuring principles within a conversation depend entirely on it. The role of intent is easier to imagine in the normalized or canonical view of a communicative act which can be represented with the tuple <Performer: Intent: Addressee: Fact: Deadline>.
	The structure of conversations is thus developed by sequentially combining or nesting pairs of communicative acts (or the tuples that represent them) between actors.The important thing being that the fact is the same in each pair of communicative acts, but the intent is different! Elementary conversations thus boil down to a message exchange around one single fact, however the intentions change; for example: ask, state, request, accept, promise, etc.
	Business conversations are constructed using the same principles discussed above but would be concerned with reaching a goal or outcome or performing a function which made sense in the context of the business domain.In this trivial example the actors are engaged in a business conversation on the exchange of a pizza; one is ordering and the other commits to producing and delivering it.
	Further analysis of business conversations reveals an often repeated pattern of three phases. Dietz calls these the order, execution and result phases. This, so called, Business Transaction Pattern is always associated with commitments to perform actions by one or other of the actors involved. The commitment is characterized by the production step in the execution phase. This production step actually causes new facts to materialize in the domain of discourse.Dietz makes a distinction between the Business Transaction Pattern and an Information Exchange Pattern which doesn't have any productions associated with it, but is essential nonetheless as a supporting pattern for the Business Transaction Pattern. Together these patterns make up the communication patterns which I have referred to quite often in this article.
	The Business Transaction Pattern outlined above is incomplete. The problem being that it represents only the sequence of communicative acts that would take place between actors in a conversation that succeeds in producing the desired outcome or performance action(s). A more complete pattern would incorporate additional layers of communicative act sequences dealing with situations in which the normal flow of conversation had to be re-negotiated or was interrupted in some way.This picture shows a negotiation and failure layer added to the normal success layer of the pattern.

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).

References

[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.

Comments

• Anonymous
  July 31, 2007
  Hi Arvindra,Good to see you tackle this topic again. I look forward to further installments and hopefully I can chip in with a comment or two!Regards,Gerke.