Gedurende het ontwikkeltraject van de meeste applicaties of systeemintegraties kom je als software-architect wel eens voor de keuze te staan tussen het 'zelf maken' van een onderdeel of het gebruiken van een (extern) component van derden. Geen gemakkelijke keuze, aangezien beide opties voordelen en nadelen hebben en je het meeste zelf zou willen doen, maar je niet opnieuw het wiel wilt uitvinden. Wat zou je mee moeten nemen in je overwegingen?
Als je zelf een component ontwerpt zal je er voor zorgen dat dit precies doet wat jij wilt dat het zou moeten doen. Niet meer, want dat is zonde van de tijd en geld, en zeker niet minder. Bij een extern component heb je vaak wat minder keuze: de functionaliteit ligt immers reeds vast en deze sluit meestal niet volledig aan bij de wensen. Zo kunnen componenten veel te uitgebreid zijn en vaak te complex of ze sluiten net niet aan bij de wensen. Vooral in het laatste geval komt het dan vaak neer op het gebruiken van een combinatie van eigen code en het extern component. De vraag is of je er dan veel voordeel van zult hebben. Maar ook een te complex component kan nadelen hebben, zoals het onnodig complex maken van de onderhoudbaarheid van je oplossing.
Onderhoudbaarheid
Een ander afweging ligt op het gebied van de onderhoudbaarheid van het component. Je eigen oplossing zal je door en door kennen en eventuele problemen kun je zelf analyseren en oplossen. Bij een externe component ligt de zaak een stuk complexer. Zelfs als de broncode beschikbaar is, blijft het lastiger om problemen op te sporen en te verhelpen. Je hebt immers minder inzicht in het ontwerp en de code en dus is het lastig om in te schatten wat voor impact een aanpassing zal hebben op het geheel. De enige hulp die in sommige gevallen ingeschakeld kan worden is, indien deze bestaat, een community rondom het component. Maar over het algemeen kun je stellen dat de onderhoudbaarheid een stuk lager is bij een extern component. Zonder broncode wordt het meteen al een stuk lastiger en kan je enkel hopen op een meewerkende fabrikant.
Broncode
Net viel het woord broncode al. De meeste externe componenten hebben een licentie waar je aan moet voldoen. Vaak is dat geen probleem, maar het kan wel je keuze beïnvloeden. Zo mag niet elke component voor commerciële doeleinden worden gebruikt en vaak legt het ook restricties op aan je eigen licentie. Uiteraard heb je met eigen componenten geen last van licenties behalve van die van je zelf.
Wat ga je doen?
Is er een goede of een foute keuze? Ik denk het niet. Behalve de bovenstaande punten zijn er ongetwijfeld nog veel meer voors en tegens. Ook persoonlijke voorkeur, die van een klant of een corporate policy, kan een rol spelen in de keuze. Dus wellicht is het beter om iets minder algemeen te kijken en te stellen dat je per klant en/of oplossing een keuze moet maken. Het is lastig om bij een klant te verantwoorden dat je per release of per applicatie een ander component gebruikt hebt voor bijvoorbeeld logging. Het is immers voor de klant ook iedere keer weer een leerproces om met nieuwe componenten te werken.
Ik denk dat het hebben van de broncode een eis is om software van derden mee te nemen in een ontwikkelproject. Als je in de toekomst onderhoud moet verrichten op het component die door allerlei reden kunnen ontstaan dan is het niet zo professioneel om tegen de klant te moeten zeggen dat dit niet mogelijk is.
Verder ben ik van mening dat je altijd de klant moet informeren of het gebruik van software van derden in een ontwikkelproject en daar toestemming voor moet vragen.
Een klant kan ook bezwaar hebben tegen componenten van derden omdat security onvolkomenheden niet gecontroleerd kunnen worden.
Het proces voor software van derden is niet zo complex.
1. De applicatie architect beoordeeld functioneel en designtechnisch of het component voldoet. Zowel functioneel nu als in de toekomst. Hierbij neem je dus aspecten als onderhoudbaarheid, vervangbaarheid en featureset mee.
2. Legal en compliance bekijkt licensing werk.
3. De bron van 3rd party component kan niet worden aangeraakt. Het component kan (buiten de broncode om) geconfigureerd en gewrapped worden. Bij voorkeur geef je de developers mee om je 3rd party componenten te wrappen, zodat je in het geval van upgrades of vervanging minder (hopelijk geen) initiele impact hebt op consumerende en aangrenzende componenten.
Het argument dat eigen code beter te onderhouden en te snappen is, is een uitspraak vanuit een developer mindset, niet vanuit een architecten mindset.
De onderhoudbaarheid van een third-party component is niet automatisch lager dan bij een eigen component. Van belang is of een componentaanbieder snel kan reageren op klantenwensen of zelfs maatoplossingen kan bieden. Juist bij inherent complexe componenten zal een gespecialiseerd bedrijf meer mogelijkheden hebben dan de eigen ontwikkelafdeling.
Zijn er twijfels over ondersteuning van een component op de langere termijn, dan is het raadzaam om hiervoor een Escrow-overeenkomst te regelen.
Zoals ik al schreef: er is niet echt een goed of fout. Het wrappen van third party componenten is inderdaad iets dat meestal gebeurd en iets minder afhankelijkheid creëert.
Het afsluiten van een Escrow overeenkomst om continuïteit te garanderen dekt ook niet alles af. Mocht een derde partij besluiten te stoppen, dan voorkomt een dergelijke overeenkomst dat je het component niet meer kan gebruiken. In zo’n geval mag je meestal zelf de broncode gaan bewerken, maar bij complexe componenten wordt je daar ook niet altijd vrolijk van.