I den föregående artikeln analyserades olika metaobjekt i Prime Arch för att identifiera vilken som lämpar sig bäst för informationsklassificering. Analysen visade att artefakten (I42) är det mest ändamålsenliga metaobjektet att använda. Den är tillräckligt konkret för att fånga informations behov av skydd utan att vara för detaljerad. Den ger dessutom möjlighet att fånga hur kravet på skydd varierar i olika faser.

En annan viktig del i arbete med informationsklassificering är arkivredovisning, vilket är ett styr- och sökinstrument till en organisations hela handlingsbestånd (MSB, 2012). Det handlar alltså om att kunna söka på olika handlingar, ta del av informationsklassificering och få en beskrivning av processers genomförande och dess informations förvar. Det är med andra ord viktigt att kunna beskriva hur och var en informationsmängd hanteras och lagras.

Kan artefakten lagras?

Eftersom atrefakten är en representation av något och eftersom den tillhör informationsdimensionen, är det lätt att tänka att artefakter inte kan lagras. Men det är egentligen just det som gör den så lämplig. 

Artefakten representerar ju ett påtagligt, konkret föremål i verksamheten och har bevisats hålla för att tilldela egenskaper som klassificering och status. Den kan också utgöra grund för att representera hanteringsregler och således också föredragna lagringsplatser.

Genom att använda artefakten kan vi uttrycka hur en viss typ av handling eller föremål ska hanteras, inte var den de facto råkar lagras just nu. Vi kan säga att det som artefakten representerar vanligtvis ska hanteras på ett visst sätt eller förvaras på ett annat. Det gör artefakten särskilt värdefull i arbeten som syftar till att definiera principer för lagring, skydd och åtkomst av information utifrån informationsklassificering. Dessutom kan artefakten innehålla information om status vilket gör det möjligt att beskriva hur behovet av hantering och lagring förändras i takt med att en informationsmängd utvecklas.

Vad innebär egentligen lagring?

Det är lätt att anta att detta enbart handlar om digital lagring i IT-system, men i praktiken är verkligheten ofta mer komplex. 
 
I vissa fall kan informationen exempelvis behöva sparas i ett specifikt dokumenthanteringsskåp, arkiveras i en fysisk mapp i ett arkivskåp, hanteras i en SharePoint-struktur, bevaras på ett visst våningsplan eller också behöva flyttas till en helt annan plats (exempelvis Riksarkivet i Uppsala). 
 
Det betyder att lagringsplatsen kan vara ett system men också en fysisk plats, en mappstruktur eller en arkivinrättning. För att fånga detta behöver vi ha ett sätt att hantera att artefakten inte enbart pekar mot en applikation, utan även kan relatera till andra typer av lagrings- och hanteringsobjekt. 

Metaobjektet "Plats" (X10)

Ett metaobjekt som kan hantera detta är Plats (X10).

 

Plats (X10) kan användas för att beteckna allt från geografiska områden, som Sverige och Östhammar, till byggnader eller enheter, så som kommunhuset och slutförvaret i Forsmark. Det kan även representera kontor, våningsplan eller specifika fysiska arkiv. Eftersom objektet representerar en konceptuell punkt kan det också användas för att representera strukturer i digitala miljöer, såsom mappstrukturer i SharePoint eller ett system.​​

En artefakt kan relateras till en plats med relationen ”relaterar till”. Vidare kan en applikationsmodul i sin tur relateras till samma plats, genom relationen ”realiserar”. På så vis ges möjlighet att visa hur en specifik applikation, just nu, är den aktuella realiseringen av (lagrings)platsen. Om applikationen byts ut i framtiden behöver inte modellens strukturella logik förändras. Platsen finns i så fall fortfarande kvar men realiseringen kan förändras.​

Genom att använda objekttypen Plats kan vi således både modellera fysiska, konceptuella och digitala lagringsplatser.​

Obs! Platsobjektet återfinns faktiskt i flera marknadsledande EA-ramverk, såsom Archimate, TOGAF, ARIS och Zachman.