BPM en de architectureluur

Een vraag:

"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.

De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."

Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.

Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.

Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.

Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.

Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.

Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.

In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.

Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.

Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.

Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.