Er bestaat een mismatch tussen de belangrijkste succesfactoren voor een effectieve architectuurfunctie en aspecten die binnen organisaties vaak het beste zijn ontwikkeld. It-architectuurprojecten worden onvoldoende getoets en de architectuurkeuze sluit vaak niet aan op de bedrijfsdoelstellingen. Dit blijkt uit promotieonderzoek van Marlies van Steenbergen, principal consultant enterprise architectuur bij ict-dienstverlener Sogeti.
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.
@ 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…