Ontology for Business Processes, SOA and Information Models

I have for a long time promoted that you should apply a specific kind of information model (the business process information model - BPIM) when composing services into business processes in service oriented solutions. A BPIM models the messages for the business events that drive the business processes. The main goal of this information model is to enable coordinated loose-coupling (semantic mediation) between the services at the composition level.

There has been a lot of discussions on how the BPIM relates to SOA services and the common information model (CIM), and how the BPM process layer relates to the SOA process layer. In the following ontology I have tried to model the relationships between the documents and the domain objects, Shy Cohen’s service taxonomy & ontology, and Jean-Jacques Dubray’s SOA+BPM ontology. 

The service classification scheme has the "hierarchy" taxomomy form. It is not a scientific hierarchy nor a tree form, thus there is no "is using" or "is dependent on" relation between the services - it is just a classification scheme. There can be no dependency between services in SOA except for composite services realizing a business process by consuming the actual services. Taking a dependency on another service will break the central "services are autonomous" tenet of SOA.

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 (bottom), and the human-driven business processes realized as composed services (top). These two levels are separate bounded contexts with well defined mappings between them: the business process domain and the resource lifecycle domain.

The BPIM is applied at the business process domain level (orchestrations / composites / sagas), while the services operate on the domain objects in the CIM to manage the lifecycle of these resources in accordance with the business events.

Note that the BPIM is related to, and is a subset of/reference to, the resource domain objects in the common information model (CIM). In addition, the messages covers more than just activity data, they also contain queries, notifications (events) and commands. This in 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 BPIM 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 business process messages (action, query, notification) driving the composite services and the resulting business events are central artifacts when designing the services and the information model. 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, getting too much focus on business process flow.

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 business processes (mashup style compositions) and composite services rather than having to constantly make changes to the services themselves, 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 flow of the business processes and composite services. 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 service business logic, avoid leaking domain logic into the orchestration layer at all cost.

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 business process driven SOA 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.

SOA, EDA, CEP, BPM

While I have been in Redmond the last three weeks learning my true color (I'm hyper green btw), there has been some interesting posts by Joe McKendrick on some topics that I've written about the last year:

• Convergence of SOA+EDA+CEP
• SOA and BPM - automation and humans
• Removing "complex" from CEP

Long time readers of my blog knows how I strongly advice applying EDA thinking when designing service-oriented solutions, but I do not foresee CEP to become a commodity for quite some time yet. However, it would be nice if designing systems around business events could provide better insight on how BPM relates to SOA in practical terms, along the ontology presented last december by Jean-Jacques Dubray.

Modeling Business Processes for SOA, don't forget the Information Model

Recently I have done a few architecture reviews at customers struggling to get their SOA efforts going. The common problem of these attempts on service-enabling legacy systems to support agile business processes have been - except from system designers not grasping that SOA is in fact a paradigm shift from invoking-operations composition thinking, and those using RPC over web-services - that they focus solely on business process management (BPM) modeling. From this model they try to identify services without having a taxonomy for classification of services (activity services, information services, composite services), struggling with service granularity and how to identify what goes into the message and data contracts.

The problem is that modeling your business processes typically misses out on the central building block of service-oriented solutions: the data and the semantics of the data as related to the business processes. This is typical for workflow models like the 'UML Activity Diagram'.

The data should represented by a Common Information Model (CIM). 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. Based on the CIM, you must then design a business process information model (BPIM) for each business process domain. Then you could follow the SOA mantra coined by David Linthicum: data-service-process (much like the TDD red-green-refactor) and create mashups based on composite services. 

Last week Jean-Jacques Dubray posted an article about 'The Seven Fallacies of Business Process Execution'. The article contains a lot of good points about the 'case-tool grail' dreams about business people doing agile modeling in BPMN and then just generating systems that automates the business processes.

The really interesting part of the article is in 'Fallacy #5: Business Process Execution' where Jean-Jacques differentiates business objects (resources) and their lifecycle from the business processes that drives the lifecycle of the resources. The article explains how the data aspects are missing from BPMN even if it is the most important part of the business - just the problem I see so often.

Another point made in the article is that it is the resource lifecycle events that are important when trying to identify the services that your business process will depend on. The business events advance the business data through a state machine until the end of the business process. This is what Jack van Hoof, Nick Malik, myself and others have blogged a lot about this year: it is the business events and their message and data (documents) that are the key artefacts in your modeling efforts when creating a service-oriented architecture.

The article also shows how process service composition (orchestration of service execution and resource lifecycle management; BPEL) is different from user-centric business processes (human workflows and tasks; BPMN, WS-HumanTask, BPEL4People).

The article goes on to discuss how development is the glue that joins the different artifacts that constitutes a SOA. Developers are needed to actually implement the BPMN using the provided services. I strongly agree. Even if you could do BPMN to BPEL code generation, professional testing and QA in a development-staging-production environment is still a must. I will only go as far as to allow business people manage a set of goverened business rules, never directly implement any process (i.e. declaratively configure the diamond shapes in flow charts). Read more about business rules/decision service at James Taylor's blog.

Finally, the need for a durable 'composite service container' for the orchestrations is also something that is often disputed during my SOA reviews. "Command-and-control" developers rarely consider how the availability of autonomous services affects the fault-tolerance in the overall SOA solution. The question I always ask is: "What is the availability of a business process that composes five services that each have 99% availability? Is it 99%?" The answer is of course less: 95%. This is where a container for providing long running + reliable processes and 'resource' state machines comes in handy.

I recommend that you read and, most importantly, understand the concepts and the architecture blueprint presented in the article. I have to give Jean-Jacques a big credit for the good figures he has made to illustrate the taxonomy and ontology presented in the article.

Enterprise Architects, Top-Down SOA

I had hoped that the age of non-programming architects was over, but yesterday I was let down. I attended the monthly meeting at the "Practical SOA forum" at SINTEF where an experienced architect ("20+ years of IT experience") presentet his groups work at a large public service company in Norway. The architect explained the EA modelling work going on to build a service-oriented enterprise, showed the EA tool and portal, documented SOA guidelines, refinement of the model into BPMN (but not into BPEL), etc.

All systematic and professional, but then he went on to complain about having to spend too much time with the developers and hired consultants to help them actually understand and implement the model according to the guidelines and policies - which prevented him from playing (my word) with the model to refine it and expand it into new areas of the business...

No wonder many of the pure top-down approach SOA projects are regarded as failures.