Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Achteruitautomatiseren

 

Computable Expert

Gijs in ‘t Veld
CTO bij Motion10, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4979411). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

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.

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

http://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?").

Leuk dat er steeds meer mensen (van o.a. Ordina) zich mengen in de discussie! Goede toevoegingen die aanzet tot nadenken.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×