In hun drang om maar zo snel mogelijk een mobiele applicatie op te leveren, laten veel bedrijven zich verleiden tot het bouwen van native apps. Ze realiseren zich hierbij vaak niet dat ze hiermee allesbehalve een mobile enterprise worden en tevens de basis leggen voor een groot legacy-probleem in de toekomst.
Bedrijven zetten met het oog op het realiseren van een kostenbesparing, een verbeterde dienstverlening en innovatie massaal in op mobiele applicaties. Ondanks dat er een groot aantal standaard- en SaaS-applicaties in de markt beschikbaar is, kiezen steeds meer bedrijven er voor om zelf hun eigen applicaties te ontwikkelen of te laten ontwikkelen. En dat is niet voor niets. Maatwerkapplicaties sluiten doorgaans een stuk beter aan op de behoeften van de business en op de processen die zij moeten ondersteunen, zeker als het gaat om je als bedrijf te onderscheiden op bijvoorbeeld (klant)interactie en service.
Ik spreek dagelijks met it-beslissers en uit die gesprekken maak ik op dat bij het ontwikkelen van enterprise applicaties hetzelfde gebeurt als bij het ontwikkelen van websites in de begindagen van het internet. Toen wilde alles en iedereen een website hebben en het liefst zo snel mogelijk. Het gevolg was een soort van rat race waarin bedrijven over elkaar heen tuimelden om maar eerder dan hun concurrenten een website in de lucht te hebben. Let wel, dit waren losstaande websites, die eigenlijk puur als visitekaartje van het bedrijf dienden. Over integratie met de back-end systemen en beheerbaarheid werd nauwelijks nagedacht.
Datzelfde zie je nu gebeuren met enterprise apps. Ieder bedrijf wil zijn eigen mobiele app hebben. En in hun drang naar snelheid kiezen ze vaak voor native apps.
Deel van het geheel
Bedrijven staan echter veel te weinig stil bij het feit dat mobiele applicaties ook deel moet gaan uitmaken van het totale systeemlandschap van de organisatie, gedurende langere tijd moeten worden beheerd en veelvuldig moeten worden aangepast en uitgebreid. In combinatie met de grote verscheidenheid aan devices, besturingssystemen en onderliggende technologieën, zijn native apps eigenlijk geen goede optie voor bedrijven om invulling te geven aan hun mobiele strategie.
Bedrijven zouden er beter aan doen om te kiezen voor hybride apps en web apps. Deze zijn beter te distribueren, kunnen eenvoudig worden geupdated en realtime bijgewerkt. Daarnaast zijn ze ook veel beter te integreren in de totale architectuur, wat uiteindelijk ook de beheerbaarheid en functionaliteit weer ten goede komt.
Om te voorkomen dat (native) mobiele applicaties de legacy van de toekomst worden, is het de hoogste tijd dat bedrijven enterprise apps als volwaardig onderdeel van hun it-strategie gaan beschouwen en zich realiseren dat deze apps ook in lifecycle management ingebracht moeten worden.
Dat begint met een duidelijke strategie en kan zeer efficiënt worden gerealiseerd door gebruik te maken van een rapid application delivery (rad)-platform. Met zo’n modern visueel, modelgedreven platform zijn in korte tijd en kosteneffectief hoogwaardige mobiele applicaties te ontwikkelen, op alle mogelijke devices in gebruik te nemen en gedurende de gehele applicatie-lifecycle efficiënt te beheren. Daarnaast omvatten dergelijke platformen een groot aantal standaard koppelingen en methodieken die het integratieproces met reeds aanwezige systemen en applicaties vergemakkelijken.
Heeft u al goed nagedacht over wat u wilt worden? Wordt u een bedrijf met een mobiele applicatie of wordt u een mobile enterprise? De keuze is aan u!
Hoewel native apps inderdaad nadelen bevatten die je zelf ook al beschijft, is het wel zo fair om ook de nadelen van hybride / web apps / browser apps te benoemen.
Native apps zijn vaak gebruiksvriendelijker, sneller, voorspelbaarder met een rijkere interface met een betere app beleving en bedienbaarheid die aansluit op het platform waarvoor ze gemaakt zijn. Wachttijd verschillen van meer dan 100 milliseconden zijn al merkbaar en worden snel als irritant en minder productief ervaren. Of het om kunnen gaan met labiele en/of wegvallende verbindingen. Vaak is het volledig correct laten functioneren van een browser of webapp uitdagend en zijn er meer dingen lastig te verwezenlijken.
Voordat je keuzes maakt moet je dan vooral kijken wat bij je past.
Ontwikkel je zelf? Verandert de applicatie vaak? Heb je toegang tot voldoende kennis? Hoeveel zal er gewerkt worden op mobiel? Hoe belangrijk is een rijke beleving?
Er is geen antwoord wat iedereen het beste past en foute keuzes kunnen inderdaad leiden tot de legacy van morgen.
Omdat het accent bij de web- portalen- apps- devices vaak alleen ligt op de front end is de legacy voor de hand liggend. In die zin een prima artikel. Ik ben het echter op een deel fundamenteel oneens. Er wordt gesproken over dat dit in de toekomst een probleem kan gaan vormen.
Omdat met name in de zorg de apps als onkruid uit de grond schoten en schieten en er voor ruim 95% geen link is om data naar een elektronisch patiëntendossier of persoonlijk gezondheidsdossier door te geven, is die legacy al ruim aanwezig. Ik zie dat als de grootste uitdaging van de huidige app hype. Op conceptueel niveau is de oplossing hiervoor ontwikkeld, een deel ook de logica waar implementatie nu voor in gang wordt gezet.
Voor mijn gevoel is legacy een te groot woord in deze.
Bij legacy denk ik meer aan grote complexe systemen die niet 1-2-3 om te zetten zijn. Deels vanwege gebrek aan kennis (de bekende cobol-mainframe omgevingen), deels vanwege grootte en complexiteit (bijv cardio-vasculaire röntgensystemen van 15 jaar oud).
Apps zijn veel kleiner, hebben een kortere levenscyclus, en de benodigde kennis is nog steeds voorhanden.
Goed nadenken over onderhoudbaarheid van je omgeving is sowieso iets wat je moet doen, en dat kan inderdaad problemen opleveren, Het is echter wel een zéér lichte vorm van legacy mijns inziens.
“Software van nu is legacy van nu”, uitspraak van Paul Klint, CWI en BIT tijdens de Legacy Coalitiedag op 12 januari 2016.
En zeker geldt dat voor apps. Als je een half jaar geen updates doorvoert werkt het vaak al niet meer, vanwege nieuwe eisen OS of kwetsbaarheden die Apple en Google niet meer toestaan.
Maar inderdaad, zoals PA VA KE aangeeft: levensduur van apps is vaak kort, en als de app veel gebruikers heeft is er vaak zeer actief beheer op.
In goed Nederlands gaat het om de erfenis, de baten van successierechten van een eerdere keus versus de lasten van onderhoud heeft dan ook weinig met ICT te maken. Typisch dat Pa Va Ke in deze discussie maar 2 en Henri 4 sterren krijgt, blijkbaar hebben sommigen werkelijk geen idee van de ecosystemen in alle digitale transformaties.
dat Henris reactie veel sterren krijgt is precies waar het artikel over gaat.
“Ieder bedrijf wil zijn eigen mobiele app hebben. En in hun drang naar snelheid kiezen ze vaak voor native apps.”
Consumerization of IT, wie levert vriendelijk snel de rijkste beleving ?
Las ik niet laatst in een reactie:
1) klant heeft altijd gelijk
2) de klant kan zich vergissen
Hoe dan ook, Henri gaat het maken en verkopen. Das triviaal.
Ja, deze hippe app staat u leuk, past helemaal bij u.
De oude kan terug in de kast.
Het mooie is snel ontwikkeling, met vrij weinig budget iets moois maken. Maar dat houdt niet lang stand. Is dat erg? vaak niet. Immers als je nu maar zorgt dat de data op een goede structurele manier is vastgelegd en die losse apps vooral worden gemaakt en gebruikt om deze data te ontsluiten dan is er eigenlijk niet echt iets aan de hand als de app wegvalt.
Gaat de app een belangrijk onderdeel uitmaken van de kernprocessen dan gelden er heel andere regels.
Zolang alles veilig (.. cybercrime..) is en de data integriteit niet in gevaar komt natuurlijk.
Het argument dat native merkbaar sneller is en dat met web niet exact dezelfde user experience die volledig aansluit is allang achterhaald.
Niet alleen omdat VMs enorm zijn verbeterd maar ook omdat in hybride scenario herbruikbare platform onderdelen native zijn geïmplementeerd in de enterprise container, die ook nog eens extra security en gemak biedt. Bij UI moet je slim gebruik maken van hardware acceleratie met CSS. Bij sommige enterprise platforms worden er native herbruikbare diensten geleverd waardoor web juist 10x sneller is te ontwikkelen omdat je alleen maar hoeft te richten op ui en minimale business logica.
Native is voor computerspelletjes, Voor enterprise apps op mobiel geldt hetzelfde als op desktop. Je bent niet goed bij je hoofd als je nu nog native gaat ontwikkelen in een enterprise omgeving.
Richard, dat is wat ik noem een uitgesproken mening. Oprechte interesse: kun je je eerste regel van je reactie onderbouwen en man en paard noemen?
Zelf ben ik nog geen “generieke” enterprise apps of web apps op mobiel tegen gekomen die beter functioneren dan native varianten. Heb je links naar youtube, artikelen, of wat dan ook?
En nogmaals: native heeft serieuze nadelen zoals dat je voor twee (nou vooruit drie) platformen moet ontwikkelen en zeker als de life cycle beperkt is en je kennis extern moet inkopen zijn dit belangrijke overwegingen. Maar van wat ik tot nu toe gezien heb is de user experience van native nog zeker niet bereikt en werken ook interne api calls met kuren en niet vlekkeloos.
De strijd tussen en native versus web apps is echt nog niet beslist al zal voor een groot gedeelte van de gevallen voor web apps gekozen worden. En zoals ik eerder schreef, ik ben ook meer van de web apps dan van native, dus het verdedigen van native is niet uit eigen belang of met een tweede agenda.
Excuus voor late reactie.
Onderbouwing gaf ik al, VMs sneller geworden en container draait alle intensieve zaken native. Er zijn veel verschillende leveranciers die een container bieden. Gebruik je bijvoorbeeld alleen container met Apache Cordova, dan wordt de meeste computatie en data transfers gedaan in javascript, maar gebruik je een container die datacommunicatie, authenticatie, app specifieke rendering (bijvoorbeeld vector berekeningen), hardware accelatie en dergelijke in de container aanbiedt, dan hoef je alleen nog wat UI (soms met native scroll implemenatie) en met wat business logica aan elkaar te knopen. Snel klaar en snel.
Een goed bewijs is bijvoorbeeld linkedin, waarvan mobiele app in html5 is geschreven om makkelijk te kunnen updaten (dus niet alleen gemak van meerdere platforms maar ook beheer is stuk eenvoudiger, uitrol van updates, maken van aanpassingen, al die dingen die erg belangrijk zijn voor mobiel).
Daarnaast is het bewijs dat java VMs enorm sneller zijn geworden, niet alleen het feit dat Android voorheen trager was dan iphone maar inmiddels sneller, omdat er veel aandacht is voor performance, met html5 benchmarks, maar ook opkomst van nodejs.
Om bij linkedin te blijven, 27x minder servers en 20x betere performance door backend in javascript te schrijven, vergeleken met ruby on rails, maar vergelijking met java backends die “native gecompileerd draaien”, zijn voorbeelden van 5x minder servers en 2x betere performance.
http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html
Wij gebruiken bijvoorbeeld deze mobiele app die in html5 is geschreven, te downloaden van app store. Kun je zelf zien hoe rap het allemaal werkt. Wijzigingen in de backend zijn binnen 2 seconden zichtbaar op device, scrollen gaat super vloeiend, alles reageert snel.
https://www.youtube.com/watch?v=sjDWi5jeWFQ
Als je wedstrijdje gaat doen zal native wel iets sneller zijn, maar niet sneller dan menselijke interactie.. je moet je dus afvragen of de enorme voordelen van web apps, updates pushen, local caching, web standaarden en eenvoud van integratie, aanpassingen, goedkope ontwikkelaars en nog veel meer, ondergeschikt is aan een niet-noemenswaardige performance verschil. Je zou anders het argument evengoed tegen web applicaties op desktop kunnen voeren want native fat client apps zijn ook sneller dan webbrowser, maar een beetje bedrijf maakt toch echt een andere afweging. Vandaar mijn statement dat native alleen nuttig is voor computerspelletjes en met grote uitzondering bepaalde rekenintensieve applicaties die op de client moet worden uitgevoerd. Ik durf te stellen dat dit voor 99% van de enterprise apps niet van toepassing is.