Open specificaties, meeneembare processen

In de meeste organisaties is de preciesste beschrijving van hoe het werk gaat de code van de software die het uitvoert. Een regel die ooit om een goede zakelijke reden is bedacht, eindigt als een voorwaarde ergens in een applicatie. Een verantwoordelijkheid wordt een mengsel van autorisaties en workflowinstellingen. Een samenwerking met een partner wordt een verzameling API-aanroepen en vertalingen.

De software blijft werken, maar de redenen erachter zijn steeds moeilijker terug te vinden. En wie de software bezit, bezit in de praktijk de kennis van hoe jij werkt.

In CaseFlows staat hoe je werkt in een open specificatie: de case, de fasen die hij doorloopt, de caserollen, wat elke rol in elke fase ziet en mag, en welke diensten worden gebruikt. Precies genoeg om uit te voeren, en leesbaar genoeg om te bespreken met de mensen die het werk doen.

De bestanden zijn open: JSON voor de structuur, markdown voor de redenering. Je kunt ze lezen zonder CaseFlows, bewaren en meenemen.

De specificatie is geen documentatie naast het systeem. Hij legt de caseflow vast die de runtime uitvoert: de fasen, rollen, bevoegdheden en regels. De runtime dwingt die grenzen af; mensen, diensten en AI doen het werk daarbinnen.

Daarin verschilt CaseFlows ook van veel modelgedreven software, waar een model wordt vertaald naar code of configuratie en de twee daarna uit elkaar kunnen lopen. Hier leest de runtime de specificatie zelf. Verander je de specificatie, dan verandert het vastgelegde proces, zonder dat dat proces opnieuw als applicatiecode gebouwd hoeft te worden. Hoe een bedoeling een specificatie wordt, staat in Van intentie naar een draaiend systeem.

Open bestanden zijn het begin. Echte meeneembaarheid vraagt drie lagen, en het helpt precies te zijn over waar elk staat:

• Open formaat: de specificatie is leesbaar en mee te nemen. Dat is vandaag waar.
• Open betekenis: een publieke definitie van wat een caserol is, wanneer een bevoegdheid geldt en wat er gebeurt als een case van fase wisselt, los van welke runtime ook. Vandaag ligt die betekenis vast in onze schema’s en in de CaseFlows-runtime; die apart publiceren is onze richting.
• Onafhankelijke uitvoering: andere runtimes die dezelfde specificatie met dezelfde betekenis uitvoeren. Vandaag is CaseFlows de enige.

Wat je vandaag bezit is dus een leesbare, meeneembare beschrijving van je manier van werken, in een vorm waar mensen en AI mee kunnen werken. Hem elders uitvoeren is wat de open formaten mogelijk moeten maken, niet iets wat al bestaat.

Open source maakte het mogelijk om software te delen, te bestuderen en te verbeteren zonder afhankelijk te zijn van de oorspronkelijke maker. Open specificaties kunnen iets vergelijkbaars doen voor de manier waarop organisaties werken.

In plaats van een applicatie delen organisaties wat ze geleerd hebben: de verantwoordelijkheden, regels, beslissingen, uitzonderingen en samenwerkingspatronen die een proces laten werken. Die kennis is niet alleen voor programmeurs. Proceseigenaren, professionals en brancheorganisaties kunnen hem lezen, bespreken en verbeteren.

De specificatie wordt het gedeelde bezit. Hoe hij wordt uitgevoerd hoort een keuze te blijven; vandaag draait hij op CaseFlows.

Drie beloften, elk met een eigen stand:

• Eigenaarschap: je organisatie bezit een leesbare, meeneembare beschrijving van hoe ze werkt. Vandaag.
• Hergebruik: een specificatie kan worden overgenomen en aangepast tot je eigen variant. Vandaag mogelijk binnen CaseFlows; tot nu toe gedaan binnen onze eigen platforms.
• Uitwisselbaarheid: verschillende leveranciers voeren dezelfde specificatie uit. Onze richting, en de moeilijkste van de drie.

Stel dat een andere organisatie een goede manier heeft gevonden om een bepaald soort aanvraag te behandelen. Deelt ze haar software, dan moet je die waarschijnlijk ombouwen om op je eigen systemen en technische keuzes te passen.

