Beste Lydia, 
 
Je argument is helder, maar niet helemaal juist. Je kunt inderdaad teruggrijpen op Montesquieu, maar ook deze Franse Baron heeft een basisprincipe toegepast op macht in een samenleving en niet dat principe uitgevonden. 
 
De basis zit in het principe van het scheiden van functies. Het functiescheiding wordt aangehouden om belangenverstrengeling te voorkomen. Simpel gezegd kan degene die vaststelt (Montesquieu’s Parlement) niet degene zijn die uitvoert (Montesquieu’s regering) of controleert/adviseert (Montesquieu’s rechterlijke macht).  
 
Met deze uitleg past de vertaling die je geeft niet. Wetgevende macht is niet architectuur, maar de top van een organisatie die (strategisch) vaststelt wat wel en niet in een organisatie kan of moet. Uitvoerende macht zit inderdaad in het management, in governance. Rechterlijke macht is controlerend, evaluerend enz., dus vaststellen of wat vastgesteld is ook inderdaad gedaan wordt maar ook de toets van de werkvloer of iets aan regels voldoet. Dit is toch wel een stevig andere doorsnede dan je geeft. 
 
Architectuur staat niet in dit verhaal. Dat klopt ook. Architectuur is immers, algemeen beschreven, de kijk van mensen vanuit hun discipline op een deel van de wereld. Simpel vertaald kijkt een programmeur naar een ander deel van zijn zakelijke wereld, een (deel van een) organisatie dan een strategisch manager. In de resp. architecturen van een organisatie, en dat zijn niet zoveel verschillende, wordt dus een kijk op de wereld neergezet. Voor de informatiekundige is dat alles rond informatie (een bedrijfsmiddel), dus de kennis van de informatie van een organisatie, voor een IT-er is dat de IT-enterprise architectuur waarin de kijk op de aansluiting (alignment) van IT in de organisatie vastgesteld wordt.  
Hier gaat het dus vooral om kennis van IT in relatie tot de organisatie die IT ondersteunt. Dat is geen wetgevende macht, maar hoogstens een ondersteuning van mensen die hun werk moeten doen in een taak binnen 1 van de 3 functies.  
Laat ik het simpeler zeggen. Stel je de wetgevende macht stelt, waarschijnlijk op voorstel, vast dat de nadruk op product moet verschuiven van een nadruk op de klant, zoals in de 90-er jaren hot-issue was in de Bankwereld. Dan zal iedereen zich aan die vaststelling moeten houden. Die vaststelling is dus deel van architectuur, en als zodanig bindend voor iedereen. Waarbij ieder zijn taak in dit kader moet invullen waarbij ieder zich aan deze (beheerde) afspraak/regel dient te houden.  
 
Het is geen vraag of functiescheiding moet. Als je het niet doet kom je per definitie in de problemen, spreek maar eens met een administratieve-organisatie-specialist. Simpeler gezegd: een manager kan zichzelf niet adviseren, zelf uitvoeren waar je de regie over moet hebben lukt ook niet en programmeurs moeten hun eigen werk niet testen/auditen. Als je accountant functiescheiding al niet van je eist dan is het gewoon verplicht om het zelf in je eigen organisatie af te dwingen. Organisaties worden er gewoon nooit beter van als zaken met de mantel der liefde bedekt (kunnen) worden. 
 
Waar je hier wel tegenaan loopt is een hard probleem waar IT-leveranciers/aannemers (softwarehuizen, systeemhuizen, IT-adviesbureaus en IT-opleiders) niet aan willen als ze niet hoeven. In principe voeren IT-leveranciers uit, waarbij de wetgevende macht bij hun cliënten ligt. Dat heet tegenwoordig regie. Nu is het mogelijk dat externen gevraagd worden om te adviseren/controleren. Prima natuurlijk, zo lang het resultaat onder de verantwoording blijft van de organisatie. Ook kan interim management zo uitgevoerd worden. 
Maar: echte functiescheiding maakt dit veel harder. Als een IT-leverancier een functie voor een (groep van) organisatie(s) vervult, bijvoorbeeld door een IT-project uit te voeren, KAN die IT-leverancier (of een al of niet bovengronds verbonden concullega-bedrijf) geen van de andere functies vervullen. Dat lijkt hard, maar het is echt de enige manier. Als deze regel niet gehandhaafd blijft worden er bruggen geslagen tussen leveranciers en daarmee verliest de vragende organisatie de regie/controle. 
 
Daar hoort nog iets bij: onafhankelijk versus neutraal. Onafhankelijk is dat organisaties die een rol spelen ten opzichte van een vragende organisatie niet aan die organisatie gebonden zijn, of aan elkaar. Neutraal is dat men samenwerkt en elkaars belangen respecteert. Zoals binnen The Open Group, bijvoorbeeld. Functiescheiding eist onafhankelijkheid. Neutraliteit is zelfs een enorme faalfactor omdat bindingen ongrijpbaarheid en niet-open gedrag mogelijk maakt. 
 
Wat je nu in de markt zal zien is dat organisaties zich in een bepaalde functie zal moeten bewegen. Net als bij de architecten en de aannemers in Nederland, waarbij de bouwfraude een flagrant voorbeeld is hoe het bij de aannemers fout gegaan is. Een architectenbureau kan dan ook niet ge- of verbonden zijn aan een leverancier/aannemer omdat functies gescheiden moeten worden. Dat is in de IT-wereld nooit zo geweest en daar gaat dan ook ontzettend veel fout.  
 
Het bovenstaande heeft een draai aan je vraag heb gegeven. Ik hoop dat je begrijpt dat ik dit moest doen om de praktijk neer te kunnen zetten. De informatie- en IT-sector is, om allerlei redenen, nog ver weg van functiescheiding. En toch zal nu, nu IT eigenlijk vrijwel alles kan wat gevraagd wordt, de nieuwe wereld gaan worden. Kwestie van volwassen worden. 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Hallo Steven 
Bedankt voor je reactie. Ik ben het volledig met je eens dat Montesquieu het niet precies bedoeld heeft zoals ik het geinterpreteerd heb. Hoe zou hij ook kunnen... Ook zal ik de laatste zijn om te beweren dat mijn gedachte al volledig uitgewerkt was toen ik hem opschreef.  
 
Daar was het me ook niet om te doen. Ik wilde de discussie aangaan over de relatie tussen architectuur, \"governance\" en \"management\" in de \"SO(A)\"-wereld. Wat bedoelen we ermee, welke partij moet waar verantwoordelijk voor worden gesteld en wat mogen we van ze verwachten? Dat waren voorheen al belangrijke onderwerpen en in een wereld waarin we meer en meer moeten gaan vertrouwen op diensten, geleverd door derden wordt het belang ervan alleen maar groter! 
 
De metafoor van de trias politica heb ik, ondanks dat hij een beetje mank gaat, geintroduceerd omdat iedereen hem herkent en omdat deze de noodzaak tot functie-scheiding onderstreept. Uit jouw reactie maak ik op dat ook jij die noodzaak onderschrijft.  
 
Jij schrijft dat (IT-)architectuur niet beschouwd kan worden als de IT variant voor de wetgever. De strategie en de richtlijnen worden niet binnen het IT-veld uitgevaardigd, maar worden vastgesteld door de top van het bedrijf. Dat onderschrijf ik, maar als we de reikwijdte van de discussie beperken tot het IT-veld dan komt de architectuur als het goed is nog het dichtst in de buurt. Zij zou de strategie en richtlijnen van het bedrijf moeten weerspiegelen. Zij zou er de vertaling van moeten vormen in IT-termen. Anders is er iets grondig mis. Daarover gaat juist die jarenlange nadruk op \"business-IT-alignment\". Dit klopt overigens ook met jouw voorbeeld van de verschuiving van product- naar klantgericht, die direct in de architectuur weerspiegeld wordt. 
 
Dat bouw en beheer (\"management\") deel uitmaken van de uitvoering, daar zijn we het denk ik wel over eens. Dat je hieraan gerelateerde activiteiten makkelijk kan uitbesteden, is ook geaccepteerd. 
 
Blijft over \"governance\" (is daar eigenlijk wel een goed Nederlands woord voor?). Daarin zit zowel besluitvorming (welk alternatief moet gekozen worden? moet dit project wel of niet worden uitgevoerd? past dit pakket wel of niet in de architectuur?) als controle op de uitvoering (wordt het werk wel goed gedaan?). Dat maakt het wat moeilijker te plaatsen. 
 
Hoe zou jij nu die broodnodige functie-scheiding invullen? De regie kun je niet uit handen geven, schrijf jij. En daar IT steeds meer onlosmakelijk verbonden raakt met de bedrijfsprocessen, is het maar de vraag of je de regie over de IT wel uit handen kunt geven. Dat standpunt lijkt redelijk, maar het stelt ook hoge eisen aan de IT professionals binnen bedrijven. Want wil je ter dege \"vendor management\" kunnen doen en zo de regie in handen houden, dan moet je dus boven de leveranciers staan en zeer goed kunnen doorzien of wat zij aandragen ook jouw problemen oplost. En dat is geen sinecure!  
 
(Ik ben er trouwens van overtuigd dat goed \"vendor management\" niet alleen in het belang van de klant, maar OOK in het belang van de leverancier is!) 
 
Ik ben het met je eens dat je als leverancier (of werknemer van een leverancier) op enig moment in enige situatie maar in een van de mogelijke rollen kan zitten. Of je adviseert de regie, of je voert uit, of je controleert (in opdracht van de klant). Je kunt wel op verschillende tijdstippen bij verschillende klanten verschillende rollen aannemen.  
 
Misschien was mijn metafoor toch nog niet zo gek, maar moeten we er nog wat langer op broeden om alle puzzelstukjes op hun plaats te krijgen...

Beste Lydia. 
 
Ja, ik denk dat functiescheiding absoluut noodzakelijk is en zal zijn in “onze” wereld. Net als dat Montesquieu hem in zijn driedeling onmisbaar verklaart in zijn wereld. 
 
In mijn idee gaat het principe van functiescheiding niet mank. Zoals ik hem nu ingevuld zie in de informatie & IT-sector gaat hij mank omdat onjuist ingevuld wordt. Dat is mijn betoog. 
 
Ik weet niet of ik je helemaal begrijp als je zegt dat “(IT-)architectuur niet beschouwd kan worden als de IT variant voor de wetgever”. Mijn probleem daarbij is dat IT-architectuur geen wetgever is. Wetgever is een functie, “iets” dat door een mens of door een organisatie van mensen “gedaan” wordt: wet geven. Architectuur, welke dan ook, is geen functie en kan dus geen wetgever zijn. In beperkte visie zou je architectuur als de wet kunnen zien. Dat zou echt een erg mechanisch gebeuren zijn, alsof een architectuur een model zou zijn. Ik weet dat IT-architecten en (IT-)Enterprise Architecten architectuur zo vaak benaderen en dat past ook een beetje bij het tactische niveau in de organisatie waar IT thuis hoort. Een soort maakbare wereld. 
In lijn met je redenering zou er een wetgever moeten zijn die de wet geeft. Net als dat er een instantie moet zijn die de gegeven wet handhaaft. Dezelfde wet, dus. Architectuur is veel breder, maar dient ook gegeven en gehandhaafd te worden. Stellen we hier architectuur, om verschil te kunnen maken, gelijk aan visie, dan zal immers de visie gegeven moeten worden en wat gebeurt binnen de visie moeten passen.  
 
Je spreekt over strategie en richtlijnen rond het IT-veld en beperkt de discussie tot dat IT-veld. Dat is een lastige. (IT-)Enterprise Architectuur en IT-architectuur, twee wat andere manieren van kijken naar en vanuit hetzelfde: IT, zijn feitelijk afgeleiden. Niet via formules, maar via een bepaalde mate van interpretatie. In termen van strategische bedrijfsmiddelen spreken we niet over IT. IT is als hulpmiddel een kapitaalgoed, terwijl informatie (& communicatie) zelf een bedrijfsmiddel is. Strategie, richtlijnen enz. worden in de praktijk steeds meer niet om IT geformuleerd, maar rond de informatie waar een organisatie mee te maken heeft en dient te hebben. Daarom strekt het IT-veld zich uit tot het tactische niveau, niet hoger. Dat heeft niets te maken met het feit dat IT van strategisch belang is voor vele organisaties. Auto’s zijn dat ook, maar toch hebben we een Ministerie van Verkeer en niet van auto’s.  
 
Zoals ik al gezegd heb is architectuur feitelijk (onderbouwde) visie. Uitgewerkt tot op het niveau van regels en richtlijnen die gehandhaafd moeten worden om de visie überhaupt te kunnen realiseren. Om de juiste IT in te kunnen zetten heb je slechts in tweede instantie IT-richtlijnen nodig. Het is veel belangrijker om te weten dat een Bank primair slechts met 3 soorten informatie te maken heeft. De basis om richtlijnen enz. uit te kunnen vaardigen op basis waarvan goed passende IT gevonden en ingezet kan worden. Niet de (IT-)Enterprise Architectuur of de IT-architectuur geven de bedrijfsrichtlijnen die nodig zijn om de goede IT in te kunnen zetten, maar de visie op de informatie van de organisatie. Het woord informatiearchitectuur wordt in de IT-wereld volledig anders gebruikt, maar dat zou een goed woord hiervoor zijn. 
 
IT-Business alignment is in feite een tweede kanteling van idee en werken. De eerste was het niet meer in separate computers denken en werken, maar het door kanteling creëren van een consistente IT-infrastructuur. De tweede is dan het kantelen van het denken in applicaties naar het denken in applicatie (en gegevens) infrastructuren. SOA is daar feitelijk een nieuwe versie van.  
De derde kanteling zit buiten de IT-wereld. Het heeft te maken met het niet meer bedenken van specificaties per te creëren applicatie, maar het neerzetten van een consistente basis, een nogal ander soort architectuur, door de kennis van de informatie bedrijfsbreed vast te stellen en te beheren. In feite een hoeveelheid kennis waaruit specificaties voor een te ontwikkelen nieuwe IT-oplossing afgeleid kan worden. We komen dan ontzettend dicht bij wat we vraagorganisatie noemen, of retained organisation. Het heeft alles met regie te maken. 
Natuurlijk klopt dit bij de verschuiving van product- naar klantgericht in mijn voorbeeld, want uiteindelijk zal een specificatie een bij de organisatie passende (= aligned) oplossing moeten bieden binnen het IT-landschap. SOA is dan niet meer of minder dan het ordenen van die IT-infrastructuur (applicatiedeel), zodat IT-oplossingen beter blijven aansluiten bij die organisatie.  
Jammer alleen dat de IT-wereld vaak nog niet het begrip service in SOA gelijk wil stellen aan dat zelfde woord in het bekende acroniem SLA. Grappig trouwens dat iets als SAAS er wel zoveel dichter bij komt. 
In mijn idee is IT-Business alignment dus het punt waar het bij IT om gaat, maar niet het einde van het denken. De genoemde derde kanteling creëert een goede vraagsituatie, waarbij IT-business alignment de top van de aanbodsituatie is. Waar informatiekunde de IT-wereld tegenkomt, waar strategisch niveau het tactische niveau tegenkomt. 
 
Wat jij bouw en beheer (\\\"management\\\") noemt vertaal ik in te managen werkzaamheden rond investeringen (wat IT-projecten genoemd worden) en exploitatie (wat beheer genoemd wordt) werkzaamheden. Als ik dit naar vraag/aanbod of strategisch/tactisch moet vertalen, dan zijn deze werkzaamheden en hun management zoals aanbod als tactisch. En ja, onder de juiste voorwaarden en condities outsourcebaar. 
 
Governance: waarom niet gewoon management? To govern, regeren. Is Balkenende een manager? 
 
Het maken van strategische keuzes is een normaal principe binnen strategisch management. Koop ik een vliegtuig, of bouw ik er zelf één? En als ik er één koop, moet dat vliegtuig dan vooral snel kunnen, of comfortabel zijn? Of moet het vooral veel kunnen vervoeren? Moet het “groen” zijn, dus vooral weinig milieubelastend en ga zo maar door. Vul voor vliegtuig een ander kapitaalgoed in, zoals IT, en het past precies. De architectuur om dit te kunnen is echter een kompleet andere dan een (IT-)Enterprise Architectuur of een IT-architectuur. Die laatste twee gaan over de IT-infrastructuur, terwijl de eerste over de organisatie en haar behoefte aan informatie gaat. 
Of het werk goed gedaan wordt? Is dat een IT-issue, of een strategisch? Als je het goed zou doen zou je pas met IT beginnen als er sluitende afspraken met “gebruikers”management zijn gemaakt. Tenzij die afspraken niet goed zijn is het zaak om binnen de afspraken te blijven. IT-management probleem, waarbij zij verantwoording afleggen aan de organisatie. Aanbod naar vraag, tactisch naar strategisch (dit laatste bij het oplossen van grotere problemen). In functiescheiding is het dus de stellende/bepalende (jij zegt wetgevende) functie die afspraken voor de vraagzijde maakt, en is het de uitvoerder, hier de IT-ers cq. IT-management, die de opdracht aanneemt (aannemer is voor investering of exploitatie), dus uitvoerend (jij zegt uitvoerende macht). Auditors (ik noem ze informatiekundigen, of informatiearchitecten in een compleet andere betekenis dan waar de IT-wereld ze in drukt) controleren dan voor de vrager of de uitvoerder het goed doet. Uit de hoek van die controleurs komen ook de mensen die de visie/architectuur/wet kennen en die via specificaties/bestekken vertalen naar uitvoerders. Binnen die architectuur kan de uitvoerder dan invulling geven aan de te maken oplossing. En zo is functiescheiding rond, en zelfs vertaalbaar naar onze bekende Baron. 
 
Hoe is functiescheiding zou invullen? Het staat hierboven eigenlijk al. Met nog een paar punten. 
 
1. Het is principieel onjuist dat bedrijfsprocessen en IT onlosmakelijk met elkaar verbonden zijn. Een flagrant voorbeeld is het idee dat geld uitgeven voor een bank gelijk is aan een ATM, een flappentap. In de 90-er jaren dacht men ook dat het bedrijfsproces geld-uitgeven niet meer nodig was omdat er ATM’s waren, en hoe verkeerd was dat. Nu er veel meer kanalen zijn is dat bedrijfsproces weer in volle glorie aanwezig, en is de alignment per kanaal een belangrijk middel voor vraag en aanbod om elkaar te vinden. 
 
2. Richtlijnen voor de inzet van IT hebben slechts in tweede instantie te maken met IT. Zeker nu IT onder de motorkap aan het verdwijnen is zijn de richtlijnen enz. steeds minder op IT dan op het bedrijfsmiddel Informatie. Een voorbeeld. Stel je stelt een lange reeks richtlijnen en uitgangspunten op waaraan een IT-leverancier moet voldoen om een gewenste IT-oplossing te realiseren. Wat je dan vooral doet is je IT-oplossing duurder maken! Zeker als ook nog eens de IT-oplossing door een IT-leverancier geëxploiteerd moet worden. Want waarom zou je uitgangspunt IBM zijn als je bepaalde informatie op een bepaalde manier nodig hebt? Misschien heeft een IT-leverancier wel een perfecte oplossing op HP draaien en kan hij die zo kopiëren en inpassen in wat een organisatie al heeft. 
Ik weet dat dit vloeken in de IT-kerk is, maar het is wel de discussie van het onder de motorkap verdwijnen. Als jij MS-Word in SAAS ter beschikking krijgt, doet het er dan iets toe of dat op Windows, Linux of MVS draait? Of met EMC of Iomega harde schijven gewerkt wordt? En dat is precies de omslag. 
Regie moet zo min mogelijk te maken hebben met IT. Maar organisaties moeten wel vertellen en afdwingen dat ze de “services” krijgen die ze nodig hebben. Daar zit de regie, niet in de IT-wereld. Daar zit IT-management. 
 
3. IT-professionals dienen niet gezien te worden als materiedeskundigen, en dat worden zij wel. Dat betekent niet dat een IT-professional geen verzekeringsdeskundige kan of mag worden, maar dan is hij/zij dus geen IT-professional meer. Ergo: IT-professionals die zich zo zwaar in bedrijfsproces storten dat ze zich als materiedeskundigen gedragen luisteren niet meer naar de echte materiedeskundigen. En creëren dus iets dat zij als IT-professional vinden dat materiedeskundigen nodig hebben omdat ze hier en daar aan die materiedeskundigheid hebben geroken. Hoe was het ook weer: 70% van de IT-projecten leveren niet op wat de organisatie graag wilde. 
Mijn ervaring, als informatiekundige met de nodige IT-ervaring, is dat als je echt in gesprek gaat met materiedeskundigen je dingen hoort en ziet waar zo vaak overheen gewalst is en wordt dat je er griezelig van wordt. Tegenwoordig licht ik vaak organisaties door op informatie en IT, en de problemen zijn zo vaak zo logisch en flagrant dat je echt niet begrijpt hoe het in hemelsnaam zo geworden is. En je wil niet weten hoe groot de uitdaging dan is om het weer naar iets normaals bij te buigen met alle belangen en meningen.  
In mijn ervaring is de IT-professional al zwaar genoeg belast als zij/hij zich bezig houdt met IT en echt goed luistert naar de organisatie. Dat gebeurt alleen zo weinig. 
 
4. Vendor management is voor mij niet gelijk aan vraagmanagement. Vraagmanagement is namelijk ook boven de interne IT-ers. Ook zij realiseren investeringen in IT of exploitatie van IT voor de organisatie. Regie strekt zich daarmee over ALLE IT-investeringen en -exploitatie uit, zonder uitzondering. Dus ook over alle IT-professionals. 
Vraagmanagement en regie baseert zich op kennis van informatie en, in 2e instantie, over hoofdlijnen voor informatie hulpmiddelen als IT. 
 
Ja, goed vraag/vendor management is natuurlijk goed voor organisatie en IT-leverancier. Stel dat een organisatie goed weet wat ze wil (kennis van hun informatie) en dit ook goed kan duidelijk maken, dan kan de IT-leverancier die dat begrijpt ook beter maken wat nodig is. Simpel. Als de IT-leverancier eerst nog eens, onder druk van tijd en geld, moet gaan uitzoeken wat de organisatie wil, dan is de kans dat het nodige divergeert zo ontzettend groot. Met de gevolgen die we op dit moment haast overal zien. 
 
Ik zie dus, in wat jij Trias Politica noemt, bepalend/stellend (wetgevend), uitvoerend en controlerend (rechterlijk). Je zegt: “Of je adviseert de regie, of je voert uit, of je controleert (in opdracht van de klant)”. De regie binnen de klant is bepalend/stellend cq. wetgevende macht. De IT-leverancier is de uitvoerende macht. Advies aan regie en controle voor klant ligt wat mij betreft niet ver uit elkaar. Ja, de rol is anders want de eerste begint vooraf en de tweede is achteraf, maar beide zijn feitelijk controlerend. De eerste legt vast wat de regie wil en kan dit ook uitleggen, de tweede kijkt of de uitvoerder de uitleg ook begrepen heeft. We weten dat het handig is om de uitlegger en de auditor, de controleur, gescheiden rollen te laten zijn. In meer IT-termen: informatie analisten en testers zijn verschillende vaklieden. Is het handig om de informatie analist te laten testen? Hangt ervan af, want de manier van werken en de bijbehorende is duidelijk anders. 
 
Natuurlijk kan je op verschillende momenten meer rollen hebben. Mijn ervaring is wel dat een adviseur geen manager moet zijn, en andersom. Uitvoerenden die door willen groeien zullen dan ook vaak bij doorgroeien moeten kiezen tussen vakinhoudelijk en managerial. Van uitvoerend naar adviseur is dan meer in lijn, want managers dienen zich te richten op het proces en minder op de inhoud. En dat is een hele omschakeling. En dat alles nog buiten het vak, maar wel als richtlijn rond de te scheiden functies. 
 
Tja, metaforen kan je niet altijd kompleet doorvoeren. Toch is functiescheiding, zoals ik eerder zei, een absolute noodzaak als we naar een volwassen informatie & IT-sector willen. Alleen zijn er nog een reeks andere principes neergezet moeten worden. Neem nu bijvoorbeeld de linking-pin van Rensis Likert. De driedeling sturend, uitvoerend en adviserend/controlerend herhaald zich dan over de niveau van de organisatie, waarbij een uitvoerend orgaan op een hoger niveau een sturend orgaan kan/zal zijn op een lager niveau, en zo dus de linking-pin, de vertaler. Logisch in vendormanagement, want de uitvoerende vendor zal ook sturend zijn/haar voor zijn personeel. Enz. Over functiescheiding gesproken….. 
 
 
Steven van ’t Veld 
 
 
\n  
 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken 
 
 

Hallo Steven 
Hoewel dit een erg interessante discussie is en ik ook blij ben met jouw extensieve reacties heb ik het even moeten laten afweten.  
Jouw laatste reactie omvat zoveel verschillende gezichtspunten, dat ik er voor het gemak maar een paar uit geisoleerd heb om op in te gaan.  
(1) Je schrijft dat \"...Het is principieel onjuist dat bedrijfsprocessen en IT onlosmakelijk met elkaar verbonden zijn...\" en dan geef je het voorbeeld van de misvatting dat betalingsverkeer langs andere kanalen zou stoppen met de invoering van de ATM. Ja inderdaad, dat klopt. Maar zo bedoelde ik het niet. Wat ik bedoelde is dat het juist steeds meer transparant wordt langs welk kanaal een dienst geleverd wordt en dat bij een aantal van de heden ten dage beschikbare kanalen IT niet meer is weg te denken. Dat het gaat om de bedrijfsfunctie, langs welk kanaal die ook aangeboden wordt, ben ik met je eens.  
(2) Je refereert aan het linking-pin principe van Likert. Ik kende het nog niet maar enig zoeken leverde voldoende interessante informatie op. Als ik het goed begrepen heb, zegt Likert dat elk organisatie-niveau vertegenwoordigd moet worden op het niveau daarboven, door een zogenoemde \"linking pin\". Dit is bijvoorbeeld een afdelingsmanager, die zijn afdeling vertegenwoordigt in het landelijke management team. De koppeling is \"enkel\", gerealiseerd door een (1) persoon. Volgens andere bronnen zou je een \"dubbele koppeling\" moeten hebben, omdat de enkele koppeling van Likert als nadeel heeft, dat de linking pins zowel de belangen van de onderliggende als de bovenliggende laag moeten behartigen.  
Wanneer we dit model, met enkele of dubbele koppelingen vertalen naar Design Authorities op verschillende lagen, hoe komt het er dan uit te zien? Hoe moet een project DA vertegenwoordigd worden in een programma DA en een programma-DA in een ondernemings-DA? Hoe gaan deze lagen zo effectief mogelijk met elkaar communiceren teneinde het gezamenlijke doel - ondernemingsbrede governance (=bestuur?) te bereiken. 
Uiteraard moet bij dit alles goed in de gaten worden gehouden, dat \"governance\" geen doel op zich is, maar een middel om allerlei bedrijfsdoelen te bereiken. Bedrijfsdoelen zouden bijvoorbeeld kunnen zijn betere, uniforme dienstverlening en kostenbesparing door consolidatie van processen. Voor zover deze door IT ondersteund worden, horen daarbij IT projecten, die op elkaar aansluiten. Naar blijkt geen triviale onderneming!  
En ben je wel klaar als de organisatie-structuur met DA\'s en linking pins een feit is? Immers op elke laag moet de visie begrepen en ondersteund worden. In de bekende theorie over architectuur-methodieken en bijbehorende governance / management onder architectuur heb ik weinig kunnen vinden over de intermenselijke aspecten van governance...

Beste Lydia, 
 
Een goede discussie neemt tijd. En ik ben snel geneigd om (te) veel te schrijven omdat ik denk dat het af en toe beter is om meer woorden te gebruiken om helder te maken wat ik bedoel. Soundbytes worden te vaak fout geïnterpreteerd. 
 
Ad (1) 
Dan zijn we het eens. Mijn zorg is dat ik steeds zie dat mensen denken dat het bedrijfsproces niet meer bestaat omdat het geautomatiseerd is. Soms alsof IT-beheerders daarmee business verantwoordelijkheid overgenomen hebben. Maar dat IT belangrijk is, dat is helder. 
 
Ad (2) 
Ja, dat is wat ik bedoel. Als je met een enkele koppeling werkt is er ook een eenduidig “kanaal” waarlangs gecommuniceerd wordt, en dat voorkomt misverstanden. Maar de man of vrouw die dat kanaal vormt is natuurlijk wel cruciaal. Als iemand niet in staat is om goed te vertalen of iemand die dat gewoon niet wenst te doen, dan wordt het echt moeilijk. Misschien is het dan tijd om zo iemand te vervangen. Sommige mensen zijn erg goed in dubbele agenda’s en eigen belangen (of hebben daarvoor geleerd), maar zoiets levert altijd wel ergens een probleem op, zeker op de langere termijn.  
 
Een dubbele koppeling zou dan “1 naar boven rapporteren, en 1 naar beneden vertellen” zijn. Zoiets past in ons poldermodel, want het geeft “ondergeschikten” de kans om zich een oordeel te vormen over hoe hun kampioen de verantwoordelijkheid voor hun werk draagt. Een soort hoefijzer.  
Heeft voordelen, maar ook nadelen. Stel dat de bovenliggende groep het niet eens is met deze kampioen en de mening van het hogere niveau komt via de andere lijn naar beneden: wat bereik je dan? Heeft je kampioen het niet goed gedaan, of is de mening van boven is niet goed. De groep kan verdeeld raken omdat enkele de originele mening aanhangen, en anderen de mening van de hogere groep. Een ding is haast zeker: je krijgt discussie. Zoals gezegd: polderen schijnt ons met de paplepel ingegeven te zijn, maar je snijdt wel ontzettend in op de verantwoordelijkheid van die kampioen. Lijkt me veel onhandiger dan dat het voordelen heeft. En, zoals gezegd, als een kampioen niet competent is moet je maatregelen nemen. 
 
Voordat ik op het laatste deel van je antwoord in ga heb ik een vraag. Met design authority, bedoel je daarmee iemand die verantwoordelijk is voor een ontwerp op enig niveau? Iemand die in een team, al of niet als leider of als primus inter pares, de leiding heeft, de beslissingen neemt en die daar dan ook uiteindelijk de verantwoording voor neemt? En als zijn/haar verantwoordelijkheidsgebied een deel van een geheel, dat zij/hij ervoor gaat staan om wat in dat deel te verantwoorden naar gelijken op andere gebieden? 
Als ik deze uitleg volg, dan verdedigd een linking pin de mening van zijn/haar groep. Er is veel gesproken over platte organisaties om het aantal lagen terug te brengen. Jouw baas, IBM, had rond 1980 9 of 10 management lagen terwijl Philips, die vergelijkbaar groot was, er 17 had (de getallen kunnen anders geweest zijn, maar het was zoiets). Breder naast smaller, dus. Ze werkten ook allebei, alleen in de ene zat meer “vet” dan in de andere.  
 
Het voorbeeld van DA’s, als ik je goed begrijp, is ook een lastige in dezen. Je spreekt namelijk op alle niveaus over design beslissingen, waarbij alleen de scope wisselt. Design van de Blueray speler, design van de PC kast, design van de gehele PC enz. Dat zijn inhoudelijke discussies, en afstemmingen (gelijke aansluitkabeltjes voor verschillende componenten enz.). 
 
Als je naar een organisatie kijkt zie je een standaard niveau indeling strategisch (beleid), tactisch (bestuur), operationeel (beheer) en de operatiën zelf. Strategisch is als een papierconcern besluit om een handelshuis te worden. Tactisch is als te verkopen goederen ingekocht worden en groepen mensen aan het werk gezet moeten worden om bepaalde onderdelen af te stoten, en andere te vormen. Operationeel management doet de inkoop van te verhandelen wollen truien in China en stuurt mensen aan die de fabrieken bezoeken. In zo’n geval rapporteert de operationeel manager over de voortgang van de inkoop, onder andere van truien in China. Operationeel management vertaalt dat naar de voortgang van de inkoop in het algemeen, want het gaat niet alleen om truien maar ook om 1.000 andere artikelen. En de tactisch manager geeft de inkoop en verkoop cijfers door aan het topmanagement, plus de voortgang van de verkoop als geheel en de vorming van bedrijfsonderdelen. Strategisch management kan dan overzien of de transitie snel genoeg gaat, of dat bijgestuurd moet worden. 
 
Stel dat je 2 mensen van een operationeel management naar tactisch management stuurt, je hoefijzer. De ene vertelt wat de voortgang is, de ander moet zijn mond houden en alleen luisteren. Dan komen ze terug, en degene die geluisterd heeft verteld aan de ondergeschikten wat de tactisch manager gezegd heeft. Waarna een discussie kan ontstaan tussen spreker en luisteraar, tussen luisteraar en uitvoerenden, tussen …. en ga zo maar door. Heeft dat nut? Klinkt een beetje Japans, waar regelmatig spionnen ingezet werden om geheim te rapporteren. Ik zie dit niet zo goed. Je laat mensen over managers, governors als je het governance wilt noemen, zo beoordelen. Feitelijk gewoon overzien op het niveau waarop je werkt, en dan de juiste beslissingen nemen om e.e.a. in de juiste richting verder te krijgen. Daarbij is wat een strategisch governor doet nogal anders dan wat een operationeel governor doet; die mate van detail wil de strategisch cq. corporate governor gewoon niet weten, want het kost haar/hem tijd en daarvoor heeft hij/zij juist die tactische vertaler. 
 
Dit argument wordt zwakker als je over iets als design en deeldesign praat. Daar blijf je dan ook tussen tactisch en operationeel zweven. Hoewel, wil degene die op PC-totaal-niveau werkt wel weten hoe een moederbord precies in elkaar gezet wordt? Hij/zij kan er feitelijk zo weinig mee. 
 
Governance gaat feitelijk over verantwoording hebben, en dragen. Breder op hoger niveau, smaller op lager niveau. Samenvatten en uiteenrafelen is dan de kunst van de manager, waarbij het interpreteren en de juiste beslissingen nemen om goed voort te gaan zijn positie bepaalt.  
 
Je zegt “Bedrijfsdoelen zouden bijvoorbeeld kunnen zijn betere, uniforme dienstverlening en kostenbesparing door consolidatie van processen.” Maar dat zijn geen bedrijfsdoelen. Een bedrijfsdoel is dat je de beste IT ter wereld wilt leveren. Of de hoogste kwaliteit zorg. Of de beste dagelijkse boodschappen. Dat je dat doet door….. is een tactische vertaling. Kostenbesparing is hoogstens een randvoorwaarde, of een eis, maar geen doel op zich. Als dat zo zou zijn, dan heeft elk van de ongeveer 17 miljoen organisaties in Nederland hetzelfde doel: winst, en dat zou toch een vreemde concurrentie opleveren. Ik weet niet hoeveel dienstverlenende organisaties we in Nederland hebben, maar die zouden dan het doel betere, uniforme dienstverlening hebben.  
 
Als je het dan hebt over consolidatie van processen is dat een keuze die je maakt als tactisch manager (kan ook nog wat lager trouwens, afhankelijk van de processen). Die keuze kost je middelen en als de keuze verkeerd is geef je die middelen voor niets uit. Slecht management. Evenzo de keuze om IT in te zetten, in plaats of tegelijk met het consolideren van je processen. Pakt ook nog vaak erg verkeerd uit. 
 
Maar ik ben met je eens dat IT gemanaged wordt op tactisch niveau. Daar hoort het ook thuis: het is immers een hulpmiddel. Op strategisch niveau is IT een detail, een manier van oplossen. Met enige uitzonderingen als bijvoorbeeld een organisatie bijvoorbeeld zelf iets met IT in de markt doet. Normaal is niet IT het strategische middel, maar is informatie dat. Organisaties moeten immers weten om te kunnen functioneren, ze hebben informatie nodig om hun kennis van zaken up-to-date te houden. Welk middel of kanaal ze daarvoor gebruiken wijzigt steeds, maar de behoefte aan informatie blijkt veel stabieler. Die is immers ingegeven door de functie die men in de organisatie heeft. Dat men daarbij steeds mooiere snufjes gebruikt is mooi meegenomen, geeft nieuwe mogelijkheden. 
 
Daarom is het ook zo dat IT wel degelijk strategisch ingezet kan worden in een organisatie, en dus heel belangrijk kan zijn, maar dat het daarom nog geen strategisch bedrijfsmiddel is. Bedenk waarom je als organisatie IT nodig hebt. Niet omdat het zo mooi knippert en in de vensterbank staat (hoewel…) maar juist omdat het de juiste informatie op de juiste tijd, plaats, kwaliteit enz. verzorgt. Tenminste, als we over administratieve IT praten. Het is dus ook de kennis van je informatie die je vraag ondersteunt. Als je dat goed doet heb je kans dat je een keer een integrale, afgestemde, agile informatievoorziening realiseert. Applicatie integratie achteraf, bijvoorbeeld, is een wassen neus, en vrijwel altijd onmogelijk om echt goed te doen. Tenzij de grondslag goed is, en dat doe je met je kennis van je informatie. En dat geldt ook voor het aansluiten van projecten. 
 
Nee, je bent niet klaar met de organisatie structuur met DA’s en linking pins een feit is. Als dat zo zou zijn kan je alles programmeren en het licht uitdoen op kantoor. Mensen, competente mensen zijn nodig om het te laten werken. Daarom lijkt ook geen autofabriek op de andere, terwijl ze tegenwoordig toch allemaal vergelijkbare auto’s produceren: 4 wielen, een stuur, een vergelijkbare vorm enz. Een competent manager wordt aangetrokken om voor haar/hem gestelde doelen te vertalen in dingen die werken. Op strategisch niveau zijn dat andere dingen dan op operationeel niveau, maar zo werkt het wel. De vertaling die iemand maakt is vooral ingestuurd door haar/zijn kennis (opleiding), ervaring en persoonskenmerken. Huur je de ene in, dan wordt het anders dan als je de andere inhuurt. Allebei kan even goed werken, of niet. Maar structuur is maar 1 van de kenmerken, net als functie, schoonheid en harmonie. En vele andere. Intermenselijke aspecten bij governance cq. management is cruciaal. Wel eens een manager gezien die niet met mensen om kan gaan? En hoe lang zat zij/hij daar nog? Governance wordt vaak uitgelegd als regels. Moet je je voorstellen dat je regels goed gehanteerd worden, maar dat er niet gecommuniceerd kan worden. Werkt het dan? Ja, als het geautomatiseerd wordt misschien, want er zijn alleen nog maar regels. Vraag maar eens na op Nijenrode hoe belangrijk psychologie en sociologie voor managers is. 
 
De huidige architectuurmethodieken zoals TOGAF, DYA, ZIFA en hoe ze allemaal tegenwoordig mogen heten werken ook niet of nauwelijks. De wereld, zeker op hogere niveaus, is gewoon niet maakbaar. Zeker in Nederland niet, met ons poldermodel. Dit soort architectuurmethoden zijn de manieren van aanpak van auto ontwerpers en nog niet eens van de monteurs, niet van strategen en mensen die ruimtelijk ordenen. Dat laatste hoort namelijk niet onder IT, want structuur en functie zijn daar alleen relatief belangrijk. Er is nog zo’n lange weg te gaan… Maar voor wie houdt van een uitdaging…. 
 
Steven van ’t Veld 
Steven.van.t.Veld (at) AIM.nl

Hallo Steven 
De stelling, waarmee deze discussie ooit gestart is, luidde dat een goede  
 
functie-scheiding cruciaal is om SOA governance te kunnen realiseren. We zijn hier in de loop van  
 
de verschillende reacties nogal van afgedwaald. Het lijkt me nu een goed moment om hier weer even  
 
op terug te komen. 
Deze stelling had in meer dan een (1) opzicht een smallere scope dan de discussies die we  
 
tot nu toe gevoerd hebben. 
Het ging ten eerste om SOA governance. We hebben eigenlijk nog niet echt de moeite genomen  
 
om dit begrip te definieren. De meningen zijn erover verdeeld wat SOA governance is. Alle bronnen  
 
zijn het erover eens dat SOA governance en IT governance nauw gerelateerd zijn. Sommigen zijn de  
 
mening toegedaan dat SOA governance een superset is van IT governance (m.a.w. SOA is een prefix  
 
aan het worden voor de nieuwe manier van IT bedrijven en pakt daarnaast ook een stuk "business  
 
alignment" mee); Anderen stellen dat SOA governance en IT governance overlappende (niet geheel  
 
disjuncte) verzamelingen zijn. 
Het algemene beeld is dat wanneer ondernemingen een Service Oriented Architecture gaan  
 
implementeren governance veel meer dan anders nodig is. Immers de belofte van SOA is, dat een  
 
juist gekozen scala van (IT-)diensten een onderneming een stuk slagvaardiger maakt dan een  
 
allegaartje van losse en vaste IT- en andere componenten. Zonder goede besturing (governance)  
 
bestaat het risico, dat overal pilot-SOA-projecten ontstaan, die in het wilde weg "diensten" gaan  
 
creeren, die geen enkele samenhang vertonen. Het beoogde doel van SOA wordt dan niet bereikt. [En  
 
inderdaad dat doel -business/IT alignment- is geen bedrijfsdoel maar een IT-doel].  
En als dat gebeurt leidt de SOA propositie ernstige imago-schade. Bedrijven raken  
 
teleurgesteld in SOA en stoppen met erin te investeren. Ze blijven zitten met halve oplossingen en  
 
hobbelen door naar de volgende hype. Dat is niet in het belang van de bedrijven die ook op het  
 
vlak van hun IT meer "dienstgericht" willen gaan opereren; het is ook niet in het belang van de  
 
bedrijven, die SOA aan de man proberen te brengen. Zo bezien MOET SOA governance dus. 
MAAR: (a) was het niet altijd al de bedoeling dat IT diensten ondernemingen zouden helpen  
 
om slagvaardig te kunnen opereren en moesten deze niet altijd al op de bedrijfsbehoeften en  
 
-doelen afgestemd zijn?  
(b) Was de besturing/controle (governance) vroeger (=in het pre-SOA tijdperk) niet ook al  
 
een behoorlijke uitdaging? Oftewel grijpen we de SOA hype niet gewoon aan om dit probleem opnieuw  
 
onder de aandacht te brengen, maar nu met andere woorden? Mijns inziens zijn business-IT alignment  
 
en IT governance en management zeer belangrijk, ook zonder SOA. Dat SOA dit belang extra  
 
onderstreept is hooguit mooi meegenomen.  
(c) Waarom zouden we de problemen nu ineens wel kunnen oplossen? Zouden we niet moeten  
 
voortbouwen op wat er al is en vooral heel goed onderzoeken, waar het vroeger fout ging en van de  
 
fouten leren?  
De grote vraag is dus of SOA governance wel iets nieuws is. Waarschijnlijk is dat maar  
 
zeer ten dele het geval; Alleen het registreren en documenteren van "webservices" en fatsoenlijk  
 
change management daarop plegen is een nieuwe techniek. De rest is oude wijn in nieuwe zakken. 
De SOA governance & management methodiek die ik bestudeerd heb schetst hoe je een  
 
governance model kunt implementeren in een organisatie. Het SOA Center of Excellence speelt daarin  
 
een hoofdrol. Dat SOA CoE kan je opvatten als een soort DA voor SOA. 
Het is goed om een gestructureerde methodiek te hebben voor het implementeren van SOA  
 
en/of IT governance. Ik ben het echter volkomen met je eens dat mechanische methoden voor  
 
implementatie van governance maar de helft van het verhaal zijn. De architectuur, in dit geval de  
 
SOA (maar hetzelfde geldt voor een andere enterprise architectuur, referentiemodel of Component  
 
Business Model) moet door de hele organisatie begrepen en gedragen worden. Dat stelt hoge eisen  
 
aan de architectuur zelf. De architectuur moet kloppen met het bedrijf, eenvoudig en duidelijk  
 
zijn en goed worden uitgelegd.  
Het stelt ook hoge eisen aan de uitdragers van de architectuur. De linking pins waar we  
 
het over hadden zullen blijk moeten geven van gedrevenheid, heldere communicatie en charisma (!)  
 
bij het uitdragen van de architectuur. 
Het tweede aspect van de stelling was de functie-scheiding. Daar zijn we nog steeds niet  
 
over uit, volgens mij. De discussie over de linking pins betreft vooral de problematiek van het  
 
doorgeven van boven naar beneden en andersom van belangrijke informatie om de tent draaiend te  
 
houden; het is dus veeleer het gevolg van het feit dat er scheidingen bestaan tussen  
 
besluitvormingsniveaus (strategisch / tactisch / operationeel). Het gaat niet in op het WAAROM van  
 
dergelijke scheidingen. 
De IT architectuur (of voor mijn part SOA) van een bedrijf is de zorg van dat bedrijf  
 
zelf. Een Telecom bedrijf baseert zich bijvoorbeeld op eTOM; de vertaling daarvan voor hun  
 
situatie is de verantwoordelijkheid van de eigen architecten-board. De aansturing van projecten  
 
die dit moeten invullen ook. En zo moet het. Je kan dit soort zaken namelijk niet uit handen  
 
geven. 
De eigenaar van de architectuur moet de hand strak aan de teugel houden.  
 
Verbeteringsvoorstellen, mits gestructureerd en gecoordineerd ingepast zijn natuurlijk welkom,  
 
maar de architectuur is WEL richtinggevend.  
Uitvoering van projecten die delen van de architectuur invullen kan je weer wel uit handen  
 
geven. De architectuur moet voldoende (maar niet teveel) ruimte overlaten voor invulling op  
 
onderliggende niveaus. De kunst is daarbij wel om zorg te dragen dat de uitvoerders binnen de  
 
marges van de architectuur blijven en geen zaken gaan aanbieden die hen toevallig goed uitkomen of  
 
de architectuur gaan ombuigen omdat dat beter past in het straatje van het product dat ze je  
 
verkocht hebben. Dan ben je voor je het weet overgeleverd aan "the world according to SAP, ORACLE"  
 
of andere grote aanbieders. Naarmate het product van de aanbieder meer in de richting van de  
 
bedrijfsprocessen kruipt en minder generiek ondersteunend is, wordt het ingrijpender. 
Ik denk dat dit een spannend krachtenveld is. Zou het helpen om een soort consumentenbond  
 
voor IT afnemers te hebben; zodat afnemers ervaringen uit kunnen wisselen en als groep in gesprek  
 
te gaan met de leveranciers? Dat houdt ook de leveranciers scherp en kan nare teleurstellingen aan  
 
beide kanten voorkomen...

Beste Lydia, 
 
Ja, onze discussie is wat afgedwaald. Goed dat je hem weer richt. 
 
Eerlijk gezegd weet ik niet of we zover afgedwaald zijn. Hangt inderdaad een beetje van je definitie van governance af. Governance is op zich gewoon bestuur, leiding. Met een governor, een bestuurder, een directeur, die bestuurt, leiding geeft (vrij overgenomen uit het woordenboek). Feitelijk een ander woord voor management, dus. En gezien de woorden directeur, gouverneur, besturen boven tactisch niveau in een organisatie. Met aan de top corporate governance, het leiding geven aan een totale organisatie, strategisch niveau.  
Wat gebeurt is dat dit woord gewoon overgenomen wordt door mensen, managers, op lagere niveaus in een organisatie. Het is lekker om je directeur te kunnen noemen, belangrijk. Dus alles heet nu ook opeens governance. En aan het begrip governance worden allerlei zaken gehangen die kennelijk aan management niet hangen. Vooral extra dingen over kwaliteit, controle, beheersing enz. SOx, Tabaksblatt, Basel, ISO 9000, IFRS, feitelijk allemaal regels en bureaucratie die zekerheden moeten geven. Feitelijk vaak schijnzekerheden, maar wel impliciet verwoord als je het woord governance gebruikt. 
 
Dan SOA. Ik ben hard opgeleid als bedrijfsinformatiekundige in de 70-er jaren. Wat we toen deden, doen we nu nog, alleen met andere mogelijkheden. Daarom zie ik SOA als vooral vakmatig goed inrichten. Vakmatigheid terug, na de uitstap via de hyperlink en groot-en-veel-ineens. 
Maar wat is SOA. Hetzelfde probleem als altijd: wat is (een) service. Voor de IT-professional: applicaties met toegevoegde waarde. Waarde toevoegen is waarom een organisatie de service wil hebben, ervoor wil betalen. Ergens moet toch het woord service in SLA het woord service in SOA raken. 
IT-ers kijken vrijwel altijd glazig bij dit verhaal. Service is iets technisch, een volgende laag bovenop wat we al hebben. Met vooral middleware ertussen, om de lagen aan elkaar te knopen. En wat zie je in de praktijk? Problemen met wat een service is. Vaak: de service is zo anders dan de operationele legacy ingedeeld is, en hoe vertaal je e.e.a. via middleware? Tot en met organisaties die vrijwel stil komen te liggen omdat hun middleware roodgloeiend staat en het niet meer aan kan.  
Vooral in de BI wereld is dit alles helder, en wordt veel meer geaccepteerd. Welke IT-er durft immers kritiek te hebben op de behoefte aan informatie van managers? Hun, en andere bazen. Dat de BI informatiebehoefte vrijwel uit de operationele systemen te persen is, is jammer maar helaas. BI is duur….. Maar ondertussen. De operationele systemen zouden niet anders ingericht moeten zijn, en BI zou daar relatief simpel uit op te lepelen moeten zijn. Geen rivieren van middleware nodig. Maar ja, het is nu eenmaal de praktijk. 
 
Als governance management is, en SOA in feit het applicatie landschap is dat op een bepaalde manier ingericht is, wat is dan SOA management? Functioneel applicatiebeheer? Het komt er wel heel erg dichtbij. En het heet en is beheer, dus operationeel management.  
 
Dan IT governance. Organisaties willen en moeten in IT investeren om de juiste informatie te blijven krijgen. Geen andere reden, want als er geen informatie nodig is hoef je ook geen (administratieve) IT te hebben. Investeringen (IT-projecten) in en exploitatie (beheer) van IT is een dure zaak. In het geheel gaat het om hardware, netwerken, systeemsoftware, data, applicaties, beveiliging enz. Het gaat om het managen van elke euro die een organisatie in IT steekt. Tactisch niveau, want het is een inrichtingszaak rond een hulpmiddel, geen strategische zaak in het richten van de organisatie.  
IT governance is dus het managen van het kapitaalgoed IT van een organisatie. Desnoods in stukje opgeknipt als bijvoorbeeld op verschillende manieren gesourced wordt. 
 
Wel vreemd, want IT management omvat ook applicaties. Waren dat niet die dingen die we in SOA services noemen en die samen als het applicatie landschap, IT landschap, IT-service landschap van een organisatie zien? Als je naar SOA kijkt is het een manier van inrichten van het IT landschap zoals de gebruiker dat ziet en op prijs stelt. En er dus voor betaalt, tenminste als hij/zij het goed kan gebruiken. Dat is dus het alignment vraagstuk, want hoe goed kan een gebruiker een service cq. een applicatie cq. IT gebruiken? En als je een applicatie wil hebben zal je de hele chebang die erachter zit ook moeten hebben, en door moeten berekenen. Is daarmee SOA governance een superset van IT governance. Logisch gezien niet. Een service is in feite een (klein) onderdeel van de gehele IT, en het managen van het service landschap is daarmee ook maar een deel van diezelfde IT.  
Alleen, de service moet zichtbaar zijn, zeker als het S in SOA en in SLA is. De effectiviteit van de service, de kwaliteit die geleverd wordt (ook: Quality of Service) zo je wil, IS onderdeel van de alignment, waarbij het bij totale IT landschap om de complete alignment gaat.  
Omdat de service zichtbaar is voor de organisatie kan de denkfout makkelijk gemaakt worden dat de SOA de superset, de grotere verzameling rond IT is. IT-leveranciers zullen dat in de huidige hype ook graag aan hun klanten vertellen, want de klant koopt zo meer middleware en nieuwe services (= nieuwe IT projecten = nieuw beheer enz.).  
 
Ik ben blij met je opmerkingen rond het verzwaren van het management als het over SOA gaat. Het is het verschil tussen integraal beheren en in delen beheren. Integraal managen, en in delen managen. In delen lijkt makkelijker, maar wie managed over de delen heen? Dat is ook het gevaarlijke om in domeinen te denken in organisaties, want hoe kom je nog naar een integraal als je delen separaat beheerd? Ofwel, hoe goed is mijn IT landschap als geheel? Delen kunnen best perfect zijn, het geheel kan dan nog ontzettend slecht zijn. Meer managen betekent altijd meer risico. 
 
Ja, een IT doel is een betere IT-Business alignment. Dat is een tactisch doel dat te maken heeft met inrichtingsvraagstukken, en dat zal gemanaged moeten worden onder regie van strategisch management, die heel andere doelen nastreeft en heel andere bedrijfsmiddelen daarvoor nodig heeft. Mijn voorkeur zou zijn om het IT-management te blijven noemen, en het deelmanagement van de applicaties/services functioneel applicatiebeheer of functioneel servicebeheer te noemen. Dit binnen en als uitvoering van SLA’s, die samen onder IT-management vallen. 
 
Natuurlijk raken bedrijven teleurgesteld in SOA! De SOA propositie is niet meer of minder dan het introduceren van vakmatig werken, en als zodanig is er alleen een lange termijn business case. Want je realiseert het morgen echt niet, je zult ernaar toe moeten groeien als je het goed wilt doen. En de rillingen lopen helemaal over je rug als je hoort over het creëren van een nieuwe laag boven op de huidige met als lijm en ultieme oplossing middleware. Je hergroepeert dan in feite wat je hebt, en als je de moed hebt om daar dan ook nog aan te veranderen ben je helemaal in de aap gelogeerd. Bovendien creëer je nog een te beheren laag, en een extra te beheren hoeveelheid middleware terwijl “de legacy” niet aangepakt wordt. Geldklopperij. En hoe bedoel je: imago-schade? IT maakt zich zo haast voorgoed belachelijk als je miljoenen gaat vragen aan bedrijven om dit te doen, en ze hier op een moment achter komen. Als adviseur krijg je dan de neiging om te gaan denken dat het goedkoper is om maar niets meer te doen, wat natuurlijk ook onzin is want stilstand is achteruitgang. 
 
Je zegt “Zo bezien MOET SOA governance dus” en je hebt gelijk. Alleen zeg ik iets meer: 
• Manage IT voortaan als geheel. En als dat SOA governance moet heten, het zij zo. Al is deze nieuwe naam alleen een excuses om te mogen veranderen zonder echte grond. 
• Ga je kennis van je informatie nou eindelijk eens beheren, en leg die in de basis van de regie over IT. Het stellen van de juiste, onderbouwde vraag is echt de enige garantie om enige kans te hebben je IT landschap te verbeteren. Want met de goede vraag zal je goed kunnen vaststellen wat nu eigenlijk je services moeten zijn, en de rest is dan weer inrichting. 
 
Ad Maar (a): Ja, zo is dat. En IT zorgt alleen voor een betere voorziening van de informatie die men nodig heeft. En als zodanig moet het optimaal services verlenen. Dus SOA is inderdaad niets nieuws, en dus ook SOA governance niet. 
 
Ad Maar (b): Ja, besturing was pre-SOA ook een uitdaging. Die uitdaging wordt echter steeds groter omdat we steeds meer IT creëren, en de relaties steeds complexer worden. En je hebt helemaal gelijk dat SOA nu het excuses is. Alleen het wordt als een techneuten-truc opgepakt, en daarmee schieten we ons doel volledig voorbij. Met de verzuchting: hoeveel hypes komen er nog voordat we nu eindelijk eens als vakmensen aan het werk gaan en doen wat nodig is? Teveel, vrees is. Met de klant die betaalt, en die daar nu al stevig van baalt. En terecht, want wij IT-ers hebben deze chaos zelf gecreëerd en stellen ons er niet verantwoordelijk voor. Feitelijk ethisch verwerpelijk gedrag. 
 
Ad Maar (c): Ja, helemaal gelijk. En we weten al zoveel over hoe het zou moeten, we brengen het alleen niet of nauwelijks in de praktijk. Aaaach, al dat gezeur geldt hier niet. Wij zijn anders….. 
 
Ja, je zult een aanpak moeten hebben voor het inrichten van governance. Echter ongeacht of dat SOA, IT of wat mij betreft huisvesting governance is. Pak de PIOFAH of de COPAFIJTH maar vast, en richt in. We hebben zoveel voorbeelden rond personeel, logistiek, huisvesting enz. management. Niets nieuws onder de zon, alleen iets anders om te managen.  
 
Waar ik wel moeite mee heb is je mening dat de SOA architectuur door de hele organisatie gedragen dient te worden. Voor de IT-wereld in de organisatie ben ik het met je eens, maar daarbuiten is voor mij echt de vraag. Hoewel we allemaal in een auto rijden hoeven we het toch ook niet helemaal te begrijpen en te dragen hoe men wegen aanlegt? En waarom we witte strepen hebben, en geen blauwe? Het interesseert de organisatie ook feitelijk geen bal. Zij willen niet meer of minder dan de juiste informatie van de juiste kwaliteit op de juiste plaats op het juiste moment. En of je daarvoor een blauwe of een groene machine gebruikt, wat zou het? IT-ers maken er een punt van dat de organisatie moet kiezen of het een blauwe of een groene moet zijn. AMD of Intel, wie interesseert zoiets buiten IT? Biedt de juiste services en lenig de behoefte aan informatie, en de organisatie is tevreden. Het is niet meer, of minder. En we zitten ontzettend ver van dit doel. 
 
Linking pins moeten elkaar leren verstaan, elkaars taal kennen. IT-management moet rapporteren aan de CIO. Niet in termen van technologie, maar in termen van toegevoegde waarde als het om de informatie van de organisatie gaat. Daarom is de kijk op de wereld, noem het architectuur, daar een hele andere dan die van de mensen die aan IT management rapporteren. Die laatste wordt tegenwoordig met enterprise architectuur, SOA, IT architectuur en meer termen benoemd. Er zit een enorm verschil in die architecturen, en IT management zal beide talen moeten leren spreken, naar elkaar kunnen vertalen willen ze goed kunnen functioneren, met gedrevenheid, heldere communicatie en charisma. Leuke uitdaging. 
 
Het scheiden van de functies zit in iets anders. Ik help op dit moment iemand om een bedrijf op te starten en een bedrijfspand te kopen. De dochter van de verkoper is zijn makelaar. Dat maakt het voor onze makelaar erg lastig, want deze mevrouw heeft zelf een eigen mening over het pand en die staat zakelijke afspraken steeds weer in de weg. Als adviseuse van eigenaar, haar vader, is zij dus feitelijk ongeschikt om tot een goede deal te komen, wat heel veel extra moeite en problemen oplevert. Zij had het geld van haar vader niet moeten willen verdienen, en hem aan een betere adviseur/makelaar moeten toevertrouwen. Ze mengt functies, en maakt het daarmee erg moeilijk. 
In ons vakgebied spreken we wel over managers, adviseurs en uitvoerenden. Als we het even zo simpel houden, dan moet je deze functies niet mengen om dezelfde reden als uit het voorbeeld komt. Nu is een architect per definitie een adviseur, die als rechterhand van en manager functioneert en tegenover andere managers staat met hun adviseurs. Als de manager ook architect is komt het nooit van de grond wat je wil. Legio voorbeelden, vooral in Nederland. In Nederland hebben we namelijk het principe dat een programmeur kan doorgroeien naar ontwerper, analist, adviseur en uiteindelijk manager. Even afgezien van Peter’s Principle is dit vragen om problemen. Een adviseur die manager wordt dient feitelijk alle inhoud naast zich neer te leggen, en zich op mensen en hun competentie te richten. Veel managers in Nederland doen dat echter niet, en blijven inhoudelijk. Met adviseurs en uitvoerenden die apathisch worden omdat ze het toch nooit goed doen. Dus scheidt de functies, en werk op de manier die bij de functie past. Anders ontstaan er problemen. 
 
Pas dit alles in het linking pin verhaal in, en het past. Managers zijn dan vooral de linking pins. Adviseurs onder elkaar worden niet echt gemanaged, maar hebben waarschijnlijk een primus inter pares, een woordvoerder. En die neemt mee wat de anderen zeggen in zijn rapportages. 
 
Dan zeg je erg veel in een paragraaf: 
• “De IT architectuur (of voor mijn part SOA) van een bedrijf is de zorg van dat bedrijf zelf.” Als externe zal dat dan wel je referentiekader zijn als je werkt aan het veranderen van de IT. Maar het is, zoals je zegt, de verantwoording van IT management (tactisch niveau). 
• “Een Telecom bedrijf baseert zich bijvoorbeeld op eTOM; de vertaling daarvan voor hun situatie is de verantwoordelijkheid van de eigen architecten-board.”. Ja, waarbij eTOM dan kennelijk een soort (standaard) referentie architectuur die de opzet en inrichting van de IT van dat bedrijf moet gaan hervormen. Die architecten board zie ik dan als adviesgroep van IT management (aanbod kant), waarbij ik een impact verwacht op strategisch niveau (vraagkant) die bepaald zal moeten worden in de discussie tussen strategisch en tactisch niveau, tussen vraag en aanbod. eTOM is immers de huidige standaard, en wie weet wat de standaard inrichting over een paar jaar zal zijn.  
• “De aansturing van projecten die dit moeten invullen ook. En zo moet het. Je kan dit soort zaken namelijk niet uit handen geven.” Hier ben je niet helemaal helder. Ja, er zullen IT-projecten zijn om eTOM te realiseren. Die komen voort uit het veranderen van het huidige om die op eTOM gebaseerde IT-architectuur te krijgen. Die Architectenboard zal moeten bekijken wat allemaal nodig is, maar IT-management zal prioritiseren en uiteindelijk beslissen wat gedaan moet worden. Op advies van die architectenboard. Met die beslissing komen er IT-projecten. En ja, dat zal de organisatie zelf moeten doen. Je hersenen kan je niet outsourcen, tenzij de gehele eTOM architectuur onder management van een derde komt. 
 
En zo kom je tot je situatie dat IT-management regie kan voeren en waar verbeteringsvoorstellen geaccepteerd, mits gestructureerd en gecoördineerd ingepast, kunnen worden. De architecten kijken dan naar de consequenties en adviseren management wat ze moeten doen. Management is en blijft namelijk verantwoordelijk en zij zullen die verantwoordelijkheid ook echt moeten dragen. Architecten, adviseurs, verantwoordelijk maken voor veranderingen is, om vele redenen, een zeer slechte zaak. Advisering t.a.v. de richting is de enige manier, waarna beslissingen genomen kunnen worden door competent IT-management. 
 
Ja, en wat je daarna zegt is logisch. Als je weet wat gedaan moet worden, het zelf zou kunnen doen, dan kan je het uit handen geven aan een derde. Zoals je zegt is het formuleren en onderbouwen van de opdracht erg belangrijk. Daar staat ook in wat precies gedaan moet worden, worden de grenzen haarscherp aangegeven. Als het goed is, tenminste. 
 
Ja, het zou helpen als een soort consumentenbond zou zijn. Maar die kan niet uit de leverancierswereld komen, want die verenigen zich juist om dat te voorkomen. Zie The Open Group. Zoiets is namelijk lastig, want daarmee komen de diensten onder druk te staan. Zie maar wat de Rekenkamer net gezegd heeft over de IT binnen de Nederlandse overheid. Zo’n consumentenbond zal niet alleen in de samenleving maar ook binnen organisaties dienen te ontstaan. Buiten IT. Hij past het beste bij de advisering van het strategische niveau, de vraagkant van de IT die regie voert over de inzet van IT.  
 
Het is een spannend en leuk krachtenveld. Het punt is alleen dat e.e.a. anno 2008 volledig en compleet gedomineerd wordt door een paar grote en een groot aantal meehobbelende andere IT-leveranciers. Maar de wereld rond IT begint zich wel te roeren, op dit moment. Spannende tijden. 
 
Lydia, de hype SOA is niet meer tegen te houden, en de schade aan het imago is eigenlijk allang aangericht. Dat begin zo langzamerhand ook zichtbaar te worden, hoewel het zo lang mogelijk onduidelijk gehouden zal worden. Op naar de volgende IT-hype. 
 
Steven van ’t Veld 
Steven.van.t.Veld (at) AIM.nl