Thank you for taking the time to report the following comment to the administrator of this site.
Please complete this short form and click the submit button to process your report.
Dat jij de relatie legt tussen architectuur en ontwerp is helder. Ik heb daar moeite mee, maar dat zit niet in het feit dat ontwerp niet iets is dat hard nodig is, maar meer in het feit dat ontwerp niet de kern van de huidige problemen in de praktijk is. Misschien is dat probleem nog wel het beste aan te duiden door planologie naast ontwerp en bouwkunde te beschouwen. Vanouds spreken wij over functioneel ontwerp en technisch ontwerp. Functioneel ontwerp is daarbij het vormgeven van een oplossing voor de omgeving die hem zal gaan gebruiken, technisch ontwerp de manier zoals de oplossing werkt. Dus als je iets wil, een probleem hebt, dan kan je daarvoor een oplossing (of verandering) functioneel (en later technisch) ontwerpen. Dus bij een Bank: je gaat vorm geven aan oplossing nummer 10.001.
Een totaal andere vraag is waarom je oplossing 10.001 zou willen hebben. Ik ken een Bankorganisatie waar men meer dan 30 verschillende workflow oplossingen heeft, en dat de vraag niet echt gesteld wordt waarom men de 31e zou willen (en de consequentie dat het aansluiten van die 31e op de 30 anderen zo kostbaar is…). Dus waarom zou je een nieuwe oplossing willen als je een probleem hebt? En dus ook: waarom zou je zo’n oplossing al gelijk functioneel, laat staan technisch, willen ontwerpen?
Stapje hoger. Als ik Jaap zijn werk zie zie ik dat hij vaak niet over 1 oplossing nadenkt, maar over een geheel waarbinnen één of meer oplossingen zouden kunnen passen. Stapje breder (en m.i.) beter, maar m.i. nog steeds (te) beperkt: • Het is praktisch onmogelijk om een ontwerp te maken van behoeften aan informatie voor een omgeving. Dat betekent dat je wel opschaalt, maar nooit kompleet zult zijn en dus geen totaaloverzicht hebt. • Met het maken van een ontwerp maak je, ongeacht hoe vrij je het opzet, keuzes. Elke keuze beperkt. En daarmee beperk je dus je ontwikkeling naar je toekomst.
Daarom zie ik architectuur en ontwerp als verschillende zaken. Architectuur voor het geheel van je gekozen werkelijkheid, ontwerp als je daar iets binnen wilt gaan veranderen. Informatiearchitectuur is dan voor mij het beeld dat een organisatie heeft van haar bedrijfsmiddel informatie in haar organisatie. Richtinggevend, maar zoveel mogelijk inrichting-vrij. Je kunt daarbij richtlijnen extra geven voor het inrichten, zoals jij met ontwerp zult bedoelen. Daarna kan je dan technologie gaan bekijken om te zien hoe oplossingen voor onderkende problemen in te zetten: dus probleemanalyse, functioneel ontwerp enz. Dus waar methoden als DYA en TOGAF rond opgezet zijn: aannemerswerk.
Wat in een informatiearchitectuur hoort is op zich niet zo moeilijk te bedenken: alles wat een organisatie rond haar informatie wil bepalen en vaststellen. Informatie, dus niet technologie. Ontwerprichtlijnen (zoals ik interpreteer wat je informatiekundige ontwerpleer noemt) kunnen daarbij horen, maar zijn feitelijk 2e plan. Technische, dus IT, richtlijnen zo beperkt mogelijk, want daarmee beperk ik de nabije toekomst ook al teveel, laat staan de verdere toekomst.
Je hebt gelijk in je opmerking rond de architect. Wat echt nodig is is ruimtelijk richten, en minder ruimtelijk inrichten, laat staan functioneel ontwerpen. De vele jaren dat ik nu met de term architect werk heb ik steeds het ruimtelijk richten bedoeld, en niet het functioneel ontwerpen. Daarom voeg ik ook het begrip harmonie toe aan de kenmerken van Vitruvius, iets dat in de architectuur pas zo’n 15 eeuwen na Vitruvius gedaan werd. Functioneel ontwerpen zou je in de informatie & IT-sector ook bij de aannemers, de IT-ers/IT-leveranciers kunnen laten, het ruimtelijk richten en waarschijnlijk ook het ruimtelijk inrichten kan daar niet bestaan. Simpel omdat je je hersenen en kennis niet door een derde kunt laten beheren, dat moet je zelf doen. En daarmee komen we dan in een terminologische tweespalt, want in de bouw is een architect dan iemand die echt los van de aannemer hoort, terwijl de functioneel ontwerper in de informatie & IT-sector best wel eens gecombineerd kan worden. Bijvoorbeeld zoals Sogeti bij Capgemini hoort. Voor ruimtelijke richten en ruimtelijk inrichten kan dat absoluut niet. Vraag los van aanbod, anders krijg je snel grote problemen.
Ja, de bewijsvoering van John Sowa, hoewel kompleet, schiet tekort omdat er een premisse onder ligt die niet juist is: alles zou een object zijn. Dat is ook de reden waarom dat ISO 14481 nooit verder is gekomen dan een Final CD. Dat wil niet zeggen dat de inhoud niet goed is, er waren in 1999 alleen 2 stromingen die niet bij elkaar konden komen: praktijk en theorie.
Neen, ik wijs TOGAF niet af zoals je denkt. Waar ik niets mee kan is met de haast agressie waarmee groepen mensen met zoiets als TOGAF omgaan, wat jij sektarisch noemt. Om TOGAF en haar community beter te leren ben ik 2 keer een week naar de States geweest om een conferentie erover bij te wonen (en om te spreken) in Miami (3 jaar geleden) en San Francisco (1˝ jaar geleden). Daar heb ik de vorming van de community rond TOGAF gezien. Gesloten, later bijna agressief, commercieel en weinig aansprekend voor de mensen die tijdens de bijeenkomsten probeerden uit te vinden wat het nu eigenlijk is, waar TOGAF om gaat. Daarom ook mijn vergelijking met SDM en het geld dat Capgemini daar jaren mee verdiend heeft. En als ik dan in mijn praktijk kijk, dan zie ik de toegevoegde waarde van TOGAF gewoon niet. Ik zie organisaties die om te beginnen een jaar of 4 een team van 5 tot 15 externen hebben die de Sisyfus-klus deden om alles te beschrijven. Een soort van wat we vroeger informatieplan noemden, maar dan nu onder de kreet enterprise architectuur. Verouderd zodra het opgeschreven is, en nauwelijks nog bij te houden (ongeacht eventuele tools) als het “af” zou zijn (wat het nooit kan zijn). En ja, met dat soort verbranden van geld heb ik moeite. Dan een veel ernstiger punt: het nut en de toegevoegde waarde. Waarom zou je zoveel centraal van je IT willen opschrijven, en nog steeds zo weinig over je informatie. IT verandert snel, dus ook de beschrijving ervan. En waarom zou je dan vele fte’s willen zetten op iets dat niet anders dan altijd verouderd kan zijn, en verouderd zal blijven. En dan nog de push van IT om het allemaal te gaan doen. Typisch blauw gedrag. En als het af is en het niet voldoet, dan gaan we weer gewoon door met het volgende. Zonder consequenties, zonder dat iemand er de vinger op kan leggen. Jammer, maar helaas. Maar we verdienen er wel lekker aan. Ben ik daarom tegen TOGAF? Nee, hoe kan je tegen een methode zijn. Ik heb wel grote bedenkingen tegen wat het beoogd te doen. Maar dat heb ik tegen vrijwel iedere van de huidige “architectuurmethoden”, gewoon omdat de praktijk bewijst dat het meeste uiteindelijk lood om oud ijzer zijn.
Pieter, ik heb al eerder een discussie met je afgebroken omdat je te grof werd. Nu verwijt je mij dat ik je documenten nog niet gelezen heb en eis je van me dat ik dat doe voordat jij me een discussie waard vindt. Het probleem is dat zoveel mensen binnen IT, al of niet in groepen, van zichzelf vindt dat hij/zij de oplossing voor alles heeft, en de denkwijze die iedereen zou moeten hebben. Als je weinig tijd hebt zijn er simpele manieren om vast te stellen of dat inderdaad het geval is. Noem het een lakmoesproef. Weet je, als iemand me niet echt kan interesseren in dit soort discussies zie ik geen reden om de (vaak vele) schrijfselen van zo iemand (of groep) te gaan lezen. Ik merk bij jou dat je steeds weer teruggrijpt op dingen die je ooit geschreven hebt, en dat je dan zelf vaststelt dat het toch wel erg goed was en dat je er niets aan wilt/gaat veranderen. Prima hoor, maar geen aantekening voor de kwaliteit ervan in mijn ogen. Als het bovenstaande niet al te ver af is van jou werkelijkheid, exclusief mijn opmerkingen daarover natuurlijk, dan weet ik je te plaatsen en te vinden als dat nodig is. Maar als jij niet zonder referenties naar jezelf of naar wat anderen een keer opgeschreven hebben kunt vertellen wie je bent en wat je ideeën zijn, dan laat ik het hier nog maar bij. Je verwijt laat ik deze keer voor wat het is.