Der findes flere forskellige ledelses perspektiver på, hvordan teknologi kan anvendes i en organisatorisk og ledelsesmæssig kontekst.

Der findes flere forskellige metodikker og fremgangsmåder for, hvordan teknologi kan og bør anvendes i organisationer. Jeg vil dette blogindlæg komme ind på nogle af fremgangsmåderne, og hvordan de kan anvendes i en organisationskontekst.

Fremgangsmåder

OBASHI-fremgangsmåden blev oprindeligt udviklet i olie-industrien for at demonstrer, hvordan informationsteknologien påvirkede de forskellige olieproducenter og deres forsyningskæder.

Fremgangsmåden viser hvordan den underliggende infrastruktur kan anvendes til at afvikle software, og hvordan det er forbundet til ejerne af den specifikke software, hardware og bagvedliggende infrastruktur.

OBASHI står for Ownership, Business, Application, System, Hardware og Infrastructure, og i udgangspunktet kan metoden (metoden er oprindeligt udviklet af Cloughley og Wallis, og hvis man skal tro på Wikipedia blev metoden opfundet i slutningen af 2001.

ITIL-metoden beskriver ligeledes forskellige fremgangsmåder der potentielt kan anvendes i forhold til identificering af artefakter inden for henholdsvis den tekniske arkitektur og informationsarkitekturen, men i udgangspunktet er det ganske få modeller, som jeg oplever at ITIL-metoden er i stand til at levere i forhold til dannelsen af artefakter til rammeværkerne, men trods dette så giver ITIL 2 nogle interessante bud på ”deployment” og ”management” af it-infrastrukturen.

Der findes forskellige perspektiver på koblinger i forhold til rammeværkerne, men jeg har fokuseret på, hvordan OBASHI og ITIL metoderne kan støtte op om henholdsvis EA³ Kuben og TOGAF.

Koblingen til rammeværkerne

Min erfaring er at det ofte kan være meget svært at identificere artefakterne inden for de tekniske lag i arkitekturen. Rammeværkerne EA³ Kuben og TOGAF er begge rammeværker der fokuserer på en holistisk fremgangsmåde for organisationens enterprise arkitektur program. Begrebet holisme skal i denne kontekst forstås som værende situationen, hvor rammeværket tager højde for elementer der findes i ”forretningen”, og de elementer der findes i it-afdelingen.

EA³ Kuben (EA³ Cube) er et rammeværk der typisk anvendes som et introducerende rammeværk på uddannelserne, hvilket nok skyldes at bogen, hvori rammeværket introducere, egentlig er designet til netop det formål (An Introduction to Enterprise Architecture), men modellen er god nok, i det den introducere forskellige lag i arkitekturen, og hvordan lagene til sammen udgør en større helhed. Problemet med EA³ kuben er at der er ganske få gode eksempler på artefakter, hvormed en metode som OBASHI kunne anvendes. OBASHIkanefterminmeningerstatteelementersomdettraditionellenetværksdiagram, applikationsoversigt og platforms oversigt. På visse områder kan et OBASHI-diagram egentlig erstatte oversigten over informationssystemer, hvis diagrammet vel at mærke får et ekstra lag information oven på.

ITIL kan være med til at få styr på både as-is og to-be situationen, da ITIL er med til at ligge et fundament for afstemning af forventninger mellem forretningen og it fx ved brugen af interne service level agreements.

TOGAF opdeler enterprise arkitekturen i tre lag. Det første lag er forretningslaget. Det andet lag er informationssystemerne og det tredje lag er hardware-platformen. Ydermere anvender TOGAF en klassificerings model der viser, hvordan begrebet applikation, system og service defineres. Dette i sig selv er ganske godt, men igen vil OBASHI-diagrammet og eventuelt en hybrid med OBASHI-metoden kunne gavne hjælpe enterprise arkitekterne.

Konklusion

Min konklusion er dermed at det kan gavne enterprise arkitekterne og chefarkitekten at skabe en synetese mellem andre metodikker end det enterprise arkitektur rammeværk som blev anvendt. Dermed sagt så findes der massere af andre rammeværker der har styrker og svagheder der kan arbejdes med og der findes andre ikke EA-metoder der kan kobles sammen med rammeværket for at den rette tilgang kan skabes til at løse de problemstillinger som enterprise arkitektur programmet og organisationen står overfor.

Med andre ord så bør rammeværket tilpasses organisationens behov, og det giver sjældent mening at implementere et enterprise arkitektur rammeværk der vel at mærke ikke er blevet tilpasset organisationens situation.