There has been a lot of discussions on how the ECDM relates to SOA services and their DDD domain objects, and how the BPM process layer relates to the SOA process layer. In the following ontology I have tried to model the relationships between ECDM and domain objects, Shy Cohen’s service taxonomy & ontology, and Jean-Jacques Dubray’s SOA+BPM ontology. Click to enlarge the ontology:
Note how there are processes at two levels in the model: the event-driven resource lifecycle processes for domain objects, and the human-driven business processes that utilize the composed services. The ECDM is applied at the service composition and human workflow level, while the services operate on the domain objects to manage the lifecycle of these resources in accordance with the business events. These two levels are separate DDD bounded contexts with well defined mappings between them: the business process domain and the resource lifecycle domain.
Note that the ECDM is related to, and is a subset of/reference to, the resource domain objects (CIM); like a mail order paper form that contains e.g. some customer data and references to product data. The word "subset" is central, e.g. the “customer has moved” action event has a ECDM document that contains the data pertinent to that specific business process event, not the complete schema of the customer domain object. The resource process service used to act on the “customer has moved” event does of course operate on the actual domain object, but this is invisible to the human workflow process.
The figure also shows business events and processes using two-headed lightning arrows to signify that these are separate model artifacts and not to be considered integral parts of service processes or compositions. I am a strong believer in designing a service-oriented solution by applying "EDA style" thinking to avoid missing out on the events and their documents due to traditional “invoke operations” SOA thinking.
An aspect not shown in the model is that the need for agility increases towards the top, while the cost of change increases towards the bottom. This is an important argument for having processes at two levels; it allows you to contain the frequent changes to the human workflow processes (mashup style compositions) and composite services rather than having to constantly make changes to the core resource level services, which could become very costly as the number of service subscribers increases over time. This is something that your business people should readily appreciate.
Design your system to have flexibility in the business processes, not in the composed business logic. The diamonds of your business process are the business decisions, and this is where you should implement a business rules engine (BRE) mechanism. Process flow logic is not business logic.
Finally, the model show how claims relate to services at all levels. I have done this to show how a claims-based security model is a cross-cutting concern throughout a service-oriented solution. I strongly recommend designing in process claims right from the beginning, as this makes it easier to learn how access control relates to the business processes and solution domain.
Master Data Management (MDM) relates to the "Resources" in the above ontology. It is imperative that you apply a MDM strategy to your enterprise resource domain objects to avoid inconsistencies and multiple versions of the truth.
I hope this ontology makes my viewpoint on SOA+BPM+CDM clear to you. Feel free to comment on this model, and also check out the six figures in JJD’s ontology for models showing different perspectives of resource lifecycles & business events, BPEL, BPMN and human tasks.
See also this related post.
Posts
6 comments:
Not sure I agree with the agility/cost comments. Blogged a response here.
JT
James Taylor
Author, with Neil Raden, of Smart (enough) Systems
blog at www.smartenoughsystems.com/wp
JT has comments on where the cutpoints for the decision service (biz rules engine) fits in my ontology, and here is my response:
Your refinement of my bulletpoint statement is good, we really do agree. I just see the decision service as conceptually being a part of the process, composition layer and the human task (workflow) layers, thus towards the top of my figure. I do not think Shy Cohen’s taxonomy ment for activity services to be the cutpoint for decisions, rather the process services.
In my opinion, the business capabilities delivered by a process stays relatively fixed, it is the flow of the process that changes most often and needs to be designed for agility. It is very important that the aspects of the system that needs agility most are the ones that need to be least expensive to change.
My main argument for the cost of change being higher for the lower layers are based on data contract (resources in JJD terms) changes; the more subscribers/consumers a set of activity and entity services have, the more impact introducing a new version of the serivce contract will have. And I think most solutions will involve coded compositions at the resource service layers, while the composition and business process layers will be declaratively designed.
Kjell:
thank you for the references. I also wanted to point you to a discussion I had with Dave Linthicum.
http://www.infoq.com/news/2007/07/soa-abstraction-layer
where we both argue that you rather need a "Logical Data Model" and not necessarily a "Common Information Model".
The argument really goes as follows:
- if you can have a CDM great
- but over time it is likely to diverge (the effort to keep a CDM is too big), so be prepared to maintain an LDM (or RDM= Reference Data Model) and use the LDM to create direct transformations from one interface to the other.
a) transformations with a CDM when the interfaces are aligned:
Cons. Ic | ---> none ---> Ip | provider
b) transformations with a CDM when the interfaces are not aligned:
Cons. | Ic --> X1 --> CDM ---> X2 ---> Ip | provider
c) transformations with a LDM:
Cons. | Ic ---> X ---> Ip | Provider
In gerenal you will end up in b) or c) and b) requires 2 transformations plus the cost of maintaining a CDM + LDM
In a given message (CDM) you tipically "project" the LDM into ways that are very specific to the interaction. A message typically may involve information from more than one business entity. A purchase order is going to have customer information. In LDM you maintain Customer and PO separately, in the CDM you are going to have a lot of message where the two business entities are convoluted.
IMHO, you also need to consider Master Data Management along side your architecture diagram.
JJ-
I have not suggested using a CIM or a Common Data Model (as in Gregor Hohpe's EAI CDM), but a canonical model of the message and documents belonging to processes and events within a business domain (plus using DDD bounded contexts and mappings when applicable). So I am with alternative C.
As the acronym CDM is so overloaded, I have previously used ECDM to differentiate this model from CIM and COMMON DATA MODEL.
After the discussions with you and DaveL last year I wrote several posts to describe ECDM (LDM) and how "ask for more" + reference data is central to keep the documents (Jack van Hoof: dossiers) as small as possible. The posts are all tagged with ECDM in my blog.
Thanks for the comment, I will add an end note to explain that the Canonical Domain Model is not CIM/EAI CDM.
apologies for mis-understanding. It often takes a single word !
I know, I did the same when Nick Malik first blogged about canonical models+schemas last year: http://blogs.msdn.com/nickmalik/archive/2007/06/12/canonical-model-canonical-schema-and-event-driven-soa.aspx
The words database and schema triggered me to think of the "one true schema" approach, which Steve Jones have disclosed properly: http://service-architecture.blogspot.com/2006/08/single-canonical-form-not-for-soa.html
Post a Comment