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.
Ad,
Even terug naar je opmerking omtrent MS Word:
Als we op holistische wijze naar de applicaties die een “organisatie” nodig heeft kijken, inclusief de onderlinge relaties en diensten en ook de link met hoe informatie van deze onderneming met haar klanten/relaties uitgewisseld wordt dan kunnen we pas zeggen of een applicatie zoals MS Office toegevoegde waarde heeft of niet.
Het is een groot verschil tussen het opstellen van applicatiecataloog voor een onderneming dan bijvoorbeeld voor jezelf als ZZPer of een klein bedrijf (0 t/m 20 gebruiker)
Wil je cloudapplicaties als organisatie gebruiken, dan heb je andere uitdagingen. Deze heb ik al in het artikel hieronder besproken:
SaaS het oerwoud van de toekomst
https://www.computable.nl/artikel/opinie/infrastructuur/4923342/2379248/saas-het-oerwoud-van-de-toekomst.html
Wil je cloudapplicaties als ZZPer of een klein bedrijf gebruiken, dan is het heel anders.
Dus, soms is achteruitautomatiseren zelfs vooruitgang te noemen? Maar dat geldt zeker niet voor dikke, apparaatspecifieke apps of ondoordachte, niet gestandaardiseerde UX.
Kijk Gijs, nu komen we op een hellend vlak van de achteruitautomatisering. Hierop is namelijk de relativiteitstheorie van toepassing.
Soms kan een gebruiker ervaren dat er achteruit geautomatiseerd wordt. Voor het gevoel krijgt hij ene tool die minder kan (bijvoorbeeld browser in plaats van een op Windows geinstalleerde app) en minder gebruiksvriendelijk is (elke weer veranderd er iets waar de gebruiker niet om heeft gevraagd). Op een ander niveau, of vanuit een beheerders niveau wordt er absoluut niet achteruit geautomatiseerd. Want het beheren van de applicatie is simpeler geworden en kan ineens ook gebruikt worden op de tablets die steeds meer in gebruik genomen zijn, daarnaast hoeft er geen lastig proces afgelegd te worden om een gebruiker met de app te laten werken.
Op niveau van strategie en directie is de organisatie wendbaarder geworden, zijn de licenties goedkoper geworden en ook nog eens eenvoudiger.
You get my drift.
Zoals alles in IT: Nothing is ever easy.
– – – –
Een klassiek geval van achteruitautomatiseren zie je vaak bij de implementies van ERP. Interfaces vaak Spartaans, veel meer handelingen nodig dan voorheen, et cetera.
Maar ook daar geldt dat er op een ander niveau soms enorme stappen worden gemaakt doordat het integratie oerwoud ineens verdwenen is door de holistische aanpak van de ERP.
@Henri
een spartaans interface is een goed interface, opgebouwd naar het KISS-principe, Keep IT Simple Stupid . . . .
ERP is zeker geen achteruit automatiseren.
Ik begrijp dat je je keuze voor Chromebook wilt verdedigen ook al worden hier vele vraagtekens gezet bij de beperkte funktionaliteit. Simpelere programma’s kun je ook krijgen onafhankelijk van Google.
Achteruitautomatiseren.. Business terug naar de middleware… Doet mij denken aan de tijd dat ik startte met automatiseren (als 12-jarige in 1978). Terug kon niet (er was immers weinig) en middelware was er niet. Toen konden we alleen vooruit. Alles moest je nog zelf bouwen. Standaard objecten, userinterfaces, classlibraries bestonden nog niet (of je moest ze zelf bouwen).
Tegenwoordig pak je een kant en klare opensource (bv Magento) webshop of crm-systeem (bijvoorbeeld) zet hem neer en gebruikt deze as-is. De neiging om hier achteruit te automatiseren is sterk aanwezig. Het toevoegen van plugins (via ingebouwde installer) leidt vaak tot problemen in de toekomst, vooral als die plugins zijn gebouwd door derden. Op korte termijn vooruit, op lange termijn al snel achteruit dus (zodra je moet upgraden).
Tja zonder kennis van ICT en architectuur klik je al snel een systeem bij elkaar, maar of dat op lange termijn is wat je nodig hebt? Maar ja over 2 jaar wil je wellicht toch weer een andere webshop of crm-systeem… 🙂
Ofwel: Gebruik wat er is = vooruit, ga je het op maat aanpassen dan is het nu achteruit en over 2 jaar achterhaald.
Gewoon een andere blik 🙂
@ Gijs in ’t Veld
Grappig en herkenbaar artikel. Brengt mij dan weer naar die twee essentiële en basale vragen die je jezelf in IT land telkens weer moet stellen.
1. Waarom automatiseer je?
2. Waarom zou je automatiseren?
Als je kijkt naar het gegeven dat er een MS Office is, slechts als voorbeeld, waar gemiddeld nog geen 40% van het gehele potentieel door de gebruikers worden gebruikt, maar je wel het volledige pakket moet kopen, dan ondersteund de gedachte je intentie hier.
Helder artikel.
Gijs, haha, goed verhaal, wegwerpmaatschappij en doorschuiven van problemen (met dure oplossingen) naar de toekomst, spot on imo.
En nu wat doe je eraan?
Als architect kun je niet meer (en moet je niet minder) dan de door jou genoemde effecten benoemen in je scenario-analyse met kosten/baten/risico’s. En die delen met *alle* belanghebbenden.
Dat de investeringsbeslissing vervolgens genomen wordt obv overwegingen die uit gebruikers- en/of beheeroptiek achteruit uitpakken, tja. Als je organisatie er per saldo maar op vooruit gaat. Dus eens met Henri Koppen.
Dus, indien we op sommige punten bij een nieuwe software (as a service) implementatie bewust achteruitautomatiseren zou dit ook in de visie, doelstellingen en business case terug moeten komen.
Maar daar waar bewust shortcuts worden genomen, of uit architectuuronwetendheid wordt gehandeld moet een architect opstaan en de kaders weer helder(der) maken en refactoring eisen.
“Een aantal simpele architectuuruitgangspunten moeten aan de start van elk traject helder omschreven worden en bij iedereen in postervorm aan de muur hangen.
–> Als dat jouw aanpak van implementeren is dan snap ik wel waarom de ontwikkelaars zonder architectuurkennis zich er niet aan houden…
@Anko – dat is inderdaad maar het begin, om iedereen rond dit soort uitgangspunten op 1 lijn te krijgen en elkaar telkens te kunnen uitdagen. Verder moet architectuur natuurlijk geborgd worden in de vorm van reviews van ontwerpen (architect) en controle van code (lead dev). Maar daar heb ik wel ‘ns een ander stuk over geschreven (“Hoe borg je nu eigenlijk architectuur?”).