Sex vanliga frågor om Integrations- och IoT-plattformar

Vilken roll har en plattform i en IoT-arkitektur

IoT omfattar många olika områden och så kallade vertikaler (sjukvård, transport, kontor, byggnad, stad och så vidare). De allra flesta IoT-lösningar består lite förenklat av de fyra lager (se bild). Nedifrån och upp är dessa:

1. Datainsamling via devices och sensorer. I många fall slangar man även in öppna datakällor eller befintliga affärssystem, från Excel-ark eller annan källa. En device kan också vara en styrbar aktuator, exempelvis ett lås eller en lampa.
2. Någon form av (ofta trådlös) nätverksinfrastruktur för att föra över data.
3. En plattform där data sparas, analyseras och där man kan hantera och konfigurera sina devices.
4. Applikations- eller effektlager (dashboards, mobil app, en integration till ett verksamhets- eller ERP-system, maskininlärning eller vad som helst).

Kan IoT-plattformar göra något mer än bara samla in data?

Bortsett från de basala funktioner som beskrevs ovan kan många IoT-plattformar göra en massa andra saker. Några exempel:

• Spara, normalisera och filtrera data.
• Representera datakällor och objekt/byggnader/personer/etc. i olika typer av objektmodeller.
• Analysera och bygga logik mellan objekten i dessa modeller via regelmotorer för att automatisera flöden och skapa alarm/events.
• Presentera data i dashboards, kartor eller skräddarsydda widgets. Ett exempel från ett av våra projekt hittar du här.
• Publicera data via (öppna eller industrispecifika) Application Programming Interfaces (APIer eller gränssnitt).
• Utföra Device Management (uppgraderingar, konfiguration etc.) av sensorer, devices och gateways.
• Managera och monitorera trådlösa accessnät, SIM-kort och abonnemang.
• Utföra mer kognitiva funktioner som bild- och röstigenkänning, maskininlärning och artificiell intelligens baserat på insamlade data.
• Erbjuda multi-tenancy-support. Detta handlar om kontroll över vem som får logga in i plattformen och vem som kan se/ändra/konsumera data.
• Autogenerera rapporter.
• Hantera olika nivåer av säkerhet.
• Erbjuda fakturering och hantering av kundkonton.
• Skicka notifikationer via t.ex. SMS eller mejl.

Det finns många plattformar. Varför är landskapet så rörigt?

En del plattformar innehåller många av funktionerna som beskrivs ovan fast för en väldigt specifik vertikal (exempelvis ett system för spårning av rullstolar på ett sjukhus eller en smart office-lösning), en del fokuserar på att hantera bara något eller några av områdena, en del hanterar bara nätverksuppkoppling medan andra plattformar egentligen bara är väldigt kapabla Lego-lådor med delar som man kan bygga plattformar av. En del plattformar supportar industrispecifika protokoll som till exempel FIWARE, Continua eller FHIR.

De flesta plattformar är skapade för en vertikal (se nedan). Alla plattformstyper kommer med någon form av ekosystem som kan utvecklas över tid. Plattformar blandas oftast ihop (medvetet eller omedvetet) vilket gör det svårt att förstå vad man faktiskt jämför. De flesta plattformar beskrivs som ”öppna” men detta är en definitionsfråga eftersom innovationsprojekt och utveckling och underhåll av APIer, integrationer, visualisering och mycket annat är processer som kräver underhåll och utveckling, ofta av plattformsleverantören.

Vad är en ”vertikal plattform”?

De fasta och mobila versionerna av Internet drevs fram av standarder. Internet of Things har varit helt applikationsdrivet och alla lösningar och i princip alla plattformar är därför också skapade för specifika syften. Det kan handla om optimering av en industriell process, ett hemlarmsystem, spårning av utrustning eller disruption av taxiindustrin. Vi kallar dessa plattformar ”vertikala” eftersom de adresserar specifika användningsområden eller vertikaler. Ofta kommer en vertikal plattform med industrispecifika integrationer som ofta följer GDPR-krav och andra lagar och regler.

En vertikal plattform har ett väldefinierat ekosystem av supportade devices, sensorer och gateways, normalt från vissa specifika tillverkare. Dessa plattformar är sällan ihopkopplade med andra vertikaler, så IoT innebär i de allra flesta fall ”Intranet of Things”. Någons bil kan exempelvis inte prata med någon annans brödrost eller hemlarm eller med en robot i Volvos produktionslina, utan de flesta tjänster är paketerade i egna, isolerade bubblor. Eftersom det inte finns några förankrade, utbredda öppna standarder för device management kan det bli tidsödande att lägga till nya devices till en vertikal plattform.

Att integrera olika vertikala plattformar mot varandra blir ofta exponentiellt komplext. Varje ny plattform behöver kopplas ihop manuellt med alla andra vertikallösningar. Det är i det läget kommuner, landsting och många företag är i just nu med sina verksamhetssystem (inte bara för IoT). I figuren ser vi tre ihopkopplade vertikala plattformar (en IoT, två verksamhetssystem). Pilarna mellan dessa lådor representeras inom de flesta verksamheter oftast av antingen hundratals konsulttimmar eller av en människa med ett Excelark. Komplexiteten blir exponentiell och dödar innovationskraften.

När man väljer en vertikal lösning är det väldigt viktigt att man definierar det önskade API-stödet. Här är det avgörande att man inte bara kan läsa ut data, utan även skicka in data till vertikalen. Ett enkelt exempel är ett system för gatubelysning där man inte bara vill få information om en lampa lyser eller om den är trasig utan även tända, släcka och dimma ljuset via konfiguration.

Om du arbetar i en kommun eller på inom ett landsting så är specifikation av den här typen av API-support antagligen den viktigaste frågan att se över inför kommande upphandlingar. Missar man detta kommer man sitta under hela avskrivningstiden utan att kunna koppla ihop systemen med varandra. API-supporten är viktigare än att faktiskt kunna koppla upp saker och egentligen mycket mer avgörande än plattformsvalet i sig.

Jag har hört talas om horisontella plattformar. Vad är det?

Den huvudsakliga uppgiften för en horisontell plattform (ibland kallad integrationsplattform) är att aggregera och korskoppla vertikaler och med det även möjliggöra att gemensamma data kan analyseras och delas mellan system och till externa intressenter på ett skalbart och säkert sätt.

Bilden nedan är en konceptuell högnivåskiss av en horisontell plattform. Eftersom varje vertikal endast behöver bygga en enda integration (mot horisontalen) skalar man linjärt när man lägger till nya system, och plötsligt är det både möjligt att innovera och skapa effekt som baseras på data från olika källor.

Horisontella plattformar används ofta för att aggregera data mellan olika vertikaler inom Smarta Städer, Smarta Byggnader samt inom Hälso- och Sjukvård. Syftet är inte bara att erbjuda ett applikationslager möjlighet att hämta ut data på ett standardiserat och skalbart sätt, utan även att kunna bygga logik mellan data från olika verksamhetsgrenar. Genom att frikoppla de olika lagren (device/nätverk/plattform/applikation) från varandra med tydliga API-gränssnitt säkerställer man också att både vertikallösningar och själva plattformen kan bytas ut över tid om något bättre skulle dyka upp.

En korrekt byggd horisontell plattform är själva fundamentet för en skalbar plattformsekonomi som kan skapa enorma värden för en kommun, ett företag eller ett helt land. Ett bra exempel är det blockkedjebaserade e-hälsosystemet X-Road i Estland.

Ska jag välja en horisontell eller vertikal plattform när jag kör igång?

Det är vanligt att man lockas eller är tvungen att använda en vertikal plattform när man sparkar igång sina IoT-projekt. Rent generellt ska man akta sig för vertikala modeller där vertikalvärdet inte är tillräckligt stort för att motivera det vägvalet. Ett bra exempel på vertikal plattform är ett körjournalsystem där fordonsflottan bestyckas med GPS-enheter och där man samlar in data i syfte att underlätta reserapportering och planering. Dessa lösningar levereras ofta som en vertikal med egen plattform där integrationer är gjorda mot företagets/kommunens Active Directory (AD), reserapporteringssystem, kanske ett planerings- eller CRM-system och en app som de anställda använder för att rapportera resorna i. Biltullar inkluderas automatiskt Andra exempel är vertikaler som kommer med olika lagkrav eller industrispecifika integrationer. Plattformar inom välfärdsteknologi och hemsjukvård är några exempel.

