Author Archives : Magnus Särnevång

Arkitektur handlar om avvägningar

Date : 18 juni, 2018

För ett par år sedan fick jag ett uppdrag av en global läkemedelskoncern att bygga en plattform för deras 2000 varumärkesdrivande webbplatser. Detta var ett stort projekt med mig som arkitekt, ett dussin utvecklare, en testare och 3-4 projektledare. Vi hade strateger och art directors som kom och gick under projektet.

Kundens problem var att de fanns med sina produkter på 200 marknader, varje marknad var självstyrande, så när exempelvis huvudkontoret i Malaysia behövde en ny webbplats för att marknadsföra en produkt eller ett läkemedelsområde i Malaysia, så upphandlade de detta lokalt, fick en lokal IT-partner och driftade det också lokalt. All IT var på så vis distribuerad och enbart vissa stödtjänster erbjöds från corporate.

Detta medför vissa problem

  1. Webbplatserna som producerades höll väldigt låg kvalitet för att man inte hade kunskapen att driva webbprojekt ute i organisationen
  2. IT-miljön blev väldigt spretig och svår att underhålla med olika leverantörer, driftpartners, tekniker
  3. All teknik som utvecklades för Malaysia måste också utvecklas för de andra 199 marknaderna. Enkelt räknat måste varje feature tillämpas 200 gånger
  4. Driftkostnaderna för 200 siter överstiger monumentalt samma kostnad för att drifta 200 siter på en och samma plattform
  5. Det är omöjligt att genomföra globala initiativ, eller ens regionala när tekniken är helt och hållet distribuerad

Mitt uppdrag var att lösa problemen ur en teknisk synvinkel. Med hjälp av EPiServer CMS skulle vi tillhandahålla en plattform som kunde bli ett internt erbjudande till alla marknader utan att inskränka deras självstyre.

En plattform för varumärkeswebbar

När vi tog fram denna lösning hade vi följande ledord.

  • Reuse by content
  • Reuse by features
  • Reuse by technology
  • Reuse by hosting

Läkemedelsbolag har väldigt höga krav på innehållet som produceras och därför måste allt innehåll granskas i en godkännandeprocess innan det publiceras. Detta kan göra innehållsarbete på digitala kanaler trögflytande eftersom det tar tid att få ut nytt innehåll. Därför tog vi fram funktionalitet för ett globalt innehållsbibliotek där varumärkesägare kunde återanvända innehåll som redan gått igenom kvalitetsprocessen.

Istället för att varje site utvecklar sin egen bannerkomponent tog vi fram ett komponentbibliotek med färdiga komponenter som webbplatsägaren kan dra in på sin webbplats för att komponera sidor. Det rör sig om allt från nyhetslistor, navigation, brödsmulor och puffar som kan återanvändas från site till site.

Eftersom plattformen är ett internt erbjudande till olika business units, måste det vara möjligt att använda flera leverantörer och därför skapade vi ett gränssnitt för kreatörer att skapa tema ovanpå webbsiternas funktionalitet. Detta ger synergier när olika leverantörer arbetar med samma tekniker och redaktörerna kan arbeta i samma CMS. Det blir lättare att kommunicera kring digital marknadsföring och hitta en gemensam riktning samt ta gemensamma stratgiska beslut.

Inte minst var driftskostnaderna en drivande faktor för att tillämpa plattformen. Att drifta en plattform med 200 webbsiter kräver färre resurser och lägre kostnad än att hålla 200 driftsmiljöer på lika många marknader.

Avvägningar

Man är naiv om man tror att man kan lösa alla problem med arkitektur. Vad man egentligen gör är att man väger vissa egenskaper som viktigare än andra. Detta är en lärdom som jag tar med mig från projektet.

Vi lyckades maximera återanvändbarheten av olika komponenter, men redaktörsverktyget blev svårare att använda när man tvingas komponera ihop sidor. Effekten blev att det krävdes expertanvändare för att kunna bygga upp webbsidor från grunden, medan vanliga redaktörer fick hålla sig till att göra enstaka tillägg och ändringar.

Om man bygger en plattform där man samlar alla sina webbar då måste man också se till att underhålla den plattformen. Tidigare har man kommit undan med att producera en WordPresswebb och släppa den, men en plattform kräver underhåll och vidareutveckling. Man måste ge support åt sina redaktörer, administratörer, beställare och leverantörer som skall tillhandahålla webbar på plattformen.

Slutligen kommer gemensam drift att sänka den totala driftskostnaden men det kommer också göra alla webbsiter indirekt knutna till varandra. Om en webbsite kräver ny deploy av plattformen kommer detta påverka alla webbar på plattformen. Vi underlättade detta till viss del genom att skapa ett pluginsystem för komponenter och teman, men det hindrar inte en leverantör som gör ett misstag att kunna sänka hela plattformen med alla webbsiter.

Vi väger återanvändbarhet mot komplexitet. Det som tidigare kunde byggas och kastas bort måste nu istället förvaltas. Ett centraliserat system ger lägre driftskostnad men blir mer känsligt för driftstörningar. Detta är de arkitektuella avvägningar vi behövt göra för att lösa kundens ursprungsproblem. Man löser vissa problem och andra problem uppstår till följd av ens lösningar.

Detta hindrade mig inte för att implementera samma koncept för två andra kunder inom livsmedelsbranschen, med nya arkitektuella avvägningar, utmaningar och lärdomar.


Paradigmer styr vår problemlösningsförmåga

Date : 18 maj, 2018

Språket vi använder påverkar sättet vi tänker. De ord och fraser vi använder påverkar vårt förhållningssätt. Detta är något politiker är väldigt bra på, att använda ord för att påverka hur vi uppfattar problem i samhället och påverka debatten.

Detsamma gäller mjukvaruutveckling.

På 50-talet hände något fantastiskt när paradigmen strukturerad programmering uppstod. Tidigare hade man skrivit kod primärt för att maskinen skulle förstå den. Man programmerade maskininstruktioner som datorn skulle exekvera en efter en. Med strukturerad programmering ville man uppnå ett språk som skulle vara för människorna som läser och skriver koden. Man införde IF-THEN-ELSE, WHILE, FOR, subrutiner och kodblock. Detta är element som är fullt integrerade i den kod vi skriver idag, men som ändrade sättet man tänkte på 50-talet.

Denna nya sortens kod som med all fördel skrevs i programspråket Algol, behövde kompileras till maskinkod för att kunna köras av datorn. Givetvis hade också 50-talet sina nej-sägare som menade att en dator aldrig kan skriva lika optimerad maskinkod som en människa. Det är inte många som skulle föra det resonemanget idag.

Den mest populära paradigmen inom programmering är den imperativa objektorienterade programmeringen. Med imperativ menas att program beskriver vad datorn skall göra i den ordning det skall utföras, ungefär som man läser ett recept.

Vispa ägg och socker, blanda med mjöl och bakpulver, in i ugnen 175 grader i 30 minuter. Nu är kakan färdig.

Objektorienterad programmering blev populärt på 90-talet. Den identifierar ett problem med de system som vi bygger, nämligen att vi försöker översätta en komplex domän med noder som på olika sätt relaterar till varandra, till en kod som är helt och hållet imperativ, där en sak händer efter en annan.

I bästa fall kan den endimensionella koden motsvara en dimension av den komplexa domänen.

Med objektorienterad programmering skapar vi klasser och objekt i vår kod som skall efterlikna verklighetens komplexitet för att minska gapet mellan verkligheten och systemets implementation.

Detta nya sätt att tänka förändrade helt och hållet sättet vi bygger system och löser problem med programmering. Man kan säga att det är en revolution som har skett och verktygen har öppnat upp våra hjärnor för en ny sorts problemlösning.

Idag är det objektorienterad programmering som lärs ut på våra universitet och som varje systemutvecklare utgår från när de skall lösa ett problem. Den objektorienterade paradigmen sätter ramarna, men också begränsningar för hur vi löser problem.

Objektorienterad programmering är inte den enda paradigmen. Det finns fler sätt att lösa problem. Ett exempel är deklarativ funktionell programmering. Där utgår man ifrån att vi har data som vi passar in i funktion och får ut annan data, eller förändrad data.

Funktioner kan kombineras, nästlas, köras sekvensiellt eller parallelt, anropa sig själva eller vad som behövs för att uppnå önskat resultat.

Denna paradigm har funnits sedan sent 50-tal men fått ett uppsving de senaste åren som en motreaktion på att objektorienterad programmering helt och hållet tagit över våra programmeringsspråk. Det är inte en dålig modell för att beskriva system på heller. Mycket av det vi gör handlar om att mappa någon form av data till en annan. Det kan vara data i en databas till ett användargränssnitt eller varor i en kundvagn till en order.

