Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Koste wat het kost genereren

Ik hoorde laatst de stelling dat je altijd scripts moet genereren als je daartoe de mogelijkheid hebt. De betreffende zegsman heeft navolgers. Ik zie dat veel organisaties heel graag scripts genereren. Genereren waar kan, lijkt het devies. Maar is dat wel zo? Daarover gaat dit artikel.

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. Koste 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.

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 ETLgebied 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.

Doorslaan

De liefde voor genereren slaat tegenwoordig echter 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? En als je dan nog niet overtuigd bent: denk nog eens even aan het herstellen van eigen gemaakte programmatuur als de ontwikkelaar vertrokken is. Wie neemt dat voor zijn rekening?

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5654982). © Jaarbeurs IT Media.
?

 

Reacties

Beetje flauw eerste voorbeeld bij het doorslaan.

"Bovendien vertoonde het VBA-programma wat bugs"

Tja, als er in de er SAS Data Integration of Powerdesigner of Erwin bugs zitten zal het genereren van het script ook niet goed gaan.

"Ik hoorde laatst de stelling dat je altijd scripts moet genereren als je daartoe de mogelijkheid hebt. " , uiteraard bedoelde diegene dat als het vol bugs zit dit valt onder "geen mogelijkheid".

Dus ja, ik snap je verhaal, maar de voorbeelden vind ik minder sterk waardoor de stelling niet geheel uit de verf komt.




Computable Expert
Tom van Maanen

Tom van Maanen
Managing Consultant, Capgemini. Expert van Computable voor het topic Datamanagement.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×