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 första delen står vi vid ett stup, fäktas med amerikanska säljare och tittar på möjliga lösningar.
För liten kostym, med hål på ärmarna
Det som internt på Aftonbladet (AB) kallades “Betalplattformen” var år 2010 en spretig historia. En samling system som växt fram genom åren med bl a följande funktionalitet:
- Single Sign On (SSO) så att användare kunde skapa ett konto hos AB och sedan logga in på olika tjänster som t ex Plus, Viktklubb och S24
- Checkout (online-kassa) för användare som ville köpa abonnemang eller enstaka innehåll på AB:s tjänster, t ex alla Plus-artiklar eller en S24-match
- En transaktionsmotor som varje natt samlade ihop transaktioner och debiterade abonnenter via kreditkort eller faktura
- En rapportmotor som sammanställde och skickade dygnets händelser i betalplattformen till ett Business Intelligence (BI)-system, som i sin tur genererade rapporter och analyser till affärsansvariga
Det ser väl inte så illa ut, tänker du. Begrunda då följande:
- SSO baserades på ett uråldrigt Content Management System (CMS), d v s ett system som egentligen är byggt för att publicera innehåll på en webbsajt. CMS:et hade inte uppgraderats på minst fem år och det fanns ingen support från leverantören. CMS:et använde i sin tur en väldigt gammal version av en databas som saknade support och med en licens som var på väg att bli inaktuell
- Vi hade två olika Checkout, en gammal och en nyare. Det var meningen att online-köpen skulle flytta över till den nyare, men en komplicerad fakturahantering i den gamla Checkout gjorde att tjänster där man kunde betala med faktura blev kvar i den gamla. Det fanns också tjänster som kunde köpas via båda Checkouts, vilket blev mycket förvirrande för affärsansvariga, utvecklare och säkert även kunder
- Eftersom systemet var så gammalt hade flera generationer utvecklare kommit och gått vad gäller utveckling och underhåll av betalplattformen. Många tillägg hade gjorts under åren och små logiska läckor uppstod ibland i skarvarna. Till slut fanns en stor teknisk skuld som resulterade i dagliga manuella handgrepp för att t ex avsluta abonnemang som gått ut eller leverera borttappad data till analysavdelningen. Förmodligen ägnade utvecklarteamet minst hälften av sin tid till underhåll av systemet och support till kundtjänsten som fick in ärenden där enstaka kunders data hamnat i “skarvarna”
- Affärssidan på AB var begränsade av den tungrodda betalplattformen och kunde inte skapa produkter eller en paketering av produkter i den utsträckning de ville. Minsta ändring måste beställas av utvecklarteamet, t o m en simpel textändring i en produktbeskrivning
Vi väljer ny kostym
Ok, så nu har vi affärsfolk som närmar sig uppror, utvecklare som pysslar om regalskeppet Vasa och en kundtjänst som är på gränsen till nervsammanbrott. Nja, kanske inte. Det rullar på, men vi är på väg mot ett stup när kärnan i betalplattformen kommer att lägga av. De oförklarliga avbrotten som kommit någon gång per år har börjat dyka upp varje månad.
Nu tar AB:s ledning ett strategiskt viktigt beslut: Vi måste byta betalplattform. Kostnaderna har blivit för höga, vi riskerar stora driftsproblem framöver och varje dag tappar vi konkurrenskraft. Utvecklarteamet får i uppdrag att göra en förstudie på hur det skulle kunna gå till. I korthet tittar vi på tre alternativ:
- Bygga ny egen betalplattform. Ger mest kontroll, men också mest arbete. All vidareutveckling måste ske internt och i allt snabbare takt. Innebär stora underhålls- och driftskostnader bl a i form av personal.
- Köra open source på egen server. Ger hyfsad kontroll, även om vi blir beroende av en leverantör. En stor del av vidareutvecklingen sker hos leverantören och vi har små möjligheter att påverka vilken funktionalitet som ska prioriteras. Vissa anpassningar måste ske internt. Fortfarande personalintensivt.
- Köpa in tjänst. Vi släpper mycket av kontrollen på tekniken och reglerar tillgänglighet i avtal. I stort sett inga möjligheter att påverka vidareutveckling av funktionalitet. Verksamheten måste anpassa sig helt till vad leverantören kan erbjuda, vilket kan innebära helt nytt sätt att jobba på. Interna utvecklare kan ägna nästan hela sin tid till andra viktiga områden
Under ett par-tre månader i början av 2011 ägnade sig teamet åt att ta fram de grundläggande kraven på en ny SSO/betalplattform och dammsuga marknaden på open source-lösningar och kommersiella produkter. Ett problem med open source är att dessa projekt ofta lider av bristfällig dokumentation. Det var svårt att hitta någon lösning som matchade våra krav, eller ens få reda på lösningens funktionalitet.
När vi kontaktade kommersiella leverantörer, som i de flesta fall var amerikanska, möttes vi av en kompakt säljmur. Vi hade inte mycket tid på oss och vi ville i stort sett bara ha dokumentation över vilken funktionalitet produkterna hade och hur vi tekniskt skulle kunna integrera med dem. Då skulle vi snabbt kunna sålla bort de som inte föll oss på läppen. Så jobbar inte jänkarna. De verkade förvänta sig att någon bokstavschef (CEO, CTO, CIO) skulle kontakta dem, bli wined-n-dined och prata avtal. Vi ställde tekniska frågor som säljarna ignorerade och istället envisades med att boka säljsamtal.
Det skulle ta alldeles för lång för oss att telefondejta alla leverantörer och vi tvingades ofta gå på det som erbjöds på deras sajter. I vissa fall pratade vi med säljmuren, men det handlade oftast om att bli pumpade på vilka volymer det gällde och vilken marknadsposition vi hade i Schweiz, förlåt Sverige. Trots detta låg alternativet att köpa in tjänsten ganska bra till i utvärderingen nästan ända fram till deadline. Men snart skulle vi snubbla på något som skulle rycka undan mattan under fötterna på alla tre alternativen.
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
