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, likea 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
Dear Roger,
BeantwoordenVerwijderenI 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..
Just experienced also today:
BeantwoordenVerwijderenDO NOT put time intensive calculations within a BPM tool. Probably it will not have the performance that you expect!
Ysorsuporo Kelly Campos https://wakelet.com/wake/HK0fkRePAoWsCm-htw5cI
BeantwoordenVerwijderenulmicootu
saupromZteo_he Jessica Gilmore link
BeantwoordenVerwijderenclick here
download
click
ommeperthough