Onderdeel van werken in de it is het bijhouden van nieuwe ontwikkelingen en het plaatsen van nieuwe hypes, trends, afkortingen, hippe frases en moderne termen in hun context. In dit stuk probeer ik enige gedachten te ontwikkelen over de combinatie van bpm met het fenomeen ‘Continuous Delivery (CD)’, let op de hoofdletters.
CD is een logische ontwikkeling in de Agile software development-wereld waarin een raamwerk geboden wordt om software releases op elk moment in de tijd en razendsnel en betrouwbaar, liefst vol automatisch, te kunnen opleveren in productie. In sommige gevallen wordt wel tientallen keren per dag een nieuwe versie uitgerold. Net als CD richt bpm zich ook op de wendbaarheid, maar dan niet zozeer vanuit de ontwikkelaarsgemeenschap, maar meer gericht op ‘business performance and operational agility’.
Een eerste gedachte zou dan kunnen zijn om CD en bpm te combineren waardoor zowel het ontwikkelproces als de business optimaal ‘Agile’ zijn. Maar als je iets dieper hierop ingaat, dan zijn er toch wat hindernissen. In mijn optiek staan bpm (en soa) namelijk enigszins op gespannen voet met Agile software development. Ik licht twee punten eruit, namelijk langlopende workflows en de tooling en techniek.
Een langlopende workflow definieer ik als een bedrijfsproces waarin een of meerdere stappen bestaan uit asynchroon berichtenverkeer, bijvoorbeeld als er op antwoord van een klant gewacht moet worden. Het aanpassen van zo’n proces in productie kan wel, maar is gebonden aan allerlei voorwaarden, zoals het in stand houden van verschillende versies van proces instanties. Voortdurend nieuwe software opleveren kan dan tot een warrige bedoeling leiden.
Het andere punt betreft de gereedschapskist. In de CD-wereld draait alles om deployment, integratie en testbaarheid, waarachter een wereld van scripting schuilt gaat, dit alles behoorlijk bottom up gedreven. In de bpm-wereld gaat het om high level modelling, uiteindelijk zelfs geschikt voor niet-programmeurs. In deze wereld is bijvoorbeeld automatisch functioneel acceptatie testen best complex en het automatisch doorschuiven van releases door de pijplijn van ontwikkelomgeving naar productie lijkt dan ook nog een brug te ver te zijn.
Een andere manier om ernaar te kijken is deze: bpm probeert de muur tussen it en business te verkleinen en CD (en zijn broertje DevOps) kijkt naar operations. Om goed met elkaar op te kunnen trekken is het verstandig om beiden in hun context te plaatsen.
Friso, ik zie de frictie niet zo, je moet de zaken echter wel scheiden van elkaar. Simpel voorbeeld: Je zit in de browser een tekst document te bewerken (bijv. Office 365, ZoHo of Google Apps). Dit is een langlopend proces. Het document (de content) is echter gescheiden van de software (de browser javascript applicatie). Zolang je de browser open hebt staan, ook als dit dagen lang is, zal zijn javascript en dus de applicatie niet upgraden. Pas als je de browser afsluit, opent en het document opnieuw weer ophaalt zul je het bestaande document met de zojuist vernieuwde applicatie openen.
Vertaald naar een BPM oplossing, dat de back-end of de software applicatie zelf veranderd hoeft niet per se impact te hebben op het lopende proces, zeker niet als dit aan elkaar hangt van webservices.
Wel zul je bij het DevOps gedeelte een instance van een server moeten laten lopen als deze bezig is met het verwerken van een bericht in een queue of moeten faciliteren dat deze live migreert naar een andere instance en dat valt het weer onder het stukje architectuur.
BPM, CD, DevOps gaat prima samen, mits je bewust hiervan bent en de diverse lagen onderscheid. Zo heeft het continu veranderen van de workflow ook zijn implicaties, die zeker niet onoverkomelijk zijn.
Niettemin leuk artikel en food for thought
Henri, graag redeneer ik nog even door met je voorbeeld van tekst bewerking in de browser. Want stel dat hier een workflow aan hangt, bijv. de brief kent een template X en als hij klaar is dan wordt het automatisch gerouteerd op basis van de inhoud.
Als je een workflow hebt gedefinieerd waarin inhoud X verwacht werd maar je hebt intussen het proces aangepast en nu verwacht je inhoud Y, dan krijg je een situatie waarin je zowel X als Y moet kunnen verwachten. Dat is vergelijkbaar met service versionering en kan leiden tot een warboel (je hebt gelijk dat dit niet los staat van de architectuur trouwens).
Ik heb vaak het gevoel dat in de CD wereld over dit soort zaken wat lichtzinnig gedaan wordt.
Friso, het voorbeeld wat je geeft is een CD op de Workflow inhoud, niet op de software die verwerking van workflows ondersteund. Dit is hetzelfde als dat een proces in status A op basis van business rule 1 de status van het proces verplaatst naar status B en dat in de CD van business rules rule 1 nu ineens verbonden wordt aan status C.
Een mogelijke oplossing in deze is dat je de Workflow MODEL van versie 1.x naar 1.y gaat, maar dat alle instances van het proces gewoon in versie 1.x blijven, of dat je een script hebt (als onderdeel van de CD) die alle lopende processen van versie 1.x migreert naar versie 1.y.
Daarin zie ik geen problemen mits de software dit faciliteert.
Wat betreft je laatste opmerking. CD of DevOps zie je vaak in puntsoplossingen. Dus een Word processor in de browser, een email client, een social network, et cetera. Als mensen ineens een error krijgen omdat ze een plaatje niet kunnen uploaden, dan rol je de nieuwe functie weer terug of stop je de clients die nog niet gemigreerd zijn of maak je een nieuwe release die met de uitzondering rekening houdt. Er is geen man over boord, want het is geen kritische applicatie.
Als je dit met een bankrekening doet…. heb je de poppen aan het dansen. DevOps leent zich goed voor bepaalde zaken, bijvoorbeeld bij bedrijven die SaaS aanbieden, maar voor SAP is het niets. daar is de impact voor een verandering vele malen groter.
de kracht van CD en DevOps komt het best tot zijn recht bij Simple Working Systems. Waarbij ik niet wil zeggen dat bijvoorbeeld een LinkedIn simpel is! Maar er zit een krachtig basis principe in wat dus ook op grote schaal werkt.
DevOps willen toepassen op een bestaande omgeving met bestaande software is een hels karwei. Als je echter een nieuws systeem ontwerpt kun je dit vanaf scratch voor CD en DevOps maken.
De hefboom werkin is enorm en als je de titanen strijd ziet tussen Google, Amazon en Microsoft (lekker die prijsverlagingen deze week!), dan weet je wat er op het spel staat. Daar is het niet hebben van DevOps ondenkbaar!
Leuke discussie dus!
Wij werken hier ook met CD maar ik denk niet dat alle Nederlandse (IT) ondernemingen hier goed mee om kunnen gaan. Want het vergt dat een organisatie hiermee om kan gaan. Dan zul je als organisatie minimaal CMM level 3 moeten hebben schat ik in.
Henri, wat jij aangeeft klopt wel denk ik, maar een aanpassing van het workflow model is linksom of rechtsom volgens mij niet zo triviaal, evenmin bij aanpassen van de onderliggende workflow software.
In veel gevallen zul je ergens een backwardse compatibiliteit moeten houden met verschillende versie van de workflow en van losse services.
De paradox is dat CD ons leert dat als iets moeilijk is, dat je het dan juist vaak moet doen zodat je gedwongen wordt het simpel te maken. Maar de ervaring met BPM is dat veel wijzigingen in langdurige workflows juist tot een lastige architectuur/ontwerp kan leiden. hmm
Daar helpt CMM level 3 je denk ik niet direct bij.
hmm