Een lezer vraagt zich af:
"Wat is in je verhaal precies de scope van "architectuurlogica"?
In welk begrip zit alles wat met BPM te maken heeft? BPM omvat in legacy applicatie veel code en is m.i. niet herbruikbaar."
De bedoelde post ging over Asterix en de business-logica.
1. architectuurlogica: daarmee bedoelde ik dat dele van de code dat ontstaat omdat een bepaalde architectuur wordt toegepast. Dus bv database-benadering, schermopbouw, in juiste formaat gieten van parameters voor een RPC, vertalen van EDI-berichten, code nodig om een EJB goed te laten werken, enzovoort, enzovoort. In de praktijk is dit een heel groot deel van de code. De eigenlijke business-logica zelf is zo gecodeerd, en de rest is "het laten werken". Dat is "architectuurlogica".
BPM-logica in de strikte zin des woords is business-logica. En dat is niet zo'n groot deel van de code, alleen lijkt het veel omdat daar de verknoping met architectuur-logica nog sterker is.
2. is BPM-logica niet herbruikbaar? Dat weet ik nog zo net niet. Het probleem van veel systemen waarin BPM-logica expliciet is opgenomen, is dat er allerlei zaken in zitten die daar helemaal niet horen. En omdat de BPM-laag van het gemiddelde systeem niet is ingericht op hergerbuik en vermijding van redundantie, is het gevolg dus; redundantie.
Het begint er al mee dat de "business-rules" vaak in de BPM-laag worden geevalueerd. Dat is in verreweg de meeste gevallen helemaal niet nodig, sterker: onhandig, maar het gebeurt toch. In dat soort systemen is de laag onder de BPM-laag meestal niet veel meer dan een veredelde database. Naar mijn idee zijn dat gewoon slechte architecturen.
Als een systeem goed wordt ontworpen, met het "gedrag" (in de zin van object behavior) op de juiste plaats (dwz in de meeste gevallen; bij de data), dan blijkt de BPM-laag helemaal niet zo ingwikkeld en dik te zijn.
Daar komt bij dat ook binnen een BPM-laag doorgaans meer hergebruik mogelijk is dan doorgaans wordt ontworpen.
Samenvattend: ik denk dat er wel degelijk veel hergebruik mogelijk is in het BPM-deel, voor een groot deel door logica in ddat BPM-deel daaruit te halen.
Abonneren op:
Reacties posten (Atom)
1 opmerking:
De BPM laag fascineert me wel (zie ook post "Functionaliteit uit de muur" en de antwoorden die je daar geeft op mijn vragen).
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.
Rik L.
Een reactie posten