I casestudiet omhandlende sammenhængsledelse i den offentlige sektor fandt jeg frem til at caseorganisationens beslutningstagere var meget centreret omkring deres specifikke domæner. Det virkede ikke til at de havde tid eller overskud til at gå i gang med et enterprise arkitektur program, hvor de skulle stille ressourcer til rådighed og måske enda risikere at blive udstillet på en måde der ikke ville gavne deres specifikke område.

På den anden side virkede det til at de ansatte der arbejdede på koncernniveauet ikke var bange for at gå i gang med forandringer for at komme udover de siloer der eksisterede internt i case organisationen. Dermed var der ikke tale om en fuldstændig blokering for at lægge et fundament for sammenhængsledelse eller det som Doucet et al (2009) kaldte for fundament arkitekturen. Fundamentarkitekturen anvendes af it afdelingen til at identificere strategiske it-baserede forretningsprojekter der kan understøtte udviklingen af it-arkitekturen og muliggøre forandringer i forretningens arkitektur. Det påvirker dermed muligheden for at forandrer enterprise arkitekturen. De forskellige kontorchefer og teamledere havde som førnævnt en til tider noget specialiseret tilgangsvinkel til deres specifikke område, og på tilbage i 2010 havde organisationen kun påbegyndt arbejdet med at vælge et enterprise arkitektur rammeværk for organisationen og dernæst at tilpasse det.

Caseorganisationen havde på det tidspunkt taget kontakt til en specialiseret konsulentvirksomhed hvis primære arbejdsområde var enterprise arkitektur, og det virkede til at enterprise arkitekterne ville afvente den hjælp der var at afhente ved et møde med det specifikke selskab. Det må antages at de havde til formål at skabe en slags syntese af et rammeværk. Min antagelse var på daværende tidspunkt, at caseorganisationen ville vælge OIO-EA og et andet rammeværk, det kunne være EA³ kuben (som typisk anvendes til undervisning), men det kunne også være en hvis sandsynlighed for at caseorganisationen ville vælge at tilpasse OIO-EA rammeværket med TOGAF.

På andre områder havde caseorganisationen arbejdet med andre former for arkitektur der primært havde relateret sig til den tekniske arkitektur. Initiativerne havde været centreret omkring implementeringen af en enterprise service bus (ESB) som led af implementering af en service-orienteret arkitektur.

På grund af disse initiativer virkede det som om beslutningstagerne fra ”forretningen” var bange for at engagere sig selv i et ”projekt” som havde store risici for ikke at fejle, ligesom det havde været tilfældet med SOA ”projektet”.

Caseorganisationen er en ældre organisation, der har anvendt teknologi i meget lang tid, og i udgangspunktet ikke haft særlig godt styr på kompleksiteten af de løsninger og systemer overtiden er blevet implementeret, desværre havde caseorganisationen (som med så mange andre organisationer i den offentlige sektor) ikke tænkt over sandsynligheden og muligheden for at data kunne og skulle udveksles med andre offentlige myndigheder, hvormed standardisering af data og funktionalitet ikke havde været prioriteret, hvilket havde bidraget til de organisationspolitiske problemstillinger med SOA. Dermed havde enterprise arkitektur gruppen en nedarvet en grad af mistillid der besværliggjorde deres arbejde.

Enterprise arkitekterne virkede ikke til at være i stand til at modbevise den mere eller mindre irrationelle selvforstærkende mentalmodel af at der var grund til at frygte støtten til enterprise arkitektur programmet.

Læring fra casen

For at enterprise arkitektur og SOA kan virke for en given organisation så kræver det at der findes en polititisk enighed og tillid til at programmerne kan være med til at understøtte den eller de målsætninger, som organisationen er sat i verden for at opnå. Det kræver ligeledes at de forskellige magtgrupperinger (som typisk findes i den offentlige sektor) understøtter at der skal foregå en forandring, og forandringen vel at mærke kan påvirke magtrelationerne (kongedømmerne) på en negativ facon.

Måden at forsøge at gå i gang med at skabe tillid er ved at skabe resultater, for selv små resultater kan bruges som artefakter og dermed påvirke den mellemledernes og topledernes psykologi, men disse skal kommunikeres ud til de forskellige interessenter i organisationen. Psykologi er grundlaget for håndtering af mentalmodellerne. Mentalmodellerne styre samtidigt en stor del af de beslutningstager der træffes.

Kommunikation er mere end indlæg på intranettet eller ugentlige nyhedsbreve pr. e-mail, kommunikation kommer igennem kommunikation mellem mennesker på måder der gør at menneskerne er i samme lokale.