Diagnose, Ontwerp en Verandering

Problemen oplossen! Simpel toch?

Problemen zijn er om opgelost te worden. Direct en zo simpel, effectief en efficiënt mogelijk. IT Architecten zijn vaak bij uitstek de oplossers in nood. Zij beheersen inmiddels het volledig arsenaal aan mogelijke oplossingen voor ieder probleem. Bijna altijd komen oplossingen direct uit het blote hoofd, en gebracht op een wijze waarop het Orakel van Delphi een voorbeeld aan had kunnen nemen. Of toch niet?

Gelukkig voor veel bedrijven gaan architecten anno 2012 gelukkig iets anders te werk. Een architect ziet een probleem als een puzzel. Een complexe puzzel. Deze puzzel dient via een zorgvuldig afgewogen theorie benaderd te worden om toch snel tot bevredigende een oplossing te komen. Dit methodisch ontwerpen kan beschouwd worden als een probleemoplossingstraject. In dit traject zijn de volgende kenmerken te onderscheiden:

  • Een omschrijving van de probleemsituatie.
  • Een diagnose.
  • Een omschrijving van de ontwerpeisen.
  • Het ontwerp.
  • De implementatie.

Vanzelfsprekend worden gedurende het gehele traject alle stakeholders betrokken, om zo veranderkundige problemen bij implementatie van een oplossing te voorkomen. Ofwel om geen tijd te verliezen en niets over het hoofd te zien is een zachte systeembenadering vaak handig.

Centrale thema’s bij het methodisch ontwerpen zijn:

  • Positie en rol van de architect. Bij het oplossen van problemen zit deze dus in de rol als onderzoeker naar oplossingsrichtingen. Daarnaast speelt ook de formele en informele positionering van de architect in de organisatie een rol.
  • Objectiviteit versus subjectiviteit. Soms is een architect ook een mens met een mening en soms zelfs belangen. Bijvoorbeeld met een lange termijn belang vanuit eerder overeengekomen enterprise architectuurprincipes.
  • Theorie versus praktijk. Hoe mooi een oplossing in een laboratorium ook kan werken, de specifieke context waarbinnen een probleem opgelost moet worden wijkt natuurlijk af. Hierdoor zal de standaard oplossing niet zondermeer werken.
  • Lineair werken versus iteratief werken. Ondanks alle agile discussies in de IT weet een ervaren architect wanneer een extra iteratie noodzakelijk is. Agile werkwijze in de organisatie of niet.

Goede architecten zijn zich altijd bewust van deze centrale thema’s.  Schematisch kan het probleemoplossingstraject worden weergegeven als onderstaande figuur. In deze figuur zijn de belangrijkste stappen met iteratieve controle vragen weergegeven.

 probleemoplossingstraject

Door de kern van deze DOV cyclus (Diagnose, Ontwerp en Verandering) niet uit het oog te verliezen borgt een architect de kwaliteit van het probleemoplossingstraject waarvoor hij (of zij) voor wordt gevraagd.