Ett exempel på skillnader i paradigmer

Det lättaste sättet att beskriva skillnaden mellan dessa två programmeringsparadigmer skulle vara att göra det i kod.

FizzBuzz är nog den vanligaste programmeringsövningen som används vid anställningsintervjuer av programmerare. Målet är att skriva ett program som skriver ut siffrorna 1..n men där var tredje siffra ersätts med ”fizz”, var femte siffra med ”buzz” och för tal som både ersätts med ”fizz” och ”buzz” exempelvis 15 istället ersätts med ”fizzbuzz”.

En implementation i imperativ objektorienterad C#-kod skulle kunna se ut såhär.

Programmet beskriver imperativt i en följd hur man går till väga för att skapa resultatet. Vi lägger hela resultatet i en resultatlista och returnerar det.

Men bara för att man kan imperativ objektorienterad programmering så skall man inte tro att det är det enda sättet att lösa detta problem på.

En deklarativ funktionell lösning i F# skulle kunna se ut såhär.

Ser ni skillnaden? Detta är inte en imperativ beskrivning av hur FizzBuzz-listan skall skapas. Istället är det deklarerat vad fizzes är, sen vad buzzes är. Följande vad words är och vad numbers är och slutligen att fizzbuzz är en kombination av words och numbers där vi väljer words om det finns, annars numbers.

Hade jag inte kunnat funktionell programmering så hade jag inte vetat att man kan lösa FizzBuzz på detta sätt. Om man kan många paradigmer kan man också välja problemlösningsmetod utifrån problemet man har framför sig. Om man enbart kan objektorienterad programmering, då kommer alla lösningar bli till klasser och objekt.

When all you have is a hammer, every problem will look like a nail.


Patrik Murman konsult

Patrik Murman konsult
Date : 8 maj, 2018

Denna vecka börjar Patrik Murman som BI-konsult hos oss på Stratiteq. Patrik har tidigare jobbat som konsult, främst inom utveckling och projektledning. Hans BI-resa började under 2015 när han kom in på ett uppdrag inom SSRS. Där väcktes intresset för BI och allt vad det innebär, och han gillar att kunna presentera och läsa av data i realtid.

Utöver rollen som konsult har Patrik över 10 års erfarenhet från försvarsmakten där han har utövat allt från gruppchef till instruktör, vilket medfört att han trivs att arbeta i grupp och lösa problem.  

Patrik har nyligen blivit pappa till en liten son, så han håller på att lära sig allt vad det innebär att vara pappa. Annars blir det träningen på fritiden, allt från Göteborgsvarvet till att försöka åka Vasaloppet utan att ha åkt längdskidor. Sen blir det också en och annan timma framför datorn med något roligt spel tillsammans med vännerna. Öl är väldigt gott också.  

Varmt välkommen till oss Patrik!


Martin Durehed konsult

Martin Durehed konsult
Date : 8 maj, 2018

Denna vecka börjar Martin Durhed som BI-konsult hos oss på Stratiteq. Martin började sin BI-resa på Perstorp för 12 år sedan och kommer senast från Deloitte i Köpenhamn, där han haft en roll som Solution Owner/BI developer. Efter 5 år i Danmark fick han hemlängtan och tycker det känns härligt att vara tillbaka på hemmaplan.

Fritiden ägnas gärna åt matlagning, vindsurfing i Klagshamn eller att lyssna på ljudböcker under hundpromenader med Charlie.

Varmt välkommen till oss Martin!


Robert Hedgate konsult

Robert Hedgate konsult
Date : 3 maj, 2018

Denna vecka börjar Robert Hedgate som konsult inom Custom Solutions hos oss på Stratiteq. Robert har jobbat som programmerare i snart 20 år, mestadels i Microsoft teknologier. Han gillar att jobba nära UX för att ta fram de bästa och snyggaste lösningarna för användarna. Sista tiden har spenderats med app-utveckling med Windows 10, Xamarin och iOS.

Robert bor i Åkarp med fru och två barn. Om inte tiden spenderas med familj så går den åt till renovering av deras gamla hus och trädgården. Någon kväll i veckan så finns det förhoppningsvis tid med lite Xbox eller någon bra TV-serie.

Varmt välkommen till oss Robert!