Van de ene kant hoor ik misnoegen over de ondergeschikte rol die BI zo vaak speelt. Wij als BI professionals vinden dat “natuurlijk” niet terecht. Ik hoor collega’s verzuchten hoe jammer ze het vinden dat meer “geavanceerde” data toepassingen (doorgaans) buiten beeld blijven. Nadat een DWH-, rapportage- of OLAP omgeving is ingericht blijft men maar al te vaak steken bij redelijk “platte” rapportages. Een aanzienlijke investering in het fundament krijgt zo niet de gewenste of beoogde ROI.

Maar van de andere kant lijkt men soms wars van zelfkritiek. Sommigen gaan zelfs zo ver dat ze menen dat BI zich boven business cases moet verheffen. Alsof het vanzelfsprekend is dat bedrijven in BI moeten investeren! Persoonlijk ga ik er van uit dat directies doorgaans rationeel en verstandig besluiten. En als BI dan “buiten de boot” valt, hebben we kennelijk onze toegevoegde waarde onvoldoende aangetoond.

Mijn keuze voor dit dierbare vak komt voort uit de rotsvaste overtuiging dat wij een centrale rol spelen bij belangrijke innovaties in de manier waarop bedrijven worden aangestuurd en beoordeeld. En de enige manier om in de “corporate foodchain” omhoog te klimmen lijkt me ook de Koninklijke weg: door keer op keer onze toegevoegde waarde aan te tonen. Ook met kwantitatieve business cases waarin de bijdrage aan bedrijfsresultaten transparant wordt aangetoond. Door een “verhaal” te destilleren uit ruwe gegevens. En door te helpen beslissingen steeds vaker te baseren op feiten i.p.v. onderbuikgevoel.

Maar als je de verhalen over deze producten leest en aanhoort, ontstaat wel een déjà vu gevoel. We gaan daarom terug in de tijd om dit toe te lichten.

Begin jaren tachtig kwamen de eerste SQL-producten op de markt. Het duurde even voordat ze door de markt geaccepteerd werden, maar zeker aan het einde van de jaren tachtig waren ze de dominante database servers. Zo begon de hegemonie van SQL in de databasewereld, die tot op de dag van vandaag voortduurt.

De eerste applicaties die ontwikkeld werden, waren voornamelijk administratieve applicaties. Sommigen wilden echter meer technische applicaties ontwikkelen. Karakteristiek aan dat soort applicaties is dat de objecten die gemanipuleerd worden zeer complex zijn. Technische applicaties ontwikkelen op een SQL-database server was toentertijd een uitdaging. In diezelfde periode kwamen ook de eerste object oriented programmeertalen op de markt, die zeer snel door de technische wereld werden geadopteerd. Maar even snel werd duidelijk dat het huwelijk tussen OO-talen en SQL niet ideaal was. Sommige leveranciers brachten dan ook  speciale OO-database servers op de markt. Deze producten sloegen de gegevens niet als tabellen en kolommen op maar als objecten, en ondersteunden geen SQL maar vaak eigen proprietary talen. Hun marketing pitch was dat met deze database servers applicaties ontwikkeld konden worden die met SQL nauwelijks mogelijk waren.

In het begin hadden zij zeker gelijk, maar uiteindelijk werden de klassieke SQL-producten zodanig verbeterd, dat ze de technische applicaties wel konden ondersteunen. Dit leidde er toe dat de nieuwere OO-database servers toch uit de markt verdrongen werden. Momenteel kom je ze alleen nog in kleine nichemarkten tegen.

Hetzelfde gebeurde met datawarehousing in de jaren negentig. In het begin hadden de klassieke SQL-producten moeite om de zware en typisch datawarehouse-gerichte query’s snel te verwerken. Dus kwamen er database servers op de markt die gegevens op een andere wijze opsloegen (dus niet meer in tabellen en kolommen) en andere databasetalen boden. Dit worden ook wel OLAP- of multidimensionale database servers genoemd. Ondertussen zijn de SQL-producten uitgebreid met mogelijkheden om ook die zware query’s snel te verwerken. Zeker de zogenaamde datawarehouse appliances (die allemaal SQL gebaseerd zijn) leveren soms indrukwekkende prestaties. Hiermee is de behoefte aan speciale, niet-SQL gebaseerde database servers sterk afgenomen.

