Als een bpms op zich geen fexibiliteit oplevert, hoe kan ik de gewenste flexibiliteit dan bereiken? In mijn vorige post ben ik ingegaan op de misvattingen rond de vermeende verhoogde flexibiliteit als gevolg van de inzet van een bpms. In dit deel wil ik kijken hoe het dan wel mogelijk is de gewenste flexibiliteit of 'agility' te bereiken, of in elk geval, wat ertoe kan bijdragen.
In essentie gaat het bij flexibiliteit om het tijdig kunnen doorvoeren van wijzigingen. Vanuit die stelling wil ik de factoren benoemen die de flexibiliteit beperken. Het doorvoeren van een wijziging kan leiden tot allerlei problemen zoals de wijziging heeft onvoorziene gevolgen, waardoor de gebruikers hun werk niet meer kunnen doen, instabiliteit, verlies van data, etc.
Gezien deze risico's is het logisch dat (ict-) organisaties een drempel opwerpen voor wijzigingen en eisen stellen aan elke oplevering. Dit kan echter doorslaan, waarbij opleverprocessen zo complex en bureaucratisch worden dat voor elke oplevering er een weken- of maandenlang traject nodig is voor de wijziging in productie kan worden genomen. Ook bpms-processen ontkomen niet aan dit proces.
Vanwege dit kostbare proces wordt er vaak gewerkt met een releasekalender, waarbij er slechts een aantal maal per jaar een oplevering kan worden gedaan. Afhankelijk van de doorlooptijd van het proces gaat het dan vaak om tien maandelijks releases of drie (!) kwartaalreleases. Wat je zou kunnen winnen door feitelijk sneller software te kunnen aanpassen verlies je op deze wijze aan de achterkant.
Dit is in mijn ogen flexibiliteiskiller #1. Als er meer flexibiliteit nodig is zul je dus dit probleem als eerste moeten aanpakken door te kijken waar het proces is doorgeslagen in bureaucratie. Dat vereist voor alles een ict (beheer-) organisatie die klantgericht is en getraind is op het omgaan met wijzigingen. Daarbij is het ook van groot belang dat er een goed functionerende change advisory board (CAB) is, die een goed overzicht heeft van het ict-landschap en de gevolgen van wijzigingen.
Nu is het uiteraard niet voor niets dat deze processen zijn ontstaan en is het dus ook belangrijk om maatregelen te nemen die ervoor zorgen dat wijzigingen geen onverwachte problemen veroorzaken.
Oplossing #1 daarvoor is: Verhoog het vertrouwen in de wijziging door uitvoeren van geautomatiseerde regressietests. Door een automatische, bij voorkeur 100 procent dekkende regressietest kan met een veel hogere mate van zekerheid gezegd worden dat een bepaalde wijziging geen onverwachte gevolgen heeft en kan dus een hoop bureaucratie en schijnzekerheid worden voorkomen. Bij uitbreidingen/aanpassingen zal deze regressietest dus ook uitgebreid/aangepast moeten worden. Een automatische regressietest geeft in 100 procent van de gevallen een verbeterde softwarekwaliteit en in 99 procent van de gevallen kunnen hierdoor onverwachte issues worden voorkomen.
Probleem # 2: Wat ik regelmatig zie is dat de medewerkers die verantwoordelijk zijn voor onderhoud op een applicatie niet betrokken zijn geweest bij de bouw van deze applicatie. Vaak krijgen ze deze verantwoordelijkheid vanuit een achterstand in kennis en vanuit die positie kunnen zij onmogelijk met gezag de impact van wijzigingen juist inschatten en met 100 procent vertrouwen deze doorvoeren. Dit kan alleen voorkomen worden als applicatieonderhoud integraal wordt meegenomen in het planningsproces. Met andere woorden, het is cruciaal dat er ontwikkelaars en applicatiebeheerders met voldoende kennis en ervaring beschikbaar zijn, maar ook dat er voldoende betrokkenheid is van een applicatiearchitect die ook bij de bouw betrokken was. Alleen als de verantwoordelijke medewerkers met autoriteit uitspraken kunnen doen over uitbreidingen en wijzigingen, kan je daarna met minimaal risico en korte doorlooptijden deze uitbreidingen en wijzigingen ook doorvoeren.
Last but not least, het architectuurontwerp van een oplossing heeft grote impact op de flexibiliteit. In een goed architectuurontwerp wordt aanpasbaarheid vanaf het eerste moment meegenomen als ontwerpcriterium. Mijn advies is om daarbij te denken in schillen met aflopende configureerbaarheid en aanpasbaarheid:
De buitenste schil bevat die delen van de applicatie die door de functioneel beheerder per direct gewijzigd moeten kunnen worden zonder tussenkomst van een softwareontwikkelaar. Dat kan door stuur- en configuratieparameters op te nemen in een database en eventueel hiervoor ook specifieke schermen voor de functioneel beheerder op te nemen.
De tweede (optionele) schil bevat bedrijfsregels, die door de functioneel beheerder ondersteund door de applicatiebeheerder kunnen worden aangepast. Deze laag wordt vaak ingevuld met behulp van een business rules engine en geeft meer flexibiliteit, maar ook een grotere kans dat er fouten in de hier vastgelegde bedrijfsregels sluipen. Daarom is het in de meeste gevallen wenselijk om wijzigingen te testen voor deze in productie worden doorgevoerd. Anderzijds vereist deze wijziging geen software-installatie en kan dus zonder ict-aandacht worden doorgevoerd.
Voor diepere schillen zijn er zoveel technische smaken en varianten dat het onmogelijk is ze allemaal te beschrijven. Ik wil hier graag een voorbeeld geven vanuit een project waarin ik betrokken ben om te illustreren hoe aanpasbaarheid hier kan worden ingevuld. In dit project worden xml-berichten verwerkt en op basis daarvan een centrale Oracle-database met transactiegegevens gevuld. Hierbij wordt gebruik gemaakt van een enterprise service bus (esb) voor berichtroutering en -transformatie, in combinatie met Toplink-database-adapters voor het uiteindelijk opslaan van de resulterende gegevens. Nu is het niet moeilijk om de esb-configuratie of database-adapters aan te passen, maar het doorvoeren van een wijziging in die delen vereist wel het tijdelijk onderbreken van de verwerking van de applicatie voor een deployment. De laag die het mogelijk gemaakt heeft om snel, flexibel en zonder onderbreking te reageren op wijzigingsverzoeken is een PL/SQL-laag rond de database. Wijzigingen in die laag kunnen, na test in de acceptatieomgeving, in veel gevallen on the fly in de productieomgeving worden doorgevoerd.
Samenvatting
Merkwaardig genoeg hebben de meeste problemen en oplossingen niets te maken met de inzet van specifieke tooling als een bpms. En dat is voor mij meteen een bevestiging dat omgekeerd de inzet van een bpms geen invloed heeft op flexibiliteit. Er zijn hier vast nog meer factoren te benoemen die de flexibiliteit beïnvloeden. Ik hoor graag van je als je deze lijst wilt aanvullen en natuurlijk ook als je anderszins wilt reageren op deze post.