Deelt ze haar specificatie, dan krijg je wat ze geleerd heeft: welke caserollen nodig bleken, waar de verantwoordelijkheid ligt, welke informatie in welke fase telt, welke uitzonderingen zich voordeden. Je neemt de caseflow, maakt je eigen variant, koppelt je eigen diensten waar die van hen niet passen, en ontwikkelt hem verder, zonder te wachten op de oorspronkelijke maker.

Werken twee organisaties samen, dan hoeven ze hun interne caseflows niet te delen. Wat ze delen is de grens: de caserol die de een aan de ander geeft, met zijn verantwoordelijkheid, zijn informatie, wat hij per fase mag, en het verwachte resultaat. Die grens is een specificatie die beide platforms begrijpen en beide bevestigen; een wijziging is een nieuwe versie die beide op hun ontwikkelomgeving kunnen proberen voordat hij telt.

Dat is een ander soort delen dan hergebruik:

• Een specificatie hergebruiken deelt een ontwerp voor een manier van werken, tijdens het ontwerpen. Je maakt je eigen variant, en er is geen gedeelde case.
• Een caserol delen deelt een begrensde verantwoordelijkheid, terwijl het werk loopt. Je handelt binnen afgesproken grenzen, in een case die bij de eigenaar blijft. Meer in Samenwerken over organisaties heen.

Open specificaties betekenen geen open interne bedrijfsvoering. Afspraken worden expliciet en toetsbaar; hoe elke kant zijn deel doet, blijft van hemzelf.

Een standaard wordt meestal ontworpen, vastgesteld en dan jarenlang toegepast. Een open specificatie blijft onderdeel van het werk. Elke case weet onder welke versie van de specificatie hij loopt. Melden mensen dat iets niet past, of komt dezelfde uitzondering steeds terug, dan wijst dat signaal naar de case, en dus naar de versie.

Daaruit ontstaat een wijzigingsverzoek, een nieuwe versie wordt gebouwd en op de ontwikkelomgeving geprobeerd, en alleen wat de proceseigenaar goedkeurt wordt de volgende versie. Nieuwe cases beginnen daaronder; cases die al lopen houden de versie waarmee ze begonnen, zodat niemands werk onder zijn voeten verandert.

Bouwen meerdere organisaties op dezelfde specificatie, dan moet iemand hem onderhouden, voorgestelde wijzigingen beoordelen en beslissen wanneer een nieuwe versie klaar is. En deelnemers op verschillende versies moeten door kunnen werken terwijl een nieuwe wordt overgenomen.

Die verantwoordelijkheid kan liggen bij één organisatie, een brancheorganisatie of een gemeenschap van deelnemers. Onze richting is gedeelde specificaties ondersteunen die organisaties kunnen overnemen, aanpassen en verbeteren, zonder de regie over hun eigen variant of hun eigen uitvoering op te geven.

Bezit je manier van werken. Deel wat je geleerd hebt. Kies hoe het wordt uitgevoerd. Het eerste draait vandaag, het tweede binnen CaseFlows, het derde is onze ambitie.

Draait vandaag

• Open, leesbare specificaties voor cases, caseflows, caserollen en diensten, die de runtime rechtstreeks uitvoert.
• Elke case draagt de versie waaronder hij loopt; een nieuwe versie geldt voor nieuwe cases.
• Signalen uit echte cases die wijzigingsverzoeken worden, geprobeerd in development en goedgekeurd door de proceseigenaar.
• Afspraken op de grens tussen twee platforms die beide kanten bevestigen, met elke wijziging als nieuwe versie.
• Specificaties hergebruikt binnen onze eigen platforms, aangepast aan elk.

Waar we naartoe gaan

• De betekenis van de specificatie apart gepubliceerd, los van de CaseFlows-runtime.
• Een plek waar organisaties specificaties publiceren die anderen kunnen vinden en overnemen.
• Specificaties die een sector samen ontwikkelt en onderhoudt, met gedeeld beheer.
• Een tweede runtime voor dezelfde open formaten.