Opletten
Sluipende systeemverandering

Opletten

Geschreven door Remco Hoetmer op 18 februari 2015

Opletten, dat is wat de applicatie architect moet doen. Op het juiste moment reageren want de tijd om te handelen is beperkt. Voor je het weet is het moment voorbij en dan zit je met een starre legacy.

Neem als voorbeeld de ontwikkeling van een User Service: een component dat de data van gebruikers bijhoudt. Het maakt deel uit van een groter systeem van onderling samenwerkende services.

Initieel bestaat de data uit een beperkte set zoals naam, adres, afdeling. Echter, naarmate het omvattende systeem meer functionaliteit krijgt, zal de User Service steeds meer data en functies krijgen. Te denken valt aan autorisaties, rollen, logging van het gebruik, gebruikersgroepen, abonnementen, etc. Maar dergelijke uitbreidingen gaan vaak geleidelijk. Zo af en toe komt er een attribuutje bij (bijvoorbeeld een rol in een ander systeem). Soms een geheel nieuwe functie (groeperingen en lidmaatschappen), een andere afnemer van gegevens (een file-extract). Het gaat van mwah naar erger. Berucht zijn vragen van een om nog even “een vinkje in de database op te nemen” - vaak een snelle oplossing maar gericht op 1 situatie in 1 applicatie. Voor je het weet zit je in een situatie dat het echt niet meer kan en dan is het te laat: enkel een grote refactoring of een migratie brengt dan nog soelaas. Dat moet voorkomen worden. Door te blijven opletten. Zelden is een initieel systeemontwerp fout: brakke systemen ontstaan sluipenderwijs door niet op te letten.

Wat doe je dan met de User Service? Opdelen want het levert verschillende functionaliteit, gekoppeld aan verschillende logische gegevensentiteiten

  • User Autorisatie Service: bevat geverifieerde persoonsgegevens met de rechten. Dit is een aparte service omdat security-maatregelen zo goed in te richten zijn.
  • User Configuratie Service: deze bevat instellingen, voorkeuren die de gebruiker zelf mag aanpassen. Dit is een gewone service.
  • Usage Logging Service: deze registreert data van allerlei verschillende componenten. De data moet op hoge snelheid worden verwerkt. Door dit als een aparte service te gebruiken, kan het infrastructureel ook anders worden behandeld. Ik zou zeggen: de immutable data zsm off-loaden naar het Data Warehouse.

De oplettende architect moet:

  • Identificeren dat er echt een verandering nodig is. Op het moment dat de noodzaak ertoe hard gemaakt kan worden.
  • Oplossing bieden, voor de problemen in de nabije toekomst. Gezien alle op dat moment bestaande eisen. Omvat tevens een oplossing voor de migratie.
  • Communiceren binnen de organisatie. Aan stakeholders uitleggen dat en waarom het nodig is. En binnen cq. naast bestaande projecten de architecturele change soepel laten plaatsvinden.