Mad, maar niet gek

Kees Kranenburg en Ad van Riel: Model-based Application Development (MAD), modelleren en genereren van informatiesystemen. Kluwer bedrijfswetenschappen 1995. ISBN 90-267-2251-6. Prijs: ƒ 64,50.

Vroeger werd je neefje computerprogrammeur, en dan waren wij allemaal onder de indruk en zwegen wij bedremmeld, want wij begrepen niet precies wat dat was. Wij wisten alleen dat neeflief geacht moest worden een beetje te kunnen toveren. Tegenwoordig is je neefje automatiseerder, en weet je niet eens meer of je onder de indruk moet zijn. Want wat dóet een automatiseerder nu eigenlijk voor de kost? Programmeert ie computers? 'Nou neuh,' zal hij zuinigjes antwoorden, want het dagelijkse programmeerwerk is een stuk in status gedaald. Het wordt zelfs al wel uitbesteed naar lage-lonen landen als India. Maar wat doet ie dan wel? 'Zorgen dat uw bedrijf zijn tanden kan laten zien', iets dergelijks beet ons nog maar kort geleden een flitsende televisiereclame toe. Dat roept het beeld op van strak in het pak zittende mannen met ferme kaken, die gedecideerd een kantoor binnenmarcheren. Voor ze het weten vinden de ingeslapen employés zichzelf terug achter flitsende terminals, als onderdeel van een efficiënt netwerk dat toegang geeft tot voldoende strategische informatie om wereldmarkten te veroveren. Iets van dat beeld klopte ooit wel, al had niet iedere automatiseerder van die reclamekaken. Als een bedrijf dacht dat er iets te automatiseren viel, de orderadministratie, vraag en aanbod van arbeidskrachten, de procesbewaking bij het maken van schoenen of het uitdelen van studiebeurzen, dan belde het een systeemhuis, dat een of meer mannetjes langs stuurde. Daaraan vertelde je wat de bedoeling was, en men ging aan het werk. Na een tijdje lag er dan een keurig uitgewerkt en precies gespecificeerd ontwerp ter goedkeuring. Stond daaronder eenmaal je handtekening, dan zat je eraan vast: het systeemhuis ging de zaak volgens de afgesproken specificaties bouwen, de benodigde apparatuur werd besteld en geïnstalleerd, en aan het eind van het proces was je de trotse eigenaar van een systeem dat hoogstwaarschijnlijk niet deed wat het moest doen. Dat lag ook voor de hand, want een bedrijf is een razend ingewikkeld ding, waarvan niemand zomaar kan overzien hoe alle radertjes precies in elkaar grijpen. Wat op papier zo mooi leek, sluit achteraf vaak niet goed aan bij de praktijk van alledag. Soms zijn er dingen over het hoofd gezien. Soms ook blijkt de juiste informatie wel beschikbaar, maar achteraf toch niet op de goede plaats. Of het geheel doet wel wat het moet doen, maar het voelt omslachtig aan, en de medewerkers krijgen er een hekel aan. Of het bedrijf is tijdens de bouwfase van het systeem zélf veranderd, is nieuwe dingen gaan doen, of heeft zijn werkzaamheden op punten anders georganiseerd, en heeft daardoor nu andere informatie nodig dan 'toen'. Dat betekende vaak weer moeizaam, langdurig en duur gesleutel aan het gloednieuwe systeem, dat er uiteraard niet echt beter van werd. Het eind van het liedje was dan op zijn minst frustratie over het matige resultaat, soms ook een drama zoals bij de studiefinanciering. Er zijn zelfs systemen die ook jaren na oplevering nog niet één dag echt gedraaid hebben, al willen de eigenaars dat liever niet weten. Langzaamaan is het bedrijfsleven daardoor heel wat skeptischer geworden over het nut van vooral grotere automatiseringsprojecten dan in de wilde jaren zeventig, toen men dacht dat de computer de zakelijke hemel op aarde zou brengen. Het moest allemaal maar eens sneller, goedkoper en beter. Vooral dat laatste vonden de automatiseerders ook allang. Immers, wie te dure en dan ook nog slecht passende schoenen verkoopt krijgt chagrijnige klanten en gaat uiteindelijk op de fles, en zo is het met automatisering ook. De techniek hielp ze een eind op weg, doordat er steeds beter gereedschap voor het ontwerpen en bouwen van programma-onderdelen kwam. Dat betekende sneller (en dus goedkoper) werken, maar gaf bijvoorbeeld ook de mogelijkheid om klanten al snel een min of meer werkend prototype te laten zien, waardoor die een veel beter idee kregen van wat ze eigenlijk wilden: 'zoiets, maar dan met een toeter en twee belletjes'. Maar vooral won de 'zachte', organisatorische kant van projecten aan belang. Allerlei methodieken werden bedacht om beter te weten te komen waar de behoefte precies lag, en om het hele proces flexibeler te maken, zodat je halverwege de koers nog gemakkelijk kon bijstellen of zelfs omgooien, bijvoorbeeld op basis van de ervaring met zo'n prototype. Eén van die methodieken, gebukt gaand onder de naam MAD, is het onderwerp van het boekje Model Based Application Development (MAD), geschreven door de praktijkdeskundigen Kees Kranenburg en Ad van Riel. MAD begint helemaal niet bij computers, maar bij het bedrijf. Hoe zitten hun werkzaamheden, voor zover relevant, in elkaar? Je maakt een model, waarin je de natuurlijke onderdelen kunt zien, en hoe die met elkaar samenhangen. Uit dat model leid je af wat er aan informatie nodig is, en wat daarvan geautomatiseerd moet en kan worden. In het informatiemodel dat daaruit volgt, vind je de natuurlijke onderverdeling van het bedrijf als geheel als vanzelf weer terug. Dan pas ga je echt automatiseren, module voor module. Doordat de modulen afspiegelingen zijn van natuurlijke onderdelen van het bedrijfsproces, blijven veranderingen en aanvullingen als vanzelf meestal tot een module beperkt. Hoe dat allemaal moet, staat in het boek van Kranenburg en Van Riel. Het is een leerboek, geen lichte kost, maar wel duidelijk en goed te doen voor diegenen die echt wat willen weten. En het is praktijkgericht, compleet met twee verhelderende gevalsbeschrijvingen. Bovendien, en dat is misschien wel het beste ervan, is er heel veel uit te leren over het hoe en waarom van relationele databases, en hoe veel van de opzet daarvan bijna automatisch voortvloeit uit het werken met de MAD-methodiek.

    • Rik Smits