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

Citizen developers staan voor de deur

 

Het is alweer vijf jaar geleden dat Gartner voorspelde dat in 2014 een kwart van alle bedrijfsapplicaties zou worden ontwikkeld door werknemers buiten de it-afdeling - de zogeheten 'citizen developers'. Hoewel er wel degelijk een trend is te zien dat niet-it'ers zich bezighouden met het ontwikkelen van apps (denk aan de Year of Code), heeft het toch niet zo'n vlucht genomen als in 2009 nog werd gedacht. It-organisaties weten nog steeds niet waar ze de developers vandaan moeten halen.

Een logisch gevolg van deze ontwikkeling is dat men zich afvraagt hoe dit komt. Laat ik beginnen met het goede nieuws: ik geloof dat het tijdperk van de citizen developers er wel aan zit te komen, en nu écht. Het idee was vijf jaar geleden zijn tijd nog een beetje vooruit. Zeker in onze markt (service automation) zien we dat steeds meer zakelijke gebruikers samen met it werken aan de ontwikkeling van apps. Grofweg zijn er drie trends die de populariteit van citizen development aanjagen.

Ten eerste is er de nieuwe generatie werknemers (Millennials) die gewend zijn om zelf technologie te ontwikkelen. Ze zijn opgegroeid in het internettijdperk en gewend aan alle self-service mogelijkheden die dit biedt. Als zij een probleem tegenkomen dat op te lossen is met it, dan krijgen ze dat voor elkaar.

In de tweede plaats brengt cloud computing nieuwe self-service-mogelijkheden met zich mee voor zakelijke gebruikers. Er is al veel over gezegd en geschreven: de grens tussen consumenten-it en zakelijke technologie verdwijnt. Medewerkers willen op de werkvloer dezelfde oplossingen gebruiken waar ze thuis ook mee werken. Dat geldt ook voor cloud-diensten die je zelf kunt ontwikkelen zonder enige programmeerkennis. Niet-it'ers kunnen zo bijvoorbeeld hun bedrijfsprocessen zoals het 'onboarden' van nieuwe medewerkers automatiseren, zonder dat ze daarbij ondersteuning nodig hebben van de it-afdeling.

Tenslotte: als it-afdelingen het niet eenvoudiger maken voor collega's om nieuwe toepassingen te selecteren, creëren en gebruiken, zullen ze hun invloed binnen de organisatie verliezen - ook wel 'rogue it' genoemd.

Dat laatste is niet alleen maar een mogelijk scenario, maar het gebeurt al op grote schaal: volgens een onderzoek van Frost & Sullivan gebruikt meer dan 80 procent van de werknemers SaaS-oplossingen die niet zijn goedgekeurd door it. De gevolgen daarvan zijn elke dag voelbaar binnen it-afdelingen: van beveiligings- en compliance-risico's tot onverwachte kosten. Als medewerkers van it te horen krijgen dat iets niet kan (of pas later, omdat het nu even niet uitkomt), dan gaan ze zelf op zoek naar een alternatief.

Betekent dit dat it 'rogue it' of citizen developers de kop moet proberen in te drukken? Nee, integendeel. Deze ontwikkeling kan zelfs een deel van de druk bij de it-afdeling weghalen, mits goed begeleid en gestroomlijnd. Dat betekent dat de it-afdeling zakelijke gebruikers zal moeten helpen om zelf applicaties te ontwikkelen, op een manier die wel past binnen het beleid van de organisatie.

Citizen developers hebben de potentie om hun vaardigheden en inzicht in de processen van de organisatie snel om te zetten in een oplossing die echt waarde kan toevoegen. Met name ondersteunende afdelingen als facility management, inkoop en finance zijn een groot deel van hun tijd kwijt met het afhandelen en coördineren van interne verzoeken door middel van e-mail en Excel-bestanden.

It-afdelingen kunnen collega's in andere delen van de organisatie helpen om hun dienstverlening te automatiseren. De mogelijkheden om interne processen efficiënter te maken zijn in een paar jaar tijd drastisch verbeterd en als medewerkers niet de support krijgen van it om hun werk te automatiseren, dan zoeken ze hun heil elders. Citizen developers zijn de ontbrekende schakel tussen de technologische mogelijkheden die er al zijn, en het daadwerkelijke gebruik ervan.

Door proactief mee te denken en collega's te stimuleren en begeleiden, kunnen it'ers die brug slaan - als ze er voor open staan.

