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.