Dataarkitektur

Dataarkitektur er modellene, retningslinjene, reglene og standardene som styrer hvilke data som samles inn og hvordan de lagres, ordnes, integreres og tas i bruk i datasystemer og organisasjoner. Data er vanligvis ett av flere arkitekturdomener som danner grunnpilarene i en virksomhetsarkitektur eller løsningsarkitektur.

Oversikt

En dataarkitektur har som mål å få laget datastandarder for alle sine datasystemer, enten som en visjon eller modell av de fremtidige interaksjonene mellom disse datasystemene. For eksempel bør dataintegrasjon avhenge av standarder for dataarkitektur, ettersom dataintegrasjon krever datainteraksjoner mellom to eller flere datasystemer. En dataarkitektur beskriver delvis datastrukturene som brukes av en virksomhet og applikasjonsprogramvaren på deres datamaskiner. Dataarkitekturen retter seg mot data som er lagret, data som er i bruk, og data i bevegelse, samt beskrivelser av datalagre, datagrupper og dataelementer, og kartlegging av disse dataartefaktene til datakvaliteter, applikasjoner, lokasjoner, og så videre.

For å oppnå måltilstanden beskriver dataarkitekturen hvordan data prosesseres, lagres og brukes i et informasjonssystem. Dataarkitekturen gir kriterier for dataprosesserings-operasjoner for å gjøre det mulig å designe dataflyter og kontrollere flyten av data i systemet.

En dataarkitekt er vanligvis ansvarlig for å definere en måltilstand, stå for samkjøring under utvikling og deretter følge opp for å sikre at forbedringer blir gjort i tråd med ånden til den opprinnelige løsningsskissen.

Når man skal definere måltilstanden søker dataarkitekturen å bryte et emne ned til "atomisk" nivå, og bygger det deretter opp igjen til ønsket form. Dataarkitekten bryter emnet ned ved å gå gjennom de tre tradisjonelle arkitektoniske stadiene:

• Konseptuelt: Representerer alle forretningsobjekt
• Logisk: Representerer logikken for hvordan enheter er relatert.
• Fysisk: Realiseringen av datamekanismer for å oppnå en bestemt type funksjonalitet.

I datakolonnen i Zachman-rammeverket for virksomhetsarkitektur finner man følgende:

Lag	Perspektiv	Data ( «hva»)	Interessent
1	Omfang / kontekstuell	Liste over ting og arkitektoniske standarder som er viktige for bransjen	Planlegger
2	Forretningsmodell / konseptuell	Semantisk modell eller konseptuell/virksomhets-datamodell	Eier
3	Systemmodell / logisk	Virksomhets/logisk datamodell	Design
4	Teknisk modell / fysisk	Fysisk datamodell	Bygger
5	Detaljerte representasjoner	Faktisk database	Utvikler

I en annen og bredere forstand inkluderer dataarkitektur også en komplett analyse av relasjonene mellom en organisasjons funksjoner, tilgjengelig teknologi og datatyper.

En dataarkitektur bør defineres i planleggingsfasen av utformingen av et nytt dataprosesserings- og lagringssystem. Hovedtyper og -kilder av data som er nødvendige for å støtte virksomheten bør identifiseres på en måte som er fullstendig, konsekvent og forståelig. Det primære kravet på dette stadiet er å definere alle relevante dataenheter, og ikke å spesifisere maskinvare. En dataenhet er en enhver relle eller abstrakt ting som en organisasjon eller enkeltperson ønsker å lagre data om.

Fysisk dataarkitektur

Den fysiske dataarkitekturen for et informasjonssystem er en del av en teknologiplan. Teknologiplanen fokuserer på de faktiske håndgripelige elementene skal skal brukes i implementeringen av dataarkitekturdesignet. Fysisk dataarkitektur omfatter databasearkitektur. Databasearkitekturen utgjør en konseptuell modell av den faktiske databaseteknologien som vil understøtte den designede dataarkitekturen.

Elementer i en dataarkitektur

Enkelte elementer må defineres i designfasen av dataarkitekturen. For eksempel må man beskrive en administrativ struktur som skal etableres for å administrere dataressursene. I tillegg må metodene som skal brukes for å lagre dataene defineres, og det må genereres en beskrivelse av databaseteknologien som skal benyttes, samt en beskrivelse av prosessene som skal manipulere dataene. Det er også viktig å designe grensesnitt til dataene fra andre systemer, samt et design for infrastruktur som skal støtte vanlige dataoperasjoner (som nødprosedyrer, dataimport, sikkerhetskopiering, ekstern overføring av data).

Uten føringer fra et velimplementert dataarkitekturdesign kan vanlige dataoperasjoner bli implementert på forskjellige måter, hvilket vil gjøre det vanskelig å forstå og kontrollere dataflyter innenfor disse systemene. Slik fragmentering er uønsket på grunn av potensial for økte kostnader og datautkoblinger. Slike utfordringer kan for eksempel oppstå i raskt voksende bedrifter eller bedrifter som har mange ulike avdelinger

En riktig utført dataarkitekturfase som en del av planleggingen av et informasjonssystem vil tvinge organisasjonen til å spesifisere og beskrive både interne og eksterne informasjonsflyter. Dette kan være mønstre som organisasjonen ikke tidligere har tatt seg tid til å konseptualisere, og det kan derfor på dette tidspunktet være mulig å identifisere kostbare informasjonsmangler, dårlige koblinger mellom avdelinger, og dårlige koblinger mellom systemer i organisasjonen som kanskje ikke har vært tydelige før dataarkitekturanalysen.

Begrensninger og påvirkninger

Ulike begrensninger og påvirkninger vil ha en effekt på dataarkitekturdesignet. Disse inkluderer krav fra virksomheten, teknologidrivere, økonomi, forretningspolicyer og dataprosesseringsbehov.

Virksomhetens krav

Disse kan inkludere økonomisk og effektiv utvidelse av systemet, akseptable ytelsesnivåer (særlig aksesseringshastighet), pålitelige transaksjoner og transparent dataforvaltning. Andre vanlige organisatoriske krav er konvertering av rådata som for eksempel transaksjonoppføringer og bildefiler til mer nyttig informasjonstyper via funksjoner som datavarehus, ettersom dette muliggjør bedre beslutningsprosesser hos ledelsen og legger grunnlag for andre organisatoriske prosesser. En av arkitekturteknikkene er oppdelingen mellom å håndtere transaksjonsdata, referansedata og grunndata. En annen er å splitte systemer for dataoppfanging fra systemer for datainnhenting (som man gjør i et datavarehus).

Teknologidrivere

Disse vil ofte foreligge naturlig i lys av den ferdige dataarkitekturen og databasearkitektur-designet. I tillegg vil noen teknologidrivere komme fra eksisterende integrasjonsrammeverk og standarder i organisasjon, og organisasjons økonomi og eksisterende ressurser vil spille inn (for eksempel tidligere kjøpte programvarelisenser). I mange tilfeller krever integrering av mange eldre systemer bruk av teknologi for datavirtualisering.

Økonomi

Økonomi er en viktig faktorer som må vurderes i dataarkitekturfasen, og det er mulig at noen løsninger ikke er potensielle kandidater på grunn av kostnadene, selv om de i prinsippet kanskje er optimale. Eksterne faktorer som konjunkturer, renter, markedsforhold og juridiske hensyn kan påvirke beslutningene utformingen av dataarkitekturen.

Virksomhetens retningslinjer

Retningslinjer i virksomheten (polycier) som driver utformingen av dataarkitekturdesignet kan inkludere interne retningslinjer, faglige standarder og gjeldende lovverk. Virksomhetens retningslinjer rundt dette beskriver hvordan virksomheten ønsker å behandle dataene sine.

Krav til dataprosessering

Disse inkluderer nøyaktige og reproduserbare valutatransaksjoner utført i stort volum, datavarehus for støtte av ledelses- og informasjonsssystemer (og potensiell datautvinnig), periodiske rapporteringer, ad hoc-rapportering og støtte for ulike organisatoriske tiltak etter behov (for eksempel årlige budsjetter, ny produktutvikling).

Se også

• Løsningsarkitektur

Eksterne lenker

• Offisielt nettsted
• (en) Data architecture – kategori av bilder, video eller lyd på Commons

Autoritetsdata