Richard Poolman, regional director Benelux, Servicenow

 

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

7


Lees meer over


 

Reacties

Vreemd, volgens het artikel is er “een nieuwe generatie werknemers, die gewend is om zelf technologie te ontwikkelen”. “Als zij een probleem tegenkomen dat op te lossen is met it, dan krijgen ze dat voor elkaar” en “Citizen developers hebben de potentie om hun vaardigheden en inzicht in de processen van de organisatie snel om te zetten in een oplossing die echt waarde kan toevoegen”

Doe je er als ICT-er niet onmiddelijk aan mee, dan werk je “rogue ICT” in de hand. Dan zijn begrippen als architectuur, beveiliging, risico's, points of failures, strategie, interfacing, coupling, uniformiteit, jurische aansprakelijkheid, encapsulation, IAM, licenties ineens wel relevant geworden ?

ICT, speeltje of toch een vak ? Zeg het maar hoor, ik wil best proactief , stimulerend, begeleidend bruggenslaand meedenken als dat de trend is.

Dit stuk is niet erg realistisch en is wellicht van toepassing op jonge bedrijfjes met 10 of minder werknemers. Werknemers die in (middel)grote bedrijven op eigen houtje gaan sleutelen aan bedrijfsprocessen hebben in de regel geen enkel idee waarmee ze bezig zijn.

Mijn ervaring (binnen wat grotere multionationale ondernemingen) is dat werknemers die willens en wetens compliance- en beveiligingsinstructies negeren teneinde (onveilige) software te introduceren binnen hun werkomgeving, gewoon ontslagen worden.

Ik citeer uit het werk van anderen:

"A citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT. In the past, end-user application development has typically been limited to single-user or workgroup solutions built with tools like Microsoft Excel and Access. However, today, end users can build departmental, enterprise and even public applications using shared services, fourth-generation language (4GL)-style development platforms and cloud computing services."

Die uitleg geeft misschien wat context aan het verhaal want het is volgens mij niet zo zeer wat nieuws maar zijn alleen andere tools.

De genoemde trends herken ik wel, maar wederom wordt voorbijgegaan aan het "waarom" van de IT afdeling.

Zoals KJ al opmerkt, dit is misschien werkbaar voor kleine ondernemingen, maar hoe zie je dit voor je als je enkele honderden IT-ers in dienst hebt binnen je onderneming? Hoe ga je bijvoorbeeld diverse e-mail en agenda clients op elkaar afstemmen? Dito voor alle andere toepassingen die je in je omgeving nodig hebt voor het dagelijks werk.

Naast software die met elkaar zal moeten samenwerken komen ook de kosten om de hoek kijken. Niet alles software is gratis zoals we weten. Wil je als organisatie gaan voor 1 keer 500 licenties, of voor 10 verschillende pakketten (met hetzelfde doel) van 50 licenties elk?

En tot slot: waar kan de gebruiker terecht als iets niet werkt? Wordt van je ondersteunende organisatie verwacht dat ze alle pakketten van voor tot achter kennen, inclusief alle onderlinge integraties?
Oh, wacht, dat doen de gebruikers natuurlijk ook zelf. Immers, "google is your friend!"

In dat geval moet je je als organisatie wellicht eens afvragen of je wel op de goede koers zit. Wat wil je dat je personeel doet? Datgeen waar ze voor aangenomen zijn, of laat je ze hun (vaak kostbare) tijd verstoken aan het uitzoeken van nog betere (?) tools dan wat ze al hebben en het werkend krijgen en houden van deze tools ???

@PaVaKe
Wat hier niet verteld wordt is de 'vendor-lock' die in dit soort oplossingen zit, hoeveel bedrijven zitten bijvoorbeeld hierdoor nog vast aan Lotus Domino?

@Ewout: vendor lock kan misschien vervelend zijn, maar als je om de paar jaar wil wisselen van leverancier, en daarvoor hele migraties van gebruikersomgevingen moet doen (bijv. alle microsoft documenten omzetten naar open office, lotus naar exchange etc), ben je dan niet veel duurder uit?

Citizen Developer? De standaard 'developers' zijn meestal militairen?

Ik begrijp de term niet helemaal. Ook geloof ik niet dat Millennials alles kunnen oplossen. Ik vind de verloren generatie ver gaan, maar dit gaat veel te ver de andere kant uit.

