• English
  • Nederlands
HOME
SEARCH
CONTACT
NEWSLETTER
 
 
 
CONTENT
About us
Call for contribution
Contributions
The CIO talks
Proceedings
Blogs
Master thesis
Forum
Wiki
Events calendar
Links
Login/Register
advertisements
Zoek je een baan?
Zoek je hulp?
Zoek je een opleiding?
Zoek je een boek?
Zoek je een tool?












 
 
BLOGS
Lerende architecten
Hans Bot   
Monday, 07 July 2008

De kwestie

Don Tapscott heeft in zijn visionaire boek “the Paradigm Shift” al in 1993 een werkmodel geschetst voor werken onder architectuur. Het bestaat uit vier stappen, te weten:

  1. Reimage – het ontwikkelen van een visie

  2. Restructure – het structureren van een oplossing

  3. Realize – het ontwikkelen en in gebruik nemen

  4. Renew – een continue verbetering

Het zal u misschien opvallen dat Tapscott zich hierbij heeft laten inspireren door de bekende Deming-cyclus (“plan-do-check-act”). Er zijn in elk geval ook vier fasen en het is beide gericht op een lerende organisatie.

In 2001 kwam Sogeti onder het kopje DYA – Dynamische Architectuur – met een eigen model. Dit bestaat uit drie stappen, te weten:

  1. De Strategische Dialoog – het bepalen van de business doelen

  2. Architectuur Services - het opstellen en bewaken van de architectuur

  3. Ontwikkelen (z)onder architectuur – het realiseren van de business doelstellingen

De parallel tussen deze twee modellen is op zich opvallend. De strategische dialoog is bedoeld om een gemeenschappelijke visie te ontwikkelen. Architectuur Services geven structuur en kader aan de oplossingen. En de daadwerkelijke realisatie wordt onder architectuur gebracht als de rol van de architecten niet beperkt is tot het beschrijven van de architectuur. Tegelijkertijd is het kenmerkende verschil in het achterliggende denkmodel opmerkelijk. Waar Tapscott veel waarde hecht aan het leren van fouten in en het continue verbeteren van eenmaal gerealiseerde oplossingen, ontbreekt dit in het DYA denkmodel volledig. Als de oplossing gerealiseerd is, dan hebben de Dynamische Architecten hun taak naar behoren vervuld.

Gemiste kans

Het verschil tussen de modellen is wellicht te verklaren uit het feit dat Sogeti, de organisatie achter het DYA-model, een leverancier is, die het moet hebben van het uitvoeren van projectgebonden activiteiten, en betrekkelijk lastig geld kan verdienen aan de structurele activiteiten die voor continue vernieuwing nodig zijn. Het structureel analyseren en verbeteren van het bestaande applicatieportfolio is immers eerder iets voor de gecommitteerde 'insiders' binnen een bedrijf, dan voor tijdelijke 'inhuurkrachten' van buiten. Maar daarom hoeft de architectuurcommunity zich nog niet bij deze omissie neer te leggen. Er werken tenslotte ook tal van gerenommeerde architecten als 'insider' bij bedrijven en instellingen. Is continue vernieuwing een relevante activiteit voor architecten? Zou het in het architectuurproces een plaats moeten krijgen? Zo ja, hoe geeft je dat dan vorm? Of zouden alle architecten zich uit hoofde van hun functie moeten concentreren op projecten met een afgebakend doel en een beperkte looptijd?

Als het leren van de gemaakte keuzes een doel is – en waarom zouden architecten niet van praktijkervaringen kunnen leren – dan ligt het in elk geval erg voor de hand dat er na het opleveren structureel een serieuze analyse wordt gedaan van de goede en mindere aspecten van de architectuur. In hoeverre was de project-start-architectuur doelmatig? Was hij correct, volledig en niet voor misverstanden vatbaar? De antwoorden op die vragen zijn ongetwijfeld leerzaam. Een end-of-project review lijkt dus een nuttig instrument om de architectuurfunctie te verbeteren. Maar is het voldoende?

Vanuit een business perspectief is de belangrijkste vraag waarschijnlijk of de gekozen architectuur adequaat is. Met andere woorden: is het op basis van de gekozen architectuur mogelijk gebleken om de business doelstellingen daadwerkelijk te realiseren. In de praktijk zal het niet vaak voorkomen dat deze vraag al aan het einde van een project beantwoord kan worden. Immers, na het invoeren van een nieuwe IT-oplossing verloopt er doorgaans de nodige tijd voordat de business doelstelling daadwerkelijk en volledig is gerealiseerd – al was het maar omdat de impact op de organisatie (waaronder de beheerorganisatie) nog moet blijken. Dat betekent ook dat er na verloop van tijd mogelijk nog belangrijke lessen te trekken zijn uit de praktijk van het levende systeem. Echter, alleen als architecten bereid en in staat zijn om een serieuze post-project review te doen, kan er van die – ongetwijfeld weerbarstige – praktijk daadwerkelijk geleerd worden.

Maar zelfs in het geval dat de business doelstelling volledig is gerealiseerd, dan wil dat nog niet zeggen dat het denken hoeft op te houden. De wereld is continu aan het veranderen. De markt ontwikkelt in een hoog tempo en de technologische mogelijkheden nemen met de dag toe. Het kan, met andere woorden, niet zo veel kwaad om periodiek en structureel te evalueren of de bestaande oplossingen nog wel adequaat zijn in de huidige situatie. Het overleven van de concurrentiestrijd vereist een mate van fitheid die zonder een gezonde portie beweging domweg niet houdbaar is.

Natuurlijk is het niet eenvoudig om dit te organiseren. Veel architecten worden geleefd door de 'hartbeat' van projecten. En zeker in het geval van inhuur is de betrokkenheid van de architect bij de organisatie vaak van beperkte duur. Maar zolang de architectencommunity niet om te beginnen de ambitie uitspreekt om een lerende discipline te willen zijn, dan gaat het zeker niet lukken om oplossingen te vinden voor dat soort organisatorische problemen. Misschien zouden we eens een business architect moeten vragen hoe je zo'n nijpend probleem nou het best zou kunnen oplossen?

Literatuur:

[1] Don Tapscott en Art Caston: "Paradigm Shift: The New Promise of Information Technology", McGraw-Hill, 1993.

[2] Roel Wagter, Marlies van Steenbergen en Martin van den Berg: "DYA: Snelheid en samenhang in business- en ICT-architectuur", Tutein Nolthenius, 2001.

[3] http://www.dya.info/Home/dya/index.jsp

[4] http://www.dya.info/Home/dya/wat_is_dya/dya_model/

[5] http://www.dya.info/Home/dya/wat_is_dya/dya_model/strategische_dialoog.jsp

[6] http://www.dya.info/Home/dya/wat_is_dya/dya_model/architectuur_services.jsp

[7] http://www.dya.info/Home/dya/wat_is_dya/dya_model/ontwikkelen_onder_architectuur.jsp

 

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 9de in een reeks. Deze is op 7 juli 2008 gepubliceerd op ArchITectuur Bedrijven.






Comments (2)
RSS comments
Written by Erica Dane on 09-07-2008 16:00
 
 
Het hele stuk is gebaseerd op een misvatting. De functies die zo kenmerkend zijn voor DYA worden geïnterpreteerd als stappen in een proces. In dit licht ontbreekt inderdaad de stap van evaluatie en verbetering. Maar het zijn geen stappen in een proces, maar FUNCTIES die continue bestaan en niet slechts voor de duur van één project. Het hele betoog is gebaseerd op deze misvatting.

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 14-07-2008 14:33
 
 
Deze \'misvatting\' wordt in stand gehouden door alle officiele publicaties over DYA. Bijvoorbeeld de website http://www.dya.info, waar ik lees dat \"De kern van DYA wordt gevormd door het DYA-model. Dit model bevat vier processen die het hele traject van strategievorming tot realisatie beslaan.\" Deze processen zijn zowel in de boeken, op de website als alle presentaties die ik over DYA heb gezien, in een \"DYA model\" verbeeld (zie b.v. http://www.dya.info/Home/dya/wat_is_dya/dya_model/). Nergens wordt gerept over FUNCTIES - hoe zeer ik ook zou willen dat dit zo was voor de \"processen\" \"Strategische Dialoog\" en \"Architectuur Services\". Je zou tenslotte van architecten mogen verwachten dat juist zij het verschil tussen een proces en een functie begrijpen. 
 
Maar zelfs als je in het DYA-model \"functie\" leest waar \"proces\" staat. dan nog blijkt uit de beschrijving nergens dat er een functie met de taak belast is om \"periodiek en structureel te evalueren of de bestaande oplossingen nog wel adequaat zijn\", zoals ik dat in mijn column voorstel. Ik ben zoiets tenminste nog nergens tegen gekomen - niet in de officiele DYA boeken en niet op de officiele DYA site. 
 
Begrijp me goed, ik heb niets tegen DYA. Sterker nog, ik geef er al jaren les in, en ben blij dat er zo\'n de facto standaard in Nederland bestaat. Tegelijkertijd zie ik vanuit de praktijk ruimte voor verbeteringen. Aangezien DYA geen open model is, en ik er dus niet direct aan kan bijdragen, probeer ik met de beste bedoelingen de discussie daarover in de architectuurcommunity aan te zwengelen. Ik ben dan ook blij dat je met me eens bent dat "evaluatie en verbetering" een belangrijke architectuurfunctie is. Ik vind dat zo'n belangrijke functie een plaats verdient in een architectuurmodel dat claimt de "de-facto standaard voor het omgaan met architectuur" te zijn. Ik hoop dat je ook dat met me eens bent. 
 
P.S. Ken jij toevallig een organisatie die zo'n functie goed heeft ingericht? Misschien kunnen we als community daarvan leren?

 

Only registered users can write comments.
Please login or register.




Share / deel
Del.icio.us!Google!Technorati!Yahoo!
 

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify This e-mail address is being protected from spam bots, you need JavaScript enabled to view it of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
feed image
ISSN: 1877-2994