informatie architectuur

RSS feed

Goede architecten zijn agile - en goede archituren zijn to-the-point

Vorige week kwam ik weer in de geijkte discussie terecht: we hadden het over het maken van een doelarchitectuur, en direct was er iemand die "geen tijd wilde besteden aan het zinloos uitwerken van een hele architectuur". Ik snap zo'n reactie niet. Waarom zou een doelarchitectuur een "hele" architectuur zijn? Wat is "heel" eigenlijk? Het klinkt als veel werk, in ieder geval. En dat bedoelt de spreker ook vaak: architecturen kosten te veel werk! En dan is het uitwerken er van ook nog "zinloos"! Goh, denk ik dan, hoeveel architecten zouden graag veel tijd steken in iets wat door hun omgeving als zinloos wordt gezien?

 
Mensen die architectuur ervaren als veel werk, hebben ervaring met  de verkeerde architecten. Beter geformuleerd: ze hebben ontwerpers of engineers mee mogen maken die zich voordeden als architect - die hebben behoefte aan (te veel) detail. Of ze zijn iemand tegengekomen die doel en middel niet uit elkaar weet te houden - het te leuk vindt om architectuur te maken om de architectuur zelf. Maar in de gemiddelde bedrijfssituatie is architectuur altijd een middel, en geen doel op zich. 
 
Een goede architect is per definitie agile. Bedenkt niet meer dan nodig is. Op het moment dat het nodig is. Je hoeft geen architectuur van 400 pagina's te maken als je de informatievoorziening wilt laten groeien naar een servicegeoriënteerd applicatielandschap. In eerste instantie zijn 4 pagina's meer dan genoeg. Vervolgens zien we wel weer verder. Een goede architectuur is per definitie doelgericht. Een organisatie wil iets bereiken, een architectuur geeft richting aan hoe dat kan. Niet meer, maar ook niet minder.
 
Zoals Ruud van Vliet, Arjen Uittenbogaard en ik al schreven voor het Landelijk Architectuur Congres 2006: "Een architect is geen showstopper, geen boe-roeper, geen luchtfietser. Helaas komen we hem maar al te vaak in een of meer van die rollen tegen. Wij menen dat dit heeft te maken met gebrek aan ‘agility ’! Een agile architect weet dat een architectuur niet in beton gegoten is, dat standaarden aangepast kunnen worden en dat minder regels beter is dan veel regels. Een agile architect weet dat je de effectiviteit van een architectuur alleen maar kunt beoordelen tijdens de toepassing ervan."
Zie ook hoofdstuk 4, De Agile Architect, in het boek "Wendbaarheid door Architectuur".
 
Een architect is geen "business preventer". Hij of zij geeft juist inzicht in total cost of ownership en total (IT) risk of ownership. Waarna de opdrachtgever mag bepalen of deze kosten en risico's door de organisatie gedragen kunnen worden.

Drijfveer

Hoe komt het toch dat informatie in organisations niet veel innovatiever, consistenter en effectiever wordt toegepast?

Dat is de vraag die me nu voor jaren intrigeert. Ik zocht de antwoorden in disciplines zoals enterprise architectuur en informatie architectuur. Hoewel ik in dergelijke beta-wetenschap begon heb ik mijn blik verruimt naar de kunst, de veranderkunde, de semantiek en de filosofie.

In deze blog zal ik gaan zoeken hoe we informatie anders kunnen gaan gebruiken, om de informatiewerker optimaal te bedienen.

SOA in relatie tot Enterprise Architectuur

Vandaag was ik bij een klant bezig met service orientatie. De technische acroniemen en invalshoeken vlogen om mijn oren. Herhaaldelijk legde ik uit dat SOA voor mij niet technisch is. En dat SOA veel te maken heeft met de enterprise architectuur. Daarvoor ging ik terug gaan naar de meest elementaire definitie van service orientatie.

Perceptie

Als informatie architecten modeleren we een werkelijkheid in informatie. Modeleren betekent vooral dingen weglaten. Als we essentie raken doen we het goed.