Tenslotte hebben we in de afgelopen jaren wederom een nieuw type workload gekregen: het opslaan, bewerken en terugzoeken van XML-documenten. Ook dat ging in het begin lastig met SQL. Dus werden er weer speciale database servers gebouwd, speciaal ontwikkeld voor XML. Echter, in de huidige versies van DB2, Oracle en SQL Server, is ondersteuning voor XML prima geïntegreerd met SQL. Wederom werd een groep niet-SQL database servers langzaam verdrongen.

Kortom, in de historie van SQL-database servers hebben we nu al minstens drie keer gezien dat deze producten een nieuw type workload initieel niet aan kunnen. Er worden dan database servers ontwikkeld die speciaal voor dat type workload bestemd zijn. Ze zijn niet gebaseerd op SQL en slaan hun gegevens niet in tabellen en kolommen op. Iedereen is daar dan in het begin laaiend enthousiast over. Wat logisch is, want eindelijk kunnen bepaalde organisaties dan hun gewenste applicatie ontwikkelen. De producten krijgen dan enkele jaren volop aandacht, totdat de leveranciers van de SQL-producten een acceptabele oplossing bedenken, waardoor de niet-SQL producten langzaam uit de markt gedrukt worden.

De grote vraag is nu: gaat dit nu ook weer met de NoSQL stroming gebeuren, is ook deze een kort leven in de spotlights beschoren en worden ook zij straks weer uit de markt verdrongen? Als we naar de geschiedenis kijken, dan is het antwoord duidelijk: ja. Of vormen zij de bekende uitzondering? Over twee of drie jaar zullen we het waarschijnlijk wel weten. Ondertussen zou ik organisaties aanraden voorzichtig te zijn met het adopteren van deze technologie. Want als u er nu in investeert en over enkele jaren blijken ze toch verdrongen te worden, dan heeft u applicaties ontwikkeld die niet portable zijn, want ze gebruiken een proprietary databasetaal. Maar ik zou ze niet negeren, want er zijn nu applicaties die we momenteel niet met de huidige SQL-producten kunnen ontwikkelen en dan is een dergelijke NoSQL-oplossing het enige antwoord.

Rick F. van der Lans is zelfstandig IT-consultant.

Verscheen eerder als column in Database Magazine 1-2010.

Toch bevredigde mijn reactie mezelf niet, want we doen de dingen inderdaad anders dan de meeste collega bedrijven. De afwijkingen zitten soms in high tech en/of high concept waarover we in dit blad schrijven, maar minstens zozeer in de ouderwetse aanpak die wij voorstaan en waarover we nooit iets publiceren. Onze systemen zijn modelgedreven en relatief monolitisch opgezet. Alles wat trendy en complexiteitsverhogend is – SOA, event-gedreven werken, workflow, multi-tool systeemontwikkeling – mijden we als de pest, tenzij er harde bedrijfseisen zijn die dat onmogelijk maken. Als we ons wagen aan nieuwigheden dan proberen we dat volgens ons ouderwetse paradigma aan te pakken. Zo denken we nu na over een vorm van modelgedreven SOA voor de Polisadministratie, want net als elders is ook bij ons SOA een productiviteitskiller. Maar telkens als ons iets lukt wordt de lock-in groter en worden we meer kwetsbaar voor kritiek.

