Dags att pensionera brevduvan
För en tid sedan skrev jag ett inlägg där jag gjorde ett litet tankeexperiment. Jag lekte med idén att använda strukturen och logiken bakom Twitter för att hantera informationsöverföring inom transportsystem. Sedan dess har jag funderat ganska mycket på detta. Många har dessutom kontaktat mig och visat intresse för dessa tankar. Så, nu en liten tid senare, är det därför dags att åter besöka detta ämne och – kanske – borra lite, lite djupare än sist.
Ni som kanske har hittat till min andra blogg vet att jag tänker när jag skriver. Eller snarare tänker genom att skriva. Och precis så var det med förra inlägget. Jag har alltid gillat att vända på perspektiv och när jag skrev förra inlägget valde jag att låta mikrobloggen Twitter fungera som ett informationssystem för godstransporter. Syftet med övningen var just att vända på det kända och bekanta och att utforska något från en annan vinkel. Nåväl. Nu har detta första inlägg fått marinera ett tag och jag inser att idén vägrar lämna mig ifred. Men istället för att fortsätta prata om Twitter och hitta likheter tänker jag denna gång försöka mig på en generalisering av konceptet.
Normal elektronisk kommunikation inom B2B (business to business) sker i de allra flesta fall på traditionellt vis. Med en avsändare och med en eller flera mottagare. Avsändaren skickar meddelanden som mottagarna tolkar. Alla inblandade är på förhand överens om hur informationen skall struktureras. Alla är överens om semantiken (vad olika begrepp och data betyder). Det är detta som gör integration av informationssystem så oerhört komplext. Att varje enda relation i förväg måste specificeras in i minsta detalj.
Naturligtvis har man försökt standardisera. Jag är själv aktiv inom ett stort standardiseringsprojekt. Problemet med standarder är att de alla kräver att alla andra ska ansluta sig till just deras dialekt av verkligheten. Och det kommer inte att ske. Arbetet med de hundratals standarder som genomförts är naturligtvis inte gjort i onödan, tvärtom. Med standardiseringens hjälp har fler kunnat ta steget in i den elektroniska världen. Men att standardisera meddelanden känns lite som att bygga en raketmotor till brevduvan, som likt förbannat fortfarande kommer att vara en brevduva när allt är klart.
En brevduva – ungefär så fungerar kommunikationssystemen idag
Låt oss granska de viktigaste begreppen lite. Avsändare. Mottagare. Meddelande. Strukturerad, överenskommen information. Låter väl tryggt, eller hur?
Nja.
Jag skulle faktiskt vilja skrota dessa begrepp helt och hållet.
Jag vill att vi slutar prata om avsändare som någon som skickar meddelanden till förutbestämda mottagare.
Jag vill att vi slutar prata om meddelanden som har förutbestämda utseenden och innehåll.
Jag vill att vi slutar prata om mottagare som måste komma överens med varje tänkbar avsändare om hur de ska kunna kommunicera.
Jag vill att vi slutar prata om hur vi ska hitta det ”universella meddelandet” som generiskt ska kunna anpassas till alla situationer (något som jag anser är omöjligt).
Jag vill att vi inför nya begrepp.
Jag vill att när vi pratar om avsändare så menar vi någon som publicerar information.
Jag vill att vi pratar om dataströmmar som publiceras och dokumenteras av avsändaren.
Jag vill att vi pratar om prenumeranter som väljer vilka dataströmmar denne vill ha tillgång till.
Jag vill att vi pratar om precis det som jag ville försöka förklara i mitt förra inlägg. Tänk om vi hade ett icke-hierarkiskt, hyperlänkat, avsändarcentrerat informationssystem! Då skulle mycket bli möjligt.
Den som transporterar gods prenumererar på dataströmmarna från fordonen, streckkodsläsarna, ordersystemen, fordonsdatorerna etc. Den som skickar gods prenumererar på dataströmmar från transportören och från mottagaren. Alla som producerar data gör denna tillgänglig via API:er (ett gränssnitt som möjliggör för IT-system att kommunicera med varandra). Dessa API:er dokumenteras och publiceras och den som vill ansluta sig kan där en gång för alla designa sin prenumeration. Det är här vi kan lära oss av proffsen. Av Twitter, Google och Facebook. Men också om hur detta redan idag sker med hjälp av den nu ganska gamla (!) RSS-teknologin.
De sociala nätverken är uppbyggda på att data publiceras och görs tillgänglig för andra system. Den som publicerar data vet inte hur denna data används av prenumeranten och den som prenumererar kan föra samman flera datakällor för att skapa nya informationsmängder.
Alla API:er kommer inte att vara publika, naturligtvis. Vissa kommer att kräva identifikation och speciell access. Men det spelar ingen roll. När vi väl har ställt om till en informationsinfrastruktur som bygger på dessa principer kommer vi aldrig att vilja gå tillbaka till en elektronisk variant av brevduvan.
Och vet ni vad det bästa är? Denna förändring kan ske gradvis, från relation till relation. Vi kan alltså fånga fördelarna redan från scratch. För avsändarna blir detta en stor förändring som kommer att spara pengar. För de fd mottagarna(numera prenumeranterna) handlar det om att bygga om redan befintliga mottagningssystem så att de kan hantera en dataström som kanske behöver filtreras, men som också ger fantastiska möjligheter till bra beslutsunderlag och ett inflöde av relevant information. Information som skulle kunna kombineras med flera andra datakällor, till och med i realtid. Allt utan att någon av avsändarna behöver tillfrågas först!
Jag kommer att fortsätta fundera på dessa koncept och kanske, kanske kommer ytterligare inlägg lite längre fram. Tills dess, kommentera gärna nedan!
0
Du bör nog sätta dig in i det här, för det är det som löser ditt problem:
http://en.wikipedia.org/wiki/Service-oriented_architecture
Jag känner till SOA och det är inte riktigt det jag menar, även om det är besläktat. Det finns inget dubbelriktat över dataströmmarna som jag föreslår (förutom eventuell en autentisiering). Ingen ”service” alltså, utan snarare en ”outlet”.
Då har du nog inte riktigt satt dig in i hur SOA fungerar på den praktiska nivån. Har varit med och implementerat flera lösningar där vissa i informationskedjan bara har det du kallar för ”outlet”, andra har ”services” med full och hårdare integration och några har om vi låter oss kalla det för ”inlet”.
Och det finns ingen väg ur eller runt ”slutar prata om meddelanden som har förutbestämda utseenden och innehåll” det finns inget informationslogiskt sätt att komma runt det, det tror jag du inser. En hope siffror och bokstäver i en dataström säger ju ingenting 🙂
Om du kikar på hur en ESB (Enterprise Service Bus) fungerar, så kan man som outlet exponera en web service, utan att fundera på vem som använder den, beroende på hur du exponerar den. Du kan exponera en J2EE komponent, ja eg. nästab ”vad som helst”.
Tror det är viktigare att diskutera varför och hur man exponerar sina dataströmmar, snarare än att via teknik t.ex. API:er försöka styra. Tror du tänker att just API:er skapar frihet och det andra låsning. Men det är standarden på information och dess struktur som skapar de enda rimliga förutsättningarna.
Kolla på t.ex. http://www.progress.com/en/sonic/sonic-esb.html med den bygger vi lösningar som varken är outlets, services eller inlets (påhittad terminologi baserat på ditt resonemang) utan faktiskt alla tre i olika kombinationer. En del hårdkodat, annat som löses med färdiga adapters, något via API:er osv osv. Det enda som är navet är tydlig informationsstruktur, men allt är relativt öppet exponerat. Om du dessutom studerar Facebook och Twitter, så kommer du ganska snart fram till att för att åstadkomma ”informationsstruktur” så har det skapats en massa metainformation, t.ex. hashtags, @ tecknet används specifikt, RT på Twitter osv osv. Prova att skriva meddelanden utan dessa metamöjligheter….
Håller helt med dig om att det viktiga är att diskutera principer före teknik. Och det är precis det jag försöker göra i inlägget. Jag menar att principen borde vara att i möjligaste mån enbart publicera data (vilken teknik som väljs är egentligen ointressant så länge den fungerar).
Vad gäller ”meddelanden som har förutbestämda utseenden och innehåll” menar jag att själva ordet ”meddelande” implicerar att det finns en avsändare och en mottagare som (av praktiska skäl) har kommit överens om exakt hur meddelandet skall se ut. Det är här många standardiseringsinitiativ fokuserar idag. Om man skrotar begreppet meddelande och istället ensidigt publicerar en dataström som dokumenteras upp av den som sänder behöver inte prenumeranten och den som sänder komma överens annat än om enkla accessfrågor. Prenumeranten tolkar dataströmmen utifrån dokumentationen men det sker ingen egentlig dubbelriktad integration.
Metainformationen är naturligtvis något som också får dokumenteras upp för varje dataström. Och här kan jag tänka mig att en standardisering skulle kunna funka.