I dag vil vi gerne introducere jer for en anden måde at tænke på apps på, og den er kraftigt inspireret af "Software-as-a-Service", eller SaaS. Vi kalder det: "Apps-as-a-Service".
SOFTWARE-AS-A-SERVICE
Kernekonceptet i Software-as-a-Service - en stor IT-ressource som vedligeholdes centralt - er lige så gammel som IT selv. Da IT var noget helt nyt, var størrelse hovedsagelig noget fysisk, og vedligeholdelse involverede, at man fjernede fysiske insekter (bugs) i hardwaren. Over tid blev computere mindre og flyttede op på vores skriveborde og endda videre til vores skød (via laptops). Det skabte helt nye udfordringer i forhold til, hvordan man vedligeholder mange ikke-forbundne computere, og det indledte tidsalderen for "IT-crowd". Internettets indtog vendte denne udvikling. Nu anvender vi cloud computing, og det vigtigste interface er webbrowseren. Vi behøver heller ikke længere installere programmer, da vi bruger softwaretjenester. Det er en fremragende model, og den har været en kæmpe succes.
Samtidig med fremkomsten af SaaS, vendte en succesfuld producent af MP3-afspillere op og ned på mobilmarkedet og udraderede i processen MP3-afspilleren. I 2007 lancerede Apple den første succesrige moderne smartphone - iPhone. I iPhonens tidlige barndom blev web-apps anbefalet, når der skulle laves apps. Apple tilføjede endda funktioner i deres browser for at hjælpe udviklere med at få websider til at ligne apps mere. En overgang så det ud til, at iPhonen ville blive en kæmpestor drivkraft for SaaS-baserede løsninger. Men et år efter lanceringen af iPhonen blev App Store så åbnet, og pludselig gik alle rundt og sagde "det er der en app til".
Mange af vores kunder og faktisk hele avisbranchen begyndte at blive opmærksomme på udviklingen - især da iPad'en blev lanceret. Her var der endelig en enhed og en formfaktor, som kunne bruges til at læse på og meget, meget mere. Alle følte pludselig, at de absolut måtte bruge Apple's App Store. På det tidspunkt var det ikke helt tydeligt, hvad det der "meget, meget mere" egentlig var. Set i bakspejlet viste det sig dog, at det hovedsagelig var videoer med katte og Angry Birds!
Fortalere for browserteknologier som basis for apps har længe givet deres mening tydeligt til kende. Men selvom SaaS-modellen, som blev gjort mulig via browserteknologier, godt nok var en meget attraktiv model for udviklere, så er slutbrugerne ligeglade med teknologien bag. De vil underholdes eller lære noget og, hvad der er vigtigst af alt, så søger de i app-butikkerne.
Der er i vore dage meget få, som argumenterer mod at have apps i app-butikkerne, men der er mindst én pointe tilbage fra diskussion om HTML vs. Native: Vedligeholdelse af en native app kræver lidt mere arbejde end blot at frigive de seneste ændringer til produktionsmiljøet. Vi skal håndtere alt fra tredjemands evalueringsprocedurer til brugere, der nægter at opgradere men stadig forventer, at det hele virker, til hyppige ændringer i platformen. Sidstnævnte er hovedårsagen til mange vedligeholdelsesproblemer. Med større årlige OS revisioner, ofte et par mindre frigivelser ind imellem, og derudover frigivelse af nye enheder og formfaktorer på tværs af to fuldstændig forskellige platforme, iOS og Android, kan du tilgives for til tider at føle dig lidt overvældet.
TÆNDERSKÆRENDE
Med tæt ved 800 apps i forskellige app-butikker, så er det noget, vi bruger meget tid på at tænke over og håndtere - men det er også lidt besværligt for alle vores kunder. Nogle gange skal en app bare opdateres, men der er nogen, som skal betale regningen. Med en meget gammel app, som ikke længere er opdateret til platformen, så kan det være en rigtig stor opgave; f.eks. da iOS gik over til et fladt design eller for nylig, da alt skulle ombygges til 64 bit.
Det hele er dog ikke ren bekymring og tænderskæren - vi har nogle projekter, som aldrig giver os problemer. De er udelukkende bygget på vores standardsoftware, som vi vedligeholder hver dag. Har du brug for en opgradering? Det kræver knap nok en udvikler. Har du brug for at aktivere en ny funktion? Selvfølgelig! - Det er bare en indstilling. Parallellerne til Software-as-a-Service burde være tydelige.
Vi vil rigtig gerne udbrede denne model til alle vores kunder - faktisk så meget at vi har givet den et navn: Apps-as-a-Service. Vi kan ikke hævde, at vi har fundet på udtrykket, men det er afgjort ikke så udbredt som dets hovedinspiration. Vores definition:
Apps-as-a-Service har alle hovedtræk til fælles med Software-as-a-Service: Det er centralt vedligeholdt software, der deles af alle, med løbende integration af feedback fra kunder og slutbrugere, hyppige opdateringer, let aktivering af nye funktioner og forudsigelige omkostninger.
Den største forskel er, at koden kan styres centralt, mens apps skal bygges og derefter frigives. Slutbrugerens app er et snapshot, som ikke bliver opdateret, før et nyt snapshot - dvs. en ny version - frigives. Eftersom alle brugere ikke opgraderer på samme tid, så skal back-end systemerne understøtte mange forskellige app-versioner på samme tid, hvilket er komplekst. Dette ville undgås i SaaS verdenen.
Apps-as-a-Service er en meget attraktiv model for købere af apps, da den tilbyder: fremadrettet kompatibilitet, løbende forbedringer og vedligeholdelse til en fast pris. Det er også en meget gunstig model for udviklerne. Ved at have en centralt styret kodebase kan vi optimere vores arbejdsprocedure, så omkostningerne bliver lavere. Vi kan investere i bedre kvalitet og større pålidelighed og trække på erfaringen fra hundredvis af apps, hver gang vi forbedrer appen - en stor fordel for alle.
SAMME STØRRELSE PASSER IKKE TIL ALLE
Du kan forledes til at tro, at Apps-as-a-Service er ensbetydende med en model, hvor alle kan bruge det præcist samme produkt. Det er ikke tilfældet. En lille lokalavis med to ugentlige udgaver vil have meget anderledes behov sammenlignet med en stor regional avis med mere end 20 udgaver hver dag. Spørgsmålet er, hvilken løsning der passer bedst til din overordnede digitale strategi.
Fremover vil vi arbejde med to projekttyper: Standard og Customized, som vil blive tilbudt som Apps-as-a-Service-løsninger. Og så har vi Co-Created: en projekttype der bruges til tids- og materialeløsninger.
En standardapp bygges udelukkende af standardkomponenter. Standard indebærer ikke, at den er simpel. Standard betyder blot, at byggestenene er umodificerede på kodeniveau. Mulighederne for konfigurering og kombination af standardkomponenterne er mange. Du vil f.eks. kunne have en meget fokuseret læse-app med et sæt basale funktioner, eller du vil måske have en større app, der understøtter flere udgaver, og/eller historiske arkiver med søgemuligheder, og/eller live indhold fra dit website eller noget andet fra vores liste med over 20 funktioner, som kan tilføjes en app - naturligvis 100 % branded og med et design, der matcher din papirudgave. Vi vurderer, at mere end halvdelen af de apps, vi indtil videre har udviklet, kan opgraderes til standard nu, uden at slutbrugerens oplevelse vil blive påvirket. At vælge Standard er den lette måde at gøre det på.
En Customized app bygges primært af standardkomponenter. Brugernes vigtigste kontaktpunkter, bortset fra papiret, startskærmen og log in-skærmen, kan fuldstændig brugerdefineres eller endda opbygges helt fra bunden. Customized giver mulighed for yderligere branding, integration med live indhold, skræddersyede kiosk-løsninger og meget mere. Customized er udviklet som et meget stærkt alternativ til Co-Created, da man hermed kan tillade ændringer i områder, der har størst effekt hos slutbrugeren og begrænse dem i andre områder. Vedligeholdelse af en Customized app kan dog ikke strømlines i samme grad, da de brugerdefinerede komponenter skal vedligeholdes for sig. Men ved at indkapsle de skræddersyede dele kan vi tilbyde brugerdefineret Apps-as-a-Service.
En Co-Created app behøver ikke passe ind i en prædefineret struktur. Alt kan lade sig gøre. Men denne ubegrænsede frihed koster. Af og til overrasker omkostningen faktisk også os, men oftest er det vores kunder, som bliver overraskede. Vi vil meget gerne undgå det sidstnævnte. Co-Created er en interessant kategori, hvor der er masser af plads til at eksperimentere og lære. Men det er ikke muligt at tilbyde Co-Created som Apps-as-a-Service, og derfor tøver vi med at anbefale det for langt de fleste projekters vedkommende.
APPS-AS-A-SERVICE HOS VISIOLINK
Hos Visiolink har vi travlt med at tilpasse vores tankegang til Apps-as-a-Service. Vi har nu i et godt stykke tid arbejdet internt på konceptet Apps-as-a-Service, og vi er glade for, at vi endelig kan præsentere det. Alle i Visiolink ser frem til at arbejde med fremtidige kunder og til at hjælpe dem med at finde den projekttype, der bedst opfylder deres behov og ønsker. Og vi er også ivrige efter at komme i dialog med vores eksisterende kunder og tale om deres løsninger, og om hvordan de kan opgraderes til en af Apps-as-a-Service-modellerne.
