Vi som nu jobbat rätt länge inom IT har under många år arbetat med att samla ihop data från persondatorns intåg på företagen där man lagrade data på disketter och hårddiskar. Vi gav företagen nätverk och filservrar, databaser och lång senare SaaS-lösningar åtkomliga från var som helst. Redan med de centrala databaserna, minidatorsystemen som öppnades upp och möjligheten med Business Intelligence där man kunde sammanstråla företagets data så det gick att arbeta datadrivet med riktigt beslutsstöd. Ledarna från den tiden valde trots data ändå att gå mycket på magkänslan snarare än fakta.
Nu är vi trygga i att data finns när du behöver den var du än är och du kan alltid hitta rätt information när som helst om du vet var du ska söka efter den. Eller vad var det precis som hände?
Om du har informationen men inte hittar den
När vi började bygga lösningar för att samla ihop den ostrukturerade informationen och koppla den till data i affärssystemen behövde vi ett system där man kunde arbeta med en flexibel datamodell där man i en och samma applikation kunde lösa företagens behov även om de såg olika ut med ett fokus på att att samla information från disketter, hårddiskar, lokala nätverk och reklambyråer till en central plats där en version av sanningen kunde distribueras ut i som helhet till alla som behövde den.
Vi letade efter standardsystem att bygga denna lösning på och min kollega Johan hittade några olika alternativ och vi testade dem men inget av dem var tillräckligt mogna så vi tappade hoppet tills vi hittade på en av lösningarna från IBM som heter IBM DB2 Content Manager som just var på väg att släppas i version 8 och erbjöd denna flexibla datamodell som vi skulle kunna bygga vidare på.
Vi träffade på många kloka människor på IBM i både Sverige och utomlands, men ett citat från Ulf Knutsson på IBM som jag bär med mig än idag “Om du har informationen men inte hittar den så har du den inte” och just detta har sedan introduktionen av verktyg där alla kan skapa lösningar blivit mer aktuellt än någonsin igen.
Likheterna med Visual Basic för vad som händer
I mitten av 1990-talet knuffades gränsen för vem som kunde bygga applikationer när Visual Basic nådde version 3 och vem som helst kunde koppla upp den till en databas i MS Access eller en SQL-databas från Oracle. Man kunde också bygga fantastiska applikationer i MS Access utan att vara utvecklare.
Vi såg Client-Server växa fram där data flyttade från persondatorerna in på servrarna på riktigt. Det var krångligt att leverera, svårt att koppla upp med drivers mot databasen och ett helt orimligt svårt problem att kunna ändra databasschemat samtidigt som man uppdaterade applikationen hos alla användare.
Datat flyttade in i serverhallen och det blev möjligt att samla ihop data för beslutsstöd.
Molnet är någon annans dator
Vad det där har för relevans i dag med all molnlagring kan man ju undra. Molnet är ju egentligen bara någon annans dator, och vi litar på att den som sköter lösningen har full koll på hur vår data hanteras, att den är säker, att det finns säkerhetskopior och en plan för återskapande om något skulle gå fel, och att min information inte lämnas ut till tredjepart utan mitt medgivande. Men då kommer jag att tänka på att det inte längre är som på 90-talet, då det fanns en central filserver, några centrala databasservrar och allt annat nere i serverhallen, där en bandrobot skrev ner dagliga säkerhetskopior som samlades ihop på en central backupserver. Även om mitt data kunde ligga på någon av de väldigt många servrarna i datorhallen så fanns den ändå där någonstans. Så är det inte längre, för när vi ansluter oss till en tjänst på nätet och köper en prenumeration hos en leverantör så förutsätter vi att de har koll på att vår data är lika säker som när vi hanterade den i källaren i vår lokala serverhall.
Risken gick att räkna på
Nu vet vi ju av praktiken att när man väl behövde återskapa något från band så var det inte helt okomplicerat. Hade man drabbats av åsknedslag, stöld eller brand var risken övervägande att det data som inte lagrades på sajten var flera veckor gammalt, om det alls fanns. Så jag påstår inte att det var säkrare förut, men vi kunde beräkna risken, sätta en siffra på den och en kostnad för att finna en lösning på den.
Vad de etablerade leverantörerna löst
De SaaS-leverantörer som funnits på marknaden en tid har ofta en bra lösning på det här. De kan tala om i vilket moln mitt data är lagrat, det finns en plan för disaster recovery, och man kan hitta ett trust-center där de genomgått kontroller för att uppfylla de krav som större kunder ställer. Där finns oftast också ett rätt kontrollerat sätt att exportera sitt eget data på, om man skulle välja att byta leverantör.
Här har flera av de nya verktyg för att skapa applikationer med AI löst datalagring och krav med bra infrastruktur och integrationer.
Skiftet som pågår nu
Skiftet som händer nu är att alla kan skapa system med hjälp av AI och bygga lösningar som ser väldigt trovärdiga ut och som fungerar rätt bra. Den som vill skapa något kan numera göra det på ett sätt som aldrig tidigare varit möjligt, och det här är inte något som kommer att gå att stoppa, utan något vi behöver anpassa oss till som en del av den nya verklighet vi ska fungera i. Vi kommer också se många fler system i bruk, och i varje system finns det data, användarprofiler, behörigheter och funktioner som inte längre delar en gemensam inloggning, eller där man inte direkt kan svara på i vilket land min data ligger lagrad.
Och det är egentligen här jag vill komma in, för distribuerad databehandling, distributed computing, har aldrig behövt betyda att man distribuerar ut sin data så pass att man inte längre vet var den finns. Att låta tjänster och beräkningar ligga utspridda är en sak, men att tappa reda på var själva datan bor är en annan, och de två har på något vis kommit att betyda samma sak för oss.
Öar eller en del av helheten
Man har oftast rätt bra koll på kärnan i sitt data i grundform, den som kommer från den transaktionella datan. Det man i stället spritt ut är de underlag som sedan påverkar hur bra det fungerar, och det är där det blir lite lurigt, för i sitt ERP kan man se en förbättring eller en försämring utan att komma åt orsakerna till varför. Man kanske har lagt ut en del av CRM-funktionen på ett nytt system som inte är integrerat och som gör själva flödet effektivt, men som samtidigt isolerar datan så att den blir en effektiv men öde ö.
Det jag vill landa i är att man behöver tänka på var min data hamnar, hur jag säkerställer att den grunddata den bygger på är aktuell, och att varje system jag lägger till blir en del av helheten snarare än separata öar. Tröttnar man sedan på att förvalta ett system man själv skapat, tröttnar den man köpt systemet av, eller hittar man ett annat system, så behöver man ha koll på sin data och äga den. Det här med att man kan bygga egna system, och att verksamheten kan fixa ett bättre stödsystem själva, är en del av den framtid vi ser redan i dag, men vi måste ta ett eget ägarskap över vår data. För utan jämförbar data som vi kan analysera faller det datadrivna sättet att leda företag långsamt tillbaka mot beslut fattade på felaktig eller saknad data, vilket på lång sikt skapar obalans. Tar vi med oss tanken att datan vi berikar och jobbar med är viktig för företaget, så behöver den också vara en del av företagets samlade data, hålla rätt kvalité, skyddas så att bara rätt personer kommer åt den, och gå att dela med de andra system som behöver den.
Det finns lösningar för detta även med det moderna sättet att bygga! Man måste inte kopiera data, man kan använda data man kan lita på. Man måste bara veta om att den finns och att det är ett sätt att lösa det på.
Det här är mer en riktning jag ser än en färdig sanning, så har du egna tankar om hur man håller ihop sin data när systemen blir fler, lämna gärna en kommentar.