En toen kwam er kort geleden op een heidag van ons bedrijf een inkoopspecialist het een en ander vertellen over Europese Aanbestedingen. Dat deed hij aan de hand van de zogenaamde Kraljic-Matrix (even googelen). Op die matrix is de waarde van een ingekocht product uitgezet tegen de complexiteit van de markt inclusief het aantal aanbieders. Als beide laag zijn dan gaat het over commodity’s zoals kantoorbenodigdheden of schoonmaakwerk. Systeemontwikkeling zit volgens de aanbestedingsexpert hoog op beide assen: het is moeilijk en duur en ook de markt is complex met onaangenaam weinig aanbieders. Hier vind je strategische producten en een onvermijdelijke lock-in, ongeacht met wie je zaken doet. Wat mij betreft klopt de beschrijving maar klopt de onvermijdelijkheid van een lock-in niet. Europese Aanbestedingen leiden vooral tot lock-ins omdat alleen de allergrootste aanbieders aan de voorwaarden voldoen. Een slim, klein bedrijf kan met een man of tien best een systeem als de Polisadministratie of de GBA bouwen. De kans zoiets te doen ontstaat echter alleen als eerst een groot ICT bedrijf een project heeft verprutst en zelfs dan is er bijna altijd wel een legacy systeem waarop kan worden teruggevallen. En het is dáár dat je de echte <cur>lock-in vindt: bij de beheerders van ouwe troep die er maar niet uit gaat; zeg maar de erven PinkRoccade. Ik vraag me zelfs af waarom de ontwikkeling van nieuwe systemen überhaupt in het strategische kwadrant van de Kraljic-Matrix zit. Als er echte concurrentie is, de opdrachtgever de regie voert maar de uitwerking zoveel mogelijk overlaat aan de leveranciers (meervoud!) en ook kleine specialisten de kans geeft, dan wordt systeemontwikkeling geen commodity maar beslist veel minder strategisch. Zoals het bij de overheid gaat is lock-in bijna een bewuste keuze van de opdrachtgevers. Een voorbeeld: één van mijn partners ondersteunt een opdrachtgever bij de bouw van een systeem. De opdracht moest worden gegund aan één van de zes grote mantelpartijen, maar de ontwikkeling moet gebeuren met Sharepoint. Resultaat: slechts twee offertes waarvan er één onacceptabel is en de andere gewoon slecht. Onnodig te zeggen dat Sharepoint specialisten niet in aanmerking komen. Afijn, het ontwerp is een factor drie uitgelopen en als de inhuurtarieven niet zo laag waren dan zou het voor de opdrachtgever tenminste een financieel drama worden, zo niet erger. Het enige waarvan mijn partner nu zeker is, is dat het een financieel drama voor de ICT-leverancier gaat worden. Dat wordt dus weer zo’n fijne win-win relatie waarbij tijdens de bouw de leverancier bloedt en de verliezen na oplevering weer dubbel en dwars worden terugverdiend. Dát is lock-in!

Nog een casus. April 2009 gooit de Belastingdienst alle externen eruit: minstens 500 man, want de budgetten zijn overschreden – in april! Exit SOA! Exit event-gedreven toekenning van toeslagen! Exit Capgemini, Ordina en al die andere grote jongens. Niks lock-in. Heeft Kraljic heeft het mis? Of zouden al die projecten zijn uitgedraaid op mislukkingen en was mijn gevatte opmerking gewoon de waarheid?

Terwijl ik dit schrijf bedenk ik me dat ik deze column een minder cynisch einde kan geven. Neem nou die Polisadministratie. Even los van een aantal plussen en minnen is dat systeem nu bijna twee jaar operationeel. En we zitten iets over de helft (…) van het bedrag waarvoor dat systeem oorspronkelijk was aanbesteed bij een grote jongen. En we hebben geen verliezen geleden die we moeten terugverdienen. Systeemontwikkeling hoeft niet tientallen of zelfs honderden miljoenen te kosten. De ene lock-in is de andere niet.

Rene Veldwijk (Rene.Veldwijk@FAAPartners.com) is partner bij FAA Partners.
 
Verscheen eerder als column in Database Magazine 1-2010

Drie jaar geleden ontwierp ik voor Database Magazine een grote poster van ongeveer 1 m2 met de titel 'Het Business Intelligence Framework'. In deze poster werd enigszins op schematische wijze weergegeven hoe data van de bronsystemen via veel producten en technologieën terecht komen in diverse soorten rapporten en voor analyse beschikbaar komen. Tevens werden de verbanden tussen verschillende termen aangegeven.

Deze zomer ben ik begonnen met een vernieuwde versie van deze poster. Na enkele weken stoeien, besloot ik de insteek te wijzigen. In de nieuwe poster worden nu alleen maar technologieën en producten opgenomen die mogelijkerwijs door leveranciers geboden zouden kunnen worden om een datawarehouse-omgeving op te bouwen. Dus zaken als methodes en aanpakken komen er niet meer in voor. Vandaar dat de naam enigszins aangepast is: het 'Business Intelligence Technology Framework'. Het voordeel van deze gewijzigde aanpak is dat het eenvoudiger wordt om de BI-stack van een leverancier in kaart te brengen, ofwel het staat toe om de volledigheid van een leverancier’s BI-stack te controleren. Tevens kunnen we de BI-stacks van leveranciers hiermee vergelijken.

