Er wordt door bedrijven tegenwoordig lustig geëxperimenteerd met het ontwikkelen van mobiele apps. Een overkoepelende app-strategie ontbreekt echter bij de meesten. En dat heeft gevolgen voor de efficiency en brengt op termijn grote risico’s met zich mee.
Ontwikkeling van mobiele apps voor de eigen business gebeurde tot voor kort in beperkte mate. De laatste twee jaar is dat echter sterk aan het veranderen. Steeds meer bedrijven zien de mogelijkheden van mobiele apps voor hun bedrijf. Voorbeelden van geslaagde innovaties zijn er immers genoeg. Voorraadbeheer in magazijnen wordt bijvoorbeeld verbeterd met mobiele apps. Sales-medewerkers kunnen via hun mobiele telefoon een ordergeschiedenis zien voordat ze een gesprek ingaan. En ook op het gebied van klantcontact liggen enorme kansen. Klanten kunnen met behulp van mobiele self-service portals zelf informatie opzoeken en zo veel support zelf doen. Een ‘mobile enterprise’ heeft zodoende een hogere productiviteit en een betere dienstverlening.
Experimenteren
Geen wonder dus dat bedrijven de afgelopen jaren sterk zijn gaan experimenteren met het ontwikkelen van eigen apps. Of het nu gaat om marketing, logistiek of de klantenservice, iedere afdeling heeft wel wat geld over om een eigen appje te laten bouwen en zo aan zijn eigen werkprocessen te sleutelen. De business staat wat dat betreft nu ineens zelf aan het roer, iets wat in voorgaande jaren veel minder het geval was.
Op zichzelf is dat een gunstige ontwikkeling. Toch zitten er ook risico’s aan deze voortvarende explosie van app-ontwikkeling. Bij de meeste organisaties gebeurt dit namelijk decentraal, zonder coördinatie met de eigen it-afdeling. Het gevaar bestaat daardoor dat er een versnipperd technologielandschap ontstaat. Apps van verschillende afdelingen kunnen ongeveer hetzelfde, maar kunnen niet uitgefaseerd of samengevoegd worden omdat ze net niet op dezelfde manier werken. Ze kunnen niet goed onderhouden worden door de it-afdeling en kunnen daardoor moeilijk van nieuwe security updates worden voorzien. En hergebruik van code is ook niet goed mogelijk. Iedere business owner heeft immers een ander bedrijf ingeschakeld om de app te bouwen. Een brede bedrijfsstrategie voor het ontwikkelen van apps blijkt bij de meeste bedrijven te ontbreken.
Business case
Het belangrijkste probleem bij app-onwikkeling is dat er geen business case wordt gemaakt. De technologiekeuzes die gemaakt worden sluiten daardoor vaak niet goed aan op de functionele wensen. Veel bedrijven denken bijvoorbeeld dat een app een native iPhone- of Android-app moet zijn en overwegen niet een webapp of hybride app te maken. In zijn algemeenheid kun je stellen dat native apps beter in staat zijn om de grafische mogelijkheden van een device te benutten. Html5 web-apps zijn juist weer goed in het weergeven van almaar wisselende content. En hybride apps, een html5-app met een native schil, heeft ook weer specifieke voordelen. Hybride apps zijn onder andere geschikt voor het ontsluiten van bedrijfsinformatie in een app met beperkte grafische dynamiek en voorkomt dat je dezelfde app moet schrijven in verschillende native talen (iOS, Android, Windows).
De functionele eisen en de technische keuzes zijn ook van belang wanneer je kijkt naar bereik. Een native app heeft een beperkt bereik, omdat het alleen kan draaien binnen een bepaald besturingssysteem. Anderzijds hebben web-apps weer te maken met de verschillende browsers. Werkt de web-app inderdaad in iedere browser even goed? En hoe zit het met dekkingsgraad en bandbreedte van het netwerk? In Nederland wordt die steeds beter, maar in sommige situaties kan het een bottleneck zijn.
Duurzaam ontwikkelen
Los van de discussie rond web-apps, hybride apps en native apps zijn er nog veel vragen over de herbruikbaarheid van code. Is er een goede scheiding van de interface-laag, de logica en de datalaag? Alleen wanneer een app op een dergelijk wijze is gemaakt, kan hij ook voor de lange termijn goed worden onderhouden. Ik zou dan ook het volgende willen stellen: blijf experimenteren, maar betrek je it-organisatie bij het maken van je apps. Zij hebben de beste kijk op het maken van technologische keuze bij de ondersteuning van een business case en op het duurzaam ontwikkelen en betaalbaar houden van deze apps.
Wellicht ben ik wat conventioneel in deze, maar is strategieloos ontwikkeln (dus ongeacht of dat nu apps zijn of iets anders) sowieso niet heel erg slim?
Visieloze opinie, delivery model van app versus deployment model van een proces zijn twee verschillende dingen. Dat een native app ten opzichte van HTML5 voordelen heeft aangaande de controle van dichtbij de gebruiker liggende functionalteiten door directer de hardware aan te sturen heeft weer als nadeel dat je minder controle op de informatie zelf hebt. En ja, netwerk heeft in dat geval altijd impact.
Volgens mij moet je eerst naar business proces zelf kijken, hoef hopelijk niet uit te leggen dat mobiel maken van business processen soms voor dure teleurstellingen kan zorgen. Probleem is dat veel apps vaak een aansluiting op de back-office nodig hebben waardoor er opeens allerlei non-functionele vereisten rond beveiliging mee gaan spelen.
Knappe reactie Ewout, vooral je eerste alinea.
Ook vind ik dat een business case niet altijd gemaakt moet worden. Centraal staat dat je waarde toevoegt of een probleem oplost. Van te voren kun je niet bepalen wat daarvan de waarde is, hooguit educated gues. Zolang je maar wel “fail fast” hanteert.
Daarnaast kun je met AppMachine redelijk generiek applicaties maken voor Android en IOS (samen 95% van de markt). Ik denk dat je zelf teveel in een bepaald veld werkzaam bent waardoor je te nauw naar applicaties op telefoons kijkt.
@Henri
De insinuatie dat ik teveel in een bepaald veld werkzaam ben klopt wel, want ik sta ‘met mijn voeten in de klei’ van de realiteit welke altijd weer weerbarstiger is dan mooie beloften. Je idee van ‘fail fast’ valt onder de categorie van de opportunistische ‘agile’ denkwijze die leuk werkt bij alle ‘stand-alone’ oplossingen, 95% van de apps zullen we maar zeggen;-)
Als je kijkt naar tweede alinea begrijp je wat ik bedoel met delivery model, wie geen business case maakt weet dus niet wat de waarde is voor de business en is strategieloos aan het ontwikkelen. Opmerkelijk vaak leidt dat dus tot non-compliant oplossingen welke voor problemen zorgen wanneer ze overgedragen worden aan beheerorganisatie, idee van DevOps probeert dit trouwens op te lossen.
“Het belangrijkste probleem bij app-onwikkeling is dat er geen business case wordt gemaakt” stelt de auteur. Dat is nogal wat, uit de mond van een Business Development Manager, expert op BI gebied.
Henri vindt dat weer niet altijd een probleem “zolang je maar waarde toevoegt of een probleem oplost”. De educated guess hoe hoog die toevoeging is, is soms het hoogst haalbare. BI als educated guess leverancier ? Insourcen als het nieuwe outsourcen ? Flexibel decentraliseren of toch maar alles centraal ? Hybride misschien ?
Elke oma kan het je vertellen hoe de wereld in elkaar steekt. We doen allemaal maar wat 😉
Ewout, sorry, alleen de eerste regel ging in op jouw reactie, de rest op het artikel.
Felix, inderdaad, we doen allemaal maar wat, en soms pakt dat verrassend goed uit 🙂
Natuurlijk moet je een strategie hebben of een idee over het de wereld er over vijf jaar uit ziet en wat voor consequenties dat heeft voor jouw bedrijf. Maar alles van te voren uitkauwen, gissingen over opbrengst verkopen als een business case, ik geloof daar niet zo in. Veel te traag.
Wat is de opbrengst van een app waarmee je kunt bankieren? Wat levert een goede gebruikers ervaring nu werkelijk op? Je weet het niet.
In dat opzicht vind ik de ING case leerzaam. Ja, ze hebben de meeste storingen van internet bankieren… wereldwijd! Maar nu is de stof een beetje neergedaald en hebben ze de best gewaardeerde APP voor internet bankieren. Dat is de opbrengst van continuous delivery. Een basis product neerzetten en daarna itereren als een malle.. dat zorgde inderdaad voor de ene storing naar de andere, maar uiteindelijk een product dat voorloopt op de rest en daarmee denk ik dat ING aan het langste eind trekt.
Je hebt dus absoluut gelijk dat veel dingen dan in de basis niet compliant zijn en frictie geven met andere processen en beheersbaarheid, de vraag is of je dan maar als het braafste jongetje van de klas alles netjes moet doen en mogelijk te traag of dat je iets sneller gaat doen en mogelijk tegen wat obstakels oploopt. Lijkt me een onderdeel van de risico analyse, maar nogmaals, conventioneel en te behouden geloof ik niet in.
Dan is het wel weer zaak om een goed team te bouwen en naar de competenties te kijken van de mensen waarmee je deze verandering gaan doen. Trekken ze om vijf uur de deur achter zich dicht, of zijn ze bereid om net dat tandje bij te zetten wat ze bijzonder maakt?
Het zou zo mooi zijn als we een konsistent taalgebruik hadden.
Wat is een “app”? Een programma geschreven in een hogere programmeertaal of een webapplikaties die op de server draait en lokaal alleen met een browser te bedienen is?
HTML5 is geen programmeertaal, maar hyper text markup language.
Ik ken ook geen “native” als programmeertaal is dat C, C++, Python, Perl of misschien wel GTK?
Smartphone-applikaties voor de zakelijke markt moeten mijns inziens wel degelijk een business-case hebben alhoewel Henri’s voorstel de gebruiker als beta-tester te gebruiken tegenwoordig ook meer regel als uitzondering is.
Ontwikkelen zonder strategie lijkt mij ook niet erg doelmatig, om het even op welk platform.
Er worden in het artikel voor mijn gevoel sowieso wat kreten te pas en te onpas door elkaar heen gebruikt.
Innovatie is niet gedreven door businesscases, pas wanneer je een innovatie naar de markt wil brengen ga je kijken of het meer oplevert dan wat het kost.
Echter, bij vervanging van iets bestaands werk je meteen met een businesscase, en speelt innovatie geen rol meer.
Goedemorgen Heren,
Hartelijk dank voor uw input, ondanks dat niet alles even constructief is 🙂
@Felix, een business development manager die toevallig ook developer is geweest… Ik weet het, een rare combinatie. Toch blijft m’n aanbod staan om een keer naar ons product te kijken. Ik weet zeker dat je dan constructievere feedback gaat verzorgen.
Felix, take the blue or red pill 😉
Heren ik lees feedback dat zaken door elkaar heen lopen, maar dat heeft meer te maken met het product dat we zelf gebruiken. Het OutSystems Platform maakt relatief weinig onderscheid in het bouwen van de diverse applicatie typen. Dat maakt het dat we intern vaak over een ‘app’ praten, ongeacht device type.
In onze context in bepaalde scenario’s geheel niet van belang, los van de UI. Die UI is in de basis weer een automatisch bouwprocess in ons Platform.
Mocht dit wat exotisch klinken, dan lees ik graag je vragen!
Vriendelijke groet,
Mark
@Henri Leg je nu een verband tussen verstoringen bij ING en de continuous delivery? Dat is wat ik soms ook denk, te wild met wijzigingen. Het zou getuigen van zwak management. Ik vind het ten opzichte van gebruikers niet te verkopen. Dit kost je klanten en geld als er veel storing is, beschikbaarheid zou op één moeten staan.