Voor de rest niet IT-ers die lekker gaan hobbyen is leuk, totdat een schat aan bedrijfsgevoelige informatie op een drive bij een dubieuze SaaS/Cloud aanbieder staat.

@PaVaKe
Precies dat is wat ik bedoel, je zit vast in een oplossing omdat gebruikers allerlei oplossingen hebben gemaakt die geen rekening houden met portabiliteit. De tool wordt belangrijker dan het doel. Om dicht bij mijn eerste reactie te blijven, de formules in Excel kunnen een showstopper worden om naar Calc te migreren.

Een probleem dat je vaak ziet in dit soort omgevingen zijn dan ook alle ongedocumenteerde koppelvlakken, er was ooit eens een reden voor het idee van de Enterprise Service Bus.

Nu zeg ik niet dat wisselen van leverancier een doel is maar je wordt wel beperkt in je keuzen als je er erg afhankelijk van wordt. En dan is het maar de vraag wie nu werkelijk het IT beleid bepaald zoals we nu dus zien met migratie van Windows XP icm Office.

Citizen developer is een term van Gartner welke opmerkelijk weinig aandacht heeft voor de ontwikkelingen in open source. Dat is vreemd aangezien juist dat perfect past binnen de gegeven definitie van Citizen Developer, delen van je oplossingen vraagt tenslotte ook een stuk onderhoud en ondersteuning.

Misschien dat Richard Poolman nog gaat reageren want tot op heden vind ik zijn verhaal gewoon buzzword bingo, dezelfde fouten worden gewoon herhaald met nieuwe tools.

@Ewout

Een vergelijkbaar fenomeen herken ik uit SW ontwikkel-omgevingen. Ook daar zie je dat sommigen al jaren "vast" zitten aan bepaalde tools omdat, gezien omvang en complexiteit, migratie schier onmogelijk is.

De nieuwe ontwikkelingen op dit gebied zijn gelukkig veelbelovend. Op basis van open interface standaarden is het nu (relatief eenvoudig) mogelijk tools van meerdere leveranciers aan elkaar te knopen. Migraties blijven lastig, maar het biedt al heel wat meer mogelijkheden dan voorheen.

De premise van Gartner is dat als je slimme libraries hebt hoef je geen universiteit gedaan te hebben om business applicaties te bouwen.

Zelf bouw ik webservices die gebruikt worden om bijvoorbeeld gepersonaliseerd marketing materiaal te customizen. Door een generieke laag te bouwen kan een niet programmeur door wat te goochelen met instellen verrassend veel maatwerk realiseren zonder dat de IT afdeling daarvoor nodig is.

Ook de Mendix-en van deze wereld maken het in principe mogelijk om een niet programmeur applicaties samen te stellen die gewoon goed kunnen functioneren. De code truukjes die soms noodzakelijk zijn, zijn vrij snel aan te leren voor iemand zonder programmeer achtergrond.

Citizen developers kunnen dus alleen maar ontstaan/bestaan als dit echt onderdeel is van een bedrijfsstrategie. Dit zal echt geen de facto standaard worden. Ook Gartner gaat voorbij aan het feit dat heel veel mensen geen interesse hebben in IT en veel andere bedrijven zullen de visie niet hebben om het in "beschermde" omgeving aan bieden van codeer mogelijkheden.

Uiteraard is het wel een goed idee om de business zoveel mogelijk leverage te geven en ben ik het er wel mee eens dat een universitaire opleiding niet een drempel moet zijn om software te mogen ontwikkelen.

@henri
Zoals ik al stelde is het niets nieuws, Excel of Mendix is lood om oud ijzer. Een aap kun je trucjes leren maar dat wil nog niet zeggen dat deze primaat zich ook ontwikkeld heeft. Dat jij 'gepersonaliseerd marketing materiaal' levert is prachtig maar niet veel meer dan Excel plus, zoiets als schilderen op nummer.

Volgens mij zit het verschil tussen HBO en universitair in het weten versus aannemen. Hoef hopelijk niet in te gaan op de case van marketing bij sommige onderzoeken, want de controleerbaarheid mist namelijk nog weleens. Als veel mensen geen interesse hebben in de IT dan zeg je eigenlijk dat ze vertrouwen op blackboxen.

Ik heb een sceptische inslag maar ik begreep dat uit onderzoek naar voren kwam dat beslissers steeds minder vertrouwen hebben in de informatie die geleverd wordt met al die mooie 'bussines leveraging' tools.