Ondertussen is voor enkele leveranciers gekeken in hoeverre ze alle producten in het BITF ondersteunen. Wat dan direct in het oog springt is dat leveranciers als IBM, Microsoft en Oracle, die zeer complete BI-stacks aanbieden, wat betreft het geïntegreerd beheren van metadata matig scoren. Uiteraard slaan al hun producten, dus hun ETL-producten, rapportageproducten, database servers en datakwaliteitproducten, ergens metadata op. Echter, er is geen product of module waarmee al die metadata geïntegreerd getoond en geïntegreerd bestudeerd kunnen worden.

Willen wij dus een geïntegreerd beeld krijgen van alle metadata, dan zullen we zelf metadata bij elkaar moeten brengen. In feite betekent dit dat we eenzelfde exercitie moeten ondernemen als die we voor onze data moeten uitvoeren. Naast integratie van data krijgen we dan ook integratie van metadata. Doen we dit niet en kunnen we dit niet, dan worden impactanalyse en lineage erg lastig.

Let wel, het geldt niet voor alle leveranciers. Als we bijvoorbeeld de BI-stacks van SAS of Information Builders bestuderen, zien we dat die veel meer de metadata van al hun producten centraal opslaan, met alle voordelen van dien. Uiteraard hebben SAS en Information Builders het voordeel dat ze bijna alle software zelf gebouwd hebben. Terwijl zeker IBM en Oracle erg veel modules gekocht hebben en het kost een leverancier uiteraard tijd om die serieus te integreren met de reeds bestaande producten.

Het blijft vreemd dat we nu al minimaal dertig jaar weten hoe essentieel metadata zijn en dat het belangrijk is dat deze ook centraal beheerd worden, dat we nu al dertig jaar bezig zijn om metadata goed georganiseerd te krijgen, maar toch moeten we concluderen dat het zelfs bij relatief nieuwe producten nog steeds niet ideaal geïmplementeerd is. Waarom blijven metadata toch altijd het kind van de rekening? Door de jaren heen zijn er al legio standaarden beschikbaar gekomen om metadata te registreren en uit te wisselen, maar ook dat heeft niet erg geholpen.

Voor veel klanten zou het beter zijn als leveranciers hun aandacht tijdelijk zouden verschuiven. In plaats van hun portfolio uit te breiden met zelfontwikkelde producten en met producten van andere leveranciers, zouden ze zich moeten richten op het ontwikkelen van een geïntegreerde metadata oplossing. Hierbij zouden alle metadata geïntegreerd bestudeerd en geanalyseerd moeten kunnen worden. Hoe ze dat doen is van ondergeschikt belang, als ze het maar doen. Het zou voor gebruikers het leven een stuk eenvoudiger maken.

Rick van der Lans is zelfstandig IT consultant.
Deze column verscheen eerder in Database Magazine 8-2009.

Ik geef een voorbeeld. In de jaren negentig was het front-end product Uniface extreem populair – zie de DB/M’s uit die tijd. Het succes van Uniface was gebaseerd op de mogelijkheid om allerlei data(base)platforms te ondersteunen; van RDBMS’en via C-ISAM file management systemen tot zelfs platte bestanden. Voor veel bedrijven die toen al een grote hoeveelheid datalegacy hadden, was dit an offer they could not refuse. Als consultant had ik soms veel plezier van de volgende aanpak. Ik vertelde mijn klanten dat het toch wel briljant was dat een klein Nederlands bedrijf er in was geslaagd om in korte tijd te doen wat nog nooit was gepresteerd: het ontwikkelen van een database (meta)optimizer die tegen alle data-omgevingen aantrapte. Daar had het in de USA toch twee decennia gekost. Ging men nadenken dan legde ik uit dat Uniface natuurlijk helemaal geen optimizer had en vaak allerlei performanceproblemen opleverde. Ander voorbeeld. Toen we met ons bedrijf FAA Partners begonnen hadden we veel last van een concurrent genaamd Utopics, die net als wij flexibele systemen verkocht. Flexibiliteit was toen een kleine hype en database-onafhankelijkheid was daar een uiting van. Het verhaal van Utopics was, kort samengevat: “alles kan”. Ons verhaal was dat flexibiteit op ICT-gebied alleen te bereiken is als je bereid bent om diep na te denken en harde keuzes te maken: de flexibele architectuur als contradictio in terminis. Dat was natuurlijk een wat minder gemakkelijk verhaal. Wat dan vaak hielp was wederom de extreme positie. “Wilt u een echt flexibel systeem voor een prikkie? Geen probleem. Koop MS-Word en alles kan. Ook dat leidde soms tot nadenken.”

Maar die mooie tijden zijn voorbij. Nu word ik regelmatig geconfronteerd met absurdistische standpunten, maar dan door mensen die bloedserieus zijn. Zo werd een tijdje terug een systeem dat wij hadden gebouwd ge-audit door het bedrijf Atos dat het in beheer zou nemen. Grootste punt van kritiek: “het systeem is niet modulair opgezet want er wordt in de database gebruik gemaakt van verwijzende sleutels.” Hoe idioot moet je zijn om zoiets te denken – laat staan op te schrijven? Nadat we van de schrik bekomen waren hebben we gemeld dat het de schuld van de klant is, die het heel belangrijk vindt dat elke factuur moet verwijzen naar een debiteur. We hebben wel toegegeven dat we zelf de fout hebben gemaakt om meerdere gegevenssoorten in één tabel te proppen. Een andere. Topconsultant Gartner geeft een klant van ons in overweging om te kiezen voor XML database technologie. Argument: bij XML databases heb je geen database-reorganisatie als de gegevensstructuur verandert. Wat zeg je op zoiets? Niets. Ik had natuurlijk mijn oude argument uit de kast kunnen halen om dan meteen maar te kiezen voor MS-Word als DBMS, maar iets zei me dat men anno 2009 de ironie niet meer zou herkennen.

 Uiteindelijk zal de wal het schip wel weer keren. Uniface is overgenomen door Compuware en uit beeld verdwenen. Utopics is overgenomen door Ordina en er geluidloos in opgegaan, wat veel rechtszaken met teleurgestelde klanten heeft gescheeld. Wat er met Atos en Gartner gebeurt zal de tijd leren. Eind goed al goed? Zeker, want de oprichters van Uniface en Utopics zijn met vele miljoenen vertrokken naar de eeuwige golfvelden terwijl ondergetekende voortploetert. Koot & Bie hebben gelijk: de realiteit is zijn eigen persiflage en niemand lacht meer.

René Veldwijk is partner bij FAA Partners.

Aangezien ik juist terug kwam van de druivenoogst in Frankrijk, was ik geïnspireerd door de gelijkenissen. Een echt goede druivenoogst is niet mogelijk zonder (voldoende) vrouwen in de equipe. Mannen en vrouwen zijn nu eenmaal anders. Hebben andere kwaliteiten. En je hebt de complete pool aan vaardigheden nodig om tot het best mogelijke resultaat te komen.

Druivenoogst is fysiek zwaar, heel zwaar werk. Maar je hebt óók fijn motorische vaardigheden nodig (o.a. bij “trier”), waar vrouwen vaker in excelleren. Vrouwen hebben daarnaast hun eigen, unieke bijdrage aan de sfeer binnen het team. En nogmaals, je hebt al die bijdragen nodig om de stress het hoofd te bieden binnen een equipe die korte tijd heel nauw en intensief moeten samen werken. Zonder “balans” staat het team bij voorbaat op achterstand.

En zo dwaalden mijn gedachten af naar een verscheidenheid aan BI teams waar ik in de loop der jaren mee heb mogen samenwerken. Het viel me op hoeveel creatiever en effectiever de teams zijn met meer diversiteit. Daar is overigens ook veel empirische evidentie voor. Bijvoorbeeld dit rapport van Catalyst of bijvoorbeeld deze studie van McKinsey.

Wat doet uw organisatie om diversiteit te vergroten?

Dan Linstedt sprak niet over zijn pronkjuweel Data Vault, maar ging in op de verschillende factoren die de komende jaren impact zullen hebben op Datawarehousing & BI ‘as we know it’.

Linstedt beschreef het Operational Datawarehouse, dat bestaat uit een Data Vault EDW met virtuele marts en een dynamische mining-engine. Non-SOR batchdata en (semi-)ongestructureerde data worden via een staging area geladen, via een webinterface worden SOR real-time data ingevoerd, en er zijn dynamische kubussen beschikbaar. Linstedt ging uitgebreid in op de manier waarop ongestructureerde data via een speciale Processing Engine footprints in het EDW moeten krijgen.

