Frank Michael Kraft's Blog

I was recently asked if I like this idea: Handle everything, that is coded in an ERP systems today as Process Patterns and instead design it as process models, that can be adapted to the requirements of the customer. The context of the discussion was if the combination of ERP/BPM/SOA would not have tremendous potential.

I aswered, that I have experience with that and that I agree that there is a tremendous potential with that. That really was an interesting discussion, because I did not hear such analysis before in the discussions in the public marketplace. I think this is the right direction to think.

I had already governed the design of the process of about 200 or more business objects, creating about 2.000 models including roughly about 5.000 web service operations. I didn’t use BPMN for that, because it was not flexible enough for this purpose, neither any of the existing languages. I used an own Domain Specific Language (DSL) for Modeling the behavior of those Business Objects.

My summary of that exercise is, that I agree to the original question. Only by modeling the process of Business Objects which are part of the ERP system, the ERP system’s web services will as a result have the right granularity. What is the right granularity for web services? Reusability. If web services are reusable, then they pay off most. In order for them to be reusable, they need to fulfil certain conditions. A web service operation should only do one thing at a time., i.e. not trigger an endless chain of activities in the system. It should have clearly defined preconditions. The effects and results of the web service operations must be clearly defined in terms, that can also be preconditions to other web service operations. That are the most important criteria in my view.

A system must be designed for this philosophy from the beginning. I strongly believe that adding web services to an existing system falls short of this goal. Even if it has some value, it would not use the full potential.

In general what I miss in the public standards is a language to describe the behavior of web services. Yes, BPMN 2.0 goes into that direction. But BPMN 2.0 still has to prove that it can fulfil the promise in practice. I think to a degree it can. It will turn out later, if it is possible to simplify the language or if it becomes an inspiration for other approaches (e.g. constraint based instead of workflow based).  And using BPMN 2.0 in itself does not guarantee the success. Additional guidance is necessary, certain quality criteria that each model must fulfil.

However, if the behavior of web service operations of an ERP system is defined, and if the granularity of the web service operations are so, that they are reusable, then the potential is very big. Because it means, that it is possible to attach own processes to that ERP service and even to interweave own processes in-between ERP processes. For example to add an approval before the release of an order under certain conditions, to add an own method of calculating benefits for the payroll and the like.

However as a limitation to the original question I would say, that not all of the processes modeled could be customized or changed arbitrarily. There are certain core processes, that the ERP system offers, that can not be changed without the danger of losing the consistency of the process. Therefore it is clearly necessary to describe which part of the process needs to remain stable and which parts of the process can change or are open for additions and interweaving. This of course must be part of the model.

Today I wanted to do a little bit of CRM – manage my Leads. I asked myself how I could utilize Salesforce.com together with XING. I searched, but did not quickly find a ready-to-use integration.

Therefore I quickly extended Salesforce with what I wanted.

[View with PicLens]

It is a lightweight integration with minimum data redundancy. Within a matter of one hour I added four links into my Lead.

1. Link to XING Profile
2. Link to XING Group Membership
3. Link to XING Messages – Inbox
4. Link to XING Messages – Outbox

These Links are calculated from the Name of the Lead, so I do not need to enter them. The only thing I need to enter is the profile name in itself – in my example FrankMichael_Kraft. Probably this can be calculated as well – if I can confirm if they are constructed.

The resulting page is displayed within the salesforce Lead. I can interact with that page as well.

So I have minimum data redundancy: I need not to copy the correspondence into the lead for example. I just use Salesforce mainly to maintain the status of the Lead.

So what I like about the Salesforce approach to CRM is:

• There are ready-to-use Business Objects – I can start in a matter of minutes.
• It is relatively easy to add new fields and links.
• The new fields and links are operative immediately. No deployment, whatever. Just run.

What I do not like so much about the Salesforce approach to CRM (as of my knowledge of today):

• I’d prefer more a social approach to CRM. I disregard mass email production. This is my preference.
• It is not clear to me how Lead Activities integrate with Email outside of Salesforce CRM.
• To add a Link you have to manually add it to every (in my example 4) layouts to be complete.
• I first missed the link construction syntax. However there was no errormessage. Just no page displayed.
• In the customization of Leads it promises to be able to change the Lead Process. But all you can do is to remove one or more of the 4 predefined statuses. This is much less than I expected.

However I am quite happy about this lean solution, that I can use right away.

On the BPMN & XPDL Industry Day of the WfMC Thought Leadership Summit one topic of discussion was the current status of BPMN Diagram Exchange.

In the BPMN 2.0 Spec there is a proposal, that builds on a generic OMG proposal, which is not finalized and which will be standardized independent of the BPMN 2.0 standardization.

In this proposal the idea is to have a Diagram Interchange Model independent from the Domain Model, which is in my opinion, a good idea. It is generic, so that other diagram types could be modeled. The diagram validation is done agains a so called Diagram Definition Model, which is also new. The Diagram Definition Model defines, which Attributes a Diagram Interchange node or connector can have, the allowed references and additional (OCL) constraints. Furthermore each Diagram Interchange node or connector is refers to a Domain Model class – in this case a BPMN Task or Gateway or Sequence Flow for example.

Advantages I see:

• Seperation of Model and View – Model maintenance
• Multiple Diagrams for the same underlying BPMN model are possible
• Generic format for different diagram types – tools can use synergies

Disadvantages I see:

• Tools vendors can not use XSD validation. They have to implement the validation against the Diagram Definition.
• The constraints of the Domain model (e.g. Sequence Flows can only be connected to …) must be repeated in the Diagram Definition Model.
• Grafical Attributes (e.g. line thickness) must be repeated as per modeling element.
• Attribute Format (name / value) too generic in my view.

The XPDL Format used to include the Graphics Info into the Elements of the Domain model.

This is simple and straight, and current tools support it, but has the disadvantage, that it is not possible to have one modeling element (e.g. one process) appear in different diagrams. Instead, the modeling elements must be repeated as per diagram, which has many disadvantages in model execution, analysis and model driven development. The Signavio modeler, which was discussed at the meeting, follows the same approach. However it is good as long as only diagrams are drawn for visualization purposes.

Because the BPMN Digram Exchange Proposal was too generic for some, Bruce Silver proposed an BpmnDI.XSD for a concrete XSD validation.

This approach repeats basically all or many BPMN domain modeling elements. This of course is the disadvantage, because it is but a redundant repetition of the already defined domain model. However it is no complete repetition, because the gateway type for example is not included. So a tool must look into the domain model anyway to render the gateway.

Within this discussion it came to my mind, how the GMF (Graphical Modeling Framework) solves this question. I think it is well worth to have a look at this approach, because I think it may be a good compromise.

The GMF defines a Grafical Definition Model, which only defines Shapes. This is simple to understand and straight. Then it defines a Mapping Model. Within the mapping models, nodes and connections are grouped as needed. For example it defines, that there is a node lane which can contain node Activity and Sequence Flow. As a followon the Acitivty node is connected to the Activity domain class and the Shape, that descibes how an activity should look like. The shape can be re-used, which is an advantage of the BPMN Diagram Exchange Approach. The Structures of the Diagram is already contained in the Mapping Model, so it can be serialized to XMI and XSD, which is also an advantage. However still the diagram logic is separated from the Domain Model, which is an advantage over XPDL. And it is a very generic model, which is an advantage over a mere BpmnDI.xsd.

I personally worked with the GMF, and found it quite practical. I am not proposing to use GMF per se, but maybe the approach should be further considered.