Om man däremot vill samla in miljödata, badvattentemperatur eller andra basala mätvärden som ska användas för att tillgängliggöra eller analysera information bör man istället arbeta med en horisontell plattform där dessa integrationer och applikationer kan hanteras ”gratis” utan löpande månadskostnader per device. Dessa plattformar bör man också kunna utveckla själv i och det ska gå snabbt och enkelt att både hämta in och visualisera data och att koppla ihop olika källor.

Bilden nedan visar hur ett sånt innovationsprojekt kan se ut hos ett energibolag. Vattenmätardata samlas automatiskt in till en horisontell plattform och visualiseras (minskad manuell hantering och ökad insikt). Samtidigt byggs en integration mot det affärssystem som hanterar kunder och mätardata (minskad manuell hantering). Man matar även detta data till en AI som hjälper till att reducera antalet avvikelser som normalt måste hanteras manuellt (minskad hantering). Slutligen kopplas externa källor av data in för att förbättra AI-algoritmen (bättre precision och minskad hantering). Ett sånt här projekt handlar till 90% om verksamhetsanalys och 10% implementation, och då är det kritiskt att den plattform man valt går att jobba snabbt i.

Slutligen, vilken plattform är bäst?

Jag hoppas att punkterna ovan har förklarat att olika plattformar kan vara bra för olika saker och att det inte finns någon universallösning som fixar allt på en gång. En del vertikala plattformar gör sin grej på ett så pass bra sätt att man kan vara tvungen att använda dem. En del horisontaler passar inte din verksamhet.

Det finns ett par generella tips som man kan tänka på när man navigerar sig i plattformsdjungeln.

1. Försök att abstrahera de fyra lager som beskrevs i inledningen av denna artikel. Helst ska man kunna byta ut vilket lager som helst över tid utan att de andra lagren påverkas. Nyckeln till att kunna göra detta stavas: tydliga API-definitioner inom hela verksamheten.
2. Väldigt mycket händer på open source-scenen där hemautomation var först ut genom att erbjuda open source-baserade horisontella plattformar som Home Assistant där man i dag kan koppla ihop allt från Alexa och Ikea Trådfri till Spotify utan att behöva koda ett enda API själv. Om man är intresserad av detta område kan jag rekommendera den här bloggen. Samma utveckling håller på att ske inom många andra vertikaler. Man kan jämföra det med hur webbsidor utvecklats. För 10-15 år sen fick man koda HTML själv. I dag bygger man en enkel hemsida genom att klicka och dra.
3. Om du jobbar inom området Internet of Things, börja alltid med att lägga den tid som behövs för att förstå den verksamhet som IoT-lösningarna ska hjälpa. I den fasen ska man inte utgå från att svaret är "IoT". Det kan vara "processförändring", "kollaboration" eller något helt annat. Man vill alltså ta hjälp av någon med en stor verktygslåda och verksamhetskompetens när man gör sin analys. Det absolut vanligaste misstaget som görs inom IoT är att många börjar med tekniken. Lär dig verksamheten och de system som finns i dag. Lägg tid på att förstå ”kundresan”, oavsett om din ”kund” är en patient, en medborgare eller någon som ska köpa dina produkter. Du kommer upptäcka att det data du tror du ska samla in redan finns i något system eller att lösningen på din utmaning inte alls är IoT utan kanske något helt annat.

Om du har frågor eller är nyfiken på IoT, automation eller plattformar delar vi på Atea gärna med oss av oberoende omvärldsanalys inom området. Vi jobbar inom alla typer av vertikaler och har bra koll på landskapet, ekosystemen och trenderna. Hör av dig så sätter vi upp ett möte!