Stel dat u uw huis opnieuw wilt inrichten en dat u het stadium van Ikea, de woonboulevards en Jan de Bouvry inmiddels voorbij bent.
Met een binnenhuisarchitect heeft u een paar mooie ontwerpen van meubels gemaakt, waarna u naar een ambachtelijke meubelmaker toestapt. Die overhandigt u het boekwerkje: ‘Meubelmaken: Van handzaag tot zaagmachine’ met de mededeling dat u dit maar eerst eens goed moet lezen voordat u verder met hem in zee gaat. Vol verwondering vraagt u naar het waarom, waarop hij zegt: ‘Met deze nieuwe methode kan ik uw meubels veel sneller en goedkoper leveren.’ U bent beleefd en wijst niet naar uw voorhoofd. Maar u denkt wel: ‘Wat heb ik nu met het productieproces van die meubelmaker van doen?’ Misschien neemt u het boekje mee naar huis, omdat u wel benieuwd bent hoe uw meubels volgens de nieuwste meubelmaaktechnieken gemaakt gaan worden. Altijd leuk wanneer later in uw chique huiskamer het gesprek met de gasten even stil valt.
Deze vergelijking kwam bij mij op toen ik het boekje ‘Van traditioneel ontwikkelen naar Component Based Development, een migratiegids voor managers’ onder ogen kreeg. Volgens de auteurs is het boek bedoeld voor managers en consultants, aan wie ze in brede zin willen uitleggen hoe een organisatie van de traditionele manier van software-ontwikkelen kan overgaan naar het samenstellen van applicaties aan de hand van componenten (‘component based development’: cbd). Allereerst belichten ze de redenen om cbd toe te passen, en wel vanuit de gezichtspunten van de ontwikkelaar, de manager en de ‘business developer’ of marketing expert (ofwel de gebruiker). In het tweede deel gaan de schrijvers in op de vraag wat het betekent om met componenten te ontwikkelen, terwijl het derde deel is gewijd aan scenario’s die gevolgd kunnen worden om van een traditionele naar een cbd-omgeving te migreren. De auteurs gaan ook in op wat er zoal mis kan gaan bij de migratie. Het vierde en laatste deel is meer technisch van aard en behandelt aspecten als cbd-techniek, applicatieservers, ‘component brokers’, legacy-systemen en ‘partial legacy system wrapping’. Het architectuurdenken wordt eveneens toegelicht.
De schrijvers proberen duidelijk te maken dat cbd niet over techniek of over ICT gaat en dat daarom de hele organisatie op de hoogte moeten zijn van wat cbd allemaal vermag. Dat lijkt mij onzin. De eindgebruikers, marketingmensen of business developers (wie of wat dat ook moge zijn) hoeven helemaal niet in de gereedschapskist van de ontwikkelaars te kijken. Voor hen is het volstrekt irrelevant of de applicatie met componenten als legosteentjes in en aan elkaar wordt geklikt of in een 4GL, Cobol, C++, Java of XML wordt geschreven. Dat is het gereedschap van de ontwikkelaar. Leuk om te weten voor de eindgebruiker. Maar niet relevant. Het enige voordeel van cbd is of zou moeten zijn: een versnelling van het ontwikkelproces en een forse kostenreductie in vergelijking met de situatie waarin van ander ontwikkelgereedschap gebruik wordt gemaakt. Een belofte die wel meer is gedaan bij de introductie van nieuwe ontwikkeltools.
Voor het management is het echter wel degelijk van belang om wat meer van cbd af te weten. Werken met componenten vergt een nieuwe werk- en denkwijze op de ICT-afdeling. Zowel het algemeen als het ICT-management moeten erop bedacht zijn weerstand te ondervinden. Veel automatiseerders behoren immers niet tot het meest vooruitstrevende deel der natie. Cbd doet oude functies verdwijnen en nieuwe beroepen opkomen. Dit veranderproces behoort goed te worden begeleid. Daarom is het best een nuttig boekje voor zowel de ICT-manager als de Cobol-krasser die bepaalde ontwikkelingen op zich af zien komen en een eerste indruk willen krijgen van cbd. Jammer is dat het boekje erg veel opmerkingen herbergt in de trant van: ‘Begin met een realistische ambitie die past in de huidige kaders en zorg ervoor dat er een leerschool ontstaat om straks de volgende stap te kunnen maken naar meer en breder cbd’ of ‘Het opzetten en inrichten van de organisatie mag niet onderschat worden’. Deze vallen toch echt onder de categorie ‘dooddoeners’.
Net als op tal van andere terreinen in de ICT-wereld is ook op cbd-gebied een richtingenstrijd aan de gang. Er bestaan drie componentenmodellen: Com, Java Beans en Corba. In het boek wordt een beknopte beschrijving gegeven van de modellen. Op basis van die beschrijving doen de auteurs een uitspraak over de overlevingskansen van de drie modellen. De verwachingen voor Corba zijn het minst gunstig. Voor Java en Dcom (Com+) gelden ‘ongeveer dezelfde toekomstverwachtingen’. Onduidelijk is of ‘dezelfde’ terugslaat op de verwachting voor Corba, of dat het alleen voor de twee genoemde componentmodellen geldt. Is dat laatste het geval, dan wordt die verwachting positief noch negatief gekwalificeerd. De vraag rest dan voor welk model gekozen moet worden. Moeilijk, want ‘die keuze heeft grote gevolgen voor de toekomst’ en ‘wordt voor een aantal jaren gemaakt en ‘er is geen (eenvoudige) weg terug’. Ja, ‘de keuze van het model kan het best gezien worden als een kruispunt, waar vandaan drie wegen vertrekken, die elkaar zoals het er nu uitziet niet meer kruisen’. Dan is het uitermate onbevredigend om als conclusie onder het kopje ‘Moet ik kiezen?’ te lezen: De keuze is dus wel degelijk van groot belang (dat wisten we onderhand wel), maar door de selectie en ontwikkeling van nieuwe componenten goed aan te pakken, kunnen de verstrekkende gevolgen van de keuze gereduceerd worden.’ Ook dat is een opmerking die valt onder de categorie ‘dooddoeners’. Maar hij doet het misschien wel goed, wanneer het gesprek eens stilvalt.
Mark Hoogenboom en Marcel Noordzij. Van traditioneel ontwikkelen naar Component Based Development. Een migratiegids voor managers, , Academic Service, ISBN 90 395 1418 6. Prijs: 49,50 gulden
