cropped-img_0905.jpg

Fem fremgangsmåder for implementering af enterprise arkitektur programmet i enterprisen

Enterpriser som står i situationen at skulle håndtere meget komplekse opgaver på tværs af mange forskellige divisioner, afdelinger og grupper i virksomheden (enterprisen) kan enterprise arkitektur som koncept være en del af løsningen. Konceptet skal dog være operationaliserbart ellers vil enterprisen ikke være i stand til at skabe værdi ved anvendelsen af konceptet.

Konceptet

Enterprise arkitektur er defineret på mange forskellige måder alt afhængigt af, hvilken kilde der anvendes. Jeg personligt foretrækker at anvende en basis definition der omfatter at enterprise arkitektur programmet indeholder strategi, teknologi, forretningen og organisationen. Organisationen dækker over begrebet mennesker, viden, strukturer, processer og netværk. Jeg baserer min basis-viden på to forskellige skoler inden for enterprise arkitektur verden. Der findes to overordenede skoler (en smule simplificeret) som har delvist modsatrettede fremgangsmåder til, hvordan enterprise arkitektur programmet kan implementeres. Begge skoler anerkender arkitektur processen og begge skoler tager sit afsæt i Zachmans oprindelige ideer, om at artefakter skal dokumenteres og organiseres for at opnå et ledelsesmæssigt overblik.

Overblikket giver de forskellige beslutningstagere den fordel (i hvert fald fra virksomhedens overordnede perspektiv) mulighed for at kunne agere på information der er valideret til at træffe beslutninger der vil gavne enterprisens strategiske situation.

Sådan kan enterprise arkitektur implementeres

Implementering af enterprise arkitektur programmet kan gøres på mange forskellige måder, og ligeledes kan selve ideen om enterprise arkitektur programmet (som nævnt ovenfor) defineres på mange forskellige måder og der kan være flere forskellige faktorer der påvirker enterprisens styring af de projekter der flytter enterprisen fra ”as – is” situationen til den fremtidige ønskede situation (to-be). Nedenfor har jeg behandlet fem fremgangsmåder til implementering i enterprise arkitektur.

Top-styret fremgangsmåde

Karakteristika

Fremgangsmåden er bygget op omkring at ledelsen har indflydelse på planlægning, eksekvering og håndtering af implementering. Projekterne der skal til for at flytte enterprisen fra ”as-is” til ”to-be” understøttes fra starten af de principper og standarder der er fastlagt i enterprise arkitektur programmet.

Fundamentet for modningen af enterprise arkitektur programmet er at de projekter der bliver initieret er nøje udtænkt, da projekterne har en stor indflydelse på, hvordan enterprisen er i stand til at indfri de mål der er blevet opstillet af beslutningstagerne.

Top-styret fremgangsmåde.
Top-styret fremgangsmåde.

Når chefarkitekten skal til at designe enterprise arkitektur fremgangsmåden vil han starte med at designe et undersøgelsesdesign for hvordan de forskellige artefakt er defineret, hvordan de identificeres og hvordan de bør organiseres i repositoriet.

Positive sider

Fremgangsmåden kan med tiden sikre at de projekter som bliver udarbejdet er med til at implementere den strategi som er blevet formuleret og udøvet af beslutningstagerne. Hurtigere eksekvering i forhold til de målsætninger som beslutningstagerne har defineret.

Negativer sider

Fremgangsmåden er i udgangspunktet meget centralistisk, og dermed bør den eller de beslutningstagere der har noget afgøre med hvilke tildenser som enterprise arkitektur programmet kommer til at håndtere. Det giver en hurtig eksekvering, men samtidigt giver det en række problemstillinger i forhold til at beslutningstagerne skal være gode til at identificere, hvilke tildenser som vil vinde frem, og hvilke som enterprisen bør ignorere. I forhold til management 2.0 (enterprise 2.0 og web 2.0 i ledelseskontekst) vil der med stor sandsynlighed vise sig at medarbejderne, hvilket vil sige en decentrale enheder, vil være bedre til at kunne håndtere trend-spotting. Centralisering har yderligere den konsekvens at de individer som har ”første-hånds-indtrykket” af situationen i bedste fald kun vil blive spurgt om strategien, politikerne, standarderne eller tilsvarende reelt vil kunne bruges i deres kontekst. Når det ikke er eksperten som kan beslutte, hvad som burde være bedst i forhold til den enkelte situation vil der sikkert optræde situationer, hvor fremgangsmåden vil medføre ringere resultater.

Projekt-orienteret fremgangsmåde

Karakteristika

