Doorgaan naar hoofdcontent

What to put in BPM?

Introduction

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 !

Conclusion

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
Labels:

Reacties

  1. Unknown12 oktober 2010 om 23:29

    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..

    BeantwoordenVerwijderen
  2. Roger van de Kimmenade14 oktober 2010 om 10:48

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

    BeantwoordenVerwijderen
  3. Ysorsuporo23 april 2022 om 16:54

    Ysorsuporo Kelly Campos https://wakelet.com/wake/HK0fkRePAoWsCm-htw5cI
    ulmicootu

    BeantwoordenVerwijderen
  4. Wvenvodiubi1 augustus 2022 om 01:04

    saupromZteo_he Jessica Gilmore link
    click here
    download
    click
    ommeperthough

    BeantwoordenVerwijderen

Een reactie posten

Populaire posts van deze blog

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h...
12 reacties
Meer lezen

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .
48 reacties
Meer lezen

Book review: Data Management at Scale (Piethein Strengholt)

 This blog is a review of the book "Data Management at Scale (See also at bol.com ) Data Management is a hot topic nowadays and this book does a fantastic job at adding value to this topic. It is a must read and one of the few technical books I finished reading in a weekend. The book gives a fantastic overview on how to implement a Data Mesh data architecture. The Data Mesh concept is explained by Martin Fowler here . The book is a good mix between conceptual and implementation architecture level. It gives a lot of examples of how this architecture at scale can work, for both small and big companies. It is practical and I used it to implement it at one of my customers. The book describes an architecture in which the focus is on the DIAL (Data- and Integration Access Layer).  On a high level the book covers the following topics: The key principles for data management at scale - Domain-Driven Design  - Domain Data Stores - Meta data management Ready Data Store The concept ...
5 reacties
Meer lezen