Voor vele organisaties is de voornaamste reden om te investeren in een service oriented architecture (soa) het verhogen van de flexibiliteit van de organisatie.
Als bestaande bedrijfsprocessen, zoals de verwerking van een uitkeringsaanvraag, de afhandeling van een bestelling, of de betaling van een factuur aangepast moeten worden, is het niet altijd evident hoe die gewenste veranderingen geïmplementeerd moeten worden. Veel bedrijfsprocessen zijn verstopt in handmatige handelingen en deels in geautomatiseerde systemen. Bedrijfsprocessen zijn alleen snel te veranderen als ze expliciet zijn.
Bovenop een soa kunnen we een laag met geautomatiseerde bedrijfsprocessen implementeren die daarna zeer expliciet aanwezig zijn. Dit maakt de organisaties flexibeler. Als het werkelijke bedrijfsproces veranderd moet worden om in te spelen op nieuwe mogelijkheden in de markt of vanwege vernieuwde regelgeving, dan is het duidelijker waar ingegrepen moet worden. Er zal bijvoorbeeld ergens een stap in het bedrijfsproces aangepast moeten worden, er moeten stappen toegevoegd worden, of bepaalde beslissingspunten moeten misschien anders opgezet worden. Dit soort veranderingen kan er weer toe leiden dat we bepaalde services moeten toevoegen of veranderen. Uiteraard moet dit wel gebeuren, maar wat er moet gebeuren is helder. En daar ligt een groot voordeel van het werken met geautomatiseerde bedrijfsprocessen en een soa.
De meest geïmplementeerde taal om bedrijfsprocessen te automatiseren is momenteel Bpel (Business Process Exucution Language). In deze taal kunnen we bedrijfsprocessen als programma’s formuleren. Er zijn al vele producten op de markt die in staat zijn deze Bpel-programma’s te verwerken, de zogenaamde Bpel-engines, ook wel orchestration engines genoemd. Deze engines zijn in staat om duizenden instanties van hetzelfde programma te draaien. Een instantie van het Bpel-programma ‘betaal-facturen’ is bijvoorbeeld het betalen van factuur 200512731.
Maar zijn Bpel-programma’s eigenlijk eenvoudig aan te passen? De programma’s zelf wel, dat is slechts een kwestie van de code een editor binnenhalen, de code bekijken en de wijziging doorvoeren. Dat is inderdaad eenvoudig. Maar hoe staat het met de engines? Programma’s zijn vaak langlopend. De verwerking van instanties van een Bpel-programma kan wel twee maanden duren, zeker als het proces manuele handelingen bevat. Indien er van een bepaald Bpel-programma dan tweeduizend instanties bestaan die zich allemaal in een bepaalde status bevinden, wat gebeurt er dan als we het programma aanpassen? En hier zit de uitdaging.
Indien u van plan bent een Bpel-engine aan te schaffen, bestudeer dit aspect dan zeer grondig. Wat gebeurt er met de lopende instanties van een Bpel-programma, indien laatstgenoemde veranderd moet worden? Betekent dit dat die allemaal gestopt moeten worden? Dat zou een onacceptabele oplossing zijn. Moet er een aangepaste kopie van het programma geïmplementeerd gestart worden? Als we hiervoor kiezen bestaat er geen relatie meer tussen de oude en de nieuwe versie van het Bpel-programma en wordt rapportage over de bedrijfsprocessen door de tijd heen lastig en misschien wel onmogelijk. Dat is dus ook niet de gewenste oplossing, maar dit is wel hoe het in veel producten helaas geïmplementeerd is. De betere oplossing is dat de engine weet dat er een nieuwe versie van het Bpel-programma bestaat en dat beide versies tegelijkertijd kunnen draaien en dat er gerapporteerd kan worden over de twee versies heen.
Soa’s worden gebouwd om de flexibiliteit van organisaties te verhogen en Bpel moet die flexibiliteit voor een groot deel leveren. Het is dan wel belangrijk dat de engines ons niet beperken. Bestudeer daarom dit aspect bij het selecteren van producten. In hoeverre beperkt de technologie ons om de beoogde flexibiliteit te halen?
