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:
- 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?
- 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.
Gijs,
Herkenbaar!
Nu moet ik wel zeggen dat ik al jaren dezelfde user interface gebruik als ‘script kiddie’ en Microsoft grote stappen voorwaarts heeft gemaakt om hun platform beheer(s)baar te maken met WMI en Powershell. Probleem is echter, zoals je ook al aangeeft dat applicatiebouwers niet veel tijd steken in non-functionele kwaliteitskenmerken omdat de business gewoon ‘eye candy’ wil.
Goed stuk Gijs.
Dank hier voor!
Jeminee Gijs, wat een parel van een artikel! Deze gaat zo mijn portfolio in die ik meeneem naar de volgende workshop.
Ijzersterke voorbeelden en ook nog eens heel goed te lezen. Ben er stil van.
‘Achteruit Automatiseren’ kan ook nog eens slechts een beleving van de gebruiker zijn.
Ik heb ooit wel eens een replacement voor legacy hardware gebouwd, welke de dezelfde functionaliteit als voorheen bood plus daarnaast nog een aantal belangrijke extra’s.
Als de gebruikers echter de kont tegen de krib gooien en dat geaccepteerd wordt, dan heb je het als automatiseerder voor het nakijken.
Naar analogie kun je de systeembeheerder niet de schuld geven dat je email programma nu via een tegeltjes interface moeten worden opgestart en niet via de startknop.
Je mag van gebruikers verwachten dat ook zij met nieuwe middelen leren werken.
Dat moet ik als automatiseerder ook, heb ik ook niet om gevraagd.
Gijs,
Leuk artikel!
Ik weet niet of ik dit “achteruitautomatiseren” mag noemen. ICT-wereld is een bewegelijke wereld met veel ontwikkelingen op verschillende fronten. De ene heeft aansluiting bij je situatie/wensen en de ander niet ( of minder). Een nieuwe software die minder functionaliteit heeft, of minder flexibel is of minder beheersbaar is hoeft niet per se als achteruitautomatiseren beschouwd te worden. Deze software heeft misschien andere voordelen die beter bij je (nieuwe) situatie passen.
In dit kader zal ik zeggen dat de laptop van Google (Chromebook) een voorbeeld van achteruitautomatiseren is! Maar is dit terecht?
P.s. ik moest lachen om “ontwikkelaars zonder architectuur(kennis)” Zeer herkenbaar en dat komen we vaak op deze site tegen 😉
Haha Reza. Ik heb al zo’n vermoeden wie je bedoelt…..
Goed artikel.
Het is heel erg herkenbaar hoe de funktionaliteit terugloopt, de interfaces er uit zien als een vuilnisemmer met reklameblaadjes.
“Mobiel” doet daar nog een behoorlijke schep boven op, koop je een smartphone (ja ik ook, sinds kort) dan ben je een eeuwigheid bezich om zo’n ding naar je eigen smaak in te richten en alle bloatware te verwijderen. Iedere “app” heeft zijn eigen interface en je hebt internet nodig om te zoeken waar je in “app” x y en z zo iets simpels al het wachtwoord wijzigt.
Ik vraag me af of de wereld zo ingewikkeld is geworden of dat we allemaal dommer en dommer worden (gemaakt), wat denkt de schrijver?
Dank voor de leuke reacties!
@Jan: De schrijver denkt dat én de wereld ingewikkelder is geworden én er onder tijdsdruk door mensen die geen verstand van architectuur hebben verkeerde beslissingen worden genomen. Het is allemaal onderdeel van de wegwerpmaatschappij denkwijze ook, terwijl je de volgende generatie met de problemen opzadelt.
Goed stuk. De opmerking van Reza Sarshar over Google Chromebook vind ik wel echter wel een hele terechte. Want minder is soms juist meer. De genoemde standaardisatie door Microsoft heeft zeker veel goeds betekent qua eenduidigheid van user interface. Maar toepassingen als MsWord zijn in de loop der jaren wat mij betreft verworden tot tekstverwerkingsmolochen. Wil je alleen wat tekst produceren dan kan overstappen naar een soberder tekstverwerker als Google Docs dan ook in bepaalde opzichten een vooruitgang betekenen. Juist de noodzaak om je in een browseromgeving meer te moeten beperken leidt er in mijn ervaring regelmatig toe dat uitgedijde Windows applicaties prima vervangen kunnen worden door cloudapplicaties die zich tot de kernfunctionaliteit beperken.
@Gijs,
als “vorige generatie” voel ik me ook al opgezadeld met de problemen die je aankaart.
Echter Windows als standaard betekenen zet nijn nekharen overeind ook al heeft het een kern van waarheid. Dat de desktop-gui zoals die bij windows gegroeid is, verworden is tot standaard defacto zie je terug bij Linux en bij de vraag naar classic shell voor windows 8, de startknop moest terug!
Ook ik gebruik KDE (gui zoals windows7) en op win8 classic shell, omdat je dan sneller je werk kunt doen.