Proces & Document 2009, nr. 1

Architectuur bij ICT is in. Iedereen noemt zich tegenwoordig architect en het Landelijk Architectuur Congres (LAC) trekt honderden bezoekers, jaar in jaar uit. Sommige topambtenaren willen alleen nog ICT-nota's zien als ze aan de NORA voldoen. Ik zie dikke rapporten waarin architecten bij gemeenten, provincies en andere overheidsorganen het bestuur dringend vragen om 'onder architectuur' te gaan werken. Wat is hier aan de hand?

Wel, in de eerste plaats is architectuur een mooie term, dus iedereen gebruikt die in de ICT. Op het LAC zitten businessarchitecten (jasje-dasje), informatiearchitecten (jasje) en technische architecten (spijkerbroek) door elkaar heen. De eerste groep heet eigenlijk businessconsultants, de laatste systeemontwerpers. Ik denk dat we er goed aan zouden doen ons te beperken tot de groep informatiearchitecten. Een informatiearchitect hoort - de naam zegt het al - primair te kijken naar informatie en de bijbehorende processen, alhoewel hij ook in staat moet zijn met techneuten en bestuurders te discussieëren. Anders gezegd: een informatiearchitect is een generalist, geen specialist.

Veel architecten zijn een tikje verdwaald in de techniek. Ze praten dan voornamelijk in twee- of drieletterwoorden als SOA, ESB, BPM of BI. Een informatiearchitect die alleen maar dit soort kreten slaakt, zou ik verbannen naar de afdeling Automatisering. Een informatiearchitect kijkt naar de samenhang van processen, over afdelingen heen, zowel in de huidige situatie als in de toekomst. Dus hoe hangen processen en systemen met elkaar samen en welke standaarden gaan we hanteren om meer samenhang te krijgen. Daarnaast kijkt de architect naar samenwerken: hoe 'klantelen' en 'ontkokeren' we onze processen, gegevens en systemen, rekening houdend met de huidige cultuur. Beide (samenhang en samenwerken) zijn essentieel voor de architect.

Veel architecten maken indrukwekkende blauwdrukken voor de toekomst. Dat heeft mijns inziens weinig zin als je niet precies weet waar we nu staan en hoe we dat aan kunnen passen. Welke applicaties gebruiken we? Welke gegevens spelen daarbij een rol (inclusief documenten en berichten)? Welke kanalen en processen, rollen en rechten zijn er nu? Welke informatie blijft binnen de afdeling? Wat gaat naar buiten? Waar willen we naar toe? Hoe doen we dat? Hoe krijgen we onze processen gekanteld, meer klantgericht? Hoe komen we van die verkokering af? Dit vraagt alles vooral om betrokkenheid van architecten, niet om blauwdrukken!

Weergaven: 223

Reactie van Stichting Digital Architecture op 9 Juli 2012 op 10.24

Geschreven door Marc Lankhorst op 03-08-2009 09:59

Ik ben het grotendeels eens met het bovenstaande, maar ik mis een belangrijk begrip: dienst (of service; en dan niet in de enge SOA-zin van het woord). Architectuur moet m.i. beginnen met de vraag wat een organisatie(onderdeel), proces of applicatie voor de klant ervan doet. Informatie is daarbij "slechts" een middel. Een van de redenen dat architecten zo slecht door de business worden gehoord, is dat "informatie" vaak wordt geassocieerd met IT, en dus met die zacht zoemende machines in de kelder in plaats van met de klant aan de balie. Ook architecten zelf hebben nog wel eens de neiging de informatielogistiek en het berichtenverkeer in plaats van de dienstverlening leidend te laten zijn.

Reactie van Stichting Digital Architecture op 9 Juli 2012 op 10.25

Geschreven door Richard Uijen op 24-08-2009 17:13

Ik had eigenlijk gehoopt hier een poging tot omschrijving van het vakgebied architectuur te vinden, waarmee in één oogopslag duidelijk wordt wie zich wel en wie zich niet met architectuur bezighoudt. Dat mensen zich onterecht architect noemen, kan alleen voorkomen worden door het beschermen van de titel en het gebruik ervan te reguleren. In mijn ogen dragen bijna alle mensen in een organisatie bij aan 'de architectuur'. Op sommige gebieden alleen wat meer dan op andere. De mate waarin dat bewust en gestructureerd wordt gedaan en de mate waarin dat als sturingsinstrument voor het management wordt gedaan, vanuit missie, visie en strategie, varieren ook. Het zou in de rol van een architect in de organisatie moeten worden verankerd dat deze, gebaseerd op een methode, gestructureerd de samenhangen binnen en naar de omgeving van de organisatie stuurt vanuit de strategie van het management en rekening houdend met alle belanghebbenden.

Reactie van Stichting Digital Architecture op 9 Juli 2012 op 10.25

Geschreven door Rick Kegel op 27-08-2009 09:15

Volgens mij gaat ICT architectuur in de kern maar over één ding: samenhang. Het in kaart brengen van de samenhang (of juist het ontbreken daarvan) in de informatievoorziening is waar ICT architec-tuur zich mee bezig zouden moeten houden. Ik ben het op dat vlak dan ook volledig met Wouter eens. Die samenhang zou je m.i. bij voorkeur duidleijk moeten maken met grafische overzichten; of je die nu blauwdrukken noemt of landschapskaarten of whatever: plaatjes dus ! Voor iedere betrokkene van elk niveau begrijpelijk en inzichtelijk. En betrokkenheid van de architect is hierbij ontegenzeglijk een be-langrijke vaardigheid maar dat staat niet op gespannen voet met het wel of niet kunnen visualiseren..

