Insights & Data Blog

Insights & Data Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

Generate or die

Een tijdje geleden werkte ik in een project met een college die de forse uitspraken niet schuwt. De collega poneerde de stelling “Generate or die”. Ofwel als je een script kunt generen, moet je het ook genereren. Kost wat kost.

Nu kan ik best een heel eind met hem meegaan, maar halverwege haak ik toch af. Laat me dat illustreren met een paar voorbeelden.

 

Ik ga halverwege mee.

Het eerste voorbeeld is het aanmaken van een database script. Als je een datamodel met een modelleringstool als PowerDesigner of Erwin maakt, is het heel verstandig om database scripts te laten genereren. Je weet dan zeker dat je geen fouten maakt in de vertaling van model naar database script. Een tikfoutje is zo gemaakt, maar het is hartstikke lastig om dat later weer te herstellen. Met een generatie vanuit een modelleringstool is de kans op zo’n foutje een stuk kleiner. Kortom: het is absoluut een aanrader om gebruik te maken van de generatiemogelijkheden van PowerDesigner of Erwin.

Het tweede voorbeeld is het aanmaken van scripts uit een ETL tool. Je hebt tools als Oracle Warehouse Builder en SAS Data Integration Studio die respectievelijk PL/SQL en SAS scripts op ETL gebied kunnen genereren. Die scripts zijn heel efficiënt opgezet en zitten vol slimmigheden die je er gratis met het generatieproces meekrijgt. In beide gevallen is het dan echt een aanrader om steeds gebruik te maken van de generatiemogelijkheden. Dat betekent dat iedere aanpassing eerst in Oracle Warehouse Builder of SAS DI Studio wordt aangebracht en dat je daarna het script opnieuw genereert. Op die manier blijf je gebruik maken van alle slimmigheden die je met het generatieproces meekrijgt.

In al die situaties ben ik het best eens met mijn collega, al zou ik de uitdrukking “Generate or die”  liever niet willen gebruiken. Ik ben wat vreedzamer aangelegd.

 

Maar de liefde voor genereren slaat tegenwoordig in sommige organisaties wel eens fors door.

Ik ken verschillende organisaties waarin ook scripts gegeneerd worden waarbij ik me afvraag wat het nut is. Het is dan ontaard in genereren omdat het kan. En dat is minder handig.

Zo is er een grote organisatie waarbij Informatica XML scripts moesten worden gegeneerd vanuit een Excel script waarachter een VBA programma zat dat vanuit Excel het XML zou moeten genereren. Nu waren er twee problemen met die oplossing. Ten eerste kon niet van alle Informatica mogelijkheden gebruik gemaakt worden omdat het VBA programma niet de complete Informatica functionaliteit afdekte. Bovendien vertoonde het VBA programma wat bugs zodat er handmatig een en ander moest worden aangepast. Het resultaat was dat het genereren van een XML script een paar dagen kostte. Als je dan een foutje ontdekte, moest je het Excel bestand aanpassen en kon je weer een paar dagen wachten. Heel wat ontwikkelaars zochten naar allerlei uitvluchten om maar direct Informatica te kunnen gebruiken om frustraties te vermijden die gepaard ging met het eindeloos wachten op een nieuw script. De leiding van de afdeling was evenwel streng en zorgde ervoor dat de meesten braaf een Excel sheet invulde. Is dat handig? Ik zou denken van niet.

Ik ken een andere organisatie waar een hele slimme architect een programma had gemaakt waarmee je automatisch XML scripts kon aanmaken om in Informatica mappings te kunnen genereren. Maar je kunt dergelijke mappings ook heel snel in Informatica zelf bij elkaar klikken. De tijdwinst die je wint met generatie is vrijwel verwaarloosbaar. Ik zag dat de ontwikkelaar op een hele slimme manier het generatieprogramma omzeilde omdat hij terecht geen zin had een programma te leren om een minimale tijdwinst te boeken. Eerlijk gezegd begreep ik die ontwikkelaar wel: het voordeel van het gebruik van het programma is minimaal. Waarom zou je je er dan aan wagen?

Deze voorbeelden laten zien waar je geen gebruik moet maken van generatiemogelijkheden. De voorbeelden laten zien dat je terughoudend moet zijn als er geen duidelijke voordelen aan het genereren zijn. Beide negatieve voorbeelden hebben ook allebei zelf gemaakte programmaatjes als gemeenschappelijk element. Probeer dit soort eigengemaakt spul te vermijden. Iedere ICT manager kiest voor “buy” boven “build”. En dat heeft een reden: eigengemaakte programmaatjes hebben nu eenmaal foutjes waar je arme ontwikkelaar mee wordt opgezadeld. En dat leidt tot frustratie en hoeveel kost dat dan weer niet?

 

 

Over de auteur

Tom van Maanen
Tom van Maanen
Tom van Maanen is managing consultant bij Capgemini. Hij werkt er nu al weer een jaar of 12. Daarvoor heeft hij in verschillende andere IT organisaties gewerkt. Sinds 1997 werkt hij op gebied van Business Intelligence. Hij heeft in zo’n 20 organisatie in de BI keuken kunnen kijken. Hij schrijft regelmatig over zijn ervaringen in de BI keuken.

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.