Rätt verktyg till jobbet – sex viktiga frågor när du väljer digital plattform

Krav- och insiktsinsamling

Innan man funderar på vilken plattform man skall använda bör man samla in vilka behov man har. Med en tydlig kravställning på plattformen ökar sannolikheten att man väljer rätt. I denna artikel kommer vi gå igenom ett axplock av frågor som man gärna vill besvara innan man tar sitt beslut:

• Vilka tredjepartsintegrationer kommer att användas?
• Hur lång är den förväntade livslängden för projektet?
• Vilket ekosystem passar bäst för min lösning?
• Hur prioriterat är prestanda? Hur mycket trafik förväntas?
• Skall datan presenteras i flera kanaler?
• Hur skall sajten administreras och av vem?

1. Vilka tredjepartsintegrationer kommer att användas?

Tredjepartsintegrationer är ofta en ganska kostsam del av ett projekt. Framförallt initialt, men de kräver oftast också en del underhåll. Många tredjepartsintegrationer tillhandahåller moduler till olika programmeringsspråk och plattformar. Helst vill vi använda så många som möjligt av dessa, dels för att inte uppfinna hjul, men också för att slippa underhålla lösningarna själva. Om vi vet vilka tredjepartsintegrationer som kommer att användas så kan vi se vilka moduler som finns tillgängliga och genom vårt val maximera utnyttjandet av dessa. Vi kan också på förhand bedöma kvalitén på integrationerna och se huruvida de är användbara för den aktuella lösningen.

Många system är skräddarsydda för en specifik verksamhet och då saknas oftast användbara moduler för externa integrationer. När projekt till stor del innefattar integrationer av denna typ kan det vara klokt att välja en plattform som är enkel att skriva integrationer för. Här levererar generellt ramverken renare integrationer som är enklare att underhålla än motsvarande lösning implementerad i ett CMS. Detta eftersom ramverk fokuserar mer på flexibilitet än att leverera en snabb "one-size-fits-all"-lösning. Om du inte riktigt vet skillnaden på ramverk och CMS så kan du läsa mer om det här.

2. Hur lång är den förväntade livslängden för projektet?

Om man bygger en kampanj som ska leva i en månad kan man med gott samvete välja den plattform som snabbast tar en i mål. Eventuella licenser spelar inte så stor roll i sammanhanget och hållbarheten i lösningen är inte prioriterad. Vill man däremot maximera livslängden i lösningen så finns det ett gäng faktorer att ta i beaktning:

• Är plattformen flexibel nog att kurera förändringar i organisationen?
• Hur skalbar är lösningen? Om trafiken tredubblas om ett år, hur kostsamt blir det att hantera detta?
• Finns det fler utvecklare som kan förvalta lösningen?
• Finns det ett bra ekosystem som går att nyttja när kravställningen på plattformen förändras?
• Är det en beprövad teknik som förväntas ha ett långt liv?

Detta är bara ett axplock, vi har skrivit en artikel om att bygga hållbara lösningar om du vill läsa mer.

3. Vilket ekosystem passar bäst för min lösning?

Olika plattformar kommer med olika ekosystem. Det kan finnas mycket att vinna på att utreda vad som gynnar en mest. Skall man t.ex. ha en katalog-webbshop så kan det vara kostnadseffektivt att välja WordPress med WooCommerce för e-handel. Vill man istället bygga ett API till en mobilapp så kanske en Django-lösning är ett bättre val. Bygger man ett multisajtnätverk med språkstöd kan Episerver/Optimizely CMS eller Umbraco CMS vara ett rimligt val. Vill man ha både ett bra headless API, en E-handel och ett multisajtnätverk med språkstöd så får man överväga vilket ekosystem som ger en mest "gratis" och så får man bygga resten själv.

4. Hur prioriterat är prestanda? Hur mycket trafik förväntas?

För de flesta hyfsat statiska webbplatser så kan man med hjälp av cache klara mycket trafik mer eller mindre oberoende av vilken plattform man väljer. Men om man har inloggade lägen där mycket innehåll blir unikt för varje användare blir det lite klurigare. Här är det ofta bra att välja en plattform som gör det enkel att sprida ut lasten på flera servrar och där plattformen i sig är resurssnål. Generellt är det fördelaktigt att välja ramverkslösningar för applikationer som behöver servera många användare samtidigt med korta svarstider eftersom ramverk ofta är resurssnåla och skalbara av sin natur.

5. Skall datan presenteras i flera kanaler?

Om det är önskvärt att servera data till mer än konventionell web, t.ex. mobilappar, TV-skärmar, etc. så kan det vara fördelaktigt att välja en plattform där det är enkelt att definiera sina egna datastrukturer och leverera dessa via ett API. Här gör de flesta plattformar jobbet efter lite handpåläggning, men ramverkslösningar levererar generellt renare implementationer med snabbare svarstider.

6. Hur skall sajten administreras och av vem?

Enkla och anpassade administratörsgränssnitt är väldigt viktigt för plattformar som är redaktionellt tunga och där innehåll produceras i stora volymer. Om det negligeras kan de administrativa kostnaderna springa iväg och mycket tid måste investeras i utbildning av systemet. I andra fall där man inte förväntar sig några större ändringar av innehållet efter lansering kan utvecklingstimmarna som krävs för att skapa en trevlig redaktionell upplevelse överstiga värdet som det tillför. Jobbar man med ett CMS är administratörsgränssnitten oftast ganska bra från början och kan bli väldigt bra med mindre handpåläggning. I ett ramverk behöver man göra mer för att få det bra, uppsidan är istället att man helt kan skräddarsy det redaktionella gränssnittet, både design- och flödesmässigt. Detta gör att ramverk ofta är bättre när innehåll skall kunna administreras av slutanvändare och att CMS ofta blir kostnadseffektivare när det kommer till att producera innehållstunga plattformar.

En annan aspekt kring administrationsgränssnitt är flexibilitet. En liten grupp administratörer med insikt i plattformens koncept, hur moduler ska användas och med ett öga för design har mycket att vinna på att gränssnittet är flexibilitet. Kan man lägga in vilka moduler man vill på vilka positioner man vill kan man lösa mycket utan att behöva blanda in utvecklare. Men flexibilitet kommer med ansvar: Om man är många administratörer behöver mycket tid sannolikt läggas på moderering och kvalitetssäkring av materialet. Flexibla gränssnitt tenderar också att ha en högre inlärningskurva och upplevs ofta som "svåra", varför det ofta är bra att istället reglera möjligheterna ganska hårt i administratörsgränssnittet.

Om att faktiskt välja

När alla krav, behov och insikter samlats in kan vi börja leta efter tänkbara plattformar. Hos oss på Fröjd görs utvärderingen primärt av utvecklare eftersom det till stor del handlar om att läsa teknisk dokumentation, se helheten kring kommunikation mellan system och att uppskatta hur stora anpassningar som kommer att krävas för respektive lösning. Vidare presenteras vilka för- och nackdelar varje plattform innebär för hela teamet, från både Fröjd och kunden, som tillsammans beslutar väg framåt. I beslutsprocessen är det viktigt att utvecklare, redaktörer, IT och övriga stakeholders är involverade så att alla intressenters behov är representerade och projektets förmodligen största beslut får förankring.

Genom att följa de här frågeställningarna istället för att gå på vad utvecklarna och/eller redaktörerna "redan kan" ökar oddsen att välja rätt lavinartat. Det är läskigt att ge sig ut på okänt vatten, men en bit in i projektet kommer det att löna sig. Plattformsval är för viktigt för att lämnas åt slumpen.