Nästan varje organisation vi möter har en plattformsambition. Ofta har den funnits i flera år, den har ett namn, och den har en bild i en presentation där lådorna ligger snyggt ovanpå varandra. Ändå ser koden ut som den gjorde innan, och de team som skulle bli självgående väntar fortfarande på att någon annan ska göra klart något.
Skälet är sällan att arkitekterna hade fel om måldiagrammet. Skälet är att en plattform inte är en teknisk struktur utan en uppsättning löften mellan grupper av människor, och att löften inte kan införas uppifrån i ett stort steg. Den här texten handlar om hur vi arbetar med den övergången i praktiken, och om de misstag vi själva har gjort på vägen.
Vad en plattform faktiskt är
En plattform är den mängd förmågor ett produktteam kan använda utan att fråga någon om lov. Det är hela definitionen, och den är avsiktligt obehaglig. Den säger att om ditt team måste skicka en begäran och vänta två veckor på en databas, då har du ingen plattform på det området, hur många lager av abstraktion som än finns i diagrammet.
Definitionen är användbar för att den går att mäta. Ta en ny utvecklare, ge personen en påhittad men realistisk uppgift, och räkna hur många gånger arbetet stannar för att någon utanför teamet måste göra något. Varje sådant stopp är ett fel i plattformen. Vi gör den övningen i början av nästan varje uppdrag och den brukar vara mer avslöjande än en månads intervjuer.
Motsatsen till en plattform är inte en monolit. Motsatsen är en organisation där varje leverans kräver samordning mellan grupper som inte känner varandra. Man kan ha den situationen med hundra mikrotjänster lika gärna som med en enda kodbas, och den distribuerade varianten är svårare att laga.
Varför den stora omskrivningen misslyckas
Den plan som ser mest rationell ut på ett papper är att bygga det nya vid sidan av det gamla och byta när det är klart. Vi har sett den planen prövas många gånger och nästan aldrig lyckas. Det finns tre skäl.
Det första är att verksamheten inte fryser. Under de arton månader det nya bygget pågår fortsätter kraven att komma, och de måste byggas i det gamla systemet eftersom det är det som är i drift. Det nya bygget siktar därmed på ett mål som rör sig, och avståndet ökar snarare än minskar.
Det andra är att kunskapen om vad det gamla systemet gör inte finns nedskriven. Den finns i undantagen, i felhanteringen och i den märkliga koden som någon skrev efter en incident 2019. Ett omskrivningsprojekt börjar med att läsa specifikationen och upptäcker de här sakerna en i taget, oftast i produktion, långt efter att tidplanen sattes.
Det tredje är politiskt. Ett projekt som inte levererar något på arton månader har inget att försvara sig med när budgeten stramas åt. Det avbryts, ofta med nittio procent av arbetet gjort, och organisationen sitter kvar med två system i stället för ett. Vi har gått in i den situationen som städare fler gånger än vi har velat.
Så gör vi i stället
Vi börjar med att hitta sömmen, inte modulen. En söm är ett ställe i det gamla systemet där ett anrop går över en gräns som redan är någorlunda tydlig. En orderläggning som anropar en lagerkontroll. En rapportgenerering som läser men aldrig skriver. Sömmen är intressant för att den går att flytta utan att förstå allt annat.
Sedan lägger vi ett tunt lager framför sömmen som skickar trafiken vidare till det gamla systemet, precis som förut. Det ändrar ingenting funktionellt, och det är själva poängen: nu finns ett ställe där vi kan ändra vem som svarar utan att någon annan behöver veta om det.
Därefter bygger vi den nya implementationen bakom lagret och kör den parallellt utan att lita på den. Båda får samma anrop, det gamla svaret går till användaren, och skillnaderna loggas. Det här steget är det som gör hela metoden möjlig, för det är där de odokumenterade undantagen dyker upp medan de fortfarande är ofarliga. Vi brukar räkna med att den första veckans skillnadslogg innehåller minst en sak ingen kunde ha gissat.
När skillnaderna är förklarade eller åtgärdade flyttas trafiken över gradvis, med möjlighet att gå tillbaka på sekunder. Först då tas den gamla vägen bort. Att faktiskt ta bort den är ett eget steg som måste planeras in, annars blir den kvar för alltid och komplexiteten har ökat i stället för minskat.
Ordningen som avgör
Frågan vi får oftast är vilken del man ska börja med. Svaret är sällan den viktigaste delen, och nästan aldrig den svåraste.
Börja med något som är litet nog att bli klart på några veckor, tillräckligt verkligt för att någon ska märka skillnaden, och som ligger i vägen för något annat. Den tredje egenskapen är den som brukar glömmas. Om den första flytten inte gör något annat lättare har ni bevisat att metoden fungerar men inte skapat något momentum.
Undvik att börja med det som skulle ge störst effekt om det lyckades. Den delen är oftast störst effekt just för att den är mest sammanflätad med allt annat, och det är ett dåligt ställe att lära sig en ny arbetsform på. Spara den till efter tredje eller fjärde flytten, när teamet kan metoden och organisationen har sett den fungera.
Vad förändringen kostar
Det ärliga svaret är att den här metoden är dyrare i tid än en omskrivning, om omskrivningen lyckas. Parallellkörning, skillnadsloggar och två vägar genom samma funktion under en period är verkligt arbete som inte syns för en användare.
Det man köper för pengarna är att projektet aldrig är i ett läge där det inte går att avbryta. Efter varje flytt är systemet i ett fungerande tillstånd, värdet är realiserat och det som är kvar går att prioritera om. För en organisation som har blivit bränd av ett stort projekt är det argumentet ofta viktigare än tidsplanen.
Det finns också en kostnad som sällan diskuteras: metoden kräver att teamen kan driftsätta ofta och säkert. Om varje release är en händelse med ändringsråd och helgarbete faller hela upplägget, eftersom det bygger på många små steg. Då är den verkliga första uppgiften inte arkitektur utan leveranskedja, och det är värt att inse innan än efter.
Data är den del som underskattas
Nästan all planering vi ser handlar om kod. Nästan all faktisk fördröjning handlar om data. En tjänst som flyttas behöver sin data, och den datan ligger i en tabell som fyra andra funktioner också läser ifrån, ofta med anspråk ingen har skrivit ner.
Det första steget är att ta reda på vem som skriver. Så länge det gamla systemet är den enda som skriver till en tabell kan den nya tjänsten läsa samma data utan risk, och den övergången är enkel. Problemet uppstår när båda ska skriva, för då finns två sanningar och ingen mekanism som avgör vilken som gäller.
Vi undviker delat skrivande helt. Antingen äger det gamla systemet skrivningen och den nya tjänsten läser, eller tvärtom, och bytet av ägare är ett eget planerat steg med kort stopp eller med en period där ändringar strömmas åt ena hållet. Att låta båda skriva i en övergångsperiod låter smidigt på ett möte och skapar avstämningsproblem som lever kvar i flera år.
Det andra steget är att acceptera att datamodellen kommer att vara ful under övergången. Den nya tjänsten kommer att ha kolumner som bara finns för att det gamla systemet förväntar sig dem, och det är rätt beslut så länge de är märkta och har ett datum. Ett försök att göra datamodellen vacker samtidigt som trafiken flyttas är att göra två svåra saker på en gång, och den kombinationen är där de flesta tidplaner spricker.
Gränssnittet ska ritas av den som ska använda det
När en förmåga flyttas ut ur en monolit uppstår frågan hur den ska anropas. Standardsvaret är att det team som bygger tjänsten också bestämmer gränssnittet, eftersom de känner domänen bäst. Vi tycker att det är fel ordning.
Ett gränssnitt som ritas inifrån speglar implementationen. Det får med begrepp som bara betyder något för den som byggt tjänsten, och det tvingar varje anropare att förstå den interna modellen för att kunna använda den. Ett gränssnitt som ritas tillsammans med den första verkliga anroparen ser annorlunda ut: det är formulerat i de termer den som anropar redan tänker i.
Ett praktiskt sätt är att låta den första anroparen skriva sitt anrop innan tjänsten finns, som om den redan var byggd. Den koden är sedan facit. Det brukar avslöja att hälften av parametrarna som var tänkta att skickas in egentligen är sådant tjänsten själv kan ta reda på, och att det som verkligen behövdes var ett svar med två fält som ingen hade planerat.
Vad vi hade gjort annorlunda
Om vi ser tillbaka på de här uppdragen finns tre saker vi konsekvent skulle gjort tidigare.
Vi skulle mätt innan vi flyttade. Det är förvånansvärt vanligt att ingen vet hur ofta en funktion anropas, av vem, eller hur den beter sig när den är långsam. Att lägga en vecka på att få den bilden innan första flytten betalar sig direkt, eftersom det både visar var man ska börja och ger ett facit att jämföra mot efteråt.
Vi skulle tagit bort mer. Varje gammal väg som lämnas kvar för säkerhets skull blir permanent, och efter tre år är systemet mer komplicerat än när arbetet började. Att sätta ett datum för borttagning i samma beslut som flytten görs är den enda metod vi sett fungera.
Och vi skulle involverat de som förvaltar systemet i drift från första veckan i stället för vid överlämningen. De vet vilka delar som verkligen går sönder, och den kunskapen finns inte i någon dokumentation. Ett par frågor till rätt person i driftteamet har flera gånger sparat oss en månad.
Tecknet på att det fungerar
Ett år in i ett sådant här arbete brukar vi titta på en enda sak: hur ofta ett team måste vänta på ett annat för att bli klart. Om den siffran sjunker går arbetet åt rätt håll, oavsett hur mycket av det gamla systemet som är kvar. Om den inte sjunker har ni flyttat kod utan att flytta beslut, och då kommer diagrammet att se bättre ut än vardagen känns.