I denna artikel används exemplet med Loka-flaskan för att förklara skillnaden mellan verklighet, information och data.
Prime Arch bygger på standarder, och för begrepp används ofta Nationalencyklopedin, NE.se. I artikeln "Ett annat perspektiv på Information och Data" förklaras definitionerna bakom information och data, och denna artikeln bygger vidare på dessa. Enkelt uttryckt definieras begreppen så här:
Som pilarna visar definieras information med referens till verkligheten, och data definieras på motsvarande sätt genom referens till information.
I denna artikel kommer vi att undersöka dessa tre begrepp genom att analysera vilka metaobjekt som används och hur dessa relateras till varandra.
Låt oss ta ett konkret exempel:
En Loka-flaska är ett verkligt ting. Den går att ta på och tappar man den på foten gör det ont. Loka-flaskan har en rad olika egenskaper: För producenten så kan den förpackas, transporteras, placeras i lager och säljas till konsument.
För konsumenten så kostar och väger den en del, men förhoppningsvis uppvägs dessa nackdelar genom att den smakar gott och läskar strupen.
I verksamhetsarkitektur används processdimensionen för att beskriva aktiviteter såsom "packa vara" och "transportera vara". Resultatet av en Process (P31) representeras av Verksamhetsobjektet (I32) som tillhör informationsdimensionen.
Processer "har output" verksamhetsobjekt, och i exemplet med Loka-flaskan så är resultatet från processen "Buteljera dryck" rimligen "buteljerad dryck", eller som vi valt att kalla det i detta exempel: Loka-flaska.
Nu vet vi att verksamhetsobjektet representerar ett verkligt ting. Men vad behöver vi informationsobjektet till?
Informationsobjektet representerar "information om ett verkligt ting", i det här fallet informationen om Loka-flaskan. Metaobjektet "Informationsobjekt" (I31) sägs vara en "logisk representation av" verksamhetsobjektet (I31).
Det finns en massa att veta om ett verkligt ting som en Loka-flaska:
- Var är den tillverkad?
- Vem har tillverkat den?
- När tillverkades den?
- Hur långt har den transporterats från fabrik?
- Vilket koldioxidavtryck lämnar den?
- Var befinner sig den nu?
- Vem äger den?
Listan över frågor kan göras lång, men för att utveckla en verksamhet är inte all information relevant. Antag att en verksamhetsutvecklare behöver veta mer om produkten avseende dess innehåll och näringsvärde. Då skulle informationsobjektet definieras som "Produktinformation" och beskrivas med den information och de egenskaper/attribut som är relevanta för att arbeta med problemet.
Informationsobjektet (I31) är således en slags logisk konstruktion för att beskriva och kravställa vilken information som behövs. Men information, på samma sätt som verksamhetsobjekt, uppstår inte ur tomma intet.
I verksamhetsarkitekturen används Verksamhetsfunktionen (F32) för att representera det som krävs för att information ska uppstå. Verksamhetsfunktionen (på engelska "Business Function") tillhör förmågedimensionen och representerar "en gruppering av logiskt relaterade uppgifter som krävs för att producera ett resultat". För mer information om detta, läs artikeln om Morotsmaskinen.
Nu när vi har koll på skillnaden mellan (och vikten av att kunna sklija på) verksamhetsobjekt och informationsobjekt kan vi ställa oss frågan: "Vad har Dataobjektet med detta att göra?"
En hel del visar det sig. Data är "implementationen av informationen om ett verkligt ting".
I vårt exempel så har vi Loka-flaskan som existerar i den verkliga världen, och produktinformationen som vi kravställer på att kunna använda. För att kunna använda informationen i vår digitaliserade värld behöver informationen implementeras i ett IT-system (i Prime Arch representeras detta av A21 Applikation) och då blir det i form av data.
Objektet som "realiserar" informationsobjektet (I31) är Dataobjektet (D41).
Vanligen används standardsystem för att stödja verksamhetens processer då det är ofta både onödigt komplicerat och dyrt att utveckla egna IT-lösningar.
I vårt påhittade exempel har verksamheten köpt in ett standardsystem från en amerikansk tillverkare. Då leverantören använder engelsktalande utvecklare som utvecklat programvaran för en internationell marknad så är den underliggande datamodellen i systemet på engelska och mycket som användarna ser har engelska datatermer.
På en fråga till leverantörens lösningsarkitekt om vilken information systemet tillhandahåller om produktens innehåll och näringsvärde blir svaret "Product Data" som specificeras med termer som "Ingedient" och "Nutrition".
Applikationsmodulen (A31) som ingår i standardsystemet "skickar" dataobjekt (D41) till andra applikationsmoduler som integrerats.
Nu har vi allt på plats för att studera den avgränsade metamodellen som beskriver hur verksamhetsobjekt, informationsobjekt och dataobjekt hänger ihop och varifrån de uppstår.
Många ramverk behandlar information och data synonymt, och även de som skiljer på dessa koncept har in lite förenklad bild av dessa koncept. För den som är intresserad av en fördjupande analys i ämnet, se artikeln: Information i relation till Data - en jämförande analys av Archimate+UML och Prime Arch.
Länkar:
Artiklar
- Ett annat perspektiv på Information och Data
- Skillnad på Data och Information
- Morotsmaskinen
- Information i relation till Data - en jämförande analys av Archimate+UML och Prime Arch