Bedrijfssoftware kaderen voor de eerste regel code

De eerste vraag gaat vaak over de stack. Next.js, .NET, een relationele database, een low-code tool. Die vraag komt te vroeg. Zolang u niet weet wie het systeem gebruikt, wat iemand probeert af te maken, en wat er gebeurt als het gewone geval niet opgaat, heeft de technologie niets om over te beslissen.

Kaderen dient daarvoor. Niet om een document te produceren dat niemand herleest. Om een beeld te krijgen dat precies genoeg is zodat de eerste stap nuttig is, en zodat de architectuur volgt uit echte beperkingen.

Begin bij het echte proces

De geschreven procedure en het echte werk lopen bijna altijd uiteen. Het handboek zegt dat een aanvraag in de tool wordt goedgekeurd. In de praktijk vertrekt de goedkeuring via e-mail, een spreadsheet volgt de uitzonderingen, en één persoon “weet” welke dossiers zonder het ontbrekende stuk mogen doorgaan.

Praten met gebruikers volstaat niet als ze het ideale proces vertellen. Volg één operatie tot het einde: een bestelling, een dossier, een interventie, een afsluiting. Wie opent, wie vervolledigt, wie blokkeert, wie hervraagt, en waar de informatie wordt overgetypt.

De nuttige afwijkingen zijn concreet. Een verplicht veld dat iedereen omzeilt. Een status die bij geen enkele beslissing hoort. Een lijst die elke ochtend wordt geëxporteerd omdat het scherm niet kan filteren. Die omwegen zijn de specificatie die het huidige systeem niet kon dragen.

Formuleer het probleem voor de oplossing

Een vraag komt vaak al vertaald als functionaliteit. “We hebben een portaal nodig”, “een workflow”, “een mobiele app”. Als u die vertaling te snel aanneemt, bouwt u het scherm dat werd genoemd, niet het probleem dat er was.

Het probleem laat zich beter formuleren als beslissingen en resultaten. Welke informatie ontbreekt op het moment dat iemand ja of nee moet zeggen? Wat wordt opnieuw ingevoerd, en met welke vertraging? Welke fout is duur, en hoe vaak? Wat moet mogelijk blijven als de nieuwe tool uitligt?

Die formulering verandert de reikwijdte. U kunt de opvolging van een dossier leveren zonder de upload, of omgekeerd, naargelang wat de meeste wrijving wegneemt. Een functielijst geeft die volgorde niet.

Breng het bestaande in kaart

De nieuwe software komt niet in een leeg landschap. Er zijn al applicaties, bestanden, mailboxen, API’s, nachtelijke exports, soms een rechtstreekse databasetoegang die “niemand aanraakt”.

De nuttige kaart is geen enterprise-architectuurposter. Het is de lijst van wat een gegeven draagt dat het nieuwe systeem nodig heeft, of dreigt te overschrijven:

• de applicatie die vandaag de referentie is, ook als ze oud is;
• de spreadsheets die die applicatie corrigeren;
• de berichten die een beslissing dragen;
• de API’s of bestanden die met een partner, een ERP of een andere tool worden uitgewisseld;
• de tijdsafhankelijkheden: afsluiting, facturatie, wachtdienst, synchronisatie.

Voor elk element volstaan drie vragen. Wie is ervoor verantwoordelijk? Wat gebeurt er als het fout is? Kunt u het missen tijdens een overgang?

Die kaart vermijdt twee symmetrische fouten. Alles “later” opnieuw koppelen, en in de test ontdekken dat een status uit een systeem komt dat u niet had voorzien. Of alles op dag één integreren, en het traject dat het project rechtvaardigde nooit opleveren. Als het vooral gaat om informatie die al ergens wordt ingevoerd, is systemen koppelen vaak een juister kader dan een volledig nieuw product.

Benoem de gebruikers en hun beslissingen

“De gebruikers” is te breed. Een dossierbeheerder, een operator op het terrein, een externe klant en een verantwoordelijke die een bord bekijkt, hebben niet hetzelfde moment, dezelfde informatie of dezelfde foutmarge.

Voor elke rol helpt één zin: op moment X beslist deze persoon Y, met informatie Z, en het gevolg is W. Als de zin niet standhoudt, is de rol vaag of bestaat de beslissing niet echt.

Rechten volgen uit die zinnen, niet uit een organigram. Wie mag een gegeven corrigeren dat al is doorgestuurd? Wie mag een dossier zien dat niet van hem is? Wie moet worden tegengehouden om goed te keuren wat hij zelf heeft ingevoerd? Die vragen bepalen het model meer dan het framework.

Terrein hoort daarbij. Wisselend netwerk, handschoenen, zon op het scherm, één vrije hand, enkele seconden geduld. Als de software buiten het kantoor leeft, maken die voorwaarden deel uit van de kadering.

