Dilemmaet om SOA Governance

Der er nok ingen tvivl om at SOA Governance (SG) sælger billetter for tiden. Mange er gået i gang med SOA, og finder ud af at SOA uden Governance ender det i kaos. Virkeligheden er nu nok, at IT uden Governance altid ender i kaos, så at SG er en nødvendighed bør ikke komme bag på nogen!

Problemet er så at mange (ingen nævnt ingen glemt) tror at SG er noget man bare putter på efter behov ? Stor fejl! SG kræver en meget veldefineret SOA, man kan ikke lave Governance på det ukendte. Dette giver dog lidt et hønen og ægget dilemma, for hvis en veldefineret SOA er en forudsætning for SG, og SG er en forudsætning for SOA har vi vist et problem ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Man starter ikke med en arkitekturmæssige veldefineret SOA, det er noget man kontinuerligt arbejder på. I samspil med dette arbejde opbygger man den dertilhørende Governance.

Den virkelighed man ofte vil se, hvis man forsøger at plastre SG på efterfølgende er, at det arkitekturmæssige grundlag ikke er detaljeret nok til at lave Governance på baggrund af. Derfor bør man altid teste ens arkitektur i forhold til Governance; Kan det kontroleres?

Og så den del som der ofte bliver glemt: Et af de vigtigste aspekter ved arkitekturprincipper er, at kunne dispensere fra disse. Arkitekturprincipper sætter retningen, men ikke alle kan følge denne retning (eller der er en business case der er god nok til at lade være). Man skal altså have en proces på plads der sikre at det er muligt styre disse dispensationer - permanente såvel som midlertidige.

Og så lige en discalmer: SG eksistere på mange planer, så at Strategisk, Designtime, Runtime osv. Mit primære fokus i ovenstående er designtime, men det meste gælder nu nok også på de andre planer af SG?