The semantic BPI "data" model is focused on the business events, messages and documents (data) and the semantics of the business events and processes that the model encompasses. The model is targeted at the process service composition layer, not at the resource services layer; as shown in the figure (click to enlarge):
A note on the splitting of the resource layer services: this is a pure metadata ontology based on a taxonomy for categorizing services, it is not a split based on technology, teams or layers.
I named the BPI information model the "event canonical domain model" (ECDM), inspired by Jack van Hoof and Nick Malik. I like to use a domain model as it by definition focuses on the concepts of the problem domain (the business process information artifacts) rather than just the data of the domain. The term event is used in a broad sense to comprise the messages for the action, query and notification events that drive the business processes. The model must be canonical for its domain to ensure that the format and semantics of the model is consitent within the domain.
There is some confusion on the difference between the BPI ECDM and the EAI "canonical data model" (CDM), plus the similar Common Information Model (CIM). As can be seen from the comments on the two postings and some blog reactions like SOA doesn’t need a Common Information Model, this has made it harder to convey the difference between the BPI ECDM and the more data-oriented models.
A CIM should be used for the resources data model - which the ECDM is related to. The data in the BPM document for the action event "CustomerHasMoved" is not a complete "Customer" resource entity, it is data of message type "AddressChange". This data is of course associated with the CIM of the underlying resource services. The ECDM message types are projections of CIM objects; in fact, they are projected compositions of the referenced resources - not just simple compositions of resource objects.
The CIM should be the starting point of your modeling efforts, in combination with Business Process Modeling Notation (BPMN) diagrams, as BPMN encompass process, events, messages and business documents. Other process modeling diagrams can be used, just ensure that the events, messages and data are captured in the model.
It is still important to recognize that having a "one true schema" for BPI or SOA in general is not a recommended practice, hence the DDD term "domain" in the naming. Rather than trying to enforce a common model across all BPI domains, federated models should be used. When composing services across the domains, mediation and transformation of messages will be required.
A thing to recgonize is that the overall model incorporates several "flows": process flows, event flows, message flows, and data state flows (resource lifecycles). Typically, only the process flow is clearly shown in diagrams, while e.g. message flow is only represented by receive and send ports. See this interview with Gregor Hohpe on Conversation Patterns about how more than just the process need to be modeled.
For an excellent primer on architectural aspects of SOA and the proliferation of acronyms, I recommend reading Architecture requirements for Service-Oriented Business Applications by Johan den Haan. Note that he does the classical simplification of focusing on business processes without including a ECDM; it is important to separate the BPI model from the resource model, just as business processes are separated from resource lifecycle processes. The BPI events, documents and messages are not just collaterals of the BPMN modeling process, they are important artifacts for semantic mediation in composite services.
[BPI: "e-Business: organizational and technical foundations", Papazoglou, M. P. & Ribbers, P. (2006)]
Posts
0 comments:
Post a Comment