Inlägg av kenock

Systemutvecklare på Aftonbladet

Can Projects and Agile Play Nice?

av kenock
Cleric, Knight and Workman (13th century)
Cleric, Knight and Workman (13th century)

Here is a story for all you Agile kids out there. Once upon a time the only way to get things done was to start a project, because all developers were mostly bogged down in maintenance of all the systems they had ever constructed before. Once in a while upper management had an idea and a project was born. The project leader was appointed and she would elevate some of the developers from the maintenance mud and form a project team. Projects were mostly executed using the Waterfall Model, where the project was initiated, the software was designed, implemented and finally deployed. If a design flaw was found in the implementation phase there was no turning back, because of the dreaded DEADLINE, when money/time/people ran out. Sometimes the project delivered on time, but almost always it delivered crappy software.

OK, so why this scary story from the Medieval times? Well, even if most of us in the software industry have embraced Agile methods for developing software, there’s still this notion around, that projects are the only way to get things done. Even if the developers in your company worship the Agile gods, there are often bean counters in the upper ranks that need to put a price tag on new or larger development efforts, i.e. limited time/resources, i.e. projects. So you end up with Agile development within a project context. Why is this a problem? The Agile guru Henrik Kniberg mentions the conflict in his excellent presentation about the “Unproject” culture of Spotify (see

In my mind, projects are a bit like mining for gold. The geological survey indicates there should be a mother lode of gold beneath our feet. We dig, blast with dynamite and hack away for a long time at great cost to find it. If we’re lucky we strike gold, somewhat lucky: silver and if we’re out of luck: nothing, but never the coveted mother lode that was predicted in the plan.

Agile is more like panning for gold. You can start right away and if you keep at it, the gold nuggets start showing up. If a spot seems barren of gold, we just pick another spot. After a while the project still hasn’t found the mother lode, but the Agile team has been piling up the nuggets from the start.

I believe that if you’re aware of the problems with projects there are a few steps you can take to make a project play nice with Agile:

  • Look at projects as a way to finance Agile product development activities, not a methodology to use for the development process
  • Keep the project within an existing team/product. Usually project teams are handpicked from different teams or hired externally. This leads to problems, e.g.:
    1. Teams losing member(s) to the project will be less productive or even have to stop developing
    2. The new team must go through the group dynamic phases while being less productive compared to an existing team. This is a bad idea especially since a project is limited in time. Furthermore, the new team may turn out to suck half-way through the project
    3. This may be obvious, but here goes anyway: Do not form a project team consisting of external developers only. What do you think happens when the project finishes? Exactly!
  • Before starting the project, make sure you have a plan for which team will be maintaining the product when it’s finished. Ideally, it’s the same project team, or at least some of the members in the project team
  • Tone down the project deliverables (detailed plans, rigid requirement docs, change requests, progress reports) in favour of delivering useful software frequently (the norm in Agile). Working software that you can demo is a pretty solid progress report and easy to give feedback on.

There are people that want to quit working in projects altogether, e.g. Allan Kelly. See a video of his presentation “Beyond Projects – why projects are wrong and what to do instead” here:

I’m sure you have more to add to this topic. Feel free to comment or send feedback on Twitter @ocklund

Bonus feature!
Create your own bedtime story replacing the following in my Medieval story:
Project = Crusade
Developers = Knights
Systems = Castles
Upper management = Queen/King
Team = Army
Waterfall Model = Suicide Attack
Software = Catapult
Deadline = Dragon

Kategorier Agile | Kommentarer

Scrum? What a drag!

av kenock
NASA wind tunnel test for reducing drag

I attended a Scrum Master course at Crisp last week. These are some of my reflections from that course (which I recommend by the way).

But first: why would I take a course on something I’ve been using for at least 5 years? I think it’s because I’ve seen so many shapes and sizes of Scrum/Agile that I’ve lost track of what was the idea from the beginning. Sometimes I feel that something is missing in our Agile processes at AB. I wanted to know: Are we doing it wrong?

The short answer to that question was: ”Define wrong”. Darn! I knew it. The more elaborate answer has more to do with which level you’re on. Henrik Kniberg (course leader) drew on his Japanese background when defining levels of Scrum/Agile:

Shu = Follow the rules
Ha = Adapt the rules
Ri = Ignore the rules

That means that Scrum/Agile itself is not important. If you’re delivering the right working software every couple of (or three) weeks and you’re constantly improving – then you need not to worry. You are probably doing it right. However, if you completly suck at these things, perhaps the best for you is to apply Shu – Scrum by the book. But it will come a time when some parts of Scrum is beginning to feel like unnecessary overhead. Then move to Ha and start shedding those practices. Now it’s becoming trickier. The improvement curve is flattening out and it’s becoming increasingly difficult to identify waste. It’s time to throw Scrum overboard. You start focusing on what you deliver, not the process – because now Agile is in your DNA. But how do you take that last step? Nobody can tell you exactly. No rules, remember? Perhaps at your orginisation it’s building a culture that supports delivering the right thing at the right time, while enjoying it.

Ok, so how do we build a culture? Well, I see Scrum as really a culture builder. It imposes constraints on your process that promotes failing fast and delivering what’s needed when it’s needed using self-empowered teams that cherish improvement. Sometimes you need to apply a constraint that’s outside Scrum, like continuous delivery. Kniberg talked about how they began using release trains at Spotify. They decided to release every week – no matter what. If you have something to release, fine. Otherwise there’s always the next release train the following week. This takes the drama out of the deployment cycle, but it also has some interesting side effects. For example, you cannot have a release train with a monolithic product that every team is working on. It would be scary unstable. So they divided their product into independent components. It also made feature toggles necessary. If your team’s component could be released at any time, its’ new features would have to be disabled for the users until they’re ready.

So, back to AB and the question: Are we doing something wrong? Yes! One thing I was reminded of last week is that it doesn’t matter how advanced you are, you can always do 10 times or even 100 times better. We did a simple exercise divided in teams at the course that illustrated this. Before doing the exercise we were asked to guess how much we could improve the simple task given to us. After 5 iterations of doing the task and holding a retrospective to improve the process we had surpassed our wildest guesses at least 100 times. One interesting observation is that the real breakthrough came when Kniberg said to the team: ”I know teams that improved X times!”. The team suddenly realised it’s really possible and we made radical changes that made the improvement rate jump up considerably. What would happen if we all had that feeling at work?

Want more Kniberg? Slides from a keynote in Paris 29 September 2013 (PDF)

Feedback is always welcome on Twitter @ocklund

Hur sprider man kunskap på en utvecklingsavdelning?

av kenock
Prototyp på gång, Schibsted Hack Day 8

På en hyfsat stor utvecklingsavdelning som på Aftonbladet finns det otroligt mycket värdefull kompetens och erfarenhet – och det ackumuleras mer för varje dag. När finns det tid tror du att sätta sig spontant och dela med sig av denna rikedom mellan de 6-8 teamen? Svaret är förstås: aldrig.

Man kan då rycka på axlarna och fortsätta snickra på varsitt hjul i varje team eller helt enkelt ta sig den tiden och försöka vaska fram kunskap som alla har nytta av. På Aftonbladet har vi valt det senare alternativet. Vi såg det som strategiskt viktigt att prata om varför vi gör saker på ett visst sätt. Vilka verktyg vi använder när vi utvecklar, vilken metodik som har funkat bäst och vilken ny teknik som verkar intressant i de olika teamen. Vi bildade därför Utvecklingsstrategigruppen (USG) med representanter från alla team (som vill). Det första namnförslaget var Strategiutvecklingsgruppen och jag lämnar till läsaren att lista ut varför vi inte valde det namnet.

Vi utvecklare är oftast möteströtta, så mötena är korta (1h/vecka) och bara de representanter från teamen som är intresserade är med. Det är ett utmärkt tillfälle för en utvecklare att driva en viss fråga, t ex ”Varför tar det så lång tid att sätta upp en server?” USG diskuterar då detta och vi ser till att börja använda t ex Puppet för att korta ned tiden för just den aspekten av ett utvecklingsprojekt. Det kommer fram små ändringar som sammantaget förbättrar leveransen från hela avdelningen.

Deltagarna behöver inte förbereda sig så mycket för ett möte. Oftast är man riktigt nöjd med en lösning som man vill dela med sig eller otroligt irriterad på att något saktar ned ens utvecklingsarbete. Om man är tillräckligt entusiastisk och har bra argument får man med sina kollegor och får till stånd en ändring. Om ett ämne känns extra angeläget kan man ha ett temamöte bara om detta nästa gång.

USG försöker hålla sig till en agenda för att det ska bli lättare att följa upp:

  1. Bra saker som alla team borde göra, t ex ”Har ni testat LESS?”
  2. Dåliga saker som borde åtgärdas, t ex ”Fan vad meckigt det är att söka igenom loggar!”
  3. Utvalda bra/dåliga saker att åtgärda, ”Kalle, håller du en utbildningstimma om LESS?” eller ”Lisa, du nämnde Splunk. Kollar du in det till nästa USG?”
  4. Uppföljning utvalda saker under åtgärd, t ex ”Hugbert, hur går det med Puppet-utvärderingen?”
  5. Kompetensinsatser, t ex ”Bra Kalle då kör du på fredag?”
  6. Övrigt, t ex ”Heads up! Det här är kända buggar i YUI2″

Vi för minnesanteckningar på USG-möten och publicerar dessa internt på avdelningen så fort som möjligt efter mötet. Det är viktigt att allt är öppet och tillgängligt så att alla får en känsla för hur diskussionerna går. USG har egentligen inget särskilt mandat, men en rekommendation från gruppen räcker långt. Det händer också att chefer som är pro-aktiva läser anteckningarna och agerar på ärenden som behöver lyftas en nivå.

Nå, så vad har USG sysslat med under 2012?

Gruppen har träffats 24 gånger och tagit upp 23 bra tips hur teamen kan förbättra sitt arbete. Vidare har USG diskuterat 28 förbättringsområden och medverkat till en genomförd förbättring på avdelningen i 40 fall (både från bra tips och förbättringsområden). Exempel på tips och förbättringar som genomförts:

  • Standardisering av teknik (t ex YUI, LESS, Grunt) på avdelningen har medfört kodutbyte och kompetensöverföring mellan team
  • Temadag och föreläsningar inom Delivery Pipeline har spunnit loss förbättringar i driftsättningskedjan, t ex Bamboo och Puppet
  • Bättre möjligheter att dokumentera (ny Wiki) med uppdaterad dokumentation som följd
  • Effektivare stå-upp-möten med digitala whiteboards på ny Touch-skärm 65″
  • Nya datorer har medfört snabbare utvecklingsmiljö
Schibsted Hack Day 9, katten med nio liv

USG har dessutom genomfört 9 interna utbildningstillfällen (kompetenstimme), beslutat rekommendera 18 teknikval (t ex New Relic, YUI3, LESS, Play framework, Puppet, Bambooo) och diskuterat 19 nya tekniker (t ex Scala, Dropwizard, Akka, WRO4J, Google Guava, Splunk). Under året genomförde USG också 2 st ”Schibsted Hack Day” som är en maratonprogrammeringsdag för nydanande prototyper som redovisas dagen efter i en öppen presentation i Schibstedhuset.

Feedback tas gärna emot på Twitter: @ocklund

När Aftonbladet bytte betalplattform (3 av 3)

av kenock

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 tredje och sista delen dissar vi Agile, leker NASA och genomför Dagen D.

Läs först del 1 och del 2.

Vad är mer Agile än Agile?

Vad gäller teamets arbetssätt under denna implementationsfasen i projektet gjorde vi tidigt ett intressant vägval. Vi var ganska väl intrimmade på agil utvecklingsmetodik, men vi kom fram till att projektet innebar ganska lite traditionell programmering av typen ”skriv en applikation och lansera den”. Det mesta av koden var den nya fasaden och en massa script/kod för att batchknåda data i de gamla databaserna. Mycket av arbetet bestod av att utreda konsekvenser av att införa SPiD och komma fram till lösningar för att mildra eventuella negativa effekter. Vi visste i stora drag vilka områden som behövde åtgärdas och ungefär vad vi behövde göra, men i många fall skulle resultatet av en utredning eller åtgärd ge förutsättningarna för nästa.

Mot alla moderna utvecklingsprinciper satte vi först ett rimligt lanseringsdatum. Sedan skrev vi upp alla åtgärder vi kunde komma på – utan att tidsuppskatta dem – och grupperade dem på en tidsaxel, jämt distribuerade fram till lanseringsdatum. Vi visste helt enkelt att alla försök till en detaljerad tidsuppskattning skulle vara en lögn i ett så tidigt skede. Efterhand som projektet fortskred så kunde vi tidsuppskatta mer detaljerat det som vi hade framför oss. Detta måste ha varit otroligt läskigt för beställarna av projektet, eftersom vi bara kunde ge vaga svar på projektets framsteg. Det visar på vilket förtroende beställarna hade för teamet. När projektet var över kunde vi dock konstatera att vi bara behövde justera lanseringsdatum en gång från början av december 2011 till i slutet av januari 2012. Ganska bra kan man tycka, med tanke på projektets komplexitet. Det var dessutom ingen bra idé att lansera strax innan Jul/Nyår ifall något skulle går fel, då många skulle vara lediga.

Dagen D

Inför lanseringen av den nya plattformen hade vi sammanställt ett körschema för varje moment i lanseringen, d v s vem som skulle vad i vilken ordning. I största möjliga mån var varje åtgärd automatiserad i script som kördes igång vid lämplig tidpunkt. Många av åtgärderna var avslutande datatvättar av olika slag. Sedan följde bl a blockering av trafik, migrering av data, tester och omdirigering av trafik till nya plattformen. Några dagar innan lanseringen genomfördes en generalrepetition med alla inblandade i en för ändamålet bokad konferenslokal. Steg för steg gick vi igenom körschemat och utförde de manuella och automatiska punkterna i en kopia av den skarpa miljön. Hela tiden monitorerades systemen och de ansvariga för varje punkt ropade ut status på sina åtgärder. Nästan som en raketuppskjutning på NASA. När något inte fungerade som väntat noterades det så att det kunde fixas innan lansering.

Själva lanseringen startades kl 01.00 den 24/1-2012 och genomfördes enligt körschemat. En del av teamet körde migreringen, medan den andra delen var hemma och sov. Importen av användardata till den nya plattformen blev klar runt kl 05.30 på morgonen. Det var data för ca en halv miljon användarkonton som leverantören SPiD anpassade och lagrade i sina databaser. Runt kl 09.00 tog den andra delen av teamet över och nattens hjältar kunde åka hem till en välförtjänt vila. Under förmiddagen testades all funktionalitet internt av aftonbladare med hjälp av vitlistade användarkonton. Sedan kunde Aftonbladets tjänster, t ex och stegvis gå över till att logga in och genomföra köp via SPiD. Kl 15.00 Släpptes all trafik på till SPiD och lanseringen var slutförd.

De dagar som följde ägnades åt trimma in den nya plattformen. Lyckligtvis var det inga större problem som uppstod i kölvattnet av lanseringen. Det kunde vara detaljer som t ex justeringar av när cookies skulle bli inaktuella, vilket påverkar inloggningen; eller missvisande texter på försäljningssidor för prenumerationer. Äntligen kunde vi andas ut efter nästan ett års förberedelser.


Det var ett tag sedan lanseringen nu i skrivande stund (augusti 2012) och uppföljning gör sig bäst strax efter man genomfört något. Det finns dock några saker som slår mig även så här efter lång tid:

  • Leta förutsättningslöst efter lösningar. Ibland ligger bästa lösningen närmare än du tror. I en annan mer prestigeladdad organisation än Aftonbladet hade det varit svårt att acceptera att ett systerföretag inom koncernen tagit fram en bättre lösning än vi. Känns skönt att vi kommit förbi ”Not invented here” som annars är vanligt inom mjukvaruutveckling.
  • Underskatta inte betydelsen av samarbete. Jag vill göra gällande att vår leverantörs vilja att samarbeta är en stor del av framgången med införandet av nya plattformen. Det hjälpte förstås att vi samarbetade inom en koncern, men det brukar inte vara någon garanti i andra organisationer. Vi etablerade också tidigt en enda kanal (Skype) för kommunikation där vi blandade högt och lågt. Alla lyssnade på den konversationen och det var en låg tröskel för att ställa frågor, vilket gjorde att hinder kunde undanröjas hyfsat snabbt. Jag kan inte föreställa mig att vi skulle haft ett lika bra samarbete med en amerikansk SaaS-tjänst.
  • Körschema och generalrepetition var en förutsättning för framgång. Martin Börlin hade framgångsrikt genomfört en lansering med ett körschema och en generalrepetition här på AB. Jag tycker att det var smart att lära oss av det receptet. Att simulera en skarp situation gör att man skärper sig. Om något går fel under genrepet är det lätt att föreställa sig hur kul det skulle vara i skarpt läge sedan. Därför tror jag att det är viktigt att försöka skapa känsla av skarpt läge så att man inte tar genrepet med en klackspark.
  • Underhållet är nu att få Release Notes i mailen. Ett vanligt problem för utvecklare är att ju mer man utvecklar, desto mer måste har man att underhålla. Till slut kan man inte utveckla mer eftersom all tid går till underhåll. Det kändes otroligt skönt att kunna lämna vidareutvecklingen av plattformen till leverantören och underhållet av integrationen mot plattformen till en serviceorganisation. Vi har därmed kunnat ta oss an nya projekt som fått vänta p g a resursbrist.
  • Äntligen kan vi lägga ned betalutvecklingsteamet. Egentligen inget konstigt eftersom vi nu har en extern leverantör av betalplattform. Det är dock inte alltid självklart för utvecklingsteam att jobba för att de inte ska behövas längre. Det borde vara det, tycker jag.
  • Hur kunde vi börja projektet utan att ha tidskuppskattat det? Jag är fortfarande imponerad av hur lite vi uppskattade från början hur lång tid saker skulle ta. Mycket styrdes dock av leverantörens tidsplan. Så här i efterhand tycker jag att vi gjorde rätt. Vi hade kunnat bryta ned allting i atomer och ägna otroligt lång tid till att estimera tidsåtgång för allting, men det hade troligtvis varit slöseri med tid och gett oss en falsk känsla av kontroll. Mycket att det vi hade framför oss när vi startade var av undersökande natur. Det enda som var konkret utveckling var integrationslagret mellan tjänsterna och SPiD.

Särskilt omnämnande

Slutligen vill jag bara sjunga lite om de som ofta är osjungna när det lanseras nya produkter – utvecklarteamet. Tack för att jag fick vara med och jobba med er:
Adam Miller (Utvecklare, AB)
Erik Fried (Utvecklare, AB)
Hans-Göran Persson (Projektledare, AB)
Mats Strandberg (Utvecklare, Crisp)
Mikael Thorsson (Utvecklare, Cygni)
Ulf Liedberg (Utvecklare, Netlight)
Joakim Wånggren (Utvecklare, Netlight/Schibsted)
Thomas Andersson (Utvecklare, Netlight)
Peter Lindgren (Utvecklare, Netlight)

Det här var den sista delen i en serie av tre. Tack för att du följde mig ända hit.

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


När Aftonbladet bytte betalplattform (2 av 3)

av kenock

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
  • 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 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

När Aftonbladet bytte betalplattform (1 av 3)

av kenock

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:

  1. 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.
  2. 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.
  3. 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

Jfokus 2012: 3 x Continuous och annat

av kenock

Jag tror att Jfokus kan bli en stor miljöförkämpe framöver. Om de håller årets nivå eller bättre finns det helt enkelt ingen kunskapsmässig anledning längre att resa långt för att få kompetent och inspirerande info som Java (JVM-baserad?)-utvecklare i Stockholm. Här nedan har jag summerat mina intryck – som inte alls är heltäckande förstås för konferensen. Jag är trots allt bara en enkärnas CPU och skalar dåligt till flera lokaler.

Ett av ledorden på Jfokus var Continuous. Det togs upp på flera plan och jag tolkade dem så här:

- På ett högre plan är Continuous Delivery (CDiv), vilket är löftet om att leverera produkter affären behöver (inte att förväxla med vad de vill) när det är affärsmässigt lämpligt. I praktiken innebär det att produkten alltid är redo att produktionsättas, men affär beslutar när nya produkter/features publiceras. Tekniskt kan det åstadkommas genom att produktionsätta med feature toggles (funktioner som kan slås av/på) eller dark launch (t ex backendfunktionalitet som inte syns)

- För Continuous Deployment (CDep) är fokus att få ut ändringar i produktion så fort som möjligt med så lite motstånd som möjligt. Det innebär att alla ändringar produktionsätts direkt efter rigorösa automatiska tester. Ändringarna är så små att risk för fel i produktion minimeras. Man rullar aldrig tillbaka utan driftsätter istället bättre kod. CDiv är i praktiken CDep fast det är ett affärsmässigt beslut att trycka på deploy-knappen när ändringar samlats ihop till något vettigt (minimal marketable feature)

- Continuous Integration (CInt) har fokus i början av leveranskedjan (delivery pipeline) där varje ändring som checkas in i källkoden plockas upp av byggserver, genomgår tester och resulterar i distributioner som kan driftsättas automatiskt i testmiljö och automatiskt/manuellt i produktionsmiljö. CInt är alltså en förutsättning för CDep och CDiv

Rådet som alla ger är som vanligt ”gräv där du står”. Börja automatisera det du kan från vänster till höger – bygge, test, driftsättning i test/prod, mät och följ upp. Här kan konceptet DevOps hjälpa till, vilket i stort sett går ut på att riva muren mellan utvecklings- (devs) och driftavdelning (ops). Det kan vara en person som funkar som en brygga mellan dessa eller ett förhållningssätt, t ex att en ops är med i projektteamet.

Det finns förstås flera utmaningar med detta – t ex att gå från arkitektur (svårt att ändra) till design (lättare att ändra), kunna ändra databaser och snabbt kunna sätta upp korrekt infrastruktur. Några tips som gavs var:

- Se leveranskedjan från idé till produktion som en kostnad och jobba för att få ned denna kostnad till ett minimum

- Dela upp system i komponenter som kan driftsättas oberoende av varandra. Det är ok att inte dela domänobjekt eftersom olika system använder dessa på olika sätt. Dela gärna på use case istället för domäner, t ex en service /user blir svår att hantera när det används både av admin (inlåst, 5 användare) och huvudsajten (publik, miljoner användare). Pröva /useradmin och /useraccount istället, ”Working complex systems comes from simple systems that work”

- Standarisera på data och protokoll (inte SOAP som tyvärr exponerar implementationen) istället för plattformar.

- Använd verktyg (t ex för att underlätta evolutionära databaser, d v s hantera ändringar på ett kontrollerat sätt

- Inse att ops-resurser (Operational Expenditure, OPEX) också är en kostnad, precis som inköp av infrastruktur (Capital Expenditure, CAPEX). Det är dumsnålt att inte investera i system och verktyg för att snabba upp leveranskedjan. Att ägna dagar/veckor åt få upp en korrekt konfigurerad server istället för på 5 minuter blir hög OPEX. Framför allt blir det också enkelt och snabbt att återhämta sig från en infrastrukturkrasch

- Använd verktyg (t ex för att automatisera hur infrastruktur sätts upp. En ny server ska vara ett knapptryck. Viktigt att versionshantera de script som beskriver hur infrastrukturen sätts upp

- Continuous Delivery, Neal Ford, ThoughtWorks –
- Agile Architecture, Marcus Ahnve, Valtech – Design For Replaceability –
- The road to REST, Rickard Öberg, Neo Technology –
- Retrospective from the year of DevOps, Daniel Fröding, Diabol AB –

Vad gäller webbsidan ser det ljust ut för Java. Webbramverket Play fångade mycket intresse på Jfokus och verkar ha alla möjligheter bli förstavalet i branschen framöver, förutom kanske i Spring-lägret. HTML5 börjar bli bara HTML i de flestas ögon, även om implementationen de nya API:na i webbläsare släpar efter. Ett av undantagen ser ut att vara localStorage som stöds av de flesta och används flitigt redan.

Nu har konsekvenser av att deploya appar i molnet börjat dyka upp och även lösningar på problem som det medför. Aktörer som VMWare genom försöker göra plattformen portabel, medan initiativ som försöker göra appen portabel mellan molntjänster (PaaS i det här fallet) genom att abstrahera bort plattformen. Kritik mot CloudFoundry finns att det inte är riktigt öppet förrän det är open source, medan jclouds får höra att deras modell inte räcker, eftersom de tjänster som molnen erbjuder (data store, jobs, queue, etc) har så olika karaktär att de inte går att generalisera. En sak som eldade på diskussionen om portabilitet var när Google App Engine blev aggresivare i sin debiteringsmodell. Just nu är det svårt att flytta från en leverantör till en annan.

Det var hyfsat högt intresse för Scala (ca 6 föreläsningar) tillsammans med funktionell programmering. Det får också lite draghjälp av Play (särskilt som version 2.0 RC släpptes i dagarna) som är Scalas hemmaplan. Andra intressanta saker som kanske inte var nya är Akka (händelsedriven, skalbar och feltolerant arkitektur – och Hadoop (distribuerad skalbar processing –

- Building a web page with HTML5, Robert Nyman, Mozilla –
- Patterns of Agile Enterprise Architecture, Rebecca Parsons, ThoughtWorks –
- Client-side Storage: When & How, Pamela Fox –
- An Intro to Hadoop, Eva Andreasson, Cloudera –
- Functional Thinking, Neal Ford, ThoughtWorks –
- HTML5 with Play Scala, CoffeeScript and Jade, Matt Raible, Raible Designs –
- Up and out: Scaling software with Actors, Viktor Klang, Typesafe –
- Developing portable PaaS applications, Andrew Phillips, jclouds –
- One-liners are your friend: Increasing Productivity with Scala, Thomas Alexandre, DevCode Consulting –

Kategorier Jfokus2012 | Kommentarer
Taggar jfokus
Sida 1 av 1
  • Tjänstgörande redaktör: Mia Carron
  • Chefredaktör, ansvarig utgivare och VD: Jan Helin
  • Stf ansvarig utgivare: Lena Mellin
  • Sajtchef: Lena Widman
  • Besöksadress: Västra Järnvägsgatan 21, Stockholm
  • 556100-1123
  • Momsregistreringsnr: SE 556100-112301
  • Kontakt: fö
  • Aftonbladet Plus Kundcenter:
  • Telefon växel: 08 725 20 00

© Aftonbladet Hierta AB