De voor- en nadelen van het zelf ontwikkelen van applicaties versus het aanschaffen van pakketten zijn al jaren onderwerp van gesprek. Meerdere wegen leiden naar Rome, maar voor conventionele zakelijke applicaties als salarisadministratie, orderinvoer en voorraadbeheer hebben de pakketten het gewonnen. Immers, waarom zou je je voorraadbeheer op een andere manier willen verzorgen?
Het ‘jaar 2000’-probleem is een flinke steun in de rug van pakketleveranciers, omdat veel organisaties de knoop doorhakken en hun oude systemen liever vervangen dan testen en opknappen.
De komst van client/server-architecturen is ook van invloed geweest. Veel organisaties beschikten niet over voldoende kennis van relationele databases en gui-programmering. Dat gold echter ook voor veel pakketleveranciers, waarvan sommige het moesten afleggen tegen nieuwe leveranciers die de nieuwe architecturen beter wisten te benutten.
Evenzeer relevant – en nauw verbonden met het client/server-model – was het concept van een geïntegreerde applicatiesuite. De database diende hierbij als een gemeenschappelijke entiteit. Dat bood een oplossing voor veel van de klassieke problemen die voortvloeiden uit de aanwezigheid van verschillende applicaties, zoals scheduling van transacties en duplicatie van gegevens.
Downsizing was een andere factor. Eigen ontwikkelteams concentreerden zich op mainframe-applicaties en in mindere mate ook op DEC VAX-systemen. Unix en client/server wonnen sterk aan populariteit en vormden daardoor ook een vruchtbare voedingsbodem voor pakketleveranciers.
Pakketten hebben het altijd goed gedaan in de markt voor kleinere applicaties, omdat slechts weinig kleine organisaties over voldoende ontwikkelcapaciteit beschikken. De leveranciers van deze pakketten zijn doorgegroeid naar midrange-systemen, met name Unix en AS/400, maar waren niet klaar voor de sterke groei van de grote applicatiepakketten.
De status van pakketten verschilt per sector. In de industrie bloeiden Baan en SAP op, ten koste van Mapics en dergelijke. Omdat de industrie ook financiële pakketten nodig heeft, is het die leveranciers gelukt hun marktaandeel ook daar te vergroten. Oracle is ook een bron van pakketten. Dit is een voorbeeld van een leverancier die begon met basistechnologie, het rdbms, maar nu probeert zijn klanten te binden door ook ontwikkeltools en zelfs complete applicatiepakketten te leveren.
Het ligt allemaal niet zo simpel als het lijkt. Een pakket bespaart programmeerwerk, maar veel meer ook niet. Applicaties moeten nu eenmaal ook ingevoerd worden. Daarvoor is nog steeds een ontwerp nodig, en kennis, training, implementatie en operationeel beheer. De integratie wordt sterk overdreven. Immers, hoeveel hebben een systeem voor productiebeheersing en een systeem voor personeelsadministratie nu werkelijk gemeen? In alle gevallen moet naast de aanschaf van het pakket nog een heleboel gebeuren. Daarvoor moet een organisatie dan weer een intern ontwikkeltraject starten, of een ander, incompatibel pakket aanschaffen.
Het toevoegen van een geïntegreerde module aan een bestaand pakket is moeilijk, zo niet onmogelijk. Alleen als de pakketleverancier de database invult (en dan bedoel ik een repository, en niet alleen een gegevensmodel), is het mogelijk om dezelfde database veilig te gebruiken. Dat komt maar zelden voor. Het wordt nog erger in client/server-systemen waar zakelijke modules gedeeld moeten worden; dat ligt op een hoger niveau dan de gegevens. Het netto effect is dat de meeste toegevoegde functies afzonderlijk worden ontwikkeld met hun eigen database, waarbij de twee databases gegevens uitwisselen. Dan ontstaat precies hetzelfde probleem als het pakket had moeten oplossen. Het zou interessant zijn om te weten welk percentage van een totale applicatiesuite werkelijk wordt vervangen als een organisatie in een echte praktijksituatie een belangrijk pakket introduceert. Mijn intuïtie zegt niet meer dan 60 procent. Dit betekent dat het nu al te laat is om het ‘jaar 2000’-probleem op te lossen door op pakketten over te schakelen.
Wat is het alternatief? Case is een voor de hand liggend antwoord, gesteld dat de gebruikersorganisatie overweg kan met tools voor het opstellen en wijzigen de zakelijke eisen. Daarna kunnen codegeneratoren de applicatie bouwen. Dit is praktischer dan veel mensen tegenwoordig geloven, maar zeker niet perfect. Het echte antwoord luidt herbruikbare code, waarbij een hele suite met herbruikbare bedrijfsobjecten beschikbaar is en applicaties worden gebouwd door de noodzakelijke modules aan te spreken. Om dit in de praktijk ook echt te kunnen realiseren, is rigoureuze definiëring van de functie van deze objecten essentieel. Daardoor kunnen ze slechts in combinatie met een repository van praktische waarde zijn. Alleen op die manier zijn het ontwerp, de runtime en het ontwikkelproces te coördineren. Deze ontwikkeling is al in volle gang en zal nog geruime tijd doorgaan. Ik denk dat we binnen tien jaar weer van de pakketten af zijn. Tegen die tijd ontwikkelen we alles weer zelf – maar dan met herbruikbare, modulaire technologie.
