Troligtvis har du läst eller hört om något företag med en lösning, eller en organisation som gått ut och sagt, att de är data-drivna. Det känns ju bra, för data är ju den nya oljan, så data-drivet måste vara jättebra. Men vad betyder det? I detta blogginlägg reflekterar Stefan Palm kring vad data-drivet betyder och beskriver olika sätt att kommunicera.
Som vanligt med dessa trend-begrepp, så kan de betyda lite vad man själv vill, du känner säkert igen vad jag menar med begrepp som ”digital transformation” och ”AI”. Så här blir det min vinkling på begreppet data-driven, men kom ihåg att det kan finnas fler tolkningar/betydelser. Hoppas du hänger med till slutet av en liten resa jag tänkte ta med dig på, och så avslutar vi med ett konkret exempel.
Vad betyder datadrivet?
Så låt oss börja analysera vad data-drivet betyder. Substantivet driv, betyder enligt SAOL ”fart, flyt”, så på något sätt ska data få saker att hända. Ett annat sätt att definiera ett uttryck kan vara att säga vad det inte är, vad betyder det att inte vara data-drivet?
Sidospår, det kan bli rätt kul när man tänker på detta sätt i andra sammanhang. När någon uttrycker sig ”Vår organisation tar denna fråga på största allvar.”, så kan jag fundera på om de tror att det finns andra organisationer som inte tar den aktuella frågan på allvar. Tidningar är fulla av dessa komiska uttryck.
För att inte bli för abstrakt, låt oss säga att vi har en välkänd process som vi vill ska utföras när vi får in en viss typ av data. Jag tror du själv kan hitta ett exempel nära dig. Hur ska vi överföra kunskap och insikter från data, så att något händer? Vi behöver hitta ett sätt att kommunicera. Det är nu det börjar bli snårigt.
Historiskt var det inget problem, man skrev ett program som gjorde allt. Enkelt, men när systemen växer uppstår problem. De flesta har i sin organisation minst en ”monolit”, ett system som vårdas ömt av ett fåtal personer, men är omöjligt att kommunicera med (förutom exportera filer).
När man i dag sätter sig ner för att rita på lösningen för en tämligen enkel process, är det stor sannolikhet att man ska kommunicera med andra system eller tjänster. Istället för monoliter pratar man nu om mikrotjänster, där varje tjänst löser en specifik uppgift. Det är genom att kombinera flera mikrotjänster man kan i dag skapar lösningar.
För detta syfte har alla moderna system / tjänster Application Programing Interfaces, API:er. Men låt dig inte luras, API:er är ännu ett av dessa begrepp som kan betyda lite vad som helst när man tittar på tekniken. Vanligaste listan av förkortningar som brukar dyka upp är för äldre system SOAP/XML, funktionsorienterade komponenter använder RPC/gRPC, men de flesta tänker på REST HTTP/JSON när de pratar om API:er, även kända som REST API:er.
REST står för ”Representational State transfer”. I fokus är resurser, eller vissa kallar det objekt, enklast är att tänka att man ska definiera ett substantiv. Har du glömt bort svenskan från skolan så är det framför dessa man kan sätta en, ett eller flera. I REST ska en resurs anges med flera framför, dvs pluralis. En resurs har flera egenskaper (attribut) och ett antal funktioner finns för att kommunicera med resursen. Sidospår; för att inte behöva implementera oändligt med resurser används ofta objekt orienterad design, för att återanvända egenskaper och funktioner.
Kommunikation sker med hjälp av HTTP, och man använder verben i HTTP för utbyte av data med resursen. Enklast är att tänka GET för att hämta data från resursen, och POST för att skicka data till resursen.
Ska vi vara lite petiga står POST för att skapa en resurs, PUT för att uppdatera en existerande resurs helt, PATCH uppdatera en existerande resurs delvis och ta bort resurs är DELETE. Men det är inte fokus just nu.
Synkron kommunikation och asynkron kommunikation
Det jag vill belysa är att REST API:er innebär synkron kommunikation. Tänk på hur en webbläsare fungerar. Jag skriver in en webbadress (URL) och gör en HTTP GET, väntar på svar och när svaret kommer visas sidan. Dvs applikationen skickar en förfrågan (request) och väntar sedan på svar (response) innan den fortsätter. Vi har skapat ett beroende mellan den som skickar förfrågan och den som svarar.
För att komma bort från denna låsning i kommunikationen kan man istället för synkron kommunikation, titta på asynkron kommunikation. Det finns sätt att implementera asynkron kommunikation med REST API:er, men det finns vissa utmaningar med det och massor av åsikter, men jag undviker den dialogen här.
Ett annat sätt att skapa asynkron kommunikation är att använda event-baserade teknologier, som i grunden är asynkron. Det finns massa varianter, men oftast pratas det om pub/sub. Här är det ett event (händelse) som är i fokus och händelsen kommuniceras via ett topic (ämne). En eller flera kan skriva till (publish), och en eller flera kan lyssna på ett ämne (subscribe). Den som skriver till ett ämne har ingen direkt koppling till den eller de som lyssnar, och tvärt om, dvs vi har inget beroende mellan komponenter i en lösning.
Den här egenskapen har gjort denna typ av kommunikation populär för moderna lösningar baserade på mikrotjänster. Det är enkelt att byta ut komponenter i lösningen, eller lägga till nya funktioner utan att påverka existerande delar.
Så det finns många fördelar att införa en arkitektur som är händelsestyrd (event-driven), men det är inte samma sak som att vara ”data-driven” (inser att detta kan läsas både på engelska och svenska, övergår till datastyrd på svenska). I en händelsestyrd lösning är det fortfarande så att någon tolkar data, och när vissa villkor uppfylls så skapas en händelse. Och det är via denna händelse som man kommunicerar och andra kan reagera på.
När man pratar datastyrd, så introduceras begrepp som ”observer” och ”observerable”. Jag har inte hittat några bra svenska begrepp, jag improviserar lite och så kan vi le lite åt dessa påhittade begrepp i framtiden. Den stora skillnaden med datastyrd kommunikation är att den sker via data, och ja det kan låta lite konstigt, det gör oftast allt som är nytt. Men väldigt enkelt: en tjänst kan välja att dela med sig av data som observerbar, och någon annan kan välja att bli observatör till denna data. Till skillnad från händelsestyrd kommunikation gör den som delar data i detta fall ingen värdering av data, det är upp till den som observerar data att reagera på det som de vill.
Ett begrepp som nu dyker upp är en data-ström. Tiden blir en aspekt. Data som delas över tid blir ett flöde av data, ett flöde som kan hanteras i en dataström. Det här är något som oftast pratas om inom Internet of Things (IoT) lösningar, där man har sensorer som skickar data regelbundet. Dataflödet från en sensor kan definieras som observerbart, och en tjänst kan observera flödet av data. Men det är inte bara inom IoT som man jobbar med dataströmmar, alla system som man kan dela data med någon form av regelbundenhet kan göra det via en dataström. Oftast kan man från en dataström inte bara få senaste värde, utan utnyttja tidsaspekten för att få hjälp med analys av dataströmmen. Medelvärde, eller max och min–värde, under viss tidsperiod är enkla saker att förstå. Men ofta har tekniken som realiserar data-strömmar stöd för att bygga komplexa analysfunktioner som stöd till de som observerar. Även här har ”AI” gjort avtryck och Machine Learning på dataströmmar finns på alla stora plattformar.
Summering av kommunikationssätten
Så en summering, för att tydliggöra skillnaderna med de 3 olika sätt att kommunicera, med ett enkelt exempel.
Vi ska bygga en app som ska skicka ett SMS om temperaturen på kontoret överstiger 25 grader.
Till vår hjälp har vi fått 3 olika sensorer som kommunicerar på olika sätt.
Sensor 1 kommunicerar via REST API.
Vår app får då regelbundet skicka en förfrågan till sensorn för att få aktuellt värde.
Om värdet överstiger 25 grader skickar appen ett SMS.
Men, om temperaturen är 25 grader någon gång emellan vi frågar kommer vi inte veta det, så vi kan lockas skicka frågan väldigt ofta. (ja, en utmaning med REST är att det kan skapa väldigt mycket trafik.)
Sensor 2 kommunicerar via events.
Vår app kan publicera till ett ämne vilket tröskelvärde som sensorn ska ha (25 grader)
Vår app kommer sedan lyssna på ett annat ämne som sensorn kommer publicera till när temperaturen överstiger tröskelvärdet, och när det eventet kommer så skickar appen ett SMS.
Mycket mindre kommunikation, men kräver en ”smartare” sensor (vilket även innebär dyrare).
Och vi ”tappar” data / information från sensorn. Om vi vill räkna ut medeltemperaturen senaste dygnet, så har vi inte underliggande data. Att bygga en smartare sensor för att även lösa detta blir dyrare och kräver förmåga att underhålla distribuerad lösning.
Sensor 3 kommunicerar via en dataström.
Vår app kan observera dataströmmen och vi kan sätta ett tröskelvärde (25) och under hur lång tid tröskelvärdet ska överskridas innan vår app skickar ett SMS.
Sensorn kan vara relativt okomplicerad (billig), och genom komprimera data kan vi hålla ner datatrafiken. Då vi har tillgång till all data från sensorn kan vi prova oss fram och utveckla nya funktioner kontinuerligt.
Kanske vill vi ha en trendkurva för medeltemperatur per timme, senaste veckan?
Eller vill vi träna en ML-modell som predikterar om temperaturen kommer gå över 25 grader kommande timme, baserad på senaste 24 timmars data?
Glöm inte bort att det är behovet som avgör vilken teknologi som ska användas.
Så det är inte frågan om vilken teknologi som man ska välja överallt, troligtvis finns det behov för alla typer av kommunikation jag beskriver ovan.
Men olika teknologier skapar olika möjligheter, så det gäller att vara medveten när man väljer. Och att skapa en arkitektur där det är lätt att ständigt jobba med optimering. För det kommer ständigt nya teknologier, som skapar nya möjligheter.
Ingen individ kan ha insikt i alla nya teknologier, men vi på Softronic har bred kompetens.
Så hör av dig till oss om du vill få lite mer insikt eller hjälp med att realisera värde med ny teknologi, för det är det vi gör.
Relaterade länkar
Blogginlägg skrivet av Stefan Palm för Softronic AB.