Dr. Richard Hackathorn deed deze zomer een uitgebreid onderzoek naar Datawarehouse Appliances en deelde de opgedane kennis met de aanwezigen.

Naast Sun Oracle (Exadata DB Machine), IBM (InfoSphere Balanced Warehouse en Smart Analytics) en specialisten zoals Teradata (Appliance Family), Netezza en Kognitio heeft nu ook Microsoft bekend gemaakt met een DWH-appliance te komen. Onder druk van het datavolume, de toegenomen eisen op het gebied van snelheid en de veelheid aan datatypen kan de vraag naar machines die om kunnen gaan met Massive Parallel Processing (MPP) alleen maar toenemen.

Rick van der Lans besprak zijn Data Delivery Platform model, dat furore maakt in de VS en waarbij onder meer de scheiding tussen applicatie en data – die overal in de IT-wereld standaard is, behalve bij BI – ook kan worden doorgevoerd naar rapportages. In het tweede deel van zijn presentatie ging hij in op de vraag of BI as a Service nu een hype is of realiteit. Feitelijk is het beide: de belangstelling neemt snel toe en aan de andere kant wordt de dienst al in de praktijk aangeboden. De drijfveer is meestal dat een organisatie af wil van de hele datawarehouse-omgeving en kiest voor de flexibiliteit van het werken met een externe leverancier, die bovendien deskundig is en vaak fysiek en digitaal beter beveiligd.

Hans Lamboo is hoofdredacteur van Database Magazine en BI-platform

Laten we kijken naar de persoonlijke, zakelijke en ethische problemen die aan deze intimiteit kleven. Allereerst: moet je als externe je tijd schrijven? De klant kan zoiets nauwelijks verbieden maar voor de betere professional is tijd schrijven in principe not done. Behalve dan dat wie werkt voor een softwarehuis vaak wordt geacht om wekelijks 40 uur billable te zijn. De integere externe die niet vrijaf neemt besteelt dus zijn werkgever. Dus schrijven de meeste externen toch maar hun uren. Als ze deugen dan voelen ze zich daar niet senang bij, al was het maar omdat elke professional vindt dat de kwaliteit van zijn/haar werk niet afhankelijk mag zijn van de relatie met de klant. Een werkgever moet zijn medewerkers betrokken houden, maar de werkgever van externen is iemand anders. Sommige ICT-werkgevers zijn er beducht voor dat hun medewerkers meer loyaliteit voelen naar de klant dan naar het eigen bedrijf. Die ontmoedigen natuurlijk deelname aan werkgerelateerde feestjes, zonder dat ze het hard verbieden, want de commerciële relatie moet natuurlijk goed blijven. Niet echt lekker als je daar als integere ICT-professional tussen zit. En als we het over commercie hebben: het is natuurlijk voor een externe geweldig als je door je klant wordt gezien als belangrijk, maar dat zou voor de klant juist reden moeten zijn om externen enigszins op afstand te houden. Sommige externen willen op een gegeven moment ook zelf iets anders gaan doen en dan is het vervelend als je door je klant in de watten wordt gelegd. Je kunt zeggen dat het commercieel slim is om een externe kracht zo aan zich te binden, maar volgens mij bestaan er methoden die zowel effectiever als chiquer zijn.

Misschien vindt u dat ik spijkers op laag water zoek, maar laten we de zaken eens omdraaien. Zoals ik belangrijk ben voor organisatie X, zijn er in organisatie X ook medewerkers die belangrijk zijn voor mijn bedrijf. Die mensen kunnen we betrekken bij intieme sessies van ons bedrijf in luxe conferentieoorden aan de Rivièra, zodat onze klanten maximaal betrokken blijven bij onze bedrijfsontwikkeling. Wie riep daar “Corrupt”? Natuurlijk is deze fictieve situatie niet helemaal symmetrisch, maar helemaal asymmetrisch is ze evenmin.

