Caseorganisationen påbegyndte en række initiativer for at kunne dele og funktioner mellem de forskellige informationssystemer som organisationen anvendte (casestudiet tilbage i 2010). Caseorganisationen begyndte dernæst at arbejde med få styr på sine forretningsprocesser.
SOA blev et ganske interessant emne for beslutningstagerne på grund af få personers omtale af potentialet i at få opbygget et service-orienteret arkitektur til at koble caseorganisationens mange specielt udviklede og meget tilpassede informationssystemer således informationssystemerne kunne udveksle data. Organisationens beslutningstagere havde igennem agitationen opbygget meget store forventninger til, hvad SOA kunne gøre for caseorganisationen set i øjnene af investeringen kunne medføre en form for besparelse på it-området. Et ”hot topic” siden finansministeriet konsekvens stillede krav om indfrielse af besparelser, hvis caseorganisationen ikke påtog sig at løse ny opgaver. Caseorganisationen investerede en ret stor sum penge i udviklingen af it-systemerne, og på grund af ændringer i caseorganisationens domæne. Den primære fortaler for SOA forlod organisationen i denne transformationsproces, og det betød at fokus forblev på it-arkitekturen (altså den del der i teorien) burde være den nemmeste at omstille til en SOA økosystem. På grund af de manglende organisatoriske omstillinger udeblev de lovede fordele og det spændte ben for den noget mere komplicerede organisatoriske del (SOE). Sidenhen havde caseorganisationen investeret i et mere regulært enterprise arkitektur program som havde til hensigt at skabe fundamentet for at enterprise it-systemerne og forretningsprocesserne kunne afbilledes til artefakter og dermed give de centrale it-ledere et indblik i, hvordan de forskellige systemer hang sammen. På den måde havde organisationen påbegyndt en form for forståelse af, hvordan de forskellige dele af it-arkitekturen fungerer. Ligeledes virkede det til at caseorganisationen forsøgte at få en bedre forståelse for de aktiviteter der fandt sted som led af at kunne levere de services som interessenterne efterspurgte.
Enterprise arkitekterne havde på daværende tidspunkt ikke arbejdet med at identificere et enterprise arkitektur rammeværk eller at tilpasse det til caseorganisationens situation. Organisationen havde som sådan ikke et samlet rammeværk til understøttelse af den indsamlede og behandlet information.
Læring fra caseorganisationen
Chefarkitekten (kontorchefen) havde ikke sikret sig en realistisk forventningsafstemning med interessenterne fra de forretningsorienterede dele af caseorganisationen.
Dertil havde chefarkitekten lagt for meget vægt på den tekniske del af SOA.
Chefarkitekten bør generelt spille en proaktiv rolle i forhold til forventningsafstemning frem for at antage at alt bare er fint, og sidenhen finde ud af at interessenterne bliver skuffede over de resultater der bliver leveret.
Enterprise arkitekten og chefarkitekten bliver nød til at forventningsafstemme med interessenterne på flest mulige niveauer muligt, da de ellers vil opleve at organisationen nemt vil komme til at tro på at resultaterne som enterprise arkitektur programmet vil levere væsentlig mere end, hvad tilfældet vil være i situationer, hvor enterprise arkitektur programmet er i sine opstartende faser.
CoherencyArchitect
EnterpriseArkitekten.com 