Er zijn heel veel boeken geschreven over het ontwerpen, bouwen en implementeren van bedrijfsprocessen en it-systemen. Daar is niets mis mee. Je moet vertrouwd zijn met architecturen, methodieken, technologieën, modellering, ontwikkeltools, et cetera om die klussen te klaren. Met tien basisregels kun je echter valkuilen vermijden en focus houden op de kernresultaten, stelt Ferdinand Geuther.
Minder is meer
Het motto ‘less is more' werd gepropageerd door de beroemde architect en ontwerper Ludwig Mies van der Rohe. Hij benadrukte daarmee dat de essentie van architectuur niet mag worden vertroebeld door decoraties en ornamenten. Godfried Bomans zei ooit "schrijven is schrappen". Schrap alle overtollige woorden net zolang tot de essentie van wat je wilt zeggen, overblijft. In de wiskunde leiden veel variabelen tot complexe berekeningen met een grote kans op fouten. Wees bij het ontwerpen van processen en systemen daarom terughoudend in het accepteren van stapels met variabelen: functionele eisen, business rules, uitzonderingen, beperkingen, enzovoort. Richt je op de kern van de bedrijfsbehoeften, streep alles door wat je kunt doorstrepen zolang die essentiële bedrijfsbehoeften worden ondersteund. Beperk je tot de noodzakelijke basisprocessen en ondersteun die met recht-toe-recht-aan systemen, zonder franje. Bedenk ook dat beter de grootste vijand is van goed. Minder is Meer.
Hou techneuten en verkopers op afstand
Techneuten vinden het interessant om technische grenzen te verkennen, nieuwe tools en gadgets te gebruiken. Dat is opwindend en soms ook veelbelovend, maar tegelijkertijd heel riskant voor elk project. Niet alleen tijdens de ontwikkelingsfase, maar juist voor de productiefase, de operations en het onderhoud. Je zult nauwelijks expertise vinden op die nieuwe technologieën en de effecten ervan op productieprocessen, waar op grote schaal gegevens worden verwerkt, zijn nog onbekend. Gebruik daarom alleen bewezen technologie en houd onbewezen techneuten op afstand!
Verkopers houden van verkopen, dat is logisch, ze willen de nieuwe producten zo snel mogelijk kunnen meenemen in hun offertes. Zelfs als die producten nog onvolledig of nog niet uitgetest zijn willen ze die kunnen aanbieden aan hun klanten. Zo wordt je geforceerd om incomplete, niet gedocumenteerde, oppervlakkig geteste processen en systemen te leveren. Iedereen kent wel een situatie waarin systemen moesten worden uitgeleverd die eigenlijk bedoeld waren als prototype voor testdoeleinden, zonder de kwaliteiten die een productieomgeving eist zoals performance, bedrijfszekerheid, onderhoudsfunctionaliteit, back-up en recovery faciliteiten, beveiligingsmiddelen. Zeg dus nimmer en nooit aan een verkooporganisatie dat je product bijna klaar is, totdat het echt klaar is om uitgeleverd te worden! Houdt verkopers te vriend, maar op afstand.
Luister naar de hartslag
One size doesn't fit all. Veel bedrijfstakken hebben hun eigen bedrijfsritme en bedrijfscultuur, zeg maar hartslag. De aard van hun producten, de omvang of geldswaarde, de manier waarop ze hun klanten bedienen, de leveringssnelheid, de klachtenafhandeling, et cetera. Daar zitten grote verschillen in. Een apotheker is uitermate precies in zijn productie- en leverproces, een milligram teveel of te weinig kan fataal zijn voor de klant. Een baggeraar daarentegen kijkt niet op een paar honderd kilo's meer of minder. Twee werelden die hemelsbreed van elkaar verschillen. Bedrijfsprocessen en systemen moeten zijn ontworpen voor die specifieke omgevingen, voor die specifieke hartslagen. Commerciële software is zoiets als ‘one size fits all'. Soms is dat zo, vaak niet. Wees dus altijd alert dat je ontwerp geschikt is voor de betreffende bedrijfstak. Kijk goed hoe men nu werkt met mensen, systemen, processen en wat de aard van de diensten of producten is. Stem de nieuwe processen en systemen daarop af (Zie ook het artikel ‘Luister naar de hartslag', Computable 27-10-2006; https://www.computable.nl/artikel.jsp?id=1822617).
De duivel zit in de details
It's so easy to fall in love. Deze hit van Linda Ronstadt is ook zeer geschikt als metafoor voor het gemakkelijk accepteren van globale functionele eisen, de high level requirements. Helaas zal alleen een dieptesondering – de detaileisen – je duidelijk maken of er een myriade van problemen onder het kalme zeeoppervlak ligt. Een eenvoudig voorbeeld is de functionele eis dat een systeem de naam van studenten moet kunnen vastleggen. It's seems so easy, nietwaar? De argeloze projectmanager rekent een uurtje of twee voor het realiseren van deze eis. Al snel komen echter vragen naar boven als alleen de achternaam, tussenvoegsels, hoeveel voornamen. Meisjesnaam. buitenlandse namen met speciale tekens of andere volgorde van voor- en achternaa.; naamswijziging bijvoorbeeld bij gescheiden studenten, enzovoort. De eenvoudige functionele eis blijkt veel meer tijd te vergen dan de twee uur die de projectmanager had toegewezen. Dat brengt me naar de tweede oneliner van Ludwig Mies van der Rohe: "God is in the details". Daarmee bedoelde hij dat de schoonheid van architectuur vaak zit in de details en dat daar dus veel aandacht aan moet worden besteed. In proces- en systeemontwerp worden planningen en begrotingen gestuwd door de complexiteit van de requirements. Ludwig had dus net zo goed kunnen zeggen: The devil is in the details!
Koppeling is Koning
‘Content is kin'" is een fundamentele wet in de internetwereld. Inhoud kan echter alleen koning zijn als er ook koppelingen zijn vanuit de diepste krochten van de systemen en databases naar de uiteindelijke gebruikers of ontvangers.
De kwaliteit van fraaie processen en systemen kan alleen tot zijn recht komen als zij geïntegreerd zijn in de bedrijfsprocesketen. Zoek daarom de buitenkant – de grenzen – op van het proces of systeem en identificeer de aangrenzende partijen. Specificeer de functionele en technische eisen voor deze koppelingen. Gegevens, definities, frequenties, gegevenskwaliteitseisen, eigendom, protocollen, performance-eisen, randvoorwaarden, enzovoort. Al deze aspecten moeten worden nagelopen en er moet overeenstemming worden bereikt met alle betrokken partijen in de gehele keten. No interface, no glory (Zie ook het artikel ‘Koppelen met het koppie', Computable, 13-9-2002
https://www.computable.nl/artikels/archief2/d37ra2wu.htm).
Geen woordenboek, geen communicatie
Britse comedies zijn bekend om de miscommunicatie tussen de hoofdpersonen. Ze praten met elkaar en veronderstellen dat ze het over hetzelfde onderwerp hebben. Jammer voor hen maar erg leuk voor de kijkers is dat de woorden meestal een totaal verschillende betekenis hebben. Wees ervan bewust dat woorden en afkortingen op verschillende manieren geïnterpreteerd kunnen worden. Dat is goed voor een comedy, maar moordend voor processen en systemen. De eerste stap in je project moet daarom het maken van een woordenboek zijn. Een woordenboek én een formeel proces om het te onderhouden en te gebruiken.
Weet wat je zegt en begrijp wat de ander zegt.
Strooi met kruimels
In het bekende sprookje strooiden Hans en Grietje met broodkruimels om de weg terug te kunnen vinden. Ongeveer zoiets moet je doen bij het ontwerpen van processen en systemen. Zorg voor voldoende audit trails, snapshots, datum/tijdstempels en logging van activiteiten en gebeurtenissen. Hiermee kun je later de oorzaak van fouten of storingen uitzoeken. Het helpt de situatie van vlak voor het probleem of de storing te herstellen, zodat je vanaf dat punt kunt herstarten. Veel van deze eisen kunnen door het besturingssysteem of het database systeem worden ingevuld, mits je die opties ook activeert. Toch is dat niet altijd voldoende en zul je zelf moeten zorgen voor aanvullende maatregelen. Maak daarom veel kiekjes en strooi ook kwistig met eigen kruimels!
Lees en schrijf geschiedenis
"Zij die de geschiedenis niet kennen zijn gedoemd hem te herhalen" (vrij naar George Satayana). Waarom zou je in dezelfde valkuilen moeten vallen waar anderen voorheen al in gevallen zijn? Waarom herbeleven, heruitvinden en herbedenken, kortom herlijden? Lees en gebruik de ervaringen uit andere projecten. Vraag aan collega's om jouw ontwerpen, plannen, of begrotingen eens langs te lopen en aan te geven wat er anders of beter kan, of helemaal niet hoeft. In de meeste gevallen vinden ze het een eer daarvoor gevraagd te worden. Ze zullen je zeker helpen. Zorg desnoods ook voor extra budget en tijd voor deze second opinions. Vergeet ook niet je eigen geschiedenislessen – lessons learned – op te schrijven en te delen met je vak- en lotgenoten. Lees en schrijf geschiedenis, letterlijk en met wat geluk ook figuurlijk!
Test, test, test
Makelaars zeggen dat de waarde van een huis door drie zaken wordt bepaald: locatie, locatie en locatie. In analogie daarop kan voor processen en systemen worden gezegd dat drie zaken van belang zijn voor de kwaliteit: testen, testen en testen.
Hoewel testen steeds meer aandacht krijgt, is het nog een stiefkind in de ict. Ontwikkeling krijgt altijd de grootste porties van het projectbudget, de resources en de planning toegewezen. Met een paar mensen moet in korte tijd – meestal in de laatste weken van een project – het testwerk worden gedaan. Te weinig, te laat. De uitkomst van deze onbalans is te zien in de vele projecten waar de nazorginspanning groter is dan de bouwinspanning. Pas daarom het Pareto Principe voor Testen toe als vuistregel voor de planning van mensen, tijd en geld: 20 procent voor ontwikkeling en 80 procent voor testen.
Gij zult niet tijdboksen
Timeboxing is een aantrekkelijke methode om snel van start te kunnen. Het lijkt ook zo logisch om alleen te bouwen wat je in een relatief kleine gefixeerde periode kunt bouwen. Je levert op tijd op én binnen budget. Dat is de belofte. Er is daarbij wel een ijzeren discipline nodig om eerst het totale ontwerp en het totale plan te maken. Dat kost echter tijd.
Er wordt dus wel eens getijdbokst zonder dat totale ontwerp en plan, met als gevolg dat onderweg allerlei bijstellingen moeten plaatsvinden. Meestal ten koste van budget en doorlooptijd.
Met timeboxing worden aan gebruikers en opdrachtgevers snel fraaie tussenresultaten voorgeschoteld, maar onvolledigheden en tekortkomingen zijn onzichtbaar. Die komen later als een boomerang terug, soms pas tijdens de productie. Onverwachts en pijnlijk. Laat de timebox boomerang dus maar liggen.
Ferdinand G. Geuther, senior management consultant Numa Group
Gebruik je gezonde verstand
De hier beschreven ‘tien wetten' voor ontwerpen, bouwen en implementeren kunnen je bijstaan bij het ontwikkelen van bedrijfsprocessen en it-systemen. Er is echter één alles overstijgende wet: Gebruik je gezonde verstand. Wees sceptisch. Geen enkele techniek, methode, tool of ontwerpwet is zaligmakend. Neem alles met een korreltje zout. De aarde draait al miljoenen jaren en de meeste daarvan zonder ict!
“In analogie daarop kan voor processen en systemen worden gezegd dat drie zaken van belang zijn voor de kwaliteit: testen, testen en testen.”
Als tester kan ik hierover drie dingen zeggen: Nee, nee en nee. Kwaliteit kun je er niet in testen. Kwaliteit moet er vanaf het begin in ontworpen worden, testen toont vervolgens aan hoe hoog die kwaliteit dan is. Ik krijg de indruk dat de auteur voornamelijk op zoek was naar leuke oneliners.
Tut, tut, tut, Aukyboy…
Volgens mij klopt de analogie die de auteur met makelaars trekt wel.
Alleen om de analogie kloppend te maken, moet “van belang zijn voor de kwaliteit” gelezen worden als: “van belang zijn voor het bepalen van de kwaliteit”.
Het werken op basis van een kwalitatief goed ontwerp is vanzelfsprekend van belang. Testen wordt, zoals de auteur ook stelt, vaak onderbelicht.
Dit is een goed voorbeeld van de vijfde basisregel:
“weet wat je zegt en begrijp wat de ander zegt”.
Voor de rest ben ik het alleen met de laatste basisregel niet eens (“Gij zult niet tijdboksen”).
Binnen een iteratief ontwikkelproces wordt timeboxing bewust toegepast zonder eerst het totale ontwerp te maken. Hierbij is het zeker niet de bedoeling om zo snel mogelijk fraaie tussenresultaten te bereiken, maar wel om afgebakende stukken functionaliteit met goede kwaliteit op te leveren.
En die kwaliteit wordt natuurlijk bepaald door de tester…
Een leuk artikel, maar wel erg veel algemeen zonder echt concrete aanbevelingen. Ik wil graag een paar citaten doornemen:
“Gij zult niet tijdboxen”.
Leuke bewering, maar waarom eigenlijk niet? Het antwoord: “Er is daarbij wel een ijzeren discipline nodig om eerst het totale ontwerp en het totale plan te maken. Dat kost echter tijd. Er wordt dus wel eens getijdbokst zonder dat totale ontwerp en plan, met als gevolg dat onderweg allerlei bijstellingen moeten plaatsvinden.”
Waarom moet je opeens eerst het totale ontwerp en totale plan gemaakt hebben voordat je mag gaan timeboxen? En natuurlijk moeten er bijstellingen plaatsvinden! De wereld verandert nu eenmaal snel, ook tijdens een ontwikkeltraject. Een timebox is er speciaal voor dat je concrete resultaten kunt opleveren in een wereld die continu verandert.
En als timeboxen niet de ge?igende methode is, welke dan wel? Waterval? Nee toch…
Nog een citaat: “De argeloze projectmanager rekent een uurtje of twee voor het realiseren van deze eis.”. Ik lees hier dat Ferdinand het normaal vindt dat een projectmanager inschat hoe lang een bepaalde activiteit gaat duren. Na 15 jaar IT projecten kan ik concluderen dat dat pertinent fout is. De enige die een exacte inschatting kan maken van een bepaalde activiteit (en daarop afgerekend kan worden) is degene die de activiteit zelf uitvoert, de programmeur dus. Projectmanagers die zich daarmee gaan bemoeien verstaan hun vak niet.
Verder heb ik net als de anderen die reageerden moeite met de bewering dat alleen testen van belang is voor de kwaliteit van een systeem. Natuurlijk is testen uiterst belangrijk en wordt er bijna altijd onvoldoende tijd voor uitgetrokken. Kwaliteit zit echter overal. Testen is een van de manieren om die kwaliteit te verifi?ren. Maar met alleen verifieren ben je er nog niet.
Ik wil Ferdinand adviseren het uitstekende artikel over Agile systeemontwikkeling te lezen. De principes van Agile systeemontwikkeling geven namelijk concrete basisregels die daadwerkelijk bijdragen aan het succes van een systeemontwikkelproject.
De reacties op dit artikel laten mij inziens twee dingen duidelijk zien:
1 er is de wereld van de ‘de vrager’ het bedrijf dat om een ICT oplossing vraagt en die van de programmeurs, systeem-ontwikkelaars
2 gezien de vele gepubliceerde ICT missers dunkt mij dat het nog het e.e.a. te verbeteren valt
3 terughakend op (1) en (2) zonder te praten over concrete gevallen kun je het zowel met de opsteller van het artikel als met de reacties eens zijn. Gezien de ‘missers’ uit het verleden ben ik geneigd meer waarde te hechten aan het artikel.