Maak de businessregels expliciet

Het gewone geval

Het gewone geval is het pad dat men kan navertellen. Een volledige aanvraag, voorraad beschikbaar, een gekende klant, een goedkeuring binnen de termijn. Beschrijf het tot wat wordt opgeslagen en wie wordt verwittigd. Het is niet het systeem.

De uitzonderingen

De uitzonderingen zijn de software. Een gedeeltelijke creditnota. Een onleesbaar stuk. Een derde die nog niet in de referentie bestaat. Een lokale regel die maar één team toepast. Een geval dat de stroom moet verlaten en later terugkomen zonder zijn historiek te verliezen.

Elke uitzondering krijgt dezelfde behandeling. Wat is de voorwaarde? Wie beslist? Welk spoor blijft? Kan het dossier verder, of moet het stoppen? Als niemand kan antwoorden, is dat geen detail voor de ontwikkeling. Het is een gat in de regel, en de code vult dat niet netjes op.

Bepaal een eerste nuttige reikwijdte

Een eerste reikwijdte is geen product dat willekeurig wordt afgesneden om in een budget te passen. Het is een volledig traject voor een echt geval, gebruikt door echte mensen, met een manier om te zien of het heeft geholpen.

De toets hoeft geen verfijnde indicator te zijn. Minder overtypen op dat type dossier. Een waarneembare behandeltijd. Eén genoemd spreadsheet dat verdwijnt. Belangrijk is dat het team het effect kan vaststellen en de volgende stap daaruit kiest, niet uit het oorspronkelijke plan.

Alles buiten dat traject blijft zichtbaar: u noteert het, u bouwt het niet. Functies “nu we toch bezig zijn” zijn de gewone manier om een kadering te missen die anders duidelijk was.

Dit sluit vaak aan bij een bedrijfsproces automatiseren, als de winst zit in het schrappen van manuele kopieën, of bij bedrijfssoftware moderniseren, als het gaat om een deel van een bestaand systeem te vervangen zonder alles uit te zetten.

Kies de architectuur daarna

De beperkingen komen voor de technologie. Volume, pieken, persoonsgegevens, antwoordtijd, offline gebruik, systemen die u niet mag breken, het team dat de code overneemt, een horizon van twee of van tien jaar. Twee contexten die “een webapplicatie willen” vragen niet dezelfde architectuur.

Dan kunt u een technisch kader kiezen zonder er een voorkeur van te maken. Een modulaire monoliet of aparte services, naargelang hoeveel teams leveren en hoe vaak. Een relationele database als regels en historiek tellen. Bestanden en wachtrijen als de business een uitwisseling is, geen formulier. Authenticatie uit de directory die u al hebt, in plaats van een tweede account.

Bouwen komt na die keuze, niet in de plaats ervan. De software ontwikkelen zonder deze stap is hypotheses coderen. Hypotheses kunt u corrigeren. Ze zijn goedkoper opgeschreven in een kadering dan verspreid in de code.

Wat een goede kadering moet opleveren

Op het einde moeten de mensen die beslissen en de mensen die zullen bouwen hetzelfde kunnen herlezen en het echte werk herkennen. Het resultaat is een korte reeks stukken, geen bundel:

• een gedeeld beeld van het proces, inclusief de omwegen;
• het probleem geformuleerd als beslissingen, niet als schermen;
• de kaart van wat bestaat en welke data de referentie is;
• de rollen en wat ze mogen beslissen;
• de regels van het gewone geval en de uitzonderingen die u bijhoudt;
• een eerste reikwijdte, met wat expliciet erbuiten valt;
• risico’s die al zichtbaar zijn: vuile data, een afhankelijkheid, adoptie, de kalender;
• een initiële architectuur die volstaat om te starten, geen definitief schema;
• de hypotheses die nog open zijn, en hoe u ze zult toetsen;
• een backlog geordend volgens het nuttige traject, niet volgens technisch gemak.

Analyse en architectuur dienen om die stukken te produceren voor de ontwikkeling wordt vastgelegd. De omvang varieert. Een traject dat de organisatie al kent, past in enkele workshops. Een activiteit verspreid over drie tools en twee sites vraagt meer tijd op de vloer. In beide gevallen is de eindstreep dezelfde: u weet wat u eerst bouwt, en waarom de rest wacht.

Kaderen betekent niet het project drie maanden stilleggen. Een kadering die verbiedt om onderweg te leren, is te lang. Een ontwikkeling die start zonder antwoord op de uitzonderingen, is te vroeg. Daartussen is er genoeg om de eerste regel te schrijven zonder de business al doende te verzinnen.