Overigens kom ik ook situaties tegen waarin de klant juist kil of zelfs vijandig staat tegenover externen, meestal wanneer er een project onder eigen regie uit de hand is gelopen maar men de externen niet kan lozen. Persoonlijk en zakelijk is deze situatie eenvoudig. De professionele externe heeft een brede acceptatiezone waarbinnen onaangename bejegening niet uitmaakt, maar op een gegeven moment is de externe foetsie en zit de opdrachtgever nog steeds met de problemen. Ik weet van één situatie waarin externen zo vijandig werden bejegend dat er op een gegeven moment zelfs eens een korte staking uitbrak. Dat bedrijf presteerde het ook om alle externen een formulier te laten invullen waarin ze alle zakelijke belangen van hunzelf en hun partner moeten aangeven. Wat te doen in zo’n geval? Eerst wilden we onze medewerkster terugtrekken maar uiteindelijk heeft ze op het formulier één partner en twee minnaars ingevuld, allemaal natuurlijk met belangen in dubieuze bedrijven. Als je als externe vertrekt, dan liever lachend.

Laat me deze column afsluiten met de opmerking dat alles hiervoor gaat over relaties tussen bedrijven en personen. Er zijn ook gewoon relaties tussen mensen onderling. Ik heb bij sommige (ex-)klanten vrienden voor het leven rondlopen en daar is niets mis mee. Zó beroerd is mijn sociale leven nou ook weer niet.

Maar wat is toch de reden dat de vele uitzonderlijk goede Open Source producten hun weg naar de gebruiker zo moeizaam vinden? Naar mijn mening heeft dat nauwelijks te maken met het gebrek aan vertrouwen in die producten, terwijl dat in discussies wel vaak als argument op tafel wordt gelegd. “We gaan geen hobbyproducten inzetten voor systemen waar de toekomst van ons bedrijf van afhangt,” citeert met dan een anonieme CxO. Een aantal Open Source producten is echter inmiddels het hobby-, zolderkamer- en sekteniveau wel ontstegen, daar kunnen we het echt wel over eens zijn. De betrouwbaarheid, schaalbaarheid, performance van de systemen en de supportmogelijkheden zijn professioneel, soms professioneler dan van de grote vendors.

Volgens mij is de langzame adoptie van Open Source te wijten aan angst voortvloeiend uit gebrek aan kennis. Het is de angst dat het systeem niet in de lucht kan worden gehouden bij problemen, moeilijk is om te updaten en lastig uit te breiden. Die angst vindt zijn oorsprong in een gebrek aan kennis over Open Source als fenomeen, de producten in het bijzonder – en eigenlijk technische IT-kennis in het algemeen. Want hoeveel echte IT’ers, mensen met een jarenlange informatica-opleiding, werken er op een willekeurige Nederlandse IT-afdeling?

Die vraag kunt u als lezer het beste beantwoorden. Komt u boven de 75 procent? Ik denk het niet. Daarin schuilt de oorzaak. Het werken met Open Source IT-producten vereist technische kennis, vakkennis. Het gebrek daaraan wordt door de grote vendors verbloemd door allerlei wizards en slimme GUI’s. Laat die eens weg en kijk dan eens of de betreffende medewerker van de IT-afdeling het systeem nog aan de praat weet te houden.

Het werken met MySQL is in kringen van webdevelopers de gewoonste zaak van de wereld. Die bezitten blijkbaar wel de kennis om vlot wat in elkaar te draaien, om even een patch-scriptje te inserten of een nieuwe functionaliteit te downloaden en in de bestaande omgeving te hangen. Dat maakt MySQL inmiddels een van de meest gebruikte databases in Nederland!

Mensen die wél verstand hebben van IT schromen niet meer om Open Source modules in te passen in hun omgeving of architectuur. Is Linux al langer gemeengoed, we zien nu ook in de databases en de BI-tooling steeds meer Open Source producten opduiken. Wat te denken van BIRT, van R, Kettle, Jaspersoft en Pentaho? En van Open Source databases zoals PostgreSQL en Firebird?

Open Source is behalve betrouwbaar, ook goedkoper en vooral flexibeler. De Community luistert naar vragen vanuit de gebruikers en reageert daar over het algemeen bliksemsnel op. Open Source IT. Je moet er wel een beetje verstand van hebben. Er valt met technische IT-kennis dus geld te verdienen!

Hans Lamboo is hoofdredacteur van Database Magazine.

Deze column verscheen eerder in Database Magazine 7-2009