Der findes en række interessante perspektiver på, hvordan organisationer bliver påvirket at ændringer fx ved krav om implementering af ny teknologi, krav fra kunder, myndigheder eller nye produkter fra konkurrenter eller nye ansatte kommer til. I sig selv er disse faktorer ikke nye og de blev oprindeligt behandlet af Leavitt (1965) der sidenhen er blevet kendt som Leavitts diamant.

Enterprisearkitektur kan bruges til at udvikle forslag til, hvordan organisationens arkitektur bør designes. Denne fremgangsmåde kaldes ofte for Enterprise Engineering. Enterprise Engineering er på mange måder forudsætter at organisationen kan konstrueres omkring et blueprint der for eksempel er formuleret omkring principper og standarder. Et glimrende værk der omhandler enterprisearkitektur i en kontekst af Enterprise Engineering er værket ”Enterprise Governance and Enterprise Engineering” af Hoogervorst (2009). Enterprise Engineering er på visse områder en radikal tilgang til enterprisearkitektur, og på visse områder kan fremgangsmåden ligge i kontrast til dynamisk enterprisearkitektur.

Den grundlæggende idé med Enterprise Engineering er at der udarbejdes en forandringsplan eller handlingsplan der understøtter organisationsforandring og individerne der indgår i forandringen alle forholder sig til de planer, principper og standarder (til sammen blueprints) der er udarbejdet. Dermed sagt må Enterprise Engineering betragtes som værende en meget risikofyldt fremgangsmåde for de fleste organisationer der eksisterer i en dansk eller sågar skandinavisk kontekst. Jeg mener dog, at Enterprise Engineering har sin merit i at fremgangsmåden på har medført en masse interessante teoretiske koncepter.

Organisatoriske perspektiver på arkitektur

I en antagelse om at individer reagere på samme måde overfor en bestemt plan, samling af standarder eller principper (blueprint), så mener jeg, at enterprisearkitektur kan bruges til at kunne vurdere og tilpasse organisationen ud fra de problemstillinger og muligheder der eksisterer. Et eksempel kunne være at et bestemt informationsteknologisk produkt skal udskiftes og et nyt produkt kan bidrage med nye måder at løse samme problemstilling på.

Nye teknologier bringer i mange tilfælde ny funktionalitet og dermed nye muligheder med sig til organisationen. Organisationer, hvis disse er bekendte med dem, og den rette ånd blandt medarbejderne og mellemlederne er til stede, være i stand til at anvende dem, organisationen tilpasses. Tilpasning medfører perspektivet der gælder for håndtering af opgaver, som organisationen på sigt vil løse. I sådan en rolle vil enterprisearkitektur funktionen spille en anden rolle og typisk være placeret uden for it-afdelingen. På visse områder mener jeg, at der kan trækkes relationer til henholdsvis Doucet et al (2009) og Lapalme (2011).

Enterprisearkitektur funktionen

Enterprisearkitektur funktionen bruger sine ressourcer på at udarbejde scenarier (baseret på den information der findes i artefakterne) og ud fra det udarbejdes strategiske scenarier for, hvordan branchen som organisationen operere indenfor forventes at udvikles. Disse scenarier er med til at afgøre, hvilket blueprint der bør implementeres og dermed understøtte designet for organisationen. Enterprisearkitektur funktionen har på sin vis en vigtig rolle for organisationen, men der findes visse teoretiske begrænsninger og visse praktiske problemstillinger der først bør behandles. Et eksempel på en teoretisk begrænsning vil være fra Henry Mintzbergs ”Strategy Safari” fra 2008, hvor ”planlægningsskolen” omtales i vendinger, hvor der fandtes en funktion for udarbejdelse af planer (et case eksempel er General Electric), men funktionen blev ikke holdt ansvarlig for implementering af planerne, hvilket havde stor betydning for at planerne som regel ikke blev gennemført eller medførte de ønskede fordele.

Fordelene blev ikke realiseret og det betød at denne skole inden for strategisk planlægning begyndte at svinde ind. På mange måder kan en Enterprise Engineering tilgang betragtes som værende en fremgangsmåde der kan minde om ”planlægningsskolen”.

Konklusion

Denne fremgangsmåde understøtter en udvikling af organisationens enterprisearkitektur program der kan understøtte det der typisk kaldes for ”forretningen” og styringen af it-afdelingen. Det har sine fordele, hvis man forventer at medarbejdere og mellemledere forholder sig til en plan (blueprint) på samme måde, og sine ulemper ved at enterprisearkitektur programmet (og dermed funktionen) kan blive afsporet ved at funktionen ikke stilles til ansvar for implementering af planen. I en skandinavisk kontekst kan et enterprisearkitektur program nok kun tage inspiration fra nogle af de ideer og koncepter der stammer fra Enterprise Engineering, men det vil være ude af trit med virkeligheden at antage at mellemledere og medarbejder tilpasser sig en plan uden at de har haft signifikant indflydelse på den.

Kilder

Doucet, G. et al., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, International Enterprise Architecture Institute.

Lapalme, J., 2011. 3 Schools of Enterprise Architecture, IEEE Xplorer Digial Liberary.

Mintzberg, H., Ahlstrand, P.B. & Lampel, J.B., 2008. Strategy Safari: The Complete Guide Through the Wilds of Strategic Management 2nd ed., Financial Times/ Prentice Hall.