Ik kan het natuurlijk mis hebben maar BI gaat niet om de 'eye candy' maar de juiste en relevante gegevens. Dat vraagt analystisch vermogen want anders is het toch weer 'all the tools but no idea' zoals ik al eens eerder zei.

Ewout, ik snap je reactie en wellicht dat het gelijk ook grotendeels aan jouw kant zit, maar ik denk dat je iets te zwart/wit denkt en/of te sceptisch.

Laat ik voorop stellen dat ik niet geloof in accidental developers. Zeker omdat de keten meer is dan een appje voor de eindgebruiker en Excel als app ronduit evil is. Aan de andere kant kan ik me wel voorstellen dat er voorwaarden geschapen kunnen worden waarin niet native ontwikkelaars oplossingen maken, maar welk probleem lossen ze hiermee op?

- Dat ontwikkelaars minder snappen van de business?
- Dat business mensen goedkoper zijn dan ontwikkelaars?
- Dat ontwikkelaars moeilijk communiceren dan business mensen?
- Dat business mensen betere oplossingen realiseren?
- Dat je met betere eco-systemen of platformen werkt waarmee je sneller oplossingen realiseert?

Hoe dan ook is het geen eenvoudige propositie en het nadeel van generieke raamwerken zijn dat ze voor standaard werk snel bruikbaar zijn, maar voor de "last mile" extreem ingewikkeld of zo omslachtig dat iemand na een half jaar niet meer weet hoe het zat en documentatie erover onleesbaar is.

Onder bepaalde omstandigheden geloof ik er in, maar vooralsnog kan ik me niet voorstellen dat dit de komenden tien jaar uit een niche komt.

Ik geloof overs dat Jack (J) hierover een boeiende mening heeft :-)

@Henri
Gelijk of geen gelijk is niet de kwestie, het gaat om de praktijk.

En die praktijk blijkt al een jaar of 20 heel wat weerbarstiger te zijn dan analisten ons willen doen laten geloven. Dat tools nu makkelijker zijn geworden wil nog niet zeggen dat daarmee de oplossingen ook beter zijn geworden.

Framewerken hebben bijvoorbeeld de neiging om je te 'framen' doordat je langs de lijn gaat lopen die leveranciers getrokken hebben. Of zoals jij het zegt, wil je wat anders dan zit je al gauw tegen hoge migratiekosten aan te kijken. Betreffende je vragen - met name rond communicatie - zou je het dus ook om kunnen draaien. Het is de business die niet open staat voor de problemen die er zijn, legacy is een keus die meestal niet door de IT is gemaakt.

ServiceNow, shit tomorrow?

@Henri,

Dit is zeker een boeiend opiniestuk, hoewel deze toch wat meer in jouw dan in mijn straatje past. Mijn pleidooi voor maatwerk door de business als aanvulling op maatwerk door ICT heeft inderdaad wel raakvlakken met het hier gestelde citizen development, maar ik wil vooral ook een aantal verschillen benadrukken.

In de eerste plaats heeft het hier uitgewerkte “citizen development” hetzelfde euvel als jouw visie: teveel cloud (-computing) en te weinig SOA. Waarbij “te weinig SOA” nog een understatement is: het begrip ontbreekt gewoon in het hele stuk.

Wordt nu, in de tweede plaats, selfservice in verband gebracht met cloud computing, dan doet zich een volgend interessant fenomeen voor: selfservice is vooral iets om te gebruiken, en blijkbaar niet om tot stand te brengen! Maar gebruik maken van de selfservice mogelijkheden die cloud computing met zich meebrengt is wel wat anders dan het realiseren van selfservice applicaties (hoewel het een het ander natuurlijk niet hoeft uit te sluiten). En je voelt hem al aankomen: selfservice applicaties realiseer je niet in de eerste plaats met cloud computing maar met SOA.

In dat opzicht is de vergezochte term “citizen development” dan ook niet een blijvertje; veel aannemelijker is het om gewoon te spreken van business development. Die citizen developers blijven dus gewoon voor de deur staan :-)

@Ewout,
Wat is jouw alternatief voor SOA: terug naar de batchverwerking binnen de silo-applicaties op het mainframe?

@Jack
Je silo-achtige applicaties binnen mainframe ontstonden vooral door de organisatorische begrenzingen. Delen was tenslotte nimmer het probleem maar het ging altijd om de regels.

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

×
×