Herbruikbare software is als de wonderlamp van Aladdin: denk goed na voordat je wat vraagt

Over de voor- en nadelen van hergebruik van softwarecomponenten

Het hergebruik van softwarecomponenten biedt een aantal voordelen en nadelen voor ontwikkelaars en organisaties. Voordelen zitten met name in verhoogde productiviteit, snellere ontwikkeltijden en kostenbesparingen. Maar nadelen zijn er ook: op het gebied van compatibiliteit, afhankelijkheid van externe partijen, en mogelijk beperkingen in flexibiliteit en aanpasbaarheid. In dit blog bespreek ik de aspecten die de keuze voor hergebruik van software beïnvloeden aan de hand van een concrete case. En, spoiler alert, er is geen standaardoplossing die op iedere situatie toepasbaar is. 

Casus

Toen ik vorig jaar mijn aandacht weer eens verlegde van infrastructuur- naar applicatiearchitectuur, en voor een grote IT-organisatie een nieuw businessproduct moest laten landen in het IT-landschap, stuitte ik direct op grote kansen in synergie. Voor zeker de helft van de storypoints was dezelfde functionaliteit nodig als voor bestaande producten A en B. En het samenvoegen van die twee in één codebase, met de afbouw van de MS-Access tussenoplossing voor product B, was reeds eerder als wens neergelegd. Ik werkte het hergebruik uit met de Java-ontwikkelaars, en bereidde de eerste ronde van de Project Start Architectuurdocument-review door het architectenboard voor met de opzet zoals weergeven in Figuur 1.

Inhoudelijk ging het om een in de Java-wereld welbekend pattern waar de GUI apart is , maar alle lagen achter de schermen gedeeld worden. En die lagen passen zich middels configuratiefiles aan, afhankelijk van product A, B of C.

Vóór het aanbieden aan de architectenboard werd ik door de lijnmanager gewaarschuwd: “Kijk even naar herbruikbaarheidspolicy XYZ, de vorige keer werden we afgeschoten omdat we teveel herbruikbaar wilden neerzetten”.

Oeps. Dat was een harde landing. De policy bij deze organisatie bleek inderdaad “extern kopen gaat boven nieuw ontwikkelen” te zijn en in algemene zin niet “hergebruik gaat boven extern kopen en dat weer boven nieuw ontwikkelen  ”. Hergebruik mág daar, nee móet zelfs, voor een aantal specifiek benoemde ondersteunende domeinen zoals incasso, web-portal, BI, workflow/case management en stamgegevens. Voor alle andere domeinen mag altijd worden ‘geforkt’ (afgeslagen) van bestaande code, maar mag niet zomaar over domeingrenzen heen herbruikbaar worden gemaakt.

Overigens was het voor mijn casus vals alarm: mijn voorstel aan de architectenboard om wél te gaan hergebruiken binnen het productdomein, omdat het drie ‘eigen’ producten betreft, werd goedgekeurd. Maar dan nog wel met een waarschuwing om de nadelen van dit specifieke geval van kleinschalig hergebruik goed te documenteren en te mitigeren. De voor- en nadelen die men ervaarde bij hergebruik bleken in discussies met collega CGI architecten universeel herkenbaar, vandaar dat ik ze hier heb samengevat

De voordelen van hergebruik

In het verre verleden, toen de markt begon met migreren van silo-applicaties naar de multikanaals web- en appwereld, was hergebruik vanzelfsprekend. We bouwden applicatielagen waar overlap was maar één keer, en niet per product/kanaal. Dat was toen best lastig verkopen aan de opdrachtgever. Bij een grootbank waar ik lang betrokken was wilden wij architecten echt een herbruikbare proces- en servicelaag voor de allereerste Internet bankierensite. Ook toen het hele project maanden vertraagd werd, en sommige lijnmanagers serieuze plannen wilden doorrekenen voor een ‘silo met webtechnologie’ om de deadlines en budgetten te kunnen halen. Gelukkig mochten we doorzetten;  en uiteindelijk plukten wij daar de vruchten van, want toen 2 jaar later de mobieltjes aangesloten moesten worden ging dit met slechts 1/3 van de kosten vergeleken met een nieuwe kanaalsilo. 

De voordelen van hergebruik kun je als volgt samenvatten:

1. Efficiëntie: generieke oplossingen zorgen voor lagere ontwikkel- en beheerkosten. De bankcasus hierboven is een mooi voorbeeld.
2. Wendbaarheid: generieke oplossingen beperken het aantal plekken waar een wijziging moet worden doorgevoerd wat het doorvoeren van wijzigingen sneller mogelijk maakt. 
3. Als er iets in de buitenwereld verandert, bijv. SEPA/IBAN voor incasso’s, dan kun je dat beter in 1 centraal incassosysteem aanpassen dan in 10+ aparte productsystemen.
4. Klantverwachtingen: generieke voorzieningen maken het mogelijk om invulling te geven aan eisen of verwachtingen van de klanten, die niet goed per middel/product kunnen worden gerealiseerd. 

De   meeste organisaties zijn graag via 1 overall website/portal bereikbaar, niet 10+ aparte. Dus we zullen aansturen op die ene totaalwebsite, niet allemaal aparte sites.

De nadelen van hergebruik

Wel, je kunt het al raden: nadelen van hergebruik zijn vaak het spiegelbeeld van de voordelen van de silo-wereld. Want die silo’s zijn, met al hun beperkingen, wél redelijk overzichtelijk en relatief makkelijk te beheersen. Door opsplitsing in componenten/lagen, en erger nog die componenten als herbruikbare services neer te zetten, wordt de keten achter een bepaalde schermfunctionaliteit een heel stuk langer!  

Een aantal voorbeelden waar de vraag om herbruikbaarheid misschien iets te snel en zwartwit gesteld werd:

1. Het willen aansluiten op een generiek case management systeem dat nog in opbouw is, wat allerlei tussenoplossingen in de eigen applicatie tot gevolg heeft. 
2. Knokken om prioriteit in het portfolio van het generieke domein, zelfs als je ‘een zakje geld meebrengt’. Wat krijgt de prioriteit: een verdere uitbouw van SEPA incasso’s, wat een nice-to-have extra is voor 5+ producten? Of toch een specifieke multi-vordering betalingsoptie die voor 1 specifiek product een must-have is? Wendbaarheid is geen absoluut, maar een relatief begrip: wendbaar voor bepaalde soorten changes botst soms met die voor andere soorten changes  .
3. In de situatie dat we een grotendeels herbruikbare businesslaag hebben, zoals de PSA-casus waar ik mee begon, zorgt een extra veld in scherm-ProdA niet alleen maar voor een change in dat scherm plus de ‘productspecifieke front business service’. Maar ook kan deze change er ertoe leiden dat de generieke component plus gegevenslaag verandert. Minimaal moet dan de hele applicatie opnieuw getest worden, inclusief product B en product C.

De juiste aanpak

Je ziet het al: herbruikbaarheid kan werken als de magische olielamp, waar Aladdin één wens doet maar de gevolgen ervan niet overziet. We moeten dus, per IT-organisatie, heel nauwkeurig formuleren wanneer herbruikbaarheid wél en wanneer niet gewenst wordt. En voorwaarden voor het hergebruik opschrijven, zoals aansluitcontracten inclusief verwachte load en andere non-functionele eisen, versiebeheer, ketenmonitoring en alle andere afbakeningen van verantwoordelijkheden.

We moeten ook duidelijk onderscheid maken tussen ‘generieke faciliteiten’ en ‘beschikbare bouwstenen’. Voor de faciliteiten stelt de organisatie dat je ze moet gebruiken, denk aan incasso of web-portal of Business Intelligence (met ook afspraken voor gevallen waarin de centrale faciliteit nog bepaalde nu vereiste functies mist). Voor bouwstenen geeft de organisatie kaders waarin je ze herbruikbaar mag neerzetten en afnemen, maar het is een eigen keuze die de architect samen met de betrokken partijen maakt. Indien niet voor herbruikbaarheid wordt gekozen, is een afslag maken (forking) altijd toegestaan.

Had ik al verteld dat wij CGI-architecten hierin een massieve verzameling kennis opgebouwd hebben? Inclusief toolsets voor het sturen van architecturele discussies zoals RCDA (Risk and Cost Driven Architecture)? Dus hoewel ik geen zeker antwoord kan geven op de vraag ‘wat is de juiste aanpak voor herbruikbaarheid in mijn organisatie’, kan ik wél zeggen dat  het significant gaat helpen wanneer onze architecten bij dit soort vragen worden betrokken…