Det här är en liten serie på tre delar om hur det gick till när Aftonbladet 2011/2012 bytte alla sina system för att registrera, logga in och ta betalt av kunder online. Jag deltog som utvecklare i teamet som fick i uppdrag att ro projektet i land. I den här andra delen hamnar vi i projektkarusellen, gräver guld i Norge och bestämmer oss för avsluta allt med en Big Bang.

Läs först del 1.

Projekt som beror på projekt som beror…

Inget projekt verkar i ett vakuum. Aftonbladet, som är ett ambitiöst företag med mycket driv framåt, vill ofta göra många saker samtidigt. Det kan innebära att flera projekt som tävlar om samma resurser körs parallellt. Att byta SSO/betalplattform påverkar också olika stora delar av verksamheten, t ex marknadsföring, produktutveckling, kundrelationer, strategier för sociala media, IT, redaktionen – ja, du hajjar. Många möten blev det. Det var främst projekt inom tre områden som riskerade sätta krokben för varandra:

• SSO/betalplattform. Drivet av ett omedelbart behov att ersätta något som fanns som var på väg mot stupet
• CRM. Dessa bokstäver står egentligen för Customer Relations Management (ungefär hur man hanterar kundrelationer), men är ett begrepp som tolkas olika beroende på vem du frågar. För vissa är det ett verktyg för att tillverka kampanjer och för vissa innebär det förädling av kunddata och för andra ett stöd för kunna sälja produkter eller ge service till kunden. Det finns nästan inga gränser för vad som skulle kunna petas in i ett sådant projekt. Utan tvivel ett strategiskt viktigt projekt.
• BI. Står för Business Intelligence, d v s nästan en sorts underrättelsetjänst som samlar data om kundbeteende och omvärlden för analyser som ska ge stöd till affärsbeslut inom ett företag. BI är helt beroende av data som kunder genererar i form av köp och av användning av tjänsterna som AB erbjuder, d v s betalplattformen. Här fanns bl a projekt som skulle möta ökade krav på nära-realtidsanalyser

Det dröjde inte länge förrän projekten hamnade i intressekonflikter. Vem äger egentligen kunddata? Är det inte kampanjverktyget som kommunicerar med kunderna hela tiden, eller BI-systemet som förädlar och analyserar kunddata, eller SSO/betalplattformen som skapar kunddata? Kanske borde kunddata ligga helt utanför alla system i en s k kundmaster. Nu började konsulter med insyn i CRM-projektet att gnugga händerna. En master-databas är ett otroligt hett koncept som kostar skjortan, förmodligen för att ingen riktigt förstår vad det innebär. Därför behövs tydligen ett särskilt system som själv förstår vad det ska göra.

Men oj, om kunddata ligger i ett separat system – hur ska andra system prata med kundmastern? Jag vet, vi startar ett infrastrukturprojekt med en Enterprise Service Bus (ESB) som systemen kan ansluta sig till för att lyssna på och göra uppdateringar i kunddata. Å andra sidan – blir det inte en omväg att gå över en ESB för att t ex snabbt logga in en kund? Då kanske inloggning/registrering av kundkonton (d v s SSO) ska ligga i direkt anslutning till kundmastern? Då måste väl kundmastern ändå ägas av CRM-systemet, och ja hela SSO borde tillhöra CRM? Förresten, Svenska Dagbladet som också ingår i Schibsted-koncernen behöver ju byta betalplattform. Kunde vi inte göra en gemensam lösning? Puh! Hur skulle vi få ihop allt detta?

Vi gräver guld på hemmaplan

I förstudiens slutskede hör vi talas om att AB:s systertidning inom Schibsted, VG, håller på att införa en egenutvecklad betalplattform med SSO. Projektledaren och ett par utvecklare sätter sig förutsättningslöst på ett plan till Oslo och träffar de två utvecklarna som byggt kärnan i den nya betalplattformen som kallas VGiD (eller VG Services, VGS). De presenterar vad systemet kan och vad de har för planer på vidareutveckling. Ett antal saker slår oss genast bara efter några minuter in på mötet:

• VGiD är i stort sett en perfekt match på de krav vi har på SSO/betalplattform
• VGiD är i det närmaste klart och har redan lanserats för tjänster som t ex Vektklubb.no
• VGiD är utvecklat inom Schibsted, vilket gör att det finns förutsättningar att kunna dela kostnaderna för underhåll/utveckling mellan bolagen inom koncernen
• De har kommit långt på kort tid

Det fanns förstås tveksamheter som vi hade i åtanke. VGiD var byggt i en teknik som vi på AB inte hade så mycket erfarenhet av. Å andra sidan hade plattformen ett omfattande och väldefinierat API som skulle vara lätt att integrera mot. Dessutom var det kanske en fördel att vi inte kunde gå in och peta i kärnan. Tanken var ju att vi skulle slippa underhåll/vidareutveckling av betalplattformen i framtiden. En annan tveksamhet var att AB hade en mindre bra erfarenhet av att dela mjukvara med VG. Vi hade för många år sedan använt en VG-produkt som visade sig ha brister. VGiD:s utvecklare var dock anställda för just för att ta fram VGiD och de hade gjort liknande lösningar tidigare. VGiD ingav förtroende, inget snack om saken.

Allt sammantaget gjorde att VGiD hamnade som rekommenderat alternativ i förstudien som färdigställdes i april 2011. Förutsättningen var att VGiD kunde levereras som en tjänst, s k SaaS (Software as a Service) så att AB kunde ägna sig åt att utveckla sin kärnverksamhet istället. Jomenvisst, sa man från VGiD:s håll. Kort därefter togs beslutet att välja VGiD som ny SSO/betalplattform. Eftersom man nu fått en så stor och viktig kund i AB kunde VGiD ta steget upp till att bli Schibsted Payment iD (SPiD) med ambitionen att leverera en totallösning till alla bolag inom Schibsted-koncernen. Gärna för oss. Ju mer vi är tillsammans, desto billigare det blir, eller hur sången nu går.

Migrering, migrering, migrering

Nu började det stora arbetet med att tvätta och transformera AB:s data så att det skulle gå att överföra till SPiD. Samtidigt behövde vi säkerställa att all funktionalitet som AB behövde fanns och kunde integreras i våra tjänster. Långa kravlistor sammanställdes och stämdes av med SPiD. I flera fall fick de komplettera funktionaliteten. Man ska komma ihåg att SPiD när det var VGiD ursprungligen inte hade hela Schibsted-koncernen som målgrupp, men det skalade upp förvånansvärt bra.

Hyfsat tidigt i projektets implementationsfas färdigställdes logik för att migrera kunder och deras data till SPiD. Det gjorde att vi kunde testmigrera i flera omgångar för att provtrycka vårt data i SPiD. Varje gång vi upptäckte problem med data, kunde vi gå tillbaka till det gamla systemet, skriva logik för att tvätta data och testmigrera igen. Vi hade ackumulerat data sedan början av 2000-talet så det fanns mycket att åtgärda. Särskilt med tanke på att vår gamla betalplattform växt fram under åren och gradvis ändrats. Datatvätten kan väl beskrivas som en scriptfestival.

Under projektet togs att antal beslut som skulle påverka hur flytten skulle gå till:

• Vi skulle behålla vår fasad (ett system som fungerar som en brygga) mellan tjänsterna och SSO/betalplattformen. Det innebar att tjänsterna inte skulle behöva göra några stora ändringar inför bytet till nya systemet. Vi byggde om fasaden att gå mot SPiD istället för vår gamla betalplattform i bakgrunden
• Flytten skulle göras som en s k Big Bang. Det finns flera strategier för att införa ett nytt system. Ofta vill man ta en del i taget för att minimera risk och kunna rulla tillbaka till gamla versionen om något går fel. I det här fallet riskerade vi i så fall att få transaktioner spridda mellan nya och gamla systemet, vilket skulle vara en mardröm. Därför valde vi att göra bytet vid en bestämd tidpunkt – Big Bang. Vi skulle inte kunna rulla tillbaka när vi väl började ta betalt. De tester vi hade gjort, bl a de ständiga migreringarna, gav oss förtroende att välja denna strategi
• Kunder skulle själva tvätta sitt kontodata vid första login. En stor utmaning vid byte av plattform var att inloggning var baserad på användarnamn i gamla systemet och på mailadress i SPiD. Det innebar bl a det kunde finnas ett stort antal konton med olika användarnamn fast med samma mailadress (ett AB-konto är gratis). Ofta hade också kunder ett konto för varje AB-tjänst. Många hade inte ens en mailadress eller en helt obekräftad mailadress, typ kalle@ankeborg.com i bästa fall och något helt barnförbjudet i sämsta fall. Alla dessa spretigheter skulle alltså magiskt konsolideras i ett konto för varje kund. Detta åstadkoms i ett snillrikt inloggningsflöde som guidade den användare som loggade in första gången efter flytten så att denne kunde slå ihop och komplettera till ett högkvalitetskonto.

Läs den spännande fortsättningen i nästa del av “När Aftonbladet bytte betalplattform” här.

Eventuella synpunkter tas gärna emot på Twitter @ocklund