Home Architectuur Huidige tekortkomingen bij Digitale Architectuur

Huidige tekortkomingen bij Digitale Architectuur

206
Overheid

In 1999 heb ik het Landelijk Architectuur Congres op de rails gezet vanuit mijn hoogleraarschap aan de Vrije Universiteit met de portemonnee van Capgemini. Sinds die tijd heb ik veel waardevolle architectuurontwikkelingen zien langs komen, maar helaas zijn er nog een aantal gebreken. Ik beperk mij tot acht.

 

 

 

 

 

1.        Business- en informatiearchitectuur zijn vaak onderbelicht.
2.        Ik zie een te eenzijdige focus op architectuurprincipes en frameworks.
3.        De PDW komt nauwelijks van de grond.
4.        DYA is sterk verouderd.
5.        NORA werkt niet.
6.        TOGAF is in feite voor engineers.
7.        De PSA is vaak overdreven uitgebreid.
8.        Wij lijden onder een ongebreidelde diversiteit aan architectentitels.

1. Business- en informatiearchitectuur zijn vaak onderbelicht.
Door het gebrek aan een echte business- en informatiearchitectuur zijn de meeste applicatiearchitecturen en de architecturen van de infrastructuur niet echt verankerd in het bedrijfsgebeuren. De businessarchitectuur hoort immers leidend te zijn voor de architectuur van de onderliggende architectuurlagen. De toekomstvastheid van menige organisatie is daardoor nauwelijks geborgd.

2. Te eenzijdige focus op architectuurprincipes en frameworks.
In bepaalde kringen zie ik een te eenzijdige focus op architectuurprincipes. Architectuurprincipes dienen om de ontwerpruimte in te perken, maar krijgen pas hun waarde als je ze verbindt met architectuurvisualisaties. Het opstellen van architectuurprincipes dreigt een l’art pour l’art activiteit te worden, het liefst nog opgeborgen in een framework ondersteund met een semantische wiki. Vaak mis ik een concretisering van de principes naar regels, standaarden en richtlijnen, waardoor de principes onnodig vaag blijven.

3. De PDW komt nog nauwelijks van de grond.
De persoonlijke digitale werkruimte komt door gebrek aan visie bij topbestuurders niet van de grond. Wij blijven hangen in te technische werkomgevingen die niet vanuit de arbeidssatisfactie van de eindgebruiker worden geformuleerd, maar uit achterhaalde ideeën van topmanagers over effectiviteit en efficiency van het arbeidsproces.

4. DYA is sterk verouderd.
DYA, dé architectuuraanpak met de grootste mindshare in Nederland, is sterk verouderd. Onder ‘informatiearchitectuur’ wordt zowel het informatieverkeer als het applicatielandschap begrepen. Bij het ontstaan van DYA in 2001 was automatiseren wellicht belangrijker dan informatie delen. In het digitale tijdperk spelen naast services, eventueel verpakt in app’s, informatie en kennis dé hoofdrol.
Gezien de grote, nuttige Body of Knowledge die rond DYA is ontstaan, is het wenselijk dat de eigenaar van DYA deze aanpak drastisch gaat vernieuwen. Het zou zonde zijn als deze Nederlandse aanpak wegens achterstallig onderhoud verdwijnt.

5. NORA, hét raamwerk voor de architectuur in de overheid, werkt niet.
Langs de horizontale as van het NORA-framework zien wij ‘wie’, ‘wat’ en ‘hoe’, een soort verkorte weergave van het verouderde Zachman-framework, dat eigenlijk is bedoeld voor engineers.
Als ik als architect een digitale (referentie)architectuur zou mogen formuleren voor de overheid (of zelfs de gehele publieke sector) zijn er twee separate aandachtsgebieden: het informatieverkeer tussen de relatief onafhankelijke overheidsorganisaties en een referentiearchitectuur voor overheidsorganisaties eventueel verbijzonderd naar specifieke domeinreferentiearchitecturen. De architectuur van bovengenoemd informatieverkeer zou zelfs veel verder kunnen gaan dan de overheid. Het lijkt immers wenselijk dat het informatieverkeer tussen burgers onderling, tussen burgers en private ondernemingen en zelfs tussen private ondernemingen onderling aan dezelfde architectuur gaat voldoen.
Maar eerst dient een architectuurplaatje te worden opgesteld voor de digitale samenleving (ook wel ‘e-samenleving’), waarbij tevens de infrastructurele voorzieningen worden aangegeven die door de overheid worden gefaciliteerd. Waar is die expliciete visie op de gewenste toekomstige digitale samenleving? Een architect dient zich immers eerst een beeld te vormen over hoe burgers en bedrijven (horen te) functioneren in een digitale samenleving. Vervolgens zou ik een visie willen zien over de gewenste toekomstige digitale overheid binnen die digitale samenleving. Pas daarna kan er onderbouwd worden gesproken over zoiets als NORA. NORA lijkt nu nog teveel een middle-out product.
En, zoals reeds jaren door mij benadrukt: ‘er is echt een digitale Rijksbouwmeester nodig om de e-overheid op slagvaardige wijze van de grond te krijgen’.

6. TOGAF is in feite voor engineers.
TOGAF is een aanpak die haar wortels heeft in een technisch architectuurframework ontwikkeld door DoD. Daarna is TOGAF verder ontwikkeld door de grote softwarehuizen en IT-leveranciers. Ik vind daarom dat in de bijsluiter van TOGAF dient te worden opgenomen: ‘vóór en dóór bouwers, uitermate schadelijk voor de creativiteit van architecten’.
Het informatieverkeer – de bloedsomloop van elke onderneming – ontbreekt geheel. Serieuze architectuurvisualisaties en waardevolle architectuurconcepten zijn nauwelijks aanwezig. Behalve een doorgeschoten theoreet of een gretig opleidingsinstituut zou geen enkele zakelijke opdrachtgever of nuchtere businessmanager in TOGAF geïnteresseerd moeten zijn.
Certificering in TOGAF impliceert dat je het boek uit je hoofd kent, dat geeft slechts schijnzekerheid. Gelukkig krijg je pas je rijbewijs als je met goed gevolg ook een blokje hebt gereden, anders was de chaos in het verkeer niet te overzien.
Eigenlijk is er behoefte aan een (wereld)standaard voor digitale architectuur ontwikkeld vanuit de vraagkant en gedragen door de businessmanagers van grote organisaties.

7. De PSA is vaak overdreven uitgebreid.
De projectstartarchitectuur is slechts een tijdelijk architectuurdocument bedoeld om te borgen dat de resultaten van het onderhavige project zullen passen in de overall architectuur van de organisatie. Het opstellen van een PSA is bij aanwezigheid van een volwassen overall architectuur een activiteit van maximaal één dag. Toch zie ik bij veel organisaties dat daar veel meer tijd aan wordt besteed, zelfs oplopend tot enkele maanden. Is de overall architectuur dan niet in voldoende mate aanwezig of worden onder de PSA allerlei oneigenlijke zaken gestopt?

8. Wij lijden onder een ongebreidelde diversiteit aan architectentitels.
De wildgroei aan soms zeer exotische architectentitels is nauwelijks meer te overzien. Niet alleen is de opdrachtgever van de architect allang de draad kwijt, ook de architecten zelf weten nauwelijks meer wie wat doet en waarom. Reeds in mijn oratie ‘Architectuur in de Digitale Wereld’ uit 2004 staat een oproep tot slechts een beperkt aantal architectentitels.
Het NAF, dé architectencommunity in Nederland, bestaat dit jaar 10 jaar. Het is jammer dat zij tot nog toe niet in staat is geweest om een aantal duidelijke competenties op te stellen waarmee een beperkt aantal architectenrollen kunnen worden gemaakt. Het formuleren van een dergelijk competentieraamwerk dient vooraf te gaan aan certificering. Een eenvoudig en algemeen geaccepteerd schema van competenties zou een kapstok kunnen zijn voor opleidingsinstituten.

Daan Rijsenbrij, www.Rijsenbrij-Academy.nl

 

 

42 REACTIES

  1. Daan,

    Ik onderschrijf veel van wat je zegt. Jij belicht hier overigens veelal de instrumenten voor een architect (methode, raamwerk, aanpak), waar wat mis mee is volgens jou.

    Deze instrumenten die jij aanstipt zijn volgens mij ooit opgetuigd onder de noemer van een kennelijk beeld over wat de architect moet kunnen en moet doen. In mijn ogen is dat huidige beeld over wat de architect moet kunnen en moet doen verouderd en moet het roer nu echt om!

    De echte architect is voor mij een ervaren of getalenteerde creatieve (her)ontwerper van totaalconcepten zoals bedrijven, informatievoorzieningen, ICT-infrastructuren of intergale bedrijfs-ICT-oplossingen in een organisatie. De architect moet visies van de opdrachtgever (directie) kunnen concretiseren in ontwerpschetsen. De architect, hij is een ontwerper!

    Mijn waarneming is dat de architect van veel grotere toegevoegde waarde is als hij de echte opdrachtgever (uitsluitend de directie of mt’s) van business architectuurvisualisaties zoals infographics en artist impressions van het businessmodel voorziet, op basis waarvan de opdrachtgever beslissingen kan nemen.

    De architect is geen Hamster, Cartograaf of Ontdekkingsreiziger. Maar dat is wel vaak de feitelijke situatie als in een organisatie geen processen, producten, diensten of applicaties fatsoenlijk geadministreerd staan. Als je het de architecten vraagt hebben ze an-sich wel een goede visie maar kruipen ze nog te weinig uit hun schulp. Ze doen vaak het werk van de beleidsmedewerker, systeemontwikkelaar of beheerder. Heel nuttig, maar niet de bedoeling en het werk van de architect blijft liggen.

    Ik zie nog te weinig business architecten bij de directie met begrijpelijke architectuurvisualisaties aan komen zetten, terwijl ze het wel in hun mars hebben, maar dan niet uit hun dogmatische safety zone durven komen omdat ze zich van oude aanpakken dan wel haperende raamwerken bedienen.

    Zoals ik ook al vaker geblogt heb: Business architecten hebben presenteerbare voorbeelden nodig (een eigen architectuurportfolio) om snel duidelijk te maken dat ze 1) verstand van zaken hebben, 2) de opdrachtgever ziet wat hij aan de business architect heeft en 3) dat het de opdrachtgever NU kan helpen met zijn probleem.

    Als de architect zich opstelt als ontwerper gaan er bepaalde processen spelen in het architectuurwerk die automatisch leiden tot een verbetering van het architectuurwerk. Ontwerpen is voor de architect de hoofdactiviteit, andere zaken die hij doet zijn nodig zodat hij kan en mag ontwerpen en dat het ontwerp verkocht kan worden en dat realisatie van het ontwerp leidt tot het verwezenlijken van de droom van de opdrachtgever. De hoofdzaak voor de architect is en blijft: ONTWERPEN voor de opdrachtgever.

    Als je als architect ontwerper bent, kies je op basis van de ambities en doelen van de opdrachtgever de juiste GROTERE bedrijfskundige en informatiekundige concepten voor de opdrachtgever en smeedt er een uniek totaalconcept mee voor hem. De gehandhaafde wijze waarop de concepten werken en resultaten produceren zijn de conceptprincipes. Deze visualiseer je zeer begrijpelijk voor de opdrachtgever zodat de opdrachtgever (de directie) ziet waarom dat de inzet van dat concept nodig is in het licht van zijn ambities, doelen, randvoorwaarden en uitgangspunten. Veelal worden ambities en doelen onterecht gelabeled als architectuurprincipe vanwege verouderde theorie.

    In de vele trainingen die ik geef zie ik hoe architecten in de nieuwe wereld van visual enterprise architecture kunnen stappen en gaan floreren als ze echte architectuurprincipes, als onderdeel van een architectuurontwerp, begrijpelijk gaan visualiseren voor de opdrachtgever, gebundeld in een aansprekend glossy A3 formaat ontwerpboek. Zodat deze opdrachtgever (de directie) beslissingen mee neemt. Motto: Durven = Doen.

    Ik denk dat veel van de door jou bovengenoemde instrumenten in het licht van een vernieuwd modern beeld van de (toegevoegde waarde van de) architect (als creatief ontwerper van totaalconcepten) moeten worden geupdate.

  2. Beste Daan,
    Veel punten die je noemt zijn terug te voeren tot √©√©n kenmerk van architectuur dat zeker ook in de niet-digitale wereld een bekend ‘probleem’ is, namelijk dat de wereld van de architectuur onvoldoende los staat van de wereld van de bouw, van de ‘ontwikkelaars’. We zitten behoorlijk ‘vast’ in de praktijk van, kort-door-de-bocht, het ingebouwde “wij van WC-Eend adviseren WC-Eend”. Zowel DYA als NORA als TOGAF zijn producten van, of worden gedomineerd door, de bouwwereld (de ICT industrie). En zelfs de architecten die daar los van staan, bijvoorbeeld omdat ze bij een niet-ICT organisatie werken, worden verondersteld hun wortels in, en kennis van, de bouwwereld te hebben. Zo is architectuur een vak geworden dat… door de ICT wordt voorgeschreven in plaats van andersom (‘On the work of the Digital Architect’ http://pauljansen.eu/workandterrain.htm).
    Ten aanzien van jouw eerste punt merk ik op dat (ook) tuinarchitecten en binnenhuisarchitecten natuurlijk niet verantwoordelijk te stellen zijn voor het (onder)belichten van de architectuur van hun context: daar hebben we nu juist die onafhankelijke Enterprise Architecten voor nodig. En ja, daar ligt wellicht een schone taak voor bijvoorbeeld het NAF (jouw punt 8).

  3. Hallo Daan,

    Ik ben blij dat je het jammer zou vinden als DYA niet meer onderhouden zou worden. Bij deze daarom allereerst een geruststelling. We zijn momenteel druk bezig met een vernieuwing van DYA, onder het motto ‘Van samenhang naar verbinden’. Ik zie als belangrijke volgende stap om tot effectieve architectuur te komen, dat wij architecten ons meer los maken van de structuren en meer focus leggen op verbinden van mensen en gedrag. DYA heeft architecten geholpen de stap te maken van Product (raamwerken en blauwdrukken) naar Proces (inbedding in de organisatie). De volgende stap is de stap naar Persoon (het verbinden van mensen). Waarbij product en proces natuurlijk belangrijk blijven, maar ze zijn niet voldoende. Verbinden speelt op verschillende terreinen. Verbinden van de vele disciplines die zich allemaal vanuit hun eigen invalshoek bezig houden met beheersbare verandering, zoals bijvoorbeeld portfoliomanagement, business analyse, requirements management en architectuur. Maar ook verbinden van de verschillende niveaus van besluitvorming. En de verbinding tussen strategie en uitvoering. Essentieel voor effectieve verandering is het samenspel tussen de mensen in de organisatie. Architectuur is daar een onderdeel van. Maar met architectuur alleen, en met architecten alleen, kom je er niet. Overigens zullen we de nieuwe visie op het komende LAC presenteren.

  4. Beste Daan,

    Sinds een aantal jaar ben ik werkzaam in het vakgebied dat digitale architectuur wordt genoemd. Hoewel ik nog veel heb vragen over dit vak, is een ding glashelder; dit vakgebied staat nog in de kinderschoenen. Hierdoor is er zelfs geen eenduidig antwoord op de vraag: wat is digitale architectuur? Volgens mij zijn alle in deze blog genoemde punten het rechtstreekse gevolg van de jeugdigheid van dit beroep. Misschien is het goed om, voordat we restricties opleggen aan architectuurtitels en proberen een harde scheidslijn te leggen tussen architectuur en engineering, duidelijker te krijgen wat nu precies het doel is van ons vak en welke verantwoordelijkheden hierbij horen. Ook moeten we accepteren en dat de ideale methodiek niet bestaat. Ik denk dat het leerzaam is om te kijken naar vakgebieden die zich al veel langer hebben kunnen ontwikkelen. Erg inspirerend vond ik bijvoorbeeld de lezing van Polo van der Putt op het PON seminar. Polo ging in zijn lezing expliciet in op de mogelijke (juridische) verantwoordelijkheid van digitale architecten door een vergelijking te maken met de juridische implicaties van de titel architect. Maar ook vakgebieden die verder van ons afstaan kunnen ons helpen. Hoe heeft de geneeskunde zich bijvoorbeeld ontwikkeld? Wat zijn de grote struikelblokken en waar kunnen we van leren? De variatie onder geneeskundige is veel groter dan die onder architecten. Dat neemt niet weg dat de kern van de geneeskunde duidelijk is. Voor Nederlandse geneeskundige wordt de kern verwoord in de KNMG-eed. Deze eed een moderne variant van de Eed van Hippocrates. Hoewel de geneeskunde sinds 400 v. Chr. een enorme ontwikkeling heeft doorgemaakt, staat de kern van deze eed nog steeds overeind.

  5. Beste Daan,

    Dank voor deze lijst. Het doet mij denken aan de lijst “The Top 10 Pitfalls of Enterprise Architecture Programs” die ik enkele jaren geleden op een conferentie van Gartner tegen kwam. Het houdt mij wakker in de uitoefening van mijn vak. Het lijstje heeft een speciale plek in mijn digitale wereld, deze krijgt een plaats er naast.

    Toevoegingen van mijn kant:

    – De architect verdiept zich in de condities waar de organisatie van de opdrachtgever aan moet voldoen om tot een succesvol resultaat te komen. Vaak zie ik architectuur voorstellen ontstaan die voor de samenwerking binnen de organisatie en tussen organisaties verstrekkende consequenties heeft. Ik mis dan echter de bespiegeling of die consequenties aanvaardbaar zijn, of wat de route is om tot die aanvaarding te komen. De moeizame start van de loonaangifte keten is in mijn opinie daar een voorbeeld van.

    – De architect heeft hands-on ervaringen met de technologie en organisatorische concepten die hij ontwerpt. Bij het schrijven van een ontwerp is het voor mij belangrijk dat ik ervaring heb met de concepten die ik aandraag. Zonodig vraag ik de opdrachtgever eerst om een paar zaken in het klein te proberen, zodat we een beter beeld krijgen bij het vraagstuk.

    Deze zijn positief geformuleerd, zodat de volgende versie van je lijst het karakter van een eed of lijfspreuk krijgt.

    Voor mij is 1 architectentitel voldoende, dat is dan iemand die uit kan leggen wat hij doet en zich daarbij aan de lijfspreuk houdt.

    Ik zie uit naar de nieuwe versie van je lijst.

    Groet,

    Saco

  6. Daan en Saco en Mieke en Marlies en Paul en Mark en alle anderen die nog commentaar, suggesties en meningen zullen geven hebben gelijk.
    Hoe is dat mogelijk?

    Het vakgebied digitale architectuur is, in vergelijking met architectuur, zeer zeer jong. Net als een pas geboren kind is de waarneming nog onvoldoende ontwikkeld. De realiteitszin is vertekend en het groeipotentieel onbekend en ongekend.

    Creativiteit, visualisaties, goede gesprekstechnieken, het ‘naast’ de opdrachtgever staan enz. zijn essentieel in het behalen van resultaten. De eerder door anderen genoemde werktuigen zijn daarbij van secundaire aard maar mogen niet in waarde worden onderschat. Net als de bouwmeesters uit de gotiek staan we aan het begin van een ongekende bloeiperiode. De excellente digitale architecten zullen, net als de eerdere genoemde bouwmeesters, op hun eigen buikgevoel afgaan en prachtige architecturen ontwerpen en producten realiseren.
    Dit kan ook zonder bijzondere uitgebreide en ingewikkelde hulpmiddelen. Net als de vakbroeders uit het verleden zonder statici toch kathedralen ontwierpen die na 900 tot 1000 jaar nog steeds bestaan.

    Dit is geen antwoord op de vragen van Daan. Het is bedoelt als ‘steunbeer’!

  7. Beste Daan,

    Prima reflectie. Even per stelling een reactie.

    1. Business- en informatiearchitectuur zijn vaak onderbelicht.
    > Eens

    2. Te eenzijdige focus op architectuurprincipes en frameworks.
    > Eens

    3. De PDW komt nog nauwelijks van de grond.
    > Sommige topbestuurders uitgezonderd (zie bv. het Zero Email initiatief van Atos)

    4. DYA is sterk verouderd.
    > Oneens. Gekwalificeerde architecten kweek je niet met aanpakken.

    5. NORA, hét raamwerk voor de architectuur in de overheid, werkt niet.
    > Eens (dat de NORA niet werkt)

    6. TOGAF is in feite voor engineers.
    > Eens. TOGAF is inderdaad schijnzekerheid en uitermate schadelijk gebleken voor het vakgebied. Oneens dat er een (wereld)standaard moet komen; ook dit zal resulteren resulteren in een schadelijke dogmatiek.

    7. De PSA is vaak overdreven uitgebreid.
    > Eens

    8. Wij lijden onder een ongebreidelde diversiteit aan architectentitels.
    > Eens

    Groet, Erik Vermeulen

  8. Inderdaad, net zoals alle hierboven ben ik het ook eens met de stellingen. Dus daar is weinig discussie over. Het begint al met het gebruik van afkortiningen zoals DYA, NORA, TOGAF, waar een normale business persoon niks mee kan.

    Ook stellen dat het PDW initiatief niet loskomt is sterk, als de afkorting PDW voor de gemiddeld IT’er onbekend is, laat staat de business… (En PDW is niet hetzelfde als “zero mail”, verbannen van email is niet de oplossing)

    Project Start Architectuur is vaak zo uitgebreid en complex (als het al gedaan wordt) omdat er geen overkoepelende beleid en/of architectuur is voor IT binnen een bedrijf. Projecten falen vaak omdat er juist binnen dat project te weinig bekend is over de ongeschreven mogelijkheden/onmogelijkheden van de bestaande IT omgeving in een bedrijf.

    Voor het verhaal van Mark is sterk, en daaruit blijkt ook dat het niet om tools en vakmethodes gaat maar het vak als ontwerper, waarbij planning, presentatie, toelichting, evaluatie minstens net zolang belangrijk zijn als het cartografen werk in de al die verschillende methodes en tools.

    Maar punt 1 is nog wel het belangrijkste: Informatie Management of Informatie Technologie (wel/niet met Communicatie erbij) wordt vandaag de dag gedaan zonder naar de Informatie zelf te kijken. Welke bedrijf heeft nu een beleid over hoe om te gaan met klant informatie, product informatie, of b.v. orders, etc.? Als er al IT beleid is dat gaat het over ERP, CRM, infrastructuur. Kortom de tools en middelen maar niet de doelen.

    De waarde van bedrijven wordt immers afgemeten aan het aantal klanten, het product assortiment, en de omzet (orders). Dus zolang IT en vooral IT architectuur zich niet daarbij aansluit zal de waarde van IT architectuur niet gezien worden.

  9. Beste Daan,

    Ik mis het volgende: een scherpe definitie van het leidend principe voor de “bovenste” architectuurlaag. Van de onderliggende lagen als applicatie-, informatie-, data- en infrastructuurarchitectuur is duidelijk waarmee zij zich bezig houden. De architectuur erboven duid jij aan met business- of digitale architectuur, terwijl enterprisearchitectuur ook wordt gebruikt. Echter, digitaal verwijst te veel naar het middel waarmee het wordt bereikt. Business (of enterprise) architectuur is te algemeen, want business is per definitie het bovenste niveau, dat is namelijk het niveau waarop mensen zaken met elkaar doen en dat is er altijd (geweest). Het gaat dus om de architectuur, waarmee de business zo competitief mogelijk wordt uitgevoerd, gebruik makend van de enorme mogelijkheden van applicaties, informatie, data en infrastructuur. Er moet meer inspanning gedaan worden in het vaststellen wat het leidend begrip is voor die architectuur. En of die vervolgens business of digitale of anderszins wordt genoemd, vind ik minder belangrijk. Voor mij is het begrip ‘service’ een goede kandidaat. In het begrip ‘service’ zie ik goed terug dat er steeds minder kale producten worden geleverd, maar altijd producten die aangepast zijn aan de wensen van de klant en ook vaak geleverd met dienstverlening er omheen. Dat is wat de ‘business’ nu doet en wat wordt mogelijk gemaakt door de huidige technologische mogelijkheden.

    Groet,

    Niek

  10. Daan,

    Ik prijs je vasthoudendheid en je tomeloze energie in het sleuren aan het half-dode paard dat je zelf graag digitale architectuur noemt. Ik onderschrijf geheel en al je acht opmerkingen, bij het lezen waarvan ik alleen maar verdrietig en wanhopig word. Ter illustratie, laatst kreeg ik het verslag van een ronde-tafel conferentie over business architecture onder ogen. Wat een kletspraat, en dat voor de zoveelste keer. Ik probeer daarom heel weinig op te pikken van wat er over digitale architectuur wordt gezegd en geschreven en geblogd, omdat ik er telkens weer verdrietig en wanhopig van word.

    De praktijk van ‘ons vak’ wordt gedomineerd door wauwelaars en lampendansers, om mijn leermeester in de informatica, Edgser Dijkstra te citeren. We gedragen ons als alchemisten en kwakzalvers, die elke dag maar weer wat aanrommelen, voor goed geld ook nog eens. Dat lukt nog steeds omdat de een niet veel beter is dan de ander, en het zal nog wel een hele tijd blijven lukken.

    Ik heb daarom al in de jaren negentig besloten aan een gedegen alternatief te werken, in plaats van mee te sleuren aan het paard. Dat alternatief heet inmiddels Enterprise Engineering. Het is een nieuw vakgebied, dat als object van aandacht de enterprise heeft, waarmee elke soort van georganiseerde menselijke activiteit wordt bedoeld. Alleen door die verbreding van de scope, en door een gedegen wetenschappelijke fundering, kunnen de problemen van de digitale architectuur zinvol worden aangepakt.

    Enterprise Engineering wordt ontwikkeld door meer dan 100 personen in een internationaal netwerk van onderzoeks- en opleidingsinstituten. Momenteel bestaat het uit de TU Delft, Antwerp Management School, TU Lisboa, Universiteit van Madeira, Business School van St. Gallen, Tokyo Institute of Technology, Higher School of Economics, Moscow en Nizhny Novgorod, Tudor Public Research Centre Luxembourg, het NOVI, en IBM Research Almaden CA. Kandidaatleden zijn CSRI Zuid-Afrika (soort TNO), Universiteit van Essen-Duisburg, TU Praag en de Universiteit van Jyväskylä (Finland).

    Samen met Jan Hoogervorst rond ik deze maand een uitgebreid artikel af, getiteld “Fundamentals of Enterprise Engineering”, met co-auteurs van de genoemde instituten. Zolang dat niet officieel is gepubliceerd, zouden we het op VNA kunnen zetten. Goed idee?

    In de verbreiding van Enterprise Engineering via het onderwijs is al het een en ander gaande. Vanaf 2014 bieden de TU Delft en de Antwerp Management School een wetenschappelijke post-master master aan. Het NOVI, samen met andere hogescholen, start ook rond die tijd een leergang Enterprise Engineering voor het HBO. Daarnaast worden er natuurlijk al jaren lang de cursussen in DEMO gegeven (DEMO is de pionier methodiek binnen Enterprise Engineering).

    Van Hans Mulder hoorde ik onlangs dat het Enterprise Engineering Institute en het NAF gaan praten over inhoudelijke samenwerking. Ik hoop van harte dat het iets gaat opleveren, want het roer moet echt om, vind je niet?

    Jan Dietz

  11. Daan,

    Graag sluit ik mij aan bij deze discussie rond ‘Business- en informatiearchitectuur zijn vaak onderbelicht’ en wil ik langs deze weg een compliment maken aan BlogIT.

    De reden van dit compliment is dat jouw en mijn blog over Enterprise Architectuur de aanleiding is geweest dat er binnenkort een overleg plaatsvindt tussen het NAF en Enterprise Engineering Institute over inhoudelijke samenwerking.

    Ik hou je uiteraard op de hoogte van de uitkomsten.

    Hans

  12. Hoezo “huidige” tekortkomingen, die waren er altijd al. We (mensen in het algemeen) hebben op alle terreinen een zo’n grote complexiteit geintroduceerd dat niemand meer kan inschatten wat de daadwerkelijke gevolgen zijn van te nemen beslissingen.

    Het gedoe rond de zorgpremie is daar een mooi voorbeeld van, net zoals de problemen in en met het hele financiele stelsel…

    Complexe methodieken en top-down oplossingen zijn niet de oplossing, ik zie meer in het verhaal dat Atul Gawande verteld in zijn Checklist Manifesto boek en op TED: http://www.ted.com/talks/atul_gawande_how_do_we_heal_medicine.html

  13. 1. Business- en informatiearchitectuur zijn vaak onderbelicht.
    Eerste stelling is zeker waar. Tweede suggereert een te sterk oorzakelijk verband. Toekomstvastheid wordt niet geborgd door business architectuur leidend te laten zijn. Wel verbeterd en in ieder geval de perceptie wat daaronder wordt verstaan en wat daarin de beperkingen zijn in lijn gebracht voor alle verantwoordelijken.

    2. Te eenzijdige focus op architectuurprincipes en frameworks.
    Jij legt hier je vinger op de onvakkundigheid van het vakgebied of op zijn minst de onvakkundigheid in de toepassing daarvan. Wat hier nog wel speelt is dat architectuur principes niet autonoom ontstaan maar altijd gebaseerd moeten zijn op business principes en daar dus altijd een uitvloeisel van moeten zijn. Principes die vaag zijn kunnen dus niet als zodanig toegepast worden. Waar jij een eenzijdige focus suggereert constateer ik een ondoelmatig opstelling en gebruik.

    3. De PDW komt nog nauwelijks van de grond.
    Ik denk dat je overall gelijk hebt. Maar je suggestie dat de PDW, indien gebaseerd op de arbeidssatisfactie van de eindgebruiker, wel van de grond zou komen of beter de effectiviteit en efficiency van het arbeidsproces zou dienen dan wanneer die is gebaseerd op ideeën van topmanagers, die jij als achterhaald kwalificeert, vind ik kort door de bocht. Die discussie kan genuanceerder.

    4. DYA is sterk verouderd.
    Ik ben onvoldoende inhoudelijk bekend met deze methode. Maar iedere methode die niet primair gebaseerd is op de overall doelen, inzichten en beschikbare middelen van een organisatie en zijn bestuurders, en daarmee dus altijd slechts een deelbelang van de organisatie kan ondersteunen, komt zeker voor verbetering in aanmerking. Daarbij denk ik niet dat de hoofdrol die jij informatie en kennis toebedeelt de bepalende factoren zijn voor de vernieuwing. Primair doel is het ondersteunen van de inrichting en werking van een organisatie. Dat betreft beweging. Informatie en kennis zijn daarin belangrijke nieuwe aspecten maar zijn mijnsinziens geen nieuwe vrijheidsgraden.

    5. NORA, hét raamwerk voor de architectuur in de overheid, werkt niet.
    In het algemeen de zelfde opmerking als aangaande DYA. M.b.t. hetgeen je zegt over de expliciete visie op de gewenste toekomstige digitale samenleving, die zou dan moeten komen van degene die voor de inrichting daarvan verantwoordelijk is. Die is er niet. Er is geen over all verantwoordelijke voor de ontwikkeling van een samenleving. Het is natuurlijk wel zo dat de taak van een overheid geen autonome, op zich zelf staande taak is, maar een die direct ingrijpt in die samenleving. Maar dat is weer niets anders dan dat je de omgeving van een organisatie meeneemt in een architectuur aanpak.

    6. TOGAF is in feite voor engineers.
    In je laatste zin sla je met het benoemen van het belang om de vraagkant als sturende factor te zien, de spijker op zijn kop. Ik denk overigens dat het gebrek aan aandacht voor de vraagkant niet zozeer een gevolg is van de gebrekkige methodes (BYA, NORA, TOGAF) maar dat dit oorzakelijke verband nu juist precies andersom ligt.
    Zolang een vragende partij niet serieus zijn eigen rol en verantwoordelijkheid onderkent in het proces van vraag en aanbod neemt hij eigenlijk zichzelf niet serieus. Om concreet te zijn: Organisaties zien het proces van levering en onderhoud van IT faciliteiten te vaak los van het algemene voorbrengingsproces (dus als een aparte bedrijfskolom met zowaar ook nog een eigen P&L of louter als leveranciersrelatie). Gezien het belang van IT in organisaties heeft men echter wel bepaalde verwachtingen aangaande de kwaliteit, kwaliteit en tijdigheid van geleverde IT-faciliteiten. Dat verhoudt zich niet lekker en dat blijkt ook al jaren.

    7. De PSA is vaak overdreven uitgebreid.
    Ik denk dat beide suggesties in de laatste zin waar zijn. Ik denk dat je in en rond een PSA het meest duidelijk ervaart wat de volwassenheid van de architectuur community is. Daar vindt de dagdagelijkse toepassing van architectuur-denken plaats en zou een direct verband gelegd moeten kunnen worden tussen de besteden tijd en middelen en bijdrage aan het einddoel.

    8. Wij lijden onder een ongebreidelde diversiteit aan architectentitels.
    Dat lijkt me een algemene (bedrijfs)economisch principe: Bij gebrek aan een duidelijke vraag is de kans van een gevarieerd aanbod groot.

  14. Daan,
    Mooi overzicht en gelukkig begin je met business en informatiearchitectuur. Als die er niet zijn is het al gauw architectuur om de architectuur met de andere punten tot gevolg.
    Wat ik mis is dat de architectuur een strategische functie zou moeten zijn – gericht op verandering van de organisatie.
    Wat ik ook een beetje mis is dat de helft of meer van de tijd zou moeten zitten in het aantonen van de waarde van architectuur – goede communicatie over veranderingen dus.
    Verder heeft elke architect zijn eigen waarheid binnen zijn of haar mogelijkheden terwijl er geen gemeenschappelijk jargon is om de toegevoegde waarde van architecten en architectuur uit te drukken. Boodschappen komen dan niet over en elke goedbedoelde opmerking wordt als belerend en negatief ervaren.
    ik hoop dat allen hun best doen om een goede architect te zijn.
    marijn

  15. Stelling 1`: Mee eens. Voor veel architecturen geldt dat zij slechts informatiesysteem architecturen zijn. Business architecturen ontbreken veelal, en informatiearchitecturen bijna altijd. Het lijkt wel of dit begrip niet echt begrepen wordt. Wat mij betreft gaat dit verder dan de beschrijving van de informatieobjecten die invoer of uitvoer zijn van een business service

    Stelling 2: Ik weet niet zeker of ik begrijp wat je bedoelt. Om een succesvolle architectuur te creëren is het irrelevant of en zo ja van welk framework gebruik gemaakt wordt. De keuze van een framework draagt bij aan de efficiëntie van de architect maar niet aan de kwaliteit van het resultaat. Bij iedere succesvolle architectuur zijn business principes van de stakeholders consequent toegepast. Architectuur principes zijn daarbij slechts ondersteunend en voor de business stakeholder nauwelijks relevant.

    Stelling 3: Mee eens. En wat nog erger is, de eindgebruiker wordt zelfs belemmerd in de creatie van zijn PDW door de terreur van steeds maar weer nieuwe versies of releases van producten waardoor hij telkens gedwongen wordt te desinvesteren in zijn PDW. Ik weet niet meer hoeveel verschillende tekstverwerkers ik heb gehad sinds ik voor het eerst kon werken met één die mijn creativiteit niet belemmerde; sindsdien kan ik nog steeds een document maken, maar als ik verder had kunnen werken met die eerst genoemde, was ik veel beter in staat geweest deze tekstverwerker te integreren in een PDW.
    Daarmee is niet gezegd dat alle vernieuwing alleen maar slecht is, maar er zijn veel marketing invloeden die negatief bijdragen aan de creatie van een PDW.

    Stelling 4: Deze sla ik over. Als medewerker van Capgemini wordt mijn mening op dit punt bij voorbaat als te subjectief ervaren.

    Stelling 5: NORA is een referentiearchitectuur, niet meer en niet minder, en als zoveel zaken bij de overheid: heel veel tekst met heel weinig inhoud. Als die vele tekst helpt om heel weinig draagvlak bij heel veel stakeholders te krijgen voor heel weinig inhoud, dan is dat toch een klein stapje vooruit en dus mooi meegenomen. Als je hogere verwachtingen had, klopt het dat je teleurgesteld bent. NORA wekt de schijn meer te zijn dan een referentiearchitectuur. Dat is het niet en die pretentie wordt dan ook niet waar gemaakt.

    Stelling 6: TOGAF is een Framework om architectuur te beheren, niet om het creatieve proces van de architect te ondersteunen. Wanneer je een slechte architectuur hebt, ondersteunt TOGAF je om deze slechte architectuur precies zo in stand te houden. Als je een goede architectuur hebt en een lage graad van maturity, stelt TOGAF je in staat om foute beslissingen onder het mom van architectuur te rechtvaardigen. Je kan met TOGAF wel degelijk ook goede architecturen creëren, zonder TOGAF trouwens ook (zie ook stelling 2).

    Stelling 7: Ik ga nog een stap verder. Wanneer men 0 dagen aan een PSA besteed, is nog een extra dag te winnen voor het creatieve proces om te komen tot een goede architectuur. Ik heb nooit begrepen wat een PSA bijdraagt aan de creatie van een goede architectuur. Het kan misschien helpen een business case wat meer schijnprecisie te geven.

    Stelling 8: Het woord architect is al enige jaren aan inflatie onderhevig. Iedere architect is een ontwerper, maar een ontwerper is nog niet een architect. In Nederland is het gebruik van het woord architect in de digitale wereld sowieso verboden en voorbehouden aan een groepje mensen die de fysieke wereld probeert te herscheppen. Helaas is het vinden van goede architecten er niet gemakkelijker op geworden nu iedereen die zelfstandig software kan schrijven zich architect noemt.

  16. Daan,

    Ad punt 4 DYA: Dat zal niet zomaar gebeuren door de eigenaar van DYA. DYA is voor Sogeti geen speerpunt meer. Dat betekent dat het een individuele actie van Marlies zal moeten zijn die in haar vrije tijd DYA 3.0 gaat uitbrengen. Of een DYABOK. Misschien is het beter om Sogeti te vragen DYA als open source te doneren aan het NAF>

  17. Normaal bemoei ik me niet meer met discussies rond architectuur. Dit is vooral een zaak van Alchemisten zoals Jan Dietz dit ook aangeeft. We kunnen dus allerlei tekortkomingen signaleren en ook alternatieven als Enterprise Engineering bedenken, maar dan zitten we weer met nieuwe discussies en stellingen die we verdedigen. Dit geeft nog meer het beeld van alchemisten.

    Belangrijker vind ik de veranderingen die plaats vinden in de IT. Het lijkt erop dat we moeten bewegen naar IT als utility. Grote partijen als Google, Amazon en ook Apple met diepe zakken ontwikkelen en bieden infrastructuren aan om heel anders naar IT te kijken. PDW is daar een uitvloeisel van, helaas nog niet uitgewerkt.
    Deze ontwikkelingen zetten door, ook in het huidige economische klimaat waar toch veel IT dienstverleners minder opdrachten krijgen en dus minder mensen in dienst kunnen hebben. Waar vroeger de overheid nog een goede klant was, verandert dit. Deze dienstverleners zullen zich moeten bezinnen op andere business modellen, willen ze overleven. Ze zullen componenten of diensten gebaseerd op deze componenten moeten leveren, maar ook dan krijgen we scherpe concurrentie.

    Natuurlijk moeten we dan nog wel iets van architectuur hebben, maar de infrastructuur die IT als utility aanbiedt, moet da geheel te configureren zijn. Er zullen tools moeten komen die bedrijfskundigen in staat stellen om met weinig of geen kennis hun IT te configureren. Ook deze tools vormen onderdeel van IT als utility.

    Als we nu eens veronderstellen dat IT een utility wordt, dan kunnen wij als architecten alchemisten blijven en voortdurend deze utility verbeteren. En dan nog zullen we zien dat er anderen komen die alternatieven bieden. Mogelijk is een vergelijking met energie te maken, waar we naast het distributienetwerk (Internet) producenten hebben (Google, Amazon, Apple, inclusief bepaalde infrastructuren) ook private stroomopwekking via zonne-, windenergie of mogelijk andere vormen een rol gaat spelen en iedereen terug kan leveren aan het netwerk, mogelijk direct aan zijn buren. Is dit niet met IT mogelijk? Denk aan alle processing en storage capaciteit die veel mensen al hebben, waarom biedt ik dat niet voor de buurt aan?

    Kortom, we moeten openstaan voor veranderingen. Connectiviteit op allerlei lagen wordt belangrijk, laten we ons daarop richten.

  18. Hallo Daan,

    Goed stuk, ik denk dat het erg nuttig is om af en toe eens expliciet stil te staan bij wat we als architecten nog te bereiken. Ik kan me eigenlijk in alle 8 je opmerkingen vinden, maar ik zou er twee aan willen toevoegen. Heb je meteen een mooi rond getal van tien 🙂

    De eerste opmerking heeft Marijn al gemaakt: architecten weten naar mijn gevoel nog steeds te weinig hun toegevoegde waarde duidelijk te maken aan stakeholders, vooral IT engineers en opdrachtgevers. Gelukkig worden er wel allerlei initiatieven ondernomen om die toegevoegde waarde inzichtelijk en aantoonbaar te maken (o.a. het werk van Raymond Slot).

    De tweede opmerking heeft te maken met een onvoldoende focus van architectuur op flexibiliteit. Als er al een trend is in de business de afgelopen 10 jaar, dan is het wel dat flexibiliteit van de digitale werkomgeving steeds belangrijker wordt. Dat geldt zeker voor de publieke sector. De meeste architectuurmethoden spelen daar nog onvoldoende op in. Ook hier geldt dat er wel ontwikkelingen zijn op dit gebied (“agile architectuur”), maar die zouden nog wel wat meer theoretische inbedding en bekendheid mogen krijgen wat mij betreft.

  19. Ad punt 4 DYA: Op dit moment is er bij Sogeti tussen de architecten een levendige discussie gaande over de volgende stappen die wij zien op het gebied van architectuur in het algemeen en DYA in het bijzonder. En we toetsen die gedachten breed in ons netwerk buiten Sogeti. Net als bij de geboorte van DYA, werken we ook nu weer vanuit de ervaring die we in de afgelopen jaren in de praktijk hebben opgedaan en de nieuwe ontwikkelingen die we nu in de praktijk zien en proberen die te vertalen naar best practices. Daarbij gaat het niet om de raamwerken, maar veel meer om gedrag. Van samenhang naar verbinden. We moeten als architecten echt ontsnappen uit het harnas van de structuren en zorgen dat we daadwerkelijk helpen om business waarde te leveren. Dat het hoog tijd is om de nieuwe inzichten ook op een of andere manier te publiceren, klopt. Daar werken we aan. En Nanne, wees gerust, ik doe in mijn vrije tijd heel andere dingen dan over architectuur nadenken.

  20. Ik herken veel wat Daan hier roept en ben het in grote lijnen wel eens wat velen hier als commentaar leveren. Ik denk dat het grootste probleem nog steeds is dat wij (voornamelijk ICT geori√´nteerd of op zijn minst door klanten en opdrachtgevers gepercipieerd) ons bedienen van het woord “architectuur”. Op het moment dat je op directie- en/of RvB niveau dit woord laat vallen is mijn stelling dat 90% van de aanwezigen denken “a, een ICT feestje”. Ik lees het hier ook in de commentaren van een aantal: we hebben het te complex gemaakt. Wat ik ook daadwerkelijk mis, is niet alleen de verbinding tussen de verschillende architectuurlagen, maar ook het de daarbij direct behorende niveau van details. Een directie/RvB lid (uitzonderingen daargelaten) trekt het niet als er meer dan 9 +- 2 bolletjes en streepjes in een slide staan. Ten tweede onze vocabulaire staat vol van de buzzwords.
    Ik heb zelf een tweevoudig arbeidsverleden bij HP en kan je verzekeren, dat als ik bij een klant kwam, dat ze met koeienletters op mijn hoofd HP zagen staan. En wat is het beeld van klanten van HP: dat is een hardwaretoko. Ik kon praten als brugman (of mijn nog meer gerespecteerde collega’s), maar het gaat je echt niet lukken om dergelijke potenti√´le opdrachtgevers ervan te overtuigen dat je ook verstand van HUN business hebt! . Dat maakt het erg lastig.
    Wellicht dat we ons moeten li√´ren aan business consultants (zodat de link tussen de architectuurlagen “op de achtergrond” kan plaats hebben). Beeldvorming is volgens mij ons grootste probleem.

  21. Tekortkoming 0: digitale architecten nemen zichzelf en vooral elkaar veel te serieus, denken teveel na over hun eigen bestaansrecht, hun manier van werken en de centrale plek die ze denken te vervullen in de informatiewaardehuishouding van het bedrijf. Terwijl de rest van het bedrijf toch vooral aan het ondernemen is, producten en diensten creëert en levert en – zeker in deze tijd – de klant tevreden probeert te houden. En daarmee steeds minder begrijpt waar die digitale architecten mee bezig zijn, c.q. waar ze toe doen. Op zijn minst krijgt de rest van het bedrijf het idee dat met die jonge gasten van de ontwikkelgroep en met die van de leverancier van IT-Cloud diensten het toch een stuk beter zaken doen is Рen dus geld verdienen Рis. Voor het 10 jarige jubileumboek van het NAF, uit te reiken tijdens het LAC2012, is deze mening in het artikel “De architect denkt te veel” verder uitgewerkt. De digitale architect anno 2012 is teveel met zichzelf bezig en te weinig met de – steeds sneller – veranderende context om zich heen en lijkt er daarmee steeds minder – binnen het bedrijf – te toe doen. Alle mooie methodieken, raamwerken en certificeringen ten spijt, de digitale architect zit op een doodspoor.

  22. @ Daan,

    Lees je lijstje nog eens door. Als je probeert te begrijpen wat je eigenlijk schrijft zie en begrijp je het failliet van dit alles.

    Zo je de acroniemen al kent is dit een lijst met vooral commercieel opgetuigde rimram waar organisaties weinig aan hebben en waar vooral geld aan verdiend is, of nog wordt. Manieren van aanpak cq. denken en/of werken als TOGAF, DYA, architectuurprincipes en ga zo maar door waren al niet of nauwelijks geschikt toen ze geïntroduceerd werden, en dat begint nu in de praktijk steeds duidelijker te worden. Zie bijvoorbeeld ook mijn eerdere evaluaties van bijvoorbeeld DYA, TOGAF, NORA en de vele andere “referentie” architecturen.

    De redenen komen voort uit een simpele achtergrond: alles is en moet volgens IT technologie gedreven zijn, en blijven. IT interesseert zich gewoon niet echt voor IT gebruikende organisaties, het gaat hen om IT. Zij blijven, impliciet en soms expliciet, roepen hoe stom organisaties zijn dat ze IT te weinig gebruiken. In organisaties hoor je daarentegen steeds meer dat IT voor hen vooral een beperkende factor is voor het ontwikkelen van de organisatie en haar producten en diensten; IT blijft maar roepen dat ze het nou eindelijk eens moeten leren.

    Maar IT moet nu echt gaan leren. Niet door de zoveelste BoKS neer te zetten (alleen al in Europa zijn er al meer dan 200 verschillende en komen er haast dagelijks bij) maar door gewoon IT eens als een reeks vakken met een bepaalde plaats te gaan benaderen. Het feit dat PSA’s (net als sourcingcontracten) zo dik zijn en we toch steeds weer constateren dat organisaties gewoon niet goed weten wat ze nu eigenlijk willen, PSA’s werken immers per probleem, spreekt boekdelen. En dat is het probleem van wie aan de informatievoorziening werkt, van niemand anders.

    Eigenlijk is ontzettend duidelijk wat moet gebeuren. Alleen trekt IT zich daar (nog) niets van aan. Lees mijn voorzet in het komende NAF lustrumboek maar. De verandering is simpel: IT moet dienstbaar worden en uit haar huidige, zelfbedachte en (vaak) megalomane rol als we echt verder willen met een informatievoorziening. En dat betekent discipline, weten waar we mee bezig zijn. Dan gaat het om mensen, en zeker niet om de soort methoden enz. zoals jij die hier met acroniemen op een rij zet. Ontwerpers dienen, bijvoorbeeld, niet ook nog even de bedrijfsprocessen verder uitwerken omdat de bestaande uitwerking hem of haar niet aanstaat. Weet, als organisatie (niet IT), wat je wil voordat je de volgende PSA of het volgende sourcingscontract gaat opzetten om een volgend probleem op te lossen. Geen “vrije” aanpak meer toestaan, zoals DYA van oudsher voorstelt. Luisteren naar wat een organisatie wil, en niet binnen de kortste keren zeker weten dat het bepaalde IT wordt omdat dat ergens anders ook zou werken. En ga zo maar door.

    Dus je hebt gelijk, en ik kan je korte lijst ook nog eens heel stevig uitbreiden. Het worden interessante tijden…..

    M.vr.gr., Steven

  23. Er is hoop: op nr 3 van BEST JOBS IN AMERICA CNNMoney/PayScale.com’s list of great careers staat met stip Software Architect

    What they do all day? Great software architects are designers and diplomats. They create innovative and valuable programs, but they also translate highly technical plans into a vision the C-suite can understand. They are a crucial link between a company’s tech unit and management.

    Klinkt lang niet gek! Als we onszelf eens minder serieus namen en meer met ons gevoel te werk gingen dan worden we in Nederland misschien net zo populair als in the US.
    Meer hierover in artikel dat ik met Erik voor de NAF-lustrumbundel in gestuurd heb.

    Charles
    Mensen ik zou zeggen keep on trucking ondanks de vallende bladeren

    zie http://money.cnn.com/pf/best-jobs/2012/full-list/index.html

  24. Een andere tekortkoming vind ik dat het architectuurproces niet duidelijk is of niet uitgevoerd wordt.
    Met architectuurproces bedoel ik de totstandkoming en handhaving van werken onder architectuur.
    Vaak wordt er wel een ontwerp neergelegd en besproken maar handhaving is ver te zoeken.
    Ik zou willen pleiten voor een z.g. projectarchitect die tijdens de uitvoering van het project meedoet en met z’n voeten in de modder waart. Tenslotte wordt de grote winst van architectuur behaald in de beheerfase. En die kan heel lang zijn…

  25. Dag Daan,

    Met veel plezier je pijnpuntenlijst gelezen. Een prima start van de discussie. Ze zijn me uit het hart gegrepen.

    Ooit was het doel van (werken onder) architectuur het verankeren van de informatievoorziening in de reguliere bedrijfsvoering. Dat is bij de meeste bedrijven nog bij lange na niet gelukt. IT is maar al te vaak een eiland met zijn eigen (onbegrijpelijke) regels, gewoonten, cultuur en besturing. De problemen die je signaleert zijn evenzovele symptomen van dit isolement. Er zijn er vast meer. Eéntje die bij mij al snel opkomt is de babylonische spraakverwarring die ontstaat doordat het begrippenkader in de informatievoorziening niet synchroon loopt met het begrippenkader in de business. Daar zijn vele voorbeelden van. Vaak zijn begrippen ook niet eenduidig gedefinieerd en betekenen ze in verschillende contexten iets anders. Dergelijke multi-realiteit is een haast nog onontgonnen terrein dat des te nijpender wordt naarmate meer informatiebronnen op enterprise niveau gecentraliseerd worden. Wat vroeger met name in enterprise data warehouses knelde, doet nu pijn in alle enterprise services Рmet de grootschalige ERP-systemen voorop.

    Ik zou tenslotte bij de inhoud nog een kritische noot willen plaatsen. Je schrijft:
    Architectuurprincipes dienen om de ontwerpruimte in te perken, maar krijgen pas hun waarde als je ze verbindt met architectuurvisualisaties.
    Daar laat je volgens mij een kans liggen. Architectuurprincipes krijgen in mijn visie pas waarde als je ze verbindt met concrete bedrijfsdoelstellingen. Dan zie je ook dat principes niet altijd alle doelen dienen en kun je als architect in je analyse tot de conclusie komen dat voor sommige problemen het volgen van de architectuurprincipes schadelijker is dan het overtreden ervan. Misschien dat dán een keer de discussie op gang kan komen dat een creatieve oplossing meer waarde creëert dan het slaafs volgen van de principes die zijn bedacht om de problemen uit het verleden te tackelen.

    Hans Bot.

  26. Daan,

    Architectuur is een spel dat in en tussen de organisaties wordt gespeeld en voor velen onder ons te moeilijk is en zeker ook voor de meeste managers. En die managers horen daar bovenop in hun netwerk geruststellend dat het overal hetzelfde liedje is met ICT. Dus daar moet je dan klaarblijkelijk mee leven. Het concept van de heilige architectuur bestaat in mijn ogen niet. Wij moeten ons tevreden stellen met de nodige deelsuccessen. Het ontwerpen en invoeren en dynamisch bijhouden van een digitale architectuur met duizend beperkingen van de deelarchitecturen is niet te vergelijken met de statische eenvoud van een gebouwontwerp en de uitvoering daarvan. Dat moeten we accepteren en we moeten ons tevreden stellen met enkele mooie edelstenen met soms groeicapaciteit (DEMO? of system engineering?). Architecten zijn eigenlijk mensen-/hersenkneders met uitgebreide kennis van digitale mogelijkheden en/of moeten weten waar ze die kennis kunnen halen. Digi-architecten kneden en knutselen met duizenden kennis knooppunten. Een levenslange puzzel die blijft boeien. Dit omdat er steeds weer andere puzzelstukjes op het bord verschijnen en andere spontaan verdwijnen.

    In de overheidswereld is dat niet anders in de verhouding van vooral de rijksoverheid en gemeenten. Zie het voorbeeld van de invoering van de voornamelijk landelijk opgezette mgba. De voorbereiding en invoering nemen jaren in beslag en tijdens het invoeren komen er on the flight/fight allerlei vraagstukken op die centraal gedresseerd worden en al die gemeenten moeten dan zelf zorgen voor een juiste aanpassing van hun interne informatiehuishouding. Ongeacht of ze architecten hebben en de beperkte middelen en capaciteit. Geen wonder dat de nieuwe regering grotere gemeenten wil waarvan ze grotere slagkracht verwachten. Zal dat een architecturale overweging zijn? Of een wens om de complexiteit te vergroten?

    Ik denk dat wij nog jarenlang lijstjes met een top tien tekortkomingen kunnen maken. Ik zou aan de door Daan gepresenteerde lijst willen toevoegen dat architectuur voor velen nog een brug/puzzel te ver is en wij ‘architecten’ veel te hoge verwachtingen hebben van het werken onder digitale architectuur.

  27. Ik zie de alignment met business en informatie architectuur als de grootste tekortkoming binnen bedrijven. Het is niet zo dat het niet bestaat, maar er bestaat geen integrale view vanuit een architectuur perspectief. Enterprise Architecten zijn meestal IT architecten. Dit terwijl het belangrijkste doel de optimilisatie van je organisatie is en de sucesvolle uitvoering van de bedrijfsstrategie. IT is daarin slechts een onderdeel. Startpunt is governance en vervolgens de organisatie, master data en KPI’s, processes en uiteindelijk IT. Ik zie Business Architectuur of Business Enterprise Architectuur dan ook als de overkoepelende discipline. Wil je als Enteprise (IT) Architect een CIO of Operational Manager kunnen blijven ondersteunen in de toekomst, dan zul je jezelf moeten ontwikkelen tot Business Architect. Concepten als Business Modellen of een Operations Model spelen daarbij een belangrijke rol. Frameworks als TOGAF helpen architecten om het architectuur proces vorm te geven maar schieten tekort t.a.v. inhoudelijke modellen en sluiten niet aan bij de taal van een hoger management. Gebruik het dus op de achtergrond, maar zeker niet richting je stakeholders. Met name waar het Business Architectuur betreft.

  28. Hallo

    Ik heb wat feedback op het punt over DYA en over raamwerken:

    1. Mooi dat we kunnen zeggen dat we met een volgende “versie” bezig van zijn DYA.
    2. In DYA|Software (hoofdstuk 6, 8) is het punt van Daan over informatiearchitectuur aangepakt en wordt uitgelegd over hoe er mee om te gaan. Ik heb daar tevens vorig jaar op het LAC een tutorial overgegeven. Ik besef dat dat stuk DYA nog niet overal toegepast wordt. (Het lijkt of veel business-/informatie-/enterprisearchitecten schrikken van het woord Software in de titel van DYA|Software)
    3. Overigens is dat punt er vooral, omdat er in DYA een raamwerk staat dat organisaties een op een overnemen, terwijl er toch duidelijk bij staat dat je het aan moet passen aan de eigen situatie. In het DYA-boek staat niet hoe je dat moet doen. In DYA|Software staat dat wel.

    Ik denk dat het goed is om een raamwerk te hebben. Maar, de meeste organisaties pakken een standaardraamwerk en gaan dat top-down invullen. Dan krijg je discussies over wat in welk hokje thuishoort. Zoals “Dat hoort wel/niet in de PSA thuis”. Dat is in mijn ogen een onzindiscussie. Je moet eerst bedenken over welke aspecten/elementen er architectuuruitspraken gedaan worden. Daarna kun je jezelf afvragen in welke verantwoordelijkheidshokjes je dat indeelt. En als gevolg daarvan kun je bedenken welke documenten je allemaal onderkent.
    Want, er is maar een architectuur: systeemarchitectuur. Het systeem kan een enterprise zijn of een ander ding in de organisatie zoals een applicatielandschap of businessdomein. Architecten die wel praten over hun/een hokje (=deelarchitectuur), maar niet over wat erin zit, weten niet waar ze het over hebben.

    groeten Robert

  29. We hebben nog een lange weg te gaan, maar dat is niet verwonderlijk bij een relatief jong vak. Daar kun je pessimistisch over zijn, of ruimte voor verbetering zien.

    De meeste punten onderschrijf ik wel. Over de frameworks/referentiemodellen ben ik minder pessimistisch. We moeten ze niet
    teveel als heilig doel zien, maar verstandig toepassen als handig hulpmiddel, om niet telkens het wiel opnieuw te hoeven uitvinden. Dezelfde houdingen (te strak aan vasthouden, verketteren, slim mee omgaan) zie je ook bij PrinceII (projecten), ITIL (beheer), Scrum (Agile ontwikkeling) en vast veel meer.

    Het is zeker waar dat voor echte Enterprise Architectuur de frameworks meer ruimte voor de business moeten inruimen. Ik ben
    benieuwd hoe Enterprise Engineering van Jan Dietz ea daar mee om zal gaan. Een interessant alternatief dat ik recent ben tegengekomen is PEAF (Pragmatic EA Framework). Dit houdt expliciet meer rekening met de business, inclusief Strategic Planning, Informatie Management, en zelfs de Cultuur van de organisatie. Dit zou de inspanning voor de verbetering van stelling 1 mogelijk beter kunnen ondersteunen.

  30. Veel van de zaken die je opschrijft vind ik in meer of mindere mate herkenbaar. De grootste tekortkoming die ik ervaar, staat er echter niet bij. Namelijk dat het grote gros van de architecten de vaardigheden mist om met hun mooie visies en vergezichten hun opdrachtgevers te inspireren. Mi omdat mensen met de titel of rol van architect vaak hele goede engineers zijn en blijven hangen, of houvast zoeken in togaf, nora, DYA, ellenlange PSA’s, verhandelingen over services en servicebussen en allerlei wetten waar “de business” zich aan moet houden (eigenaarschap, governance, klantspecificaties), maar die diezelfde business zelden begrijpt.

    Als het vakgebied zich daar niet uit ontworstelt, zal het marginaliseren.

    Ditzelfde risico is er trouwens ook voor andere IT gerelateerde beroepsgroepen, zoals de service manager en de informatiemanager die zichzelf onbegrepen voelen door hun baas. Ze vertonen hetzelfde patroon: mijn werk is belangrijk, maar mijn baas begrijpt me niet, daarom zoek ik houvast bij modellen en standaarden. De hele wereld gebruikt die, dus dat moet goed zijn. En zo schuilen ze bij elkaar, beschermd door hun eigen terminologie en heilige overtuiging dat ze het goede doen…..maar of het daardoor beter wordt voor de business?

    Wat moet er nu gebeuren om er voor te zorgen dat een grotere groep architecten uit zijn schuilplaats komt, vol in het licht gaat staan en zij aan zij met de business gewoon aan het werk gaat? Principes gebruikt in plaats van ze alleen maar opschrijft en er toetst, pragmatisch is oplossingen bedenkt, maar dogmatisch blijft in het blijven streven naar die stip op de horizon, mogelijk makend in plaats van beperkend?

    Dat lijkt mij nou een mooie vraag voor de volgende 13 jaar NAF, een mooie en noodzakelijke volgende stap in de volwassenheid van het beroep van architect van de virtuele wereld.

    Misschien een wat filosofische bespiegeling, maar ik zie dit als een belangrijk issue.

    Hoop dat je er wat aan hebt.

  31. Ha Daan!
    Ik sluit me bij Jan Dietz aan, maar wijs ook graag op de kanttekeningen van indertijd Ben Eppenhof, die jij je nog wel zult herinneren, zie: http://www.sparring.nl/index_bestanden/demo.html
    De crux van alle discussie is wat mij betreft voornamelijk de relativiteit van ons streven om met complexiteit om te gaan die we in feite niet goed aankunnen. Van nature zullen we dan structuur proberen aan te brengen en samenhang, en lopen we onmiddellijk in de fuik van de veronachtzaming vd menselijke maat en het menselijk contact.
    Hulpmiddelen zijn in dezen allemaal zo lang als ze breed zijn en een beetje meer begrip en respect is wat mij betreft beter dan polemiseren op het scherp vd snee. Vraag je steeds vooral ook af in hoeverre niet de ene gehandicapte de andere verder probeert te brengen.
    “Architectuur” heb ik voor IT altijd erg pedant gevonden, buiten de legendarische systeemarchitectuur dan van onze eminente landgenoot Gerrit Blaauw, zie: http://www-set.win.tue.nl/UnsungHeroes/heroes/blaauw.html . Laten we het daar gewoon bij laten, stel ik voor: “”
    Alle alinea’s over architectuur, waar je in gemoede dat woord kunt vervangen door frituur, zijn een misdadige poging tot verwarring – zeker op het uiterst belangrijke terrein van de “digitale architectuur”.
    Hartelijke groet, Jaap Bloem

  32. Beste Daan,

    Je zou haast gaan denken dat er alleen maar valt te mopperen op de met architectuur bereikte resultaten. En dat vind ik niet terecht. Want veel gerealiseerde veranderingen in organisaties aan bedrijfsprocessen, informatievoorziening en IT hadden we zonder architectuur toekomstbeelden, principes en andere kaders, gebruik van standaarden en hergebruik van IT niet voor elkaar gekregen.

    In de onderbouwing van je geponeerde tekortkomingen van DYA, NORA en TOGAF proef ik de behoefte aan een andere/betere architectuur methode, en aan een overkoepelende visie waar het naar toe moet, ipv middle out te werken.
    Ik vind dat dit ons niet zal helpen om architectuur succesvol(ler) te laten zijn. Daarvoor zijn een realisme en pragmatiek essentieel. Want de realiteit is dat veel organisaties een complexe IT-omgeving hebben (dat hadden we zonder architectuur overigens niet eens voor elkaar gekregen☺), er in de back office veel legacy is waar we nog jaren mee voort moeten, dat organisaties steeds meer samenwerken in ketens en dat voor die ketens regievoering vaak ontbreekt. Zoals bijvoorbeeld die digitale Rijksbouwmeester voor de e-overheid inderdaad ontbreekt. Maar het is een illusie te denken dat deze regievoering gaat opereren vanuit een green field overkoepelende toekomstvisie. Dit zal ons niet gegund worden. Het zal een kwestie zijn van pragmatisch verbinden van bestaande organisaties en IT-omgevingen, met losse en gestandaardiseerde koppelingen tussen applicaties.
    Architectuur is een van de disciplines om organisaties te kunnen blijven veranderen in samenhang. Want dat is nodig, en het tempo van veranderingen neemt alleen nog maar toe. In deze context zijn mensen nodig, die door middel van veel communicatie, afstemming en vasthoudendheid met alle stakeholders eerst adviseren over veranderingen, en dan de belangrijkste veranderingen voor elkaar helpen krijgen. Met als rode draden hergebruik, standaardisatie, decomplicering, samenwerking (ook in ketens) en verbinden (bv. met de cloud, de nieuwe hype).

    Laten we als architecten deze handschoen oppakken. Zo hebben we echte toegevoegde waarde voor een organisatie (ook in financiële zin door besparing op IT-kosten).
    Energie en kunde om benodigde veranderingen tijdig voor elkaar te helpen krijgen is in ieder geval voor mij de fun factor, niet de perfecte architectuurmethode of een ‘holy grail’ toekomstvisie. Want wie van onze stakeholders zit daar op te wachten?

    George

  33. Dames en heren commentatoren,

    Ik heb de afgelopen twee weken niet gereageerd op alle waardevolle commentaren op mijn blog over de tekortkomingen in de digitale architectuur. Tijdsdruk!

    Ik ben de blog begonnen met de behoefte aan een beeldenstorm door de vele heilige huisjes die zijn ontstaan. Door die heilige huisjes zijn grote delen van het architecturen verworden tot een mechanisch proces waarin geen enkele creativiteit meer is te ontdekken.

    Uit de vele positieve commentaren krijg ik de stellige indruk dat er velen zijn die vinden dat het tijd wordt voor een renaissance van de digitale architectuur.
    Daar ben ik blij om! Hoe kunnen wij dat vorm gaan geven? Ik ben over twee weken op het Landelijk Architectuur congres aanwezig, dus spreek mij daarover aan s.v.p.

    Groet,
    Daan.

  34. Jan Dietz,

    Jammer dat jij een opbloeiende discipline als digitale architectuur betitelt als een ‘dood paard’. Ik en velen met mij zouden het liever betitelen als een jong veulen dat geholpen moet worden om te leren lopen.
    Dat leren lopen doe je trouwens niet met allerlei ingewikkelde formules. Dat schrikt eerder af.

    Moedig dat je in alle eerlijkheid uitspreekt ‘we gedragen ons als alchemisten en kwakzalvers’. Dat getuigt van veel zelfkennis. Gelukkig ken ik veel architecten die helder en transparant werken.

    Groet,
    Daan.

  35. Peter,

    Ik ben blij met jouw oproep tegen complexiteit.

    Blaise Pascal schreef een paar honderd jaar geleden een lange brief aan een vriend met in de PS een excuus: ‘Als ik meer tijd had gehad, was de brief korter geweest’. Dat is een groot probleem in de IT, we nemen niet de tijd om zaken bondig (wel begrijpbaar) te formuleren. Dat geldt van architect tot programmeur.

    Daarnaast zie ik nog steeds architecten die gek zijn op complexiteit liefst gelardeerd met een aantal interessant-lijkende formules. Ik zie overvolle complexe architectuurvisualisaties. Ik zie pietepeuterige architectuurprincipes.
    Een boerenwijsheid: ‘Eenvoud is het kenmerk van het ware’.

    Groet,
    Daan.

  36. Marijn,

    De businesswaarde van architectuur zou centraal moeten staan. Ik bedoel businesswaarde zoals gepercipieerd door de business zelf, niet uitsluitend de businesswaarde die de architect vindt dat de business dient te ervaren.
    Bij grote architectuuropdrachten doe ik eerst een rondje langs de smaakmakende businessmanagers om hun acceptatiecriteria voor architectuur te ontdekken. Belangrijk om te weten om applaus te kunnen oogsten (verwachtingsmanagement).

    Groet,
    Daan.

  37. Arnold,

    Interessant jouw opmerking over NORA: ‘heel veel tekst, met heel weinig inhoud’! Een statement uit het AO-tijdperk: ‘Wie schrijft die blijft’. Daarom is AO (Administratieve Organisatie) verzand tot Alles Opschrijven. Aan deze ziekte lijden nog veel architecten.

    Je stelt terecht dat TOGAF op zijn hoogst een raamwerk is om de consistentie en coherentie van de verzameling architectuurprincipes te controleren. Het is beslist geen katalysator voor het creatieve proces dat architecting zou moeten zijn.
    Ik vind trouwens dat een architect die opschept over zijn/haar TOGAF-certificaat terzijde moet worden gelegd bij selecties.

    Jouw laatste opmerking: ‘iedere architect is een ontwerper, maar een ontwerper is nog niet een architect’ doet bij mij de vraag opkomen: ‘wat kan of doet een architect meer dan een eenvoudige ontwerper?’.

    Hartelijke groet,
    Daan.

  38. Leuk stuk. Wat mij betreft zou het volgende nog toegevoegd kunnen worden: ‘Het concretiseren van architectuur onderwerpen lijkt in een Agile Project omgeving vaak niet te werken’. Over het algemeen zie ik architectuur-‘afdelingen’ worstelen met het tijdig opleveren van de benodigde richtlijnen/documentatie/uitwerkingen en missen daarbij de snelheid om zich aan te passen aan een steeds sneller veranderende wereld. Om de klant goed te kunnen blijven volgen is een Agile project aanpak voor veel projecten ideaal, maar wel onder de technische aansturing/richtlijnen van een architectuur. Ik zie dit helaas vaak mis gaan.

  39. Michiel,

    Ik ben het met je eens dat architecting een extra uitdaging krijgt bij agile systeemontwikkeling waaronder Scrum. Een gedeelte van de architectuur wordt immers pas geconcretiseerd tijdens de sprints.
    Door de interactieve werkwijze wordt er ook een groter beroep gedaan op de alertheid van de architect! Interessant toch?

    Groet,
    Daan.

  40. @ Stephan Hendriks

    Ik geloof niet in de alignment tussen business (inclusief informatie) en IT. Dit is een item dat 15 jaar geleden is aangekaart door de IT. De business is niet geïnteresseerd in alignment, de business wil bij veranderingen niet beperkt worden door de bestaande IT. Dus maak op alle niveaus een adaptieve architectuur.

    Enterprise architect is mijns inziens een rol. Ik spreek liever over businessarchitecten, informatiearchitecten, IT-architecten en infrastructuurengineers. Zij kunnen ondernemingsbreed werken, maar ook op een beperktere scope.

    Ik ben het met je eens dat architectuur begint in de business, dus de overkoepelende architectuur is de businessarchitectuur, zie mijn recente blog hierover.

    En eens, val de business niet lastig met TOGAF.

    Groet,
    Daan.

  41. @ Atilla

    Dank voor jouw waardevolle aanvullingen.

    Jij stelt dat toen je als HP’er bij een klant kwam, men jou associeerde met een ‘hardwaretoko’. Dat vind ik niet zo verwonderlijk. Je kunt nog zo objectief zijn, maar at the end of the day wordt je toch betaald door die hardwareleverancier.

    Ik zou daarom willen voorstellen dat alle architecten opstappen bij IT-leveranciers, softwarehuizen en sourcingsproviders en zich aansluiten bij dan wel vestigen als onafhankelijke, onpartijdige architectenbureaus. Heb ik zelf ook gedaan. Op zijn hoogst kunnen ze overstappen naar een integer consultancy bureau. Dus geen enkel belang bij hardwareleveranties, softwarepakketten, softwarebouw dan wel outsourcingstrajecten.
    Dat zou het voor de klant ook veel duidelijker maken welk belang de architect dient.

    Groet,
    Daan.

  42. @ Barend Jan

    De projectarchitect als rol bestaat al een groot aantal jaren. En, in mijn perceptie hoort een architect te blijven tijdens de bouw.
    Bij sommige organisatie komt hij steekproefsgewijze kijken, bij andere organisaties is hij het hoofd van het design office dat permanent aanwezig is tijdens de projectperiode.

    Sommige CIO’s zijn meer gecharmeerd van projectarchitecten omdat die ten minste met hun voeten in de modder willen staan. Terwijl de enterprise architecten in de ivoren toren blijven.

    Groet,
    Daan.

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here