Achteruitautomatiseren

Tijdens een workshop rond business architectuur bij een organisatie die zich bezig houdt met re-integratie van arbeidskrachten probeerde ik het belangrijkste primaire proces 'indiensttreding' in kaart te brengen met als doel het verregaand te gaan digitaliseren. Eén van de workshop deelnemers nam daarbij het woord 'achteruitautomatiseren' in de mond. Een grappig woord! De betreffende persoon had het over een aantal ervaringen die hij tot nu toe had meegemaakt en de trend die hij daar in zag. De intentie van de workshop en het daaruit volgende implementatietraject hebben vanzelfsprekend die trend doorbroken; eindelijk weer in z’n vooruit!

Toch is het wel interessant om eens dieper op dit woord in te gaan. Achteruitautomatiseren kan namelijk op vele manier worden geïnterpreteerd, afhankelijk van het perspectief. Laten we er eens een aantal varianten van op een rijtje zetten:

• Nieuwe software, minder functionaliteit: Hierbij wordt een nieuwe software implementatie uitgevoerd, waarbij de uiteindelijk geboden functionaliteiten minder zijn dan in de situatie er voor. Redenenen kunnen zijn: door noodzakelijke kostenbesparingen is gekozen voor goedkopere software (of SaaS), die minder functionaliteiten biedt, of de uiteindelijk opgeleverde implementatie van maatwerksoftware levert niet wat er van verwacht werd.
• Nieuwe software, minder beheersbaar: Hierbij is de geboden functionaliteit minstens zo goed als bij de vorige software, echter is de nieuwe omgeving niet meer zo goed beheersbaar en moet er veel meer tijd gestoken worden in het in de lucht houden van het pakket, wat weer veel extra menselijke inspanning kost.
• Nieuwe software, minder flexibel: De nieuwe software-implementatie biedt minstens net zo veel op functioneel vlak als de vorige versie, echter men heeft een silo gecreëerd die niet (makkelijk) uitbreidbaar is of die niet goed kan aansluiten op andere producten of diensten.

Dit zijn maar drie varianten, maar er zijn natuurlijk nog legio andere vormen van achteruitautomatisering te identificeren. Leuke exercitie voor een grijze zondagmiddag.

Twee vormen van achteruitautomatiseren wil ik hier toch wel met name onder de aandacht brengen, omdat die er wat mij betreft de laatste tijd héél erg uitspringen met de komst van web, cloud computing en mobile:

1. User interface anarchie: Waar moet je tegenwoordig klikken? En waar kan je dingen ingeven? Wat is een toets? En hoe scroll je? In de tijd van client/server met Windows client applicaties was er, mede dankzij de formidabele inzet van Microsoft op het gebied van standaardisatie, eenduidigheid rond user interface componenten. Die is tegenwoordig met web based user interfaces ver te zoeken en dit leidt vaak tot gefrustreerde gebruikers. Wanneer staat hier eens een (onafhankelijke) partij op en komen er goede standaarden?
2. Thick apps: Apps zijn cool. En handig. Behalve als je er honderderden op je tablet of phone hebt en ze zijn ook nog eens heel dik. Apps die tegen de 100 procent van de functionaliteit in de app zelf hebben zitten zijn veel te log en moeten continu geüpdatet worden op al die honderduizenden of miljoenen devices, omdat de functionaliteitswensen maar uitgebreid worden en de kans op bugs groot is. De (business)logica moet weer terug de middleware laag in, centraal beheersbaar, schaalbaar en gemakkelijk up-to-date te houden! Thin apps moeten weer de norm worden.

Als men ontwikkelaars zonder architectuur(kennis) aan het werkt laat gaan ontstaan bovenstaande situaties al snel. Zelfs met een Agile-aanpak kan dit overigens ook prima voorkomen worden. Een aantal simpele architetuuruitgangspunten moeten aan de start van elk traject helder omschreven worden en bij iedereen in postervorm aan de muur hangen. Laten we in de toekomst op het gebied van it weer eens echt drie stappen vooruit gaan, in plaats van drie stappen vooruit en twee achteruit.