Software-ontwikkeling is er de laatste jaren niet op vooruitgegaan. Client/server-software heeft het gui-interface naar de voorgrond gebracht en daarmee spaghetticode in de hand gewerkt, iets waarvan iedereen dacht dat het eind jaren tachtig was uitgeroeid. De huidige case-tools zijn best indrukwekkend, maar ze zijn niet geïntegreerd met andere case-tools. Bovendien wachten ze nog steeds met smart op dé repository. Is Microsofts Platinum misschien het antwoord?
Moderne ontwerptools bewijzen hun diensten bij het partitioneren van code. Deze tools maken onderscheid tussen presentatie-, zakelijke en gegevensfuncties en produceren zo overzichtelijke, beheersbare entiteiten. Tegenwoordig ligt de nadruk op dunne clients; zulke architecturen zijn veel robuuster en beter te onderhouden. Er zijn ook uitstekende codegeneratoren op de markt; sommige zijn gericht op de meer conventionele systemen (APS en MVS/Cobol), terwijl andere gebaseerd zijn op een nieuwe generatie object-applicaties (Dynasty en Forte). Zelfs Oracle en IBM zien nu in dat systemen voor het ontwikkelen van software voor andere platformen belangrijk zijn; ze komen met producten op de markt die ook op andere systemen draaien.
Intussen stellen vele organisaties zichzelf de volgende vraag. Voorraadbeheer is niets nieuws. Waarom zouden we een applicatie ontwikkelen die als twee druppels water lijkt op applicaties die al door andere organisaties wordt gebruikt? En zo ontstonden de applicatiepakketten.
De eerste pakketleveranciers verkochten de broncode van hun product aan de gebruiker. Gebruikers moesten en zouden de broncode hebben! Een enorm onderhoudsprobleem was hiervan het gevolg: gebruikers brachten zoveel lokale modificaties op de broncode aan, dat het resultaat niet meer aansloot op nieuwe releases en upgrades. Vandaag de dag worden er applicatiepakketten ontwikkeld die voor een specifieke organisatie op maat kunnen worden gesneden, zonder dat hiervoor de broncode hoeft te worden aangepast.
Het volgende probleem, dat overigens nog steeds speelt, was integratie. Er werden pakketten geïnstalleerd, die weer werden aangesloten op zelf ontwikkelde applicaties. Het probleem hierbij is dat de grenzen tussen applicaties vaak niet duidelijk worden gedefinieerd, zodat overlapping onvermijdelijk wordt. Bij het migreren van de ene applicatie naar de andere treden nog meer problemen op. Het beheer van zulke diensten is complex en zeer gevoelig voor operationele storingen.
Deze integratieproblemen leidden tot de laatste applicatiepakketten van SAP, Baan, Oracle en dergelijke. Deze leveranciers claimen volledige integratie op basis van een gemeenschappelijk database-model, met flexibele bedrijfsmodules daar bovenop. Dit principe werkt voor een groot deel, maar niet helemaal. Je zou zeggen dat deze pakketten een groot deel van het probleem zouden oplossen, maar er blijft nog steeds zo’n 30 tot 40 procent aan niet-geïntegreerde software over.
Deze extraatjes worden gerealiseerd door middel van andere, incompatibele pakketten en zelf ontwikkelde systemen, zowel nieuw als bestaand. De integratie is verbeterd, maar dit schept tegelijkertijd een nieuw probleem, omdat toegang tot de pakketten via een specifiek api verloopt, dat alleen bij dure, gespecialiseerde softwarehuizen te krijgen is!
Werkstroom- en datamartmodules binnen het pakket zouden het probleem moeten oplossen, maar werkstroom zou betrekking moeten hebben op alle functies binnen een bedrijf, niet alleen op de functies die toevallig in het pakket zitten. Evenzo moet een gegevenspakhuis worden beschouwd als een systeem voor het hele bedrijf dat moet worden gevoed met gegevens uit alle mogelijke bronnen. Werkstroom, ‘groupware’ en gegevenspakhuizen dienen daarom onafhankelijk te zijn van applicatiepakketten.
De laatste ontwikkeling zijn systemen op basis van componenten. Deze nieuwe pakketten, zoals SAP R/3 en Baan, zijn gebouwd op de dunne client-architectuur; de bedrijfsmodules worden echter niet vrijgegeven als componenten voor externe ontwikkeltools.
Er zijn gegeneraliseerde ‘suites’ met componenten voor gui-interfaces, maar voor bedrijfsfuncties zijn deze suites nog maar dun gezaaid. Toch is vooruitgang op dit vlak onvermijdelijk; let op ontwikkelingen als IBM’s San Francisco-project. Zijn de pakketten van morgen een combinatie van componenten en een repository? De conclusie is dat de balans nu is doorgeslagen in het voordeel van de pakketten, maar dat componenten op den duur kunnen leiden tot een come-back van zelf ontwikkelde systemen. De ontwikkeling daarvan zal echter in niets lijken op de aanpak zoals we die tegenwoordig kennen.
Als zakelijke applicaties baat hebben bij pakketten, hoe zit het dan met andere IT-systemen? De volgende grote ontwikkeling zijn pakketten voor het werken met gegevenspakhuizen. Sommige leveranciers komen met belachelijke claims over ‘drop-and-go’ gegevenspakhuizen, maar die kunnen we gevoeglijk in de wind slaan. (Binnen 25 dagen een gegevenspakhuis – wie kan er binnen 25 dagen alle gegevensbronnen inventariseren?)
Rolap- en Olap-tools bieden functies om analytische modellen te bouwen met behulp van componenten. Op dit niveau zijn pakketten voor gegevenspakhuizen te ontwikkelen, bijvoorbeeld met behulp van Information Advantage of SAS, net zoals Cobol en case-tools worden gebruikt voor zakelijke applicaties. Je zou voor elke branche een standaard analysepakket kunnen ontwikkelen, in navolging van de ontwikkelingen op het gebied van traditionele systemen, waardoor zelfs een nieuwe generatie softwarehuizen zou kunnen ontstaan.
