OIO Enterprise Arkitektur reol

En enterprise arkitektur reol er en struktur for de produkter der leveres i et EA projekt, samt for beslægtede produkter der bruges som input i EA projektet. Et reol kan sammmelignes med en velordnet bogreol - den giver systematik og overblik over dokumentationen.

OIO Enterprise Arkitektur reolen forefindes i flere versioner – se nedenfor.

Hvad er en arkitekturreol?

Et enterprise arkitektur reol er en struktur for de produkter der leveres i et EA projekt, samt for beslægtede produkter der bruges som input i EA projektet. Et ”produkt” er ofte et dokument (tekst, præsentation, regneark, tegning mv.), men kan også være en model bygget i et værktøj; eller simpelthen blot det, at der er sket en ændring i arbejdsgange.

En EA reol er altså en klassifikation af EA produkter, men ikke en metode! Man kunne kalde en EA reol for en ”bogreol”.

Man skal bemærke at et konkret dokument sagtens kan have indhold der hører til i flere forskellige ”hylder” – samt indhold der falder udenfor OIO EA reolen.

OIO EA reolen

OIO EA reolen er inspireret af det originale Zachman reolen. Der er dog et par forskelle. Først og fremmest er OIO EA reolen simplere og mere fokuseret på kernen i EA – navnlig er Zachman’s ”People” og ”Time” søjler neddroslede.
OIO EA reolen er til gengæld beriget med en række produkter (produceret af OIO EA metoden og andetsteds) der tjener til at vedligeholde og styre brugen af en enterprise arkitektur.

En stor udgave af OIO EA reolen kan findes ved at klikke på nedenstående figurer:

Den “rå” udgave af OIO EA reolen er præsenteret nedenfor.

Helt bart, uden ”hylde-overskrifter”

Fra venstre til højre sker der en klassificering af arkitektur-produkter fra det strategiske hen imod det mere teknologi-orienterede. Fra top til bund sker der en ændring af ejerskabet i en organisation. Leverancer fra et enterprise arkitektur projekt fordeler sig normalt således:

På det konceptuelle niveau er ejerskabet normalt forankret hos topledelsen i organisationen. Dokumenterne på dette niveau beskriver overordnede, strategiske beslutninger.
På det logiske niveau er ejerskabet forankret hos de ansvarlige for den daglige ledelse i organisationen. Dokumenterne på dette niveau beskriver de generelle design man opererer ud fra.
På det fysiske niveau er ejerskabet forankret hos de operationelt ansvarlige i organisationen, og herunder hos de leverandører man benytter til at levere løsninger.

I nedenstående figur er der sat overskrifter på de enkelte hylder i ”reolen”:

Med ”hylde-overskrifter”

Indholdet i OIO EA reolen

Nedenstående figur er en uddybning af den foregående. Her beskrives i tekst hvilke typer indhold der hører hjemme i de enkelte kategorier (”hylder”) i reolen.

Generel beskrivelse af indholdet af de enkelte ”hylder”

OIO EA leverancer sat ind i OIO EA reolen

OIO EA metoden foreslår i de enkelte trin nogle leverancer. Det er bestemt ikke en udtømmende liste over hvad man kunne producere i de enkelte trin – kun de mest anvendte leverancetyper. OIO EA metodeleverancerne er skruet således sammen at de naturligt hører til i én bestemt placering i OIO EA reolen – én ”hylde” om man vil.

Diagram viser hvilke OIO EA leverancer der hører til hvor

Man skal bemærke at en konkret leverance i et arkitekturprojekt ofte vil have indhold der hører til i forskellige kategorier. Omvendt kan leverancer indenfor én dokumenttype variere meget i detaljeringsgrad. For eksempel er leverancen C2.1 ”Applikationskatalog” placeret på det logiske niveau, da det normalt er det niveau applikationer beskrives på, men ét applikationskatalog kan være meget overordnet, et andet meget detaljeret. Et ”to-be” applikationskatalog vil ofte kun beskrive fremtidige applikationer på et niveau der er tæt på at være konceptuelt, uden at nævne de konkrete applikationer, da de jo ikke er valgt endnu. Derimod kan et ”as-is” applikations-katalog være meget detaljeret, da de nuværende applikationer jo kendes, og således være tættere på det fysiske niveau.

Standarder

EA produkter vil ofte benytte standarder – teknologi- og metodestandarder. Enten fordi produktet er blevet til under brug af en standard metode, eller fordi produktet (leverancen) specificerer at arkitekturen skal overholde nogle givne standarder. Listen af kandidat-standarder er lang, men nogle af de væsentligere standarder er indpasset i OIO EA reolen her.