Låter detta huvudlöst? Då har du helt rätt!
För att hjälpa till att förmedla det nya perspektivtet brukar man rita mikrotjänster och API:er som en ny “våning” i infrastrukturen när man ska förklara hur de förändrar arkitekturen. Om du tänker dig att alla dina olika plattformar (ett CMS för webben, ett CRM för att hålla reda på kundrelationer, ett affärssystem för att hålla reda på ekonomin och så vidare) är bottenvåningen eller kanske till och med grunden, så kommer sedan mikrotjänster och API:er mellan dem och de applikationer som dina kunder använder. Och här använder vi uttrycket kunder i en förlängde bemärkelse: Din organisation har också “interna kunder” i form av alla medarbetare som också behöver olika system för att göra sina jobb.
Det här är en förenklad bild som ska hjälpa oss att förstå hur applikationerna inte behöver veta vilka plattformar som finns i grunden. Om vi också tänker oss att kunden, eller användaren, är längst upp i den här bilden och likt Michelangelos målning sträcker hen ned sin hand från himmelen för att interagera med/använda vad det nu är som du och din organisation vill erbjuda. Allt från att läsa något, se en film, beställa något eller använda någon av era tjänster.
[Bild: De olika våningarna/lagren med Applikation/Mikrotjänster och API:er/Plattformar. Och Guds hand som kommer ned uppifrån för att röra vid det översta applikationslagret.]
Perspektivet hjälper oss också att förstå hur mycket snabbare vi kan förbättra kundupplevelsen --- där handen möter dina applikationer --- om den inte är direkt kopplad till plattformarna. Så att de inte hela tiden ensamma levererar kundupplevelsen. Det är så vi slipper bli instängda i vad respektive plattform kan och inte kan. Och vi kan byta en specifik plattform när det behövs utan att behöva på ändra allt annat i strukturen. Du har säkert hört folk prata om hur jobbigt det är med “integrationsprojekt” --- att integrera plattformar med varandra --- och det beror på att man förr i tiden byggde ihop plattformar direkt med varandra. Dels var det krångligt att göra och dels betydde det att plattformarna sedan satt ihop. Så om du bytte en var du i princip tvungen att byta den andra. Eller göra en ny integration mellan den nya plattformen och den som blev kvar.
Det här ledde så klart till kedjereaktioner där organisationer inte bara satt fast i en särskild plattform --- till exempel en webbplattform som EPI --- utan också i alla andra plattformar som de hade integrerat webben med. De var med andra ord instängda i sin egen arkitektur.
Ett annat sätt att säga det är att prata om beroenden. Som i att i exemplet ovan var webben beroende av de plattformar den var integrerad med och tvärtom. Många beroenden leder med andra ord till en dominoeffekt om du ändrar på ett ställe. Och tvärtom, det vi nu strävar efter är att ha så få beroenden som möjligt. Lite senare kommer vi att märka att detta inte bara gäller teknologi utan även våra arbetssätt.
Så om mikrotjänster och API:er gör det möjligt att koppla ifrån oss från beroenden, koppla bort hårda integrationer, så har vi redan konstaterat att det också gör det möjligt att byta ut plattformar oberoende från varandra. Men det gör det också möjligt att byta ut andra moduler i strukturen oberoende av varandra. Det är också därför de här tankesättet blivit så viktiga för hur vi ökar farten i utvecklingen av kundupplevelsen.
För att komplettera bilden behöver vi lägga till en våning. Eller ett till koncept. Återigen ligger ett av våra tre M bakom: Apples lansering av iPhonen gav oss ett nytt fenomen i det mobila surfandet. Och även om det var fascinerande hur man kunde zooma med fingrarna på skärmen så tog det inte lång tid förrän de som ville förbättra upplevelsen för sina besökare började presentera dem med en anpassad version av webben. En mobil webb. Sen ökade det mobila surfandet dramatiskt så i princip alla behövde en mobil version av sin webb och då blev det för mycket merarbete att ha två olika versioner. Istället började man designa responsiva upplevelser. När besökaren kom till sajten kände den helt enkelt igen om du satt på en laptop eller en smartphone och anpassade utseendet därefter.
Och här lärde vi oss en ordentlig läxa.
Det här var nämligen precis en sådan situation som vi har pratat om. Med hög hastighet förändrades besökarnas beteende och en hel uppsjö av de befintliga webbplattformarna kunde inte visa upp två versioner av en och samma webb, anpassade för den enhet kunden för tillfället använde. Alla företag och organisationer behövde ha en responsiv sajt men en majoritet var tvungna att byta hela sitt CMS, sin webbplattform, för att kunna göra det. I många fall satt de fast i beroenden --- deras webb var hårt integrerade med andra system --- och då fanns det flera som blev tvungna att vänta tills tillverkaren av deras webbplattform släppte en ny version som kunde hantera responsiva webbar.
Det är lätt att skratta åt det förflutna idag, men det viktigaste är att lära sig av läxorna. (Exakt samma sak håller nu att hända med den rösttstyrda webben för de som inte lärt sig av historien. Och det är tyvärr många.)
I ungefär samma veva insåg Twitter, som då börjat växa så det knakade, att de också behövde en webbapp som var anpassad till telefoner om det var det användarna surfade med. Och några kodare som jobbade där tyckte det verkade fånigt att man skulle behöva vara beroende av webbservern för att få en responsive sajt. De utvecklade vad man nu kallar för ett framework --- ett ramverk för hur en webbserver skulle hantera enhetsanpassningen av sidorna den blev ombedd att visa upp varje gång en besökare kom till domänen. Vi skulle kunna kalla det för ett regelverk också, för i sin enklaste uttolkning var det en uppsättning regler för hur sidorna skulle bete sig.
“Om besökaren har en skärm som är så här bred, lägg då de här modulerna bredvid varandra, max sex i bredd.”
“Men om besökaren har en skärm som är så här smal, lägg modulerna under varandra.”
Om den som designade och byggde sajten tog detta i beaktande och såg till att sidorna bestod av moduler som kunde plockas runt efter behov, så spelade det inte så stor roll vilken webbplattform man var på. De kallade sitt ramverk för Bootstrap efter den engelska termen för att använda något halvfärdigt för att komma igång snabbare. (Boot straps är de handtag eller öglor man använder för att lättare dra på sig ett par cowboy-boots.) Och de släppte ramverket fritt på nätet så att vem som helst kunde använda det.
Sedan dess har inte bara Bootstrap fått vingar, utan också hela idén, hela konceptet. Med hjälp av ett ramverk kan vi bli ännu mer plattformsoberoende, samtidigt som flera olika plattformar i vår infrastruktur kan använda ramverket och saker gjorda inom det, till exempel design. Om ändrar några av reglerna eller något i din design, slår det igenom och fungerar överallt där du använder ramverket. Hög grad av återanvändning, med andra ord! Plus många sparade arbetstimmar. Nu finns också ramverk som Angular, React och Node.js som bland annat gör det möjligt att uppdatera saker live, även design och funktioner.
Det är en större grej en vad många kanske tror, för tidigare har man varit tvungen att göra nya releaser varje gång man ska lansera nya funktionalitet och ny design på webben eller i en app. Vi skulle kunna likna det vid att webbservern behövde startas om för att nyskriven kod skulle laddas och bli aktiv. Sådan lanseringar var alltid kringgärdade med ett visst mått av nervositet och brukade ske på natten för att störa så få besökare som möjligt. En sådan uppförsbacke, ett sådant hinder, brukar betyda att man gärna tänker sig för en och två gånger innan man gör en uppdatering. Men i verkligheten vill vi nu ha det motsatta beteendet: Att du ska göra små förbättringar ofta. Det ökar farten på utvecklingen av kundupplevelsen och alltså är det inte konstigt att den nya infrastrukturen med ramverk och mikrotjänster som nya lager/våningar ovanför plattformarna blivit mer och mer populär.
När webben på så sätt delats upp och olika tjänster levererar de funktioner och förmågor som beståndsdelarna representerar, brukar man säga att webben eller infrastrukturen är huvudlös. (Vilket är ett ironiskt namn på ett upplägg som är smartare än det monolitiska!) Vi kan tolka det som att det inte längre är webbservern som “visar upp” din sajt för besökarna. Du kanske använder WordPress som redaktörsgränssnitt, men det är React, plus ett innehålls-API, tillsammans med ett look & feel-API som gemensamt befolkar sidorna med rätt moduler för varje besökare. Det är alltså inte längre webbservern som står “för allt”, den är inte huvudnumret.
Vi kan också tolka det som att det inte längre är webbservern som är “först” i att besvara en förfrågan från en besökares browser om att få se något. Webbservern är inte längre “chef” över upplevelsen.
Hur vi än väljer att förklara begreppet är denna förbättrade infrastruktur i många lager inte bara en intressant teknologihistoria. Det är en förutsättning för att du ska öka farten på utvecklingen av din kundupplevelse. Så även om den inte har med teknologi att göra, finns nu ett antal mycket bra förutsättningar för att ta bort den flaskhals som funnits kring design, UX och upplevelser.
Vi kan effektivisera processen genom att decentralisera den. Och genom att göra den mycket mer kreativ än tidigare!