Overige tips
Deze pagina is nog in volle opbouw. De content hieronder is dus onder voorbehoud.
Besef dat processen langlopend kunnen zijn
De duurtijd van een proces strekt zich uit over meerdere dagen, weken of zelfs maanden. Dit betekent dat je na verloop van tijd met enkele tientallen tot honderden actieve processen en dossiers zit. Stel dat je op dat moment nog wijzigingen wil aanbrengen in de BPMN-definitie of in één van de betrokken configuratie-items, dan is dit absoluut niet voor de hand liggend.
Volgende tips kunnen je helpen:
Lees de uitgeschreven documentatie rond backwards compatibility.
Breng via een risicoanalyse in kaart welke functionaliteiten het meest voor wijziging in aanmerking komen. Wat zijn de mogelijke wijzigingen die je kan verwachten en hoe kan je daarop anticiperen? De oplossing is om deze zaken te isoleren en te expliciteren.
Bijvoorbeeld: bij een procedure delen we dossiers in volgens categorieën. Het is verstandig om de toewijzingsregels te expliciteren in een beslissingstabel.
Bijvoorbeeld: er zitten heel wat timers in het proces die van elkaar afhangen en dus ook op elkaar afgestemd moeten worden. Ook in dat geval kunnen we enkele globale variabelen definiëren via een beslissingstabel en vervolgens op basis van die variabelen alle timers dynamisch uitrekenen binnen het proces.
Zorg dat je het volledige end-to-end proces grondig test en valideert vooraleer je de dienstverlening in productie brengt. Alles staat of valt hier met een efficiënte projectwerking: duidelijke scope, rolverdeling, doelstellingen, definitions of done, enzovoort.
Zorg voor een release strategie die je op voorhand afspreekt met de business owner. Hot fixes krijgen altijd absolute prioriteit, maar dat geldt niet voor extra functionaliteit toevoegen of correct werkende functionaliteit wijzigen.
Vermijd misbruik van de workflow engine
Een workflow engine is in de eerste plaats bedoeld om een proces te orchestreren en de exacte status ervan bij te houden. In principe speelt de engine zelf geen actieve rol binnen het proces, d.w.z. het mag al het gedefinieerde werk niet zelf uitvoeren. Vergelijk het met een coach die aanwijzingen geeft aan zijn of haar spelers, maar zelf niet actief deelneemt aan het spel. Of met een dirigent die het orkest aanstuurt, maar zelf geen instrument bespeelt.
Althans, dat is de theorie. In de praktijk is het echter onvermijdelijk dat de workflow engine zelf ook enkele taken moet uitvoeren. Denk aan het samenstellen en uitsturen van een call naar een externe service, het aanspreken van interne Skryv functies met daarbij het uitrekenen en meesturen van de benodigde input parameters, het opvangen en afhandelen van errors, het evalueren van conditionele expressies in het kader van gateways, enzovoort.
Probeer deze taken echter zo veel mogelijk te beperken tot achtergrondtaken die nauw aansluiten bij de orchestratieopdracht van de engine. Vermijd om hier ‘echte’ taken met grote businesswaarde in uit te voeren. Deze moet je uitbesteden aan ofwel menselijke gebruikers (via de gebruikerstaken, denk aan het invullen van een formulier) ofwel (externe) services (denk aan het authenticeren van gebruikers, uitsturen van mails, uitvoeren van betalingen, enzovoort).
Door gebruik te maken van het Skryv platform word je hierin automatisch al op goede weg geholpen. Toch heeft elke applicatie specifieke noden en zal je op een bepaald ogenblik voor de keuze staan om taken al dan niet binnen de workflow engine uit te voeren. Hou dan zeker bovenstaande redenering in gedachten.
Ga voor ontkoppeling en decentralisatie
Nauw samenhangend met vorig punt zijn de principes van onkoppeling en decentralisatie. Dit slaat op de architectuur van je totale oplossing, d.w.z. het ‘end-to-end process'.
In het verleden, toen software nog erg gebonden was aan on-premise hardware zoals servers en netwerken, was het gebruikelijk om zoveel mogelijk functies binnen één domein of zelfs applicatie onder te brengen. Op die manier ontstonden ‘monolieten’ die moeilijk onderhoudbaar waren. Ook ontwikkeling was lastig, omdat aanpassingen in één component direct ook aanpassingen in andere componenten vereisten. Organisaties werden zo op den duur erg afhankelijk van een handvol interne IT-experten, want ‘enkel zij weten nog hoe alles in elkaar zit’. Typisch zie je na verloop van tijd de plotse beslissing om alles in één keer op de schop te nemen en te vervangen door een nieuw systeem. Dit vergt meestal een grote inspanning waarvan de duurtijd en de kostprijs systematisch onderschat wordt.
In een moderne setting is software minder gebonden aan hardware. Systemen bestaan uit verschillende ‘services’ die gedecentraliseerd zijn (d.w.z. ze worden niet aangestuurd vanuit een centrale applicatie of 'commandocenter') en die niet noodzakelijk gebonden zijn aan lokale hardware (denk aan de vele cloudservices vandaag beschikbaar). De services zelf vertonen een hoge mate van interne cohesie (doe één iets en doe het zo goed mogelijk), maar zijn voor de rest maximaal ontkoppeld van elkaar. Communicatie gebeurt typisch via API waarbij de communicatielogica volledig ingebed zit binnen de service (slimme endpoints), d.w.z. elke service moet goed weten wat het voor elke andere service kan betekenen. Dergelijke systemen zijn makkelijker te beheren. Services zijn apart onderhoudbaar, kunnen zich onafhankelijk van elkaar ontwikkelen, zijn afzonderlijk vervangbaar zonder grote impact op de stabiliteit van het systeem, en kiezen hun locatie daar waar ze de gepaste resources vinden (denk aan serverless cloud computing waarbij rekencapaciteit instant opgeschaald kan worden in functie van de actuele vraag, denk aan opslag van gevoelige data op een private cloud of aan webapplicaties die maximaal toegankelijk zijn voor menselijke gebruikers). Een dergelijk systeem is doorgaans robuuster, kan makkelijker schalen en heeft een potentieel veel langere levensduur.
Doordacht gebruik van extensies en customizaties
De kracht van het Skryv platform is dat de ontwikkeling, het onderhoud en de ondersteuning gecentraliseerd aangepakt wordt. Regelmatig worden er nieuwe versies uitgebracht