Den projekt-orienterede tilgang til enterprise arkitektur er decentraliseret i den forstand at de forskellige enterprise arkitekter og chefarkitekten står for at tilbyde arkitektur-lignende services til de forskellige it-baserede forretningsprojekter i enterprisen. Ud fra denne devise vil nogle af de principper og standarder der blev formuleret af enterprise arkitektur gruppen finde frem til de projekter som er interessante. Det er ligeledes en måde at forsøge at overbevise aktører i enterprisen om at de it-baserede forretningsprojekter vil kunne implementeres hurtigere end under forhold, hvor der findes en begrænset mængde ressourcer.

Projekt-orienteret fremgangsmåde
Projekt-orienteret fremgangsmåde

Selve implementeringen af enterprise arkitektur programmet er bygget op omkring at projekterne over tid vil gøre de forskellige aktører i enterprisen bevidste om at det er et behov for det videre arbejde med et decideret program.

Positive sider

Den projekt-orienterede tilgang til enterprise arkitektur har nogle fordele i det at projekterne (hvis de ikke styres af en central-gruppe) vil kunne medføre at dem med ekspertviden på et eller flere af disse områder kan få afgørende indflydelse på, hvordan arkitekturen fremover vil håndtere de problemstillinger som den bliver stillet overfor. Der vil ligeledes være en mulighed for at sikre at der findes flere forskellige typer projekter der kan være med til at fremme enterprisens mål.

Negative sider

Den løst-koblede strategi eller rettere den løst-koblede fremgangsmåde tager som ofte længere tid at få implementeret, og samtidigt gør denne fremgangsmåde det ualmindelig svært for chefarkitekten at kunne påvise en positiv sammenhæng mellem enterprise arkitektur programmet og de projekter der bliver implementeret.

Teknologi-orienteret fremgangsmåde

Karakteristika

Chefarkitekten, CIO’en, CTO’en eller anden beslutningstager inden for den teknologiske del af enterprisen implementere enterprise arkitektur for at kunne afdække de behov som findes i forhold til at udvikle it-projekterne. Der er altså tale om en slags dynamisk kravspecifikation som udelukkende anvendes af it-afdelingen til at finde frem til, hvordan databaser, informationssystemer og forskellige former for teknologier understøtter forretningen.

Teknologisk-orienteret fremgangsmåde
Teknologisk-orienteret fremgangsmåde

Positive sider

En af de positive sider vil være at it-lederen, chefarkitekten, projektledere, udviklere og implementerings agenter vil være i stand til at identificere de muligheder der findes ved anvendelse af den nuværende teknologi i forhold til at assistere med at finde frem til den bedst mulige løsning for enterprisens forretnings-organisation.

En anden positiv side ved denne tilgang til enterprise arkitektur er, at fremgangsmåden vil være med til at kunne sikre den videre udvikling af enterprisen i forhold til udnyttelsen af de teknologiske værktøjer (technological capabilities) som enterprisen råder over. Set i forhold til perspektivet om at finde frem til de it-baserede forretningsprojekter der vil være relevante for enterprisen (Business to IT alignment), vil enterprise arkitektur kunne anvendes til at skabe mere realistiske planer, og reelt være med til at kunne skabe grobunden for en bedre udnyttelsesgrad af de investeringer som enterprisen allokere ressourcer til.

Den it-orienterede tilgang giver dog mulighed for udvikling og afprøvelse af det rammeværk som chefarkitekten eller it-lederen udarbejder, og hvis det bliver muligt kan rammeværket og dermed fremgangsmåden optimeres således den let kan anvendes i forretningen.

Negative sider

Sandsynligheden for at forretningen vil anvende enterprise arkitektur til at udforme fx forretningsstrategien efter vil være minimal. It-lederne og it-afdelingerne er i de fleste virksomheder anskuet som sekundære elementer i forhold til ledelsen og i betydning for at enterprisen udvikler sig. Denne position vil påvirke enterprise arkitektur programmets betydning og anvendelse i forhold til udviklingen af forretningsstrategien, og dermed vil de muligheder som it-afdelingen kan påvirke ikke komme i den strategiske betragtning der er relevant i forhold til at opnå komparative fordele (competitive advantages) og udnytte investeringerne i teknologi fuldt ud.

Proces-orienteret fremgangsmåde

Karakteristika

Den proces-orienteret fremgangsmåde er bygget op omkring ideen om at det perfekte enterprise arkitektur program ganske enkelt ikke findes. På grund af påvirkningen fra enterprisens omverden (nær og fjernmiljø) vil der være et behov for en konstant tilpasning af programmet og af enterprisens arkitektur. De fleste rammeværk påråber sig at være bygget op omkring en proces, eller i hvert fald at være bygget op omkring ideen at enterprise arkitektur (som program) er kontinuerligt, men det er ikke alle rammeværk som anerkender selve ideen om at ”blueprinting” ikke vil medføre fordele, ligesom disse rammeværk ofte betegner muligheden for at opnå et perfekt resultat.

Proces-orienteret fremgangsmåde
Proces-orienteret fremgangsmåde

Fordele

