Marlies van Steenbergen deed onderzoek naar de effectiviteit en volwassenheid van de it-architectuurfunctie in Nederland. Zo toont een benchmark van 56 organisaties aan dat toetsing van it-projecten aan opgestelde architectuur onvoldoende gebeurt. Ook het aansluiten van architectuurkeuzes op bedrijfsdoelstellingen blijft onderbelicht. Uit een survey met 293 respondenten blijken dit echter belangrijke factoren te zijn. Een vergelijking tussen sectoren toont verder aan dat de overheid achter blijft in effectiviteit.
Onderzoeksresultaten
Grote organisaties hebben te maken met een toenemende complexiteit in hun informatievoorziening. Dit leidt veelal tot ongewenst hoge it-kosten, problemen bij het garanderen van de betrouwbaarheid van gegevens en gebrekkige flexibiliteit en slagvaardigheid. Een enterprise architectuur helpt bij het inzichtelijk maken en terugdringen van deze complexiteit. Uit het promotieonderzoek blijkt dat enterprise architectuur wel het benodigde inzicht biedt, maar dat veel organisaties moeite hebben dit inzicht te verzilveren.
Zo geeft 74 procent van de organisaties aan dat architectuur de complexiteit van organisaties inzichtelijk maakt. 72 procent van de respondenten is van mening dat architectuur een helder beeld schetst van de gewenste toekomstige situatie. Daarentegen geeft slechts 29 procent van de ondervraagden aan dat architectuur helpt complexiteit te beheersen. Niet meer dan 13 procent geeft aan dat kosten hiermee beheerst kunnen worden. Ook samenwerking kan worden verbeterd. Zo vindt niet meer dan 38 procent van de respondenten dat er sprake is van structurele kennisuitwisseling tussen architecten en projectmedewerkers. Slechts 28 procent is van mening dat architectuur wordt ingezet voor meer samenwerking binnen en buiten de organisatie.
Geïntegreerde architectuurpraktijk
‘De onderzoeksresultaten laten zien dat architectuur veel meer onderdeel moet worden van de structurele bedrijfsvoering om optimale effectiviteit te realiseren', aldus Van Steenbergen. ‘Uit mijn meest recente onderzoeken blijkt dat er sprake is van een lichte verbetering, maar nog altijd zijn veel organisaties zoekende naar hoe architectuur op een effectieve manier in te zetten. Enterprise architecten kunnen de onderzoeksresultaten gebruiken om meer aandacht te vragen voor hun inspanningen bij organisatiebestuurders. Mijn advies is te verschuiven van een aparte architectuurfunctie naar een geïntegreerde architectuurpraktijk. Architectuur moet een vaste vaardigheid worden in plaats van een aparte afdeling binnen organisaties.
Onderzoeksmethode
Dit wetenschappelijk architectuuronderzoek is gebaseerd op verschillende onderzoeksmethoden waaronder casestudies, een benchmark van 56 uiteenlopende organisaties en een survey met 293 respondenten uit alle sectoren van de grootzakelijke markt en de overheid. Daarbij stonden drie onderzoeksvragen vanuit uiteenlopende invalshoeken centraal. Hoe wordt de effectiviteit van architectuur vastgesteld? Hoe kan de architectuurfunctie verbeteren en wat is de impact van omgevingsfactoren zoals cultuur op de architectuurfunctie? Dit nationaal onderzoek heeft plaatsgevonden in de periode van 2007 t/m 2011. Het proefschrift is op aanvraag beschikbaar of gratis te downloaden via http://igitur-archive.library.uu.nl/dissertations/2011-0609-200519/steenbergen.pdf.
Reacties
Een uitstekend en grondig uitgevoerd onderzoek van Marlies van Steenbergen, Chapeau. Ik denk dat dit exemplarisch is voor veel meer onderdelen en disciplines binnen de twee werelden IT vs Non IT.
Steeds vaker zie je de discrepantie tussen deze twee werelden groter worden met alle negatieve gevolgen van dien. Daar waar IT zou moeten fungeren als een 'Strategische Dienstverlener', is nog steeds dat besef nog niet tot de wereld van Non IT doorgedrongen terwijl aan de andere kant, de hand in eigen boezem stekend, IT er al die tijd duidelijk niet in is geslaagd dit gat te dichten.
Als IT professional vind ik deze constatering pijnlijk omdat dit meer en meer afbreuk doet aan hetgeen waar, me dunkt, IT voor zou moeten staan. Namelijk kosten reduceren door automatiseren en niet lekker commercieel hypen zodat zelfs veel IT'ers niet eens meer weten wat de werkelijke basis en doel van hun vak is.
Alle prachtige hypes over 'nieuwe methoden' en vondsten en zogenaamde vernieuwingen ten spijt, is de commerciële tak van de IT klaarblijkelijk niet eens meer in staat om op verantwoorde wijze goede constructies te bedenken waar de klant besparingen mee kan halen.
Ik denk dat dit artikel een ieder werkzaam in de IT weer eens even met beide benen op de grond moet doen staan als professional en bij zichzelf te rade zou moeten gaan wat ook alweer de basis principes van automatiseren was en bovenal, weer eens gaan nadenken of men wel iets begrijpt van de principes en wetmatigheden die IT nu eenmaal met zich mee brengt.
IT is een pracht vak maar als je niet weet waar je mee bezig bent, dan gaat het geld kosten, niet te vergeten ook nog eens je naam. En was dat nu juist niet waarvoor we IT implementeren?
Onderzoek is afgerond Mei 2011. Is dat nu (Maart 2012) nieuws?
Beetje laat.
Inhoudelijk wel een zeer relevante studie. Die percentages uit de enquete zijn natuulijk leuk maar weinig wetenschapplijk. Gelukkig is het verder een zeer gedegen studie.
Probleem bij Enterprise Architecture is dat de Architecten vaak in de Ivoren toren blijven zitten. Verhogen van de maturity werkt dan juist averechts. De afstand tot de dagelijkse praktijk neemt dan enkel toe. Na nog eens nader gekeken te hebben naar het Architecture Effectiveness Model (AEM) van Sogeti kom ik toch tot de conclusie dat ook dit niet gaat helpen om het ivoren-toren syndroom te bestrijden. De formule die het AEM hanteert is volstrekt niet te kwantificeren (veel te complex en bevat variabelen die los staan van de IT). Daar tijd in steken gaat de effectiveness echt niet verhogen. Veel pragmatischer is het om Architecten te beoordelen op het resultaat in de praktijk. Dus niet in de ivoren-toren blijven zitten (en enkele mooie abstracte designs produceren) maar zorgen dat goede gestandaadiseerde oplossing (conform Design en EA) ook daadwerkelijk in de praktijk gebracht worden.
Marlies is een van de grondleggers van DYA de enterprise architect methode van Sogeti. Betreft het hier Enteprise architectuur de titel vindt ik persoonlijk niet de lading dekken. De term IT-architectuur wekt de indruk van een systeem/applicatie architectuur. Het betreft hier Enterprise Architecture.
Het wordt tijd dat de dames en heren architecten meer maatwerk gaan leveren. Het is mijn ervaring dat - ik chargeer - architecten zich vooral hebben toegelegd op een bepaalde productsuite en daarnaast over het algemeen adviseren in de richting van ERP en SOA.
Op basis van principes zijn dat correcte keuzes, ware het niet dat met name SOA in veel gevallen niet heeft bewezen de beloftes die zijn gedaan waar te maken.
Bovendien wordt er op basis van de architect vaak een veel te zwaar project opgetuigd. Een van de oorzaken dat projecten falen.
Toch ben ik positief over architecten en hun rol binnen de organisatie. Zij brengen structuur in de chaos. Daarnaast onderschrijf ik het advies van de verschuiving naar de geïntegreerde architectuurpraktijk. Het is daarvoor onder andere nodig dat architectuur als vast onderdeel in opleidingen voor economen, bedrijfskundigen, controllers etc. wordt opgenomen. Zij zien nog steeds architectuur als een specialisme, iets technisch waar je vooral niets van moet weten maar over geadviseerd moet worden. Op die manier is het moeilijk om te komen tot BITA.
Getriggerd door de opmerking van numoquest:
"Daar waar IT zou moeten fungeren als een 'Strategische Dienstverlener' "
komt bij mij toch weer de vraag boven wat er nu wel en niet onder IT verstaan wordt.
Worden producten als bijvoorbeeld telefooncentrales (en dan bedoel ik de grote knooppunten zoals een KPN die heeft), beeldverwerkings-software in de medische sector, de embedded software die een airbag aanstuurt, pick en place machines waarmee printplaten gemaakt worden enz enz dan niet tot de IT gerekend?
Beste Edwin Fokker,
Ik heb even bij Sogeti navraag gedaan n.a.v. jouw opmerking en dit is hun antwoord:
Marlies van Steenbergen is in het najaar van 2011 gepromoveerd op dit onderzoek waarna ze opnieuw aanvullend onderzoek heeft gedaan. Deze resultaten zijn vandaag voor het eerst gepresenteerd aan de 300 architecten die vanochtend in de zaal zaten tijdens onze DYA-dag.
Het grappige van dit soort onderzoeken is dat onderzoeken twintig jaar geleden dezelfde uitkomsten hadden, alleen had men het dan niet over enterprise architecturen maar over corporate informatie-architectuur.
Het architectuur-denken is de afgelopen 20 jaar eigenlijk niets verandert, alleen de schematechniekjes en de namen zijn wat veranderd. Dus ja, dan blijven de constateringen gelijk en hebben de onderzoeken dezelfde uitkomsten.
Het enige wat men kan bedenken is hoe de architectuur vastgetimmerd in moeilijke plaatjes er over 5 tot 10 jaar uit moeten zien. Maar er is geen manager, die weet of zijn bedrijf over 5 jaar al niet twee keer is overgenomen. Gelukkig dat die architecturen ook allemaal niet gerealiseerd worden, want over 5 jaar is de technologie weer anders en dan zeggen alle architecten dat wat 5 jaar geleden bedacht en waar die business manager dus heel veel geld in gestopt was totaal achterhaald is.
Gelukkig zijn die managers wijzer en stoppen daar geen geld in. Ondertussen proberen ze men met wat opruimen en opschonen, wat consolideren en wat nieuwe dingen proberen een stap of twee stappen verder te komen en dat lukt.
Zolang architectuur een statisch theoretische ontwerpbenadering is, waarbij men zich niet echt af gaat vragen wat die business manager beeegt, zullen over 20 jaar nog wel van dit soort onderzoeken zien
@Robert: "Op basis van principes zijn dat correcte keuzes, ware het niet dat met name SOA in veel gevallen niet heeft bewezen de beloftes die zijn gedaan waar te maken."
Dat lag niet aan SOA an sich. Er is een groot voorbeeld die aangeeft dat SOA zeer goed de beloftes van SOA waarmaakt: Amazon Webservices. Als een SOA zijn beloftes niet nakomt kun je de oorzaken elders zoeken.
@NumoQuest: "Steeds vaker zie je de discrepantie tussen deze twee werelden groter worden met alle negatieve gevolgen van dien. Daar waar IT zou moeten fungeren als een 'Strategische Dienstverlener'"
Ik denk juist dat als je IT als strategisch dienstverlener ziet, je de discrepantie in stand houdt. IT is niet meer een afdeling of een dienstverlener. IT komt niet meer van 1 plek af, maar IT is nu juist onderdeel van het gehele bedrijf geworden! Juist door zelfbediening en bijvoorbeeld externe tools middels SaaS te gebruiken is IT verweven met het bedrijf en de afdelingen. In mijn ogen moet je IT niet meer als iets los zien. Door de vele legacy is dit vaak nog geen realiteit.
@Pakave
Bijzondere valide stelling. Vanuit mijn optiek valt onder IT ALLE componenten, infrastructuren, en software die zorg dragen voor data transitie, in de ruimste zin van het woord, binnen IT. Dus wat mij betreft ook telefonie integraal.
@ Henri Koppen
Ik moet ook hier weer een beetje zuchten om je stelling en voorstelling van zaken. Prachtig dat je probeert met een technische/methodische oplossing te komen. Helaas heb je niet helemaal begrepen dat je allereerst terug zult moeten naar de basis van de materie, wat een solide basis moet zijn.
Dat betekend dat zowel de IT specialist als de IT afnemer, dienen te moeten begrijpen wat de materie IT nu eigenlijk is, hoe het zich beweegt, en hoe het KAN worden geïmplementeerd en WAAROM je iets zou implementeren.
De focus die je in veel reacties ziet is zoals hier ook weer in het aandragen van een methode of techniek terwijl ik in de regel erg weinig mensen zie praten over 'Nut en Besparen'. Juist deze twee laatsten hier zouden de basis van inzicht, inzet en implementatie moeten zijn en niet allerhande oplossingen en 'zienswijzen'.
Ik weet het, men kijkt er graag anders tegen aan maar ik blijf erbij, als je niet weet hoe IT als materie beweegt en hoe er het meest economisch mee om te gaan, mag altijd een extra zak geld meenemen. Dat is namelijk de keerzijde van veel IT projecten en implementaties.
Helaas.
IT architectuur bestond nog niet toen we met IT begonnen. Dus we deden maar wat. Achteraf moesten we in kaart brengen wat we hadden gedaan. Maar toen was het al te laat.
Probleem is dat bedrijven van zichzelf al vaak geen architectuur hebben. Geen grondplan van goed beschreven primaire processen, activiteiten, mensen en middelen. Alleen op een dergelijk grondplan kun je een IT architectuur neerzetten; een IT huis bouwen dat stáát en volledig in dienst staat van de organisatie.
Maar ik ben bang dat als het al verandert, dat heel langzaam gaat. Je kunt niet van IT verwachten dat een gammele bedrijfsstructuur optimaal ondersteund kan worden door het goed verzorgen van IT architectuur alleen. Geen architect zal zich wagen aan het ontwerpen van een huis als hij niet beschikt over een goede ondergrond, een duidelijke basis, een stevig fundament. Dat is dan ook als vanzelf zijn eerst prioriteit.
In de IT (architectuur) zou dat ook zo moeten zijn. Die conclusie verbaast mij dus niet.
Architectuur bestaat al meer dan 25 jaar, in de jaren 70 en 80, zijn hier grote stappen gezet. Het begrip corporate informatiemodel was eind jaren 70 (!) al bekend en toen geaccepteerd gedachtegoed. SOA is niet iets wat uit de lucht kwam vallen, het is gewoon een stap verder in ontwikkelingen, die in de kern in de jaren 60 is ingezet.
Business Alignment is dus dat je een gammele bedrijfsstructuur en minder perfecte gebruikers niet ondersteund met perfecte systemen maar met niet perfecte IT. IT die op de punten waar het belangrijk is, het goed doet en de andere punten mag het minder zijn. Iedere manager weet dat zijn medewerkers ook niet perfect zijn. Maar op een maar punten moet het goed zijn. IT wil het altijd perfect doen. Maar daar wil de business niet op wachten en niet voor betalen. Dus een bestaand systeem oplappen vind business vaak een beter alternatief en je ziet overal dit soort plannen ingezet worden en die werken verrassend vaak. Er komt geen perfect systeem uit, maar daar kan business prima mee leven.
Tweede, je moet architectuur niet meer zien in een blauwdrukwereld. Enterprise denken gaat er vanuit dat alles opnieuw ontworpen moet worden. Maar bijna alles is al geautomatiseerd en we zitten dus niet meer in groene weide te bouwen, maar ik een overvolle stad. Architectuur moet uitgaan van stadsvernieuwingsgedachten, wijkjes oplappen, wegen oplappen, soms een nieuwe weg, soms een stukken huizen slopen. Dan krijg je business gecommit en dat is te overzien.
En in de praktijk werkt dat...