What to put in BPM?


When implementing a BPM or using a BPM tool I see a lot of functionality that (in my opinion) does not belong into that layer, but within a SOA Service.
But are there some general rules or guidelines that you use to decide what to put in BPM and what to put in a Service?
This blog item is a first try.

Put in a Service

This is a list of items/functionality that I would put in a Service:
  • Static calculations not dependant on business data (example: Fahrenheit to Celcius calculations)
  • High performance / complex calculations on data (example: complex calculations over series of data)
  • Technical orchestrations (example: Getting data out of several different databases)
  • Sending messages (in a particular format) to another department or even another organization (B2B)
    (example: ebXML messages, HL7 messages)
  • Adapters (example: database-, file-, mailadapters)
    These are always implementation specific in most cases and the implementation should be abstracted with a service.
    However in most cases you will see these adapters used within the BPM tools.

Put in a BPM

This is a list items/functionality that I would put in a BPM:

  • A step in a business process implemented in a Service operation or sub process.
  • Scheduled triggers to execute a business process (example: every day execute a particular business process)
    You can put the schedule in a business rule to make it flexible
  • Steps / Activities that mean something to the business
    Remark: Discuss in depth because even business people dive into technical details.

You are invited to increase the list !


I think there will remain discussions where to put which functionality. With the BPM tools nowadays you can use integration software that you do not want in the BPM layer, like
a database adapter or file adapter. This should be put in a Service and abstracted. However time-to-market and ease of implementation is often a (maybe valid) argument to
do it like this. But hope you take a step back and think about it when you use a BPM tool because also with this tool you can make spaghetti !
And last but not least: Do not use a BPM tool as just another visual programming tool


  1. Dear Roger,
    I fully agree on your vision.
    I strongly believe BPM is a powerful tool, but it's not the panacea for all the problems of the world.
    Thus, analysts and designers should have a clear vision of the separation of concerns in a complex project. Your suggestions make perfectly sense.
    From my experience, I would further separate some additional dimensions, that I think are completely orthogonal to the two you mention:
    - DATA MODELING: contents and data are an asset of the enterprise and a basis for the additional layers (services and APIs, and also BP models)
    - USER NAVIGATION AND INTERACTION MODELING: more and more BP are nowadays involving user interaction on the Web. In one sense, this is definitely a plus since it covers a crucial need of the enterprise (and goes in the direction of BPEL4People and similar initiatives). On the other sense, it must be kept clearly separate and must be addressed as a complementary but orthogonal aspect.
    - VISUAL PRESENTATION: this is a further layer, which can be simply "painted" upon the previous one (like a CSS in html).

    To support this vision, we developed the WebML language (http://www.webml.org) and the WebRatio toolsuite (http://www.webratio.com), which combines these different dimensions in a set of models and provides code generation features. The approach proved to be successful so far (see also our presentation at BPM 2010: http://www.slideshare.net/mbrambil/web-ratio-bpmindustrialcasesbpm2010), but we would be glad to get feedback from external experts..

  2. Just experienced also today:
    DO NOT put time intensive calculations within a BPM tool. Probably it will not have the performance that you expect!