De fordele som findes ved at anvende denne fremgangsmåde er ved at der findes et relativt realistisk syn på at processerne for implementering og udbygning af enterprise arkitektur programmet bliver forbedret ligger i at det på forhånd skaber et indtryk hos chefarkitekten og beslutningstagerne om at der ikke findes et utopisk løsning.

Der findes et iterativt perspektiv for, hvordan enterprisens arkitektur program bliver udviklet (det vil sige udvikling, tilpasning og håndtering af enterprise arkitektur fremgangsmåden) således enterprise arkitektur gruppen bidrager til virksomheden på en fornuftig og realistisk måde.

Ulemper

Den proces-orienterede tilgangsvinkel har sine ulemper fx har de rammeværk der fokusere på en proces-orienteret tilgang ofte fokusere mere på processen end på enterprisen som helhed. Ligeledes har implementerings processen en forfordeling af ressourcer set i forhold de aktiviteter der egentlig er med til at sikre enterprisens lederskab (beslutningstagere) er i stand til at træffe de beslutninger der gør forskellen for enterprisens evne til at opnå de resultater der er opstillet for enterprisen, og i sidste ende er det jo enterprisens evne til at opnå sin målsætninger der afgør om enterprisen er succesfuld eller ej.

Ligeledes er minimum et af de største rammeværk der anvendes inden for den proces-orienterede tilgang fejlbehæftet i forhold til definitioner af hvordan de forskellige komponenter. Den proces-orienterede tilgangsvinkel skal fornyes, tilpasses og galvaniseres. Disse elementer bliver ofte underprioriteret, og der bør lægges mere vægt på begrebet kommunikation og forandringsledelse.

Holistisk-orienterede fremgangsmåde

Karakteristika

Den holistiske-orienterede fremgangsmåde er bygget op omkring at enterprise arkitektur anvendes i forretningen, men til at skabe et fundament for informeret ledelse, hvilket vil sige enterprise arkitektur programmet anvendes til skabe klarhed over hvilke projekter der vil kunne få enterprisen til at udvikle sig fra ”as is” situationen til den fremtidige fortrukne situation ”to be”, hvor enterprise arkitektur programmet. Fremgangsmåden behandler forretningsarkitekturen, hvilket vil sige forretningsmodeller, procesmodeller, procesbeskrivelser, forretningsstrategier, og værdikæder. Det vil sige den videre udvikling af enterprisen drives af de informationer som kan genereres ved anvendelsen af den teknologiske og informationsarkitekturen i forhold til at kunne skabe værdien der er nødvendig i forhold til den nødvendige transformation af enterprisen således den opnår det bedst mulige resultat, og dermed forhåbentlig opnår de mål der blev formuleret af beslutningstagerne. Enterprise arkitektur programmet anvendes dermed både til at udforme enterprisens it-arkitektur, men også enterprisens måde at gøre forretning på. Ydermere må det tolkes som at enterprise arkitektur programmet kan være med til at skabe et fundament for videndeling, og igennem forskellige ”governance” grupper vil enterprise arkitektur programmet være med til at kunne forbedre de forhold som de forskellige aktører i enterprisens arbejdsforhold.

Det kan på sin vis konstateres at den holistisk-orienteret fremgangsmåde til implementering af enterprise arkitektur er den mest modne. Denne form for enterprise arkitektur er ikke ”partisk” i forhold til håndteringen af enterprise arkitektur programmet som for eksempel den proces-orienterede tilgang til enterprise arkitektur eller den top-styret tilgang der oftest vil være baseret på ”blue printing”, hvilket vil sige måden at enterprisen bliver opbygget efter de planer som beslutningstagerne har truffet på samme måde som arkitekter i byggebranchen håndter konstruktionen af bygninger.

Holistisk-orienteret fremgangsmåde.
Holistisk-orienteret fremgangsmåde.

Fordele

Der findes mange fordele ved at anvende en holistisk-orienteret fremgangsmåde til at implementere enterprise arkitektur i en hvilken som helst given enterprise, men metoden er som sådan også temmelig ressource krævende og det kræver at beslutningstagerne forstår nødvendigheden i at opnå det der kan defineres som ”informeret ledelse”. Når programmet implementeres ud fra den holistiske tilgangsvinkel vil det blive betydeligt enklere at identificere mulige it-baserede forretningsprojekter der kan være med til at skabe det fornødne pres for at enterprisens arkitektur modnes og de mål som beslutningstagerne har formuleret bliver implementeret. De forskellige aktører i enterprisen har forstået, at enterprise arkitektur programmet kan anvendes til at skabe en platform for fælles forståelse (taksonomi) og mental-modeller, og måden de behandles på er i forhold til at kunne geare de forskellige projekter til at blive implementeret hurtigere end hvad de ville have været, hvis enterprisen ikke ville have implementeret et enterprise arkitektur program.

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s