Architectuurvolwassenheid

Daan Rijsenbrij, vrijdag 01 mei 2009

Regelmatig vraagt een klant of een deelnemer aan een van mijn lezingen/workshops naar de drie ondernemingen in Nederland die hun digitale architectuur echt goed voor elkaar hebben. Mijn soms wat teleurstellend antwoord is dat nog geen enkele onderneming zo ver is. Dat komt niet omdat ik de lat zo hoog leg, maar omdat wij met z’n allen bezig zijn digitale architectuur te ontdekken en met vallen en opstaan leren wat een juiste architectuur is.
Er staan in de literatuur zogenaamde architectuurvolwassenheidstabellen. Consultants zijn hier dol op, zo’n tabel impliceert immers big business: ‘jij, onderneming, bent pas hier en je zou daar horen te staan. Dat zijn nog vier stappen en voor elke stap heb je mij, externe consultant, nodig’.
In feite dient de architectuurvolwassenheid afgestemd te zijn op de IT-volwassenheid en die is sterk afhankelijk van de aard van de onderneming en de bedrijfscultuur. Dus kijk uit, laat je niet op de kast jagen door de zogenaamde volwassenheidsconsultant!

Bij een kwalitatieve uitspraak over de architectuurvolwassenheid zijn de volgende tien onderwerpen van belang:

  1. het architectuurbegrip: een eenvoudige formulering en de bekendheid in de eigen organisatie, in het bijzonder bij opdrachtgevers van IT-projecten,
  2. inspirerende, overzichtsgevende architectuurvisualisaties,
  3. ordenende, vereenvoudigende architectuurconcepten,
  4. concrete, complexiteitsverlagende architectuurprincipes,
  5. de betrokkenheid van de stakeholders,
  6. de rol en de positie van de CAO1 en zijn relatie met de CIO,
  7. de opbouw en de kwaliteit van de architectenpopulatie,
  8. de architectuurgovernance als onderdeel van de IT-Goverance,
  9. de mate waarin architectuur stuurinstrument is voor topmanagement ten behoeve van strategiebeslissingen en grote IT-gerelateerde transformaties,
  10. hoe architectuur functioneert als stuurinstrument bij de realisatie: bouw, aanschaf pakketsoftware, outsourcing.

Het is niet echt interessant welke methode dan wel welk raamwerk wordt gevolgd, immers niet de processen maar de resultaten horen centraal te staan. Zoals ik al vaker heb benadrukt, lijkt het architectuurgebeuren veel op kwaliteitsmanagement, met de drie centrale vragen: is architectuur duidelijk gedefinieerd, wordt het echt begrepen door de stakeholders en wordt het daadwerkelijk toegepast?

Architectuur is geen discipline die op zichzelf staat, het heeft cruciale relaties met andere activiteiten in de onderneming. Daarom is het belangrijk dat naast bovenstaande tien onderzoeksonderwerpen ook een aantal belangrijke driehoeksverhoudingen onder de loep worden genomen.

  • Ten eerste de relatie tussen de businessstrategie, de informatieplanning en de architectuur. Bij veel ondernemingen zijn de informatieplanning en de architectuur op een ondoorzichtige wijze met elkaar vervlochten.
  • Ten tweede het opdrachtgeverschap, de IT-Governance en de architectuur.
  • Ten derde de architectuur van de sociale relaties, de bedrijfstructuur en de architectuur van de digitale wereld.
  • Als laatste maar zeker niet minder belangrijk de algemene IT-principes, de architectuurprincipes en de engineeringsprincipes, waarbij in het bijzonder de aansluitbaarheid van de engineeringsprincipes op de architectuurprincipes belangrijk is.

Na analyse van bovenstaande onderwerpen en driehoeksverhoudingen horen aanbevelingen te worden geformuleerd, met bij elk verbetervoorstel de toegevoegde waarde die met die verbetering wordt beoogd. Dus geen verbetering om je te kunnen meten met de ‘buren’ (industrie benchmark), maar om beter aan te sluiten bij de daadwerkelijke behoefte van de onderneming.

Over de tegenovergestelde vraag ‘wat zijn voorbeelden van slechte architectuur?’ zwijg ik liever. Maar het valt mij op dat er nogal wat ondernemingen en instellingen zijn waar het architectuurgebeuren zonder enige visie wordt opgestart. Het krijgt min of meer in het wilde weg vorm: tientallen verschillende modellen (die vaak eigenlijk in het functioneel ontwerp pas aanbod horen te komen), veel zogenaamde architectuurvisualisaties die slechts bedoeld zijn voor de architect zelf of zelfs voor de bouwer en een chaos aan architectuurprincipes, waarbij echte architectuurprincipes en principes op het gebied van IT-Governance door elkaar worden gehaald.
Kortom, ik kan CIO’s aanraden om hun architectuur eens onafhankelijk extern te laten auditen. Auditen niet alleen op correctheid maar zeker ook op nuchterheid en zakelijkheid. Wij hebben in de IT nog een lange weg te gaan met architectuur.

* Gepubliceerd in de Automatisering Gids, 24 april 2009, nummer 17, pagina 14.
1 CAO staat voor Corporate Architectural Officer.

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

19-06: KNVI/PLDN sessie over semantische data integratie in de weg- en spoorinfrastructuur 

28-06: LAC summit meer...

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden