Formål
Denne aktivitet beskriver den nuværende og den fremtidige informationsarkitektur. Herunder udvikles en logisk datamodel og et data distibutionsskema.
Input
Til nuværende informationsarkitektur:
- Eksisterende dokumentation.
- Interview med it nøglepersoner.
Til fremtidig informationsarkitektur:
- Dokumentation af den nuværende arkitektur
- Diverse dokumentation fra forretningsarkitekturaktiviteterne og andre aktiviteter
Derudover suppleres med interview/workshop med forretningssiden.
Vær også opmærksom på de date der kan blive berørt af fællesoffetlige datastandarder og grunddatainitiativet.
Generelt i forhold til alle typer projekter er en klar oversigt over de centrale Forretningsobjekter (B1) et centralt input, uden hvilket det vil være vanskeligt at udvikle en forretningsorienteret informationsarkitektur. Eksisterende logiske datamodeller og evt. essentielle data-beskrivelser der måtte foreligge (i skemaer, på skærm-billeder osv.) kan indgå som inspiration. I forbindelse med konsoliderings og migrationsprojekter skal den nuværende arkitekturer skal være dokumenteret, for at man meningsfyldt kan definere en fremtidig informationsarkitektur og en migreringsplan fra nuværende til fremtidig. Leverancer fra aktiviteterne It-principper (A3), Lokationer/organisation (B2), Forretningsservices (B3), Forretningsprocesser og workflows (B4) og Forretningsregler (B5) samt Use cases (B6) kan tjene til at støtte udformningen af informationsarkitekturen. Ligeledes kan der hentes inspiration fra Applikationsarkitektur (C2), Servicearkitektur (C1) og Teknologiarkitektur (C4) i det omfang der findes relevant dokumentation på det givne tidspunkt. Ofte ofte starter man med informationsarkitekturen og har ikke de øvrige på plads.
Output
I løsningsprojekter såvel som i projekter på EA niveau kan denne aktivitet levere et eller to sæt dokumenter alt efter behovet: Ét der beskriver den nuværende informationsarkitektur, og ét der beskriver den fremtidige informationsarkitektur (”as-is” og ”to-be”).
For både den nuværende og fremtidige arkitektur kan output omfatte:
- Informationsobjekter i LDM – Logisk DataModel (C1.1). Her sker en uddybning af forretningsobjekt modellen (B1) til noget der ligner (er) en logisk datamodel (LDM). Her beskrives attributter for de enkelte objekter, deres indbyrdes relationer og kardinaliteter.
- Data distribution (C1.2) For de enkelte logiske objekter: en oversigt (gerne i et lokationsdiagram) over hvilke datastrømme der er – hvordan horisontale og vertikale fragmenter af data flyder rundt i organisationen.
I relation til SOA: Et SOA princip er at en services data kun kan tilgås via servicen og ikke direkte i databasen. Derfor må replikering og opdateringsansvar analyseres (fx bør data kun opdateres et sted for at undgå inkonsistens). - Databasekatalog (C1.3). Dette er en oversigt over nuværende og fremtidige databaser – indhold, størrelse, teknologi-platform, kvalitet af data, osv.
- Fysisk datamodel (C 1.4). Her bliver man meget konkret med valg af datastandarder for de enkelte logiske objekter. Ikke mindst bør man specificere hvilke OIO datastandarder der skal overholdes – herunder referere de helt konkrete OIOXML skemaer der allerede findes, og specificere hvilke nye der bør udvikles.
Metode
De vigtigste deltagere i denne aktivitet er udover informationarkitekten (projektet / organisationens begrebs/informationsmodellerings-ansvarlige), enterprise arkitekten og organisationens database-ansvarlige. Desuden indgår forretningsarkitekten og repræsentater for forrretningssiden samt it-chefen efter behov.
Nuværende arkitektur:
At afdække den nuværende arkitektur er i høj grad et ”arkæologi-arbejde”. Det anbefales at læse den generelle artikel om dokumentation af den nuværende tekniske arkitektur.
Fremtidig arkitektur
Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitektur-områder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige ”fløje” i organisationen, der advokerer forskellige teknologier.
I arbejdet med LDM-udviklingen har man brug for klassiske datamodellerings-kompetencer. Fokus bør være på at etablere en ønskelig fremtidig informationsstruktur, der bedre understøtter forretningsprocesserne. Temaer kan typisk være: “konsolidering af ‘kunde’ information (patient, borger)”, “al data ét sted”, og “historik tilgængelig”. Det er dog ikke givet, at al data for et givent logisk objekt for eksempel altid kan samles kun ét sted; man vil i al fald ofte se, at dette kræver en migrering, og på det fysiske niveau noget data vask/data transformation.
Man kan i denne aktivitet også tage stilling til, hvilke konkrete formatstandarder (såsom OIOXML formater), de enkelte objekter/data eventuelt skal overholde. Er der ikke nogle relevante OIOXML standarder, kan dette give anledning til at det overvejes at definere disse.
I arbejdet med datadistribution søger man at kortlægge hvilke datastrømme, der naturligt flyder, så man kan designe sin databasestruktur efter dette. Ideelt set kunne man måske lægge al data centralt, men der vil ofte være en række grunde til at have decentrale, horisontale og vertikale udsnit af data – f.eks. sikkerhed, performance eller teknologiske hindringer. På baggrund af data distributionsskemaet kan man begynde at designe hvilke mængder data, der skal flyttes rundt, med hvilke realtime-krav, sikkerhedskrav, osv. Herudfra kan man begynde at placere de enkelte databaser per lokation. Man har samtidig input til valg af konkret database management system teknologier. Et datadistributionsskema er naturligvis mest relevant for større organisationer med flere fysiske lokationer.
En praktisk måde at konsolidere data på er at etablere et datavarehus, hvor al relevant data samles og gøres tilgængelig via rapportudtræk og business intelligence værktøjer.
Her er et links til Digitaliseringsstyrelsen hjememside, hvor du kan læse mere om hvordan man laver OIOXML.
Gode råd
Nuværende arkitektur
Det giver værdi at have mange bidragsydere til at dokumentere denne, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende, der fortsætter med at udarbejde den fremtidige arkitektur.
Det bemærkes, at projekter der pågår, også skal regnes ind under den nuværende EA.
Fremtidig arkitektur
Der vil typisk være omkring 25-40 logiske informationsobjekter. Formålet i de første iterationer er at lave en Logisk Data Model (LDM), dog ikke i detaljer. Et senere skridt vil være at ombryde denne til en fysisk datamodel, hvor relationer normaliseres, hvor der tænkes på implementerings-effektivitet, og hvor mindre vigtige informationsobjekter identificeres og defineres.
I enterprise arkitektur-arbejdet er det essentielt at få et godt overblik over de allermest essentielle informationsobjekter og relationer mellem disse. En stor organisation vil ofte have 300-1000 informationsobjekter (forretningsbegreber), og det er derfor vigtigt i en enterprise arkitektur at identificere de væsentligste objekter og designe de væsentligste relationer. Projekter som følge af migreringsplanen vil altid kunne uddybe og tilføje objekter og attributter, så fokus i denne aktivitet er at definere en velgennemtænkt grundstruktur.
Det er også vigtigt at læne sig op af at eksisterende dataformat-standarder.
Læs om datastandarder på Digitaliseringsstyrelsen hjememside
Søg efter datastandarder (XML-skemaer) på digitalisér.dk
Læs om grunddatainitiativet.