Waarom zou je zelf software bouwen als het er al is? We zien het vaak gebeuren: organisaties die allemaal soortgelijke generieke componenten bouwen. Een tijdrovend proces dat veel efficiënter en goedkoper opgelost kan worden met gedeelde open-source componenten. We leggen de voor- en nadelen uit van zelf software bouwen en open-source componenten.

Ja, we gaan automatiseren! Maar let op:

We hebben al eens het verschil uitgelegd tussen DWA-oplossingen en de Model Driven Data Engineering (MDDE)  aanpak. Het grote voordeel van MDDE is de technologie onafhankelijke benadering die meer vrijheid en flexibiliteit biedt. Wanneer teams de voordelen van MDDE begrijpen en inzien dat ze moeten automatiseren, gaan ze vaak zelf tools bouwen. Technische mensen in het team vinden dit leuk om te doen, en dat begrijpen we. Binnen korte tijd hebben ze een bruikbare tool gebouwd die in eerste instantie ook echt wat oplevert. Maar als je naar de lange termijn kijkt, levert het regelmatig de volgende problemen op:

• De zelf ontwikkelde tools zorgen voor veel onderhoudswerkzaamheden in het team, vaak in technologie waar het team minder goed bekend mee is.
• Als de engineer die de tool gebouwd heeft het team verlaat, verlies je de kennis van de tool.
• Voor nieuwe teamleden is het lastiger om bekend te worden met de specifieke manier van werken in het team. Er is nu eenmaal geen kennis en/of ervaring in de markt te vinden over zelf ontwikkelde tools.

Zelf bouwen of is de functionaliteit al op de markt?

Als je gaat automatiseren kun je zelf tools bouwen, maar op lange termijn levert dat dus aardig wat hoofdbrekers op. Maar nog belangrijker: vaak heeft het team functionaliteit nodig die al bestaat. Een tool is meestal niet organisatie-specifiek en het loont dus om te kijken wat er al door anderen is gemaakt. We vergelijken het automatiseren van het ontwikkelproces van een datawarehouse of dataplatform ook weleens met een autofabrikant. Een autofabrikant heeft veel verstand van auto’s, maar niet van de robots die de verschillende onderdelen van een auto monteren. Ze weten wat de robot moet doen, maar niet hoe die in elkaar zit en gebouwd wordt. Dat laten ze door gespecialiseerde bedrijven doen. De functionaliteit van zo’n robot is meestal ook niet merk-specifiek, waardoor een generieke variant voldoende is. Want wat de carrosserierobot bij Volkswagen doet is redelijk hetzelfde als wat die bij Tesla moet doen. De robot heeft alleen andere stuurinformatie nodig.

De voordelen van open-source componenten

Je hoeft het wiel dus niet opnieuw uit te vinden; veel tools zijn al beschikbaar. Het gebruiken van bestaande tools scheelt een hoop tijd en ontwikkelkosten. Ook zijn bestaande tools makkelijker overdraagbaar naar andere mensen. Je hebt niet maar één engineer die er alles van afweet en vaak zijn er documentatie en trainingen beschikbaar voor het gebruik van de tool. Alles wat je nodig hebt om de tool zo goed mogelijk in te zetten, zowel nu als in de toekomst, is al aanwezig.

Reuse before buy, buy before build

Wij adviseren daarom altijd om stil te staan bij welk probleem je wilt oplossen, een stap die vaak overgeslagen wordt. Of voor de engineers onder ons: Resist the urge to start coding. Kijk eerst eens goed naar het probleem. Wat wil je oplossen? En wat zijn de eisen voor de oplossing? Kijk daarna in de markt naar wat er al beschikbaar is. Steeds meer grote organisaties zien dit in en gebruiken ‘reuse before buy, buy before build’ in hun architectuurstandaarden. Men moet hierbij eerst kijken of de benodigde functionaliteit al in huis is. Zo niet, dan moeten ze eerst kijken of het al op de markt beschikbaar is en pas daarna wordt er voor gekozen om zelf te gaan ontwikkelen.

Laagdrempelig gebruik van tools: onze visie

Binnen CrossBreeze kijken we ook eerst wat er al beschikbaar is. Gelukkig vinden we meestal wel goed onderhouden open-source projecten die ons helpen. Er zijn echter ook enkele uitdagingen waar dit niet het geval was en hier hebben we zelf software voor ontwikkeld. Een voorbeeld hiervan is ons test framework voor data-oplossingen, CrossTest. Om bij te dragen aan de open-source community en het ‘reuse’ te bevorderen, stellen we de meeste software zelf ook open-source beschikbaar. Zo hopen we de drempel voor engineers laag te houden om deze tools toe te passen en er zelf ook aan bij te dragen. Op deze manier helpen deze tools niet alleen ons in projecten, maar onze ervaring leert dat ook anderen deze functionaliteiten goed kunnen gebruiken. Die hoeven ze dus niet zelf (opnieuw) te gaan bouwen!

Wil je een ontwikkelproces (verder) automatiseren? Kijk dan eerst naar de open-source markt voordat je zelf iets gaat bouwen. Er is al zoveel moois beschikbaar wat je kunt hergebruiken of waar je zelfs aan kunt bijdragen! Nieuwsgierig naar de CrossBreeze tools? Of kun je wel wat hulp gebruiken bij het vinden van de juiste tools? Neem dan contact met ons op!