Natuurlijk heeft Marc gelijk als hij zegt dat het uiteindelijk gaat om het verbeteren van de dienstverle-ning aan de klant. Maar dat is pas mogelijk als je, zoals Wouter terecht stelt, een helder beeld hebt van de huidige situatie. En of je dat beeld nu wel of niet hebt gevormd op basis van een (standaard) methode, is voor een opdrachtgever niet van belang. Die zal het worst zijn of je zijn informatiehuis-houding in kaart heb gebracht met Tapscott, TOGAF of Zachman. Zo lang hij maar het overzicht heeft op basis waarvan hij verbeteracties kan starten.

De hele discussie over methodes en standaarden vind ik eigenlijk een beetje zonde van de tijd en energie die beter besteed kan worden aan het simpelweg “doen”. Ik zie nog te vaak dat we als be-roepsgroep blijven hangen in die ivoren toren waar we mooie plannen maken om die vervolgens op de plank te zien belanden. Laten we gewoon de mouwen opstropen en zoals we in Rotterdam zeggen “niet lullen, maar poetsen”. Zodra klanten zien welke mooie, creatieve en waarde-toevoegende oplos-singen we niet alleen kunnen bedenken maar ook daadwerkelijk voor ze kunnen realiseren, zullen we als groep ook die waardering krijgen waar we blijkbaar zo naarstig naar op zoek zijn.

Reactie van Stichting Digital Architecture op 9 Juli 2012 op 10.25

Geschreven door Paul Duran op 06-09-2009 06:53

Als er iets opvalt in het IT werkveld, dan is het wel dat we termen van andere vakgebieden overnemen en daar een andere invulling aan geven. Desktop, file, statement, domain, vocabulaire. We verwarren onze omgeving ermee en uiteindelijk ook onszelf.

Zo ook architect, een begrip uit de bouw. De architect is een bouwkundig ontwerper die een beeld van een gebouw creeert dat moet voldoen aan alle eisen die de opdrachtgever er aan stelt. Die architect gebruikt alle middelen om iets bijzonders te ontwerpen dat de opdrachtgever aanspreekt en waarvan de architect duidelijk kan maken dat de gewenste functionaliteit kan worden ondersteund. Als de opdrachtgever daar tevreden is zorgt de architect ervoor dat de de bouwkundige specificaties zo compleet mogelijk op papier of tegenwoordig in de computer terecht komen. Vervolgens kan het worden aanbesteed en dooe een aannemer gerealiseerd.

Iedere opdrachtgever van een bouwopdracht weet precies wat hij doet als hij een architect inhuurt en doet dat bewust. In zo'n geval heeft die opdrachtgever een visie en weet dat architect hem of haar kan helpen die visie om te zetten in iets zeer bruikbaars wat ook nog eens opvalt. Als dat ontwerp is gerealiseerd -door een aannemer en ongetwijfeld allerlei onderaannemers- kunnen mensen die het zien zeggen: "wat een ... architectuur." (Vul een bijvoegelijk naamwoord in dat enige emotie uitdrukt.)

Wat Wouter zegt over de IT architecten zou ik willen verbinden met termen uit de bouw: veel IT architecten die je tegenkomt zijn stadsplanners, projectontwikkelaars, aannemers, constructeurs, bouwtechnisch ingenieurs, bouwinspecteurs, betonspecialisten, timmerlieden, electriciens en loodgieters. Omdat het IT vak ook met vormgeving te makan heeft kom je ook specialisten uit dat vak tegen: ontwerpers, vormgevers, drukkers, uitgevers.
En allemaal zijn ze in de IT architect.

Een opdrachtgever die enige architect uit het IT werkveld inhuurt verwacht dat hij een helder ontwerp krijgt en dat hij praat met iemand die zijn wereld begrijpt. Althans, sommige opdrachtgevers hebben die illusie mogelijk nog, de meeste zijn in complete verwarring achtergelaten en hebben een gigantische behoefte aan enige standaard werkwijze om ervoor te zorgen dat ze krijgen wat ze nodig gebben.

Onze pogingen onze taal en werkwijze voor de buitenwereld duidelijk te maken vatten we in allerlei methoden en technieken die inmiddels een halfwaardetijd hebben twee jaar. We worden doodgegooid met nieuw acroniemen die allemaal nieuwe zakken zijn voor de oude wijn. Ooit werd de snelheid van computers uitgedrukt in MIPS: millions instructions per second. De andere betekenis van die afkorting die bij een aanbestedingstraject naar boven kwam is mij beter bijgebleven: Misleading Information Provided by Salespersons.
In de IT zijn we bezig de "E-Tower of Babel" te creeeren.

En uiteindelijk hebben we het vaker over het hoe en maar weinig over het wat. En het laatste is waarom het draait: op welke manier ondersteunt een informatievoorziening de werkprocessen die met hulp van de eerste beter en sneller kunnen. Waar ik nog aan toe zou willen voegen: waar de opdrachtgever, de mensen in zijn organisatie en hun klanten ook gelukkiger van worden.

Een (bouw/tuin/informatie/IT/business) architect moet zich bezig houden met de mens en zijn of haar werk- en leefruimte, want dat is hetgene dat hij creeert.

Daarvoor moet hij Nederlands kunnen praten, maar ook het vakidioom kunnen gebruiken. Een architect moet ook veel kennis hebben van techniek, maar hoeft geen 2000 regels programmacode per dag te produceren, of 9 meter schoon metselwerk op te leveren.

Ik ervaar dat ik als informatie architect alleen wordt opgehouden door de nieuwe acroniemen die we onze omgeving door te strot duwen.
En tegelijkertijd moet ik met software als Word, Excel, Powerpoint en Viso mijn ontwerpen maken omdat mijn baas, meestal een aannemer, vindt dat het goedkoper en sneller kan.
Het is de wereld op zijn kop.

Opmerking

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

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden