Wat drijft de kost van software?

IBM zocht in de jaren ’60 een antwoord op deze vraag. De eerste belangrijke conclusie was dat de grootste kost van software niet zit in de initiële ontwikkeling, maar in het onderhoud. De tweede belangrijke conclusie was dat coupling een zeer belangrijke factor is in de onderhoudskost.

Wat is coupling en waarom kan het tot problemen leiden?

Coupling (koppeling) verwijst naar de mate waarin softwarecomponenten afhankelijk zijn van elkaar. Hoe sterker hun afhankelijkheid, hoe moeilijker het wordt om wijzigingen door te voeren zonder ongewenste bijwerkingen in andere delen van het systeem.

Een klassiek voorbeeld is een applicatie die direct data ophaalt uit de database van een ander systeem. Zodra de eigenaar van de database een wijziging doorvoert (zoals het hernoemen van een kolom), kan dat jouw applicatie breken. Dat gebeurt vaak zonder waarschuwing, en zonder dat je er iets aan kan doen.

De drie dimensies van coupling

Coupling kent drie dimensies die bepalen hoe onderhoudsvriendelijk een systeem is.

1. Strength: hoe diep systemen met elkaar verweven zijn. Hoe sterker de koppeling, hoe groter de impact van een verandering.
2. Volatility: hoe vaak het systeem verandert. Hoe hoger de volatiliteit, hoe groter de kans dat gekoppelde systemen hier hinder van ondervinden.
3. Distance: hoe ver de gekoppelde componenten van elkaar verwijderd zijn. Dit kan een fysieke afstand zijn (verschillende microservices of systemen) of een organisatorische afstand (verschillende teams of departementen).

De vuistregel: hoe hoger de strength, volatility en distance, hoe moeilijker en duurder het wordt om wijzigingen door te voeren.

Sterke koppeling en hoge volatiliteit zorgen ervoor dat een systeem voortdurend moet meebewegen met andere systemen. Als daar ook nog een grote afstand bij komt (bijvoorbeeld meerdere teams of departementen), wordt het onderhoud een nachtmerrie.

Soorten coupling en hun impact

Niet alle koppelingen zijn even schadelijk. Sommige maken een systeem extreem fragiel, terwijl andere een gezonde balans tussen afhankelijkheid en flexibiliteit bieden.

Er zijn 4 niveaus van coupling. We sommen ze op van meest problematisch naar best beheersbaar.

1. Implementation coupling (meest problematisch)
   Hierbij is een systeem afhankelijk van de implementatiedetails van een ander systeem. Dit maakt het zeer kwetsbaar, omdat kleine aanpassingen in het ene systeem onbedoelde kettingreacties kunnen veroorzaken.
   • Voorbeeld: Een applicatie die direct uit de database van een ander systeem leest. Als die database gewijzigd wordt, kan die applicatie breken zonder waarschuwing. Er kunnen namelijk geen interpretaties meer gemaakt worden.
2. Functional coupling
   Wanneer meerdere componenten dezelfde businessfunctionaliteit aanbieden en synchroon gehouden moeten worden. Als je één aanpassing wil doen, moet die daardoor op verschillende plaatsen gebeuren. Het resultaat is dubbel werk en hogere onderhoudskosten.
   • Voorbeeld: Een telecomprovider met verschillende implementaties van abonnementen: voor de mobiele app, website en interne systemen. Elke wijziging moet overal apart worden doorgevoerd.
3. Model coupling
   Dit gebeurt wanneer API’s de interne details van hun systeem onvoldoende afschermen. Daardoor dwingen interne wijzigingen ook aanpassingen bij API-gebruikers af.
   • Voorbeeld: Een API die ruwe databasevelden teruggeeft in plaats van een stabiele datalaag. Elke wijziging aan de database zorgt er dan voor dat de API-gebruikers hun code moeten aanpassen.
4. Contract coupling (best beheersbaar)
   Een goed ontworpen en goed gedocumenteerde API die logisch is in gebruik. De interne details van het systeem zijn volledig de-coupled van de API, zodat interne systeemwijzigingen geen impact hebben op API-gebruikers.
   • Voorbeeld: Een webshop en een betaalsysteem die communiceren via een gestandaardiseerd API-contract, waardoor beide systemen onafhankelijk van elkaar kunnen evolueren.

Hoe balanceer je coupling?

Er zijn dus heel wat manieren waarop coupling voor issues en extra kosten kan zorgen. Maar hoe kunnen we dat nu voorkomen?

Belangrijk om te onthouden is dat je coupling nooit volledig kan elimineren. Software moet nu eenmaal samenwerken. Maar je kan wél slimmer omgaan met afhankelijkheden om onderhoudskosten en complexiteit te beperken.

Je kan coupling onder controle houden door een van de drie dimensies te elimineren of zwaar te reduceren. Een systeem met hoge strength en hoge volatility maar een kleine distance (waarbij één persoon of team de aanpassing kan doen) is goed beheersbaar. Dit noemen we ook wel high-cohesion.

Enkele bewezen strategieën:

• Test-driven development (TDD)

Door tests te schrijven, dwing je jezelf om zaken van elkaar los te koppelen. Want als je een grote blok code in zijn geheel moet testen, wordt dat veel moeilijker. Deze methodiek zorgt dus voor al modulariteit in je eigen codebase.

• Hexagonale architectuur

Door businesslogica los te koppelen van externe afhankelijkheden (zoals databases of API’s), wordt een systeem flexibeler. Door deze zaken in een aparte module te stoppen, ben je zeker dat de businesslogica blijft werken als er changes zijn in een andere module.

• Consumer-driven contracts

Bij het werken met externe API’s of microservices kan je consumer-driven contract testing inzetten. Afnemers van een API specifiëren wat ze nodig hebben, en de API-eigenaren zorgen ervoor dat dit gewaarborgd blijft.

• Strategic Domain-Driven Design (DDD)

Met deze methodiek breng je processen en structuren samen in bounded contexts. Dat doe je op basis van het gedrag, organisatorische structuren en weloverwogen heuristics. Elke bounded context kan daardoor zelfstandig evolueren, zonder andere onderdelen te verstoren.

• Conway’s Law

Conway’s Law stelt dat de manier waarop teams communiceren, direct invloed heeft op de structuur van de software die ze bouwen. Als er een mismatch is tussen de teamstructuur en de softwarearchitectuur, ontstaat er frictie. Zorg er dus voor dat ze op elkaar afgestemd zijn.

• Team topologies

Deze benadering richt zich op het optimaliseren van teamstructuren en de samenwerking binnen een organisatie. Wanneer je teams indeelt op basis van verantwoordelijkheden, verloopt softwareontwikkeling sneller en flexibeler.

Conclusie

“The cost of coupling” wordt vaak pas zichtbaar als systemen duur en complex worden in onderhoud. Door bewust om te gaan met koppeling en slimme architecturale keuzes te maken, houd je je software flexibel en kostenefficiënt.

Wil je dieper in deze materie duiken? Bekijk dan zeker eens de talks van Kent Beck op DDD Europe en Vlad Khononov op Code Europe Tech Festival!