Home Architectuur Wanneer breekt architectuur eindelijk door in de IT?

Wanneer breekt architectuur eindelijk door in de IT?

130
Overheid

Als er iets mis gaat bij een groot IT-project, als de IT niet naadloos aansluit op de business, als het applicatielandschap dient te worden gerationaliseerd, als nieuwe technologie vloeiend dient te worden geïntegreerd in de technische infrastructuur dan lijkt al jaren het toverwoord bij uitstek ‘architectuur’!
Als je architecten mag geloven, maken we flinke vorderingen met architectuur: een palet aan methodologieën, een grote diversiteit aan raamwerken om architectuurprincipes te inventariseren en een scala aan certificatiemogelijkheden. Kortom de traditionele IT-kenmerken van een volwassen vakgebied.

Is architectuur dus nu al echt doorgebroken in de IT? Ik poneer dat architectuur pas in de kinderschoenen staat. In mijn perceptie is de grote uitdaging voor architecten te zorgen dat architectuur daadwerkelijk wordt erkend door opdrachtgevers van IT-intensieve transformaties, door de business als noodzakelijk instrument om de impact van hun mogelijke beslissingen te kunnen overzien en voor de eindgebruikers van de IT om reële verwachtingen te kunnen koesteren over te bieden IT-functionaliteiten en de bijbehorende belevingswaarde.

In mijn dagelijkse praktijk zie ik veel businessmanagers en opdrachtgevers die wel met de mond belijden dat architectuur nodig is, dat staat immers in de theorieboekjes, maar in daad nauwelijks beseffen waarom architectuur voor hen nuttig zou kunnen zijn.
De business wil nog nauwelijks aanvaarden dat zij in feite de eigenaar zijn van de architectuur, maar het betreft wel hun IT die het functioneren van hun organisatie dient te ondersteunen. De architect is slechts de vakman die helpt om orde en samenhang te bewerkstelligen, die helpt om slimme constructies te formuleren, die helpt om een interessante beleving aan te brengen. Als regisseur van het verbeeldingsproces speelt de architect een katalyserende rol, maar de toekomst van de organisatie hoort te worden bepaald door de business in alle geledingen.

Ik hoor regelmatig het verwijt dat architecten te veel met elkaar bezig zijn en niet voor de business werken, dat zij weinig inlevingsvermogen tonen voor wat de business echt nodig heeft. Ik hoor soms dat architecten zich bezig houden met wat mag en wat beslist niet mag, dat zij ontwikkelingen afremmen in plaats dat zij stimulerend meedenken met de business over verbeteringen en innovaties in de organisatie. Dit verwijt is al ruim 40 jaar oud, vroeger heette het dat de programmeur de gebruiker niet werkelijk begreep en iets maakte wat hij vond dat de gebruiker nodig had.

Hoe komen we nu uit dit verlammende wederzijdse onbegrip? In mijn perceptie ligt de sleutel bij de business. Zij moeten rücksichtslos architectuurbeschrijvingen / architectuurvisualisaties weigeren die zij niet zonder uitgebreide mondelinge toelichting van architecten kunnen begrijpen.

Businessmanager: als je een architectuurbeschrijving krijgt die je niet in jouw denkwereld kunt overzien, geef hem dat direct terug aan de betreffende architect met de opdracht binnen een week terug te komen met een beschrijving die je wel begrijpt! Je zult wellicht zien dat de meeste architecten dat wel kunnen maar er nooit toe zijn uitgedaagd.

Daan Rijsenbrij, www.Rijsenbrij-Academy.nl

 

48 REACTIES

  1. Daan,

    Ik kan me helemaal vinden in je betoog.

    Voordat de business echter massaal de waarde en de mogelijkheden van enterprise architectuur of IT architectuur gaat inzien, voelt en wil gaan gebruiken is er denk ik wel een reeks aan successen nodig.
    Daar waar duidelijk aanwijsbaar architectuur significant heeft bijdragen aan het succes van een project staan businessmanagers zich vooraan te verdringen om die architectuur ook te gebruiken.

    Maar ja, waar zijn die successen…?

    Bij architecten hoort wat mij betreft de druk te liggen om opdrachten voor architectuur binnen te halen. Maar dan moet je als architect wel duidelijk kunnen maken of kunnen laten zien wat je gaat doen en wat de businessmanager er aan heeft.

    Ik zelf geef meestal aan dat architectuur vaak niets meer of niets ander is dan een ontwerp van een systeem op conceptueel niveau in relatie tot de strategie van de organisatie. Dat moet je dan overigens wel maar even kunnen! Een architect is niets meer of minder dan een ervaren creatieve ontwerper en realisatie-coördinator van voorzieningen en infrastructuren.

    Stel dat een logistieke organisatie van de strategische inzet van concepten als e-procurement en e-fullfillment een succes wil maken, dan is het slim om als business aan architecten de opdracht te geven een ontwerpschets, een principetekening en een blauwdruk van deze concepten te maken en uit te werken, alvorens projecten op te starten en producten van leveranciers aan te schaffen.

    Deze ontwerpschetsen, principetekeningen en blauwdrukken van de concepten dienen dan bijvoorbeeld te laten zien waarom de inzet van de concepten nodig / noodzakelijk is in het licht van de strategische uitgangspunten en de bedrijfsdoelen. De visualisaties van de concepten dienen ook te laten zien hoe goed en op welke wijze de concepten geïmplementeerd dienen te worden zodat de concepten de beloofde voordelige resultaten gaan leveren (met andere woorden dat de implementatie van het concept werkt conform het concept-principe).

    Als de business met een bepaald ontwerp van de concepten akkoord is gegaan zijn de architectuurvisualisaties te gebruiken richting projecten en leveranciers om de realisatie in de hand te houden. Een dergelijk traject hoeft geen weken te duren, als de architecten maar over de juiste kennis van zaken (lees concepten en concept-principes) beschikken.

    Kortom: architecten krijgen met de juiste aansprekende en begrijpelijke architectuurvisualisaties het voor elkaar dat ze vele opdrachten krijgen van de business. En de business ziet hun plannen vaker en beter slagen dankzij de mooie architectuurvisualisaties die ze ter ondersteuning van hun management beslissingen daadwerkelijk gebruiken.

  2. Beste Daan,

    Als architect in de praktijk herken ik veel van wat je zegt. Een deel van de problematiek is te wijten aan de volwassenheid van het vakgebied, waarbij teveel zaken het label “architectuur” opgeplakt krijgen en mede hierdoor methoden ook onvoldoende scherp zijn. Hierdoor weten zowel de architect zelf als de opdrachtgever eigenlijk niet precies wat ze van architectuur moeten verwachten.

    Een gevolg hiervan is tevens dat allerlei mensen architect heten, die eigenlijk vooral ervaren specialist zijn en niet de leiderschap, analytische en sociale skills bezitten die essentieel zijn om architect te zijn. Enterprise-architectuur is een strategisch instrument en daar heb je dan ook hele goede mensen voor nodig. IT-architecten moeten IT volledig doorgronden en hebben 10+ jaar IT-ervaring nodig.

    Mvgr,
    Danny

  3. Mark,

    Dank voor jouw uitgebreide reactie.

    Ik ben het roerend eens met jouw constatering dat er een succes nodig is om architectuur echt te verkopen. Probleem is dat bij mijn weten nog nergens architectuur kamerbreed op een volwassen niveau is toegepast. CIO’s en topmanagers zien daar de noodzaak nog niet van in. Dus we zitten in een ‘kip ei probleem’. Hoe breek je daar doorheen.
    Ik zie overigens bij een groot aantal ondernemingen en overheidsorganisaties waardevolle, hoogstaande deeloplossingen op het gebied van architectuur.

    Het instrument ‘architectuur’ is ook geen garantie voor succes, maar het niet toepassen van een volwassen architectuur geeft wel een 95% zekerheid van het falen van het zakelijk inzetten van IT.

    Je hebt gelijk dat architecten echte architectuuropdrachten dienen binnen te halen. Maar ja, laten we eerlijk zijn ‘architectuur’ is voor de top van de business en wellicht ook voor sommige CIO’s nog steeds een onderwerp aan de zijlijn. Als het goed gaat met de business dan wordt de noodzaak niet gezien van architectuur (zonde van het geld), als het slecht gaat heeft men het geld er niet voor (een van de eerste bezuinigingsposten). Ik kan daar vele voorbeelden van geven.

    Tussen de regels door geef je ook aan dat we moeten ophouden een onderscheid te maken tussen architecten en ontwerpers. Dat is een van mijn oude stokpaardjes.
    Bij sommige objecten als auto, kleding en apparaat spreken we over (top)ontwerpers, bij andere objecten als huis, stad, interieur, tuin en vaartuig spreken we (officieel) over architecten. Dat verschil is mij nooit duidelijk geworden. Maar ik constateer wel dat het vakgebied ‘IT’ beide denkt nodig te hebben. Mijn voorkeur is alle ontwerpers architect te noemen, desnoods junior architect. Of anders zou ik de ontwerpers onder aansturing van een architect zetten, waarbij de laatste de eindverantwoordelijkheid heeft over de bouwbaarheid van het ontwerp.

    Ik heb ook moeite met architecten die zich alleen maar bezig houden met architectuurprincipes. Hoe waardevol deze ook zijn, voor de business zijn architectuurprincipes niets anders dan een kille, analytische opsomming van bedoelingen. Ik schat dat minder dan 10% van de echte architectuurprincipes aanspreekbaar zijn voor de business en de eindgebruikers.

    Veel architecten moeten de knop nog omzetten richting de business: van ‘tell me’ naar ‘show me’. Businessmanagers en eindgebruikers zijn vaak visueel ingesteld, alleen de CFO wil een spread sheet.

    Groet,
    Daan.

  4. Danny,

    In Europa kijken wij teveel naar Amerika. Dat geldt ook voor het gebruik van de term ‘architect’. Het is typisch Amerikaans om alles dat gewichtig moet lijken het voorvoegsel ‘architectuur’ te geven. En als overtreffende trap zie ik dat bepaalde collegae van mij zich zelfs ‘global architect’ (laten) noemen.

    Toen ik na de overname van de adviespoot van Ernst & Young door Capgemini met de architecten van Ernst & Young in New York kennismaakte, schudde ik zelfs de hand van een java-architect. In Europa noemde wij dat toen nog een java-topexpert.

    Engineers moeten ophouden zich architect te (willen) noemen. Engineer is een mooi vak, waar je je niet voor hoeft te schamen. Een top engineer mag wat mij betreft een hoger uurtarief krijgen dan een architect, omdat zijn/haar utilisatie lager zal zijn
    Wij hebben een gebrek aan creatieve, vakbekwame architecten, maar wij hebben nog een veel groter gebrek aan top techneuten.

    Ik hoorde laatst bij een klant dat zij hun top engineer hadden gepromoveerd tot architect. Niet omdat hij nu in eens architectuur ging bedrijven, maar omdat de salarisschalen van de architecten hoger doorliepen dan die voor techneuten. Ik vind dat beschamend jegens de beroepsgroep van de engineers.

    Groet,
    Daan.

  5. Daan,

    Ik ben het helemaal eens met wat je zegt en kom de door jou geschetste beelden ook vaak tegen in de praktijk. Gelukkig kom ik echter ook steeds meer voorbeelden tegen die laten zien dat het ook anders kan. Bekend voorbeeld is PGGM dat ondertussen bewezen successen heeft behaald met behulp van architectuur. Ook de concernarchitectuur van de Belastingdienst is een mooi voorbeeld van een door het hoogste businessmanagement gedragen architectuur. Bij een aantal andere grote beursgenoteerde nederlandse bedrijven zijn de architecten ook heel goed bezig en is zelfs de situatie bereikt dat niet programma- en projectmanagers bepalen wat er gemaakt moet worden, maar de architecten. Voor de komende DYA Dag op 16 maart a.s. hebben we weer gezocht naar een aantal voorbeelden waaruit het succes van architectuur blijkt. Sprekers zijn o.a. Henrik van Bruggen, chief architect retail banking benelux van ING en Joost van den Dool, senior enterprise architect van DAF Trucks.

    Groet,
    Martin

  6. Zeer herkenbaar, maar dat iedere architect dit zou kunnen is niet mijn ervaring. Het vereist niet alleen kennis, maar ook bepaalde vaardigheden. Deze vaardigheden die nodig zijn om ‘echt’ met de business te praten en deze ook daadwerkelijk te begrijpen is niet voor iedereen weggelegd.

    Jouw opmerking over de architecten titel op basis van salaris herken ik ook, zeker bij de overheid. Het gaat hier om het verschil van de functie architect (de hoogte van het salaris) en de rol van architect die bepaalde vaardigheden vereist. Ik ben het met je eens dat de naam ‘architect’ hierbij ten onrechte wordt gebruikt maar dat heeft niets met architectuur te maken. Dat bijv. een programmeur iets minderwaardigs zou zijn is nonsens, maar ligt nu eenmaal in het functiegebouw besloten. Ik ben het met je eens dat een zeer ervaren specialist is minstens zo waardevol is als een goede architect.

    Tot slot wil ik graag reageren op jouw opmerking m.b.t. architectuurprincipes. Ik denk dat je hierbij een onderschied moet maken tussen de architectuurprincipes van de business (ook wel hoofdprincipes genoemd) en de afgeleide principes (waaronder veel ontwerp- en bouwprincipes). De hoofdprincipes zijn zeer belangrijk voor de business. Met deze principes is het namelijk mogelijk je te focussen. Strategisch beleid is hier doorgaans niet toereikend voor doordat er teveel interpretaties mogelijk zijn. Mijn ervaring is dat als je samen met het strategisch management het beleid vertaalt naar eenduidige hoofdprincipes (of businessprincipes) deze bij gebruik een zeer gunstig effect hebben op de verdere ontwikkeling van je organisatie. Met behulp van deze principes kun je ervoor zorgen dat alle ontwikkelingen dezelfde kant op gaan aangezien ze voor ieder gebied kaderstellend zijn (niet alleen IT). Ook projecten kun je hieraan toetsen waardoor je iets als portfolio management veel effectiever kunt inzetten. Dat is dus heel wat anders dan ‘kille analytische opsommingen’. Ik hoop overigens inderdaad dat de businessmanager een stuk kritischer naar architectuurproducten gaat kijken op bruikbaarheid.

  7. Daan, sorry,het is een wat langere reactie geworden, maar wel leuk om te maken. Lees het met een knipoog.

    Cynische reactie:
    De complexiteit en jargon van IT en het gebruik van allerlei terminologie in oa. dit artikel is het antwoord op de vraag. Welk business management begrijpt nou wat daar staat en wat het eigenlijk impliceert…..laat staan dat zij aandacht, budget en macht geeft aan architect-snuiters die mekaar bevechten over wat nodig is om de voordelen van architectuur te ‘krijgen’. Dit wordt inderdaad nooit iets zolang de business niet zelf het architectuur-instrument ter hand neemt.

    Optimistische reactie:
    het gebeurt wel degelijk, ieder management ‘doet’ architectuur op zijn eigen manier, impliciet of expliciet. Dit wordt ook wel maturity-denken of capability management genoemd. Dus, wat is dat eigenlijk, het ‘doorbreken’ van architectuur?
    De successen met architectuur zijn d√°√°r waar het management op haar eigen manier gebruik maakt van (een vorm van) architectuur. Zowel in termen van zelfstandig naamwoord (‘de’ architectuur (beschrijving) dus) als ook in termen van werkwoord (het ‘doen’ of ‘gebruiken’ dus).
    Als alle drie tegelijk kloppen (eigen manier, artefact, creatie&implementatie), d√°n heb je succes, of tenminste de perceptie van succes.
    De fout die de meeste bedrijven maken echter, is dat zij:
    – andermans succes gaan ‘kopi√´ren’ terwijl dat natuurlijk niet zo werkt
    – een ANDER laten bepalen hoe zij het zouden moeten doen, en/of
    – met architectuur aan de slag gaan ‘ boven hun kunnen’.

    Academische reactie:
    dat het artikel eindigt met een pleidooi over de begrijpelijkheid van de ‘beschrijving’ als middel voor succesvol doorbreken is jammer, een begrijpelijk beschreven architectuur kan nog steeds ‘fout’ zijn (en dus niks brengen) en moet daarna ook nog eens ge√Ømplementeerd worden….en gaat het d√°√°r niet veel vaker fout? (De plaat maken is minder moeilijk dan hem implementeren.) Ik hoop van ganser harte dat we niet de zaak omdraaien door te stellen dat een begrijpelijk (dus niet ‘formeel’ ?) beschreven architectuur belangrijker is dan een goede architectuur, er is al genoeg schade aangericht met goedbedoelde powerpointjes met leuke symbooltjes.

    Zelfreflectief antwoord:
    zolang niet √©√©n business manager op dit artikel reageert, is daarmee het bewijs geleverd van de stellingname in het artikel. De architectuur community zit mekaar te overtuigen van het wel en wee van ‘ ons’ vak en het interesseert verder niemand wat.
    OF
    Zolang niet één business manager reageert, is de nood / het besef blijkbaar nog niet hoog genoeg om architectuur als instrument nodig te hebben.
    OF
    Zolang niet één business manager reageert op dit artikel, is het inderdaad meer dan nodig om na te denken over de bruikbaarheid van architectuur.
    Zeg het maar.

    Wat helpen zal, is dat steeds meer doorgroeiende jonge managers de cross-over met architectuur makkelijker lijken te maken dan het huidige/oude zittende management. Uiteindelijk komt het goed en ondertussen krijgt elke manager die architectuur die hij verdient.

    Interessant (?) antwoord:
    de manager-mens is gedreven, wispelturig, oneerlijk, ambique en slordig, IT is digitaal, een systeem(landschap) doet derhalve ALTIJD PRECIES wat je ‘ooit’ gezegd hebt dat je wilde. Dat is natuurlijk vreselijk!! En dan verwachten wij dat een manager, die wil draaikonten, onderhandelen en achterf altijd gelijk wil hebben, √≥ns een instrument in handen gaat geven om achteraf aantoonbaar zijn ongelijk te bewijzen toen hij vertelde welke IT hij wilde? Architectuur mag vooral NIET serieuzer doorbreken dan nu. Zit de manager zich eerst aantoonbaar te laten meten in het KPI dashboard en met de Balanced ScoreCard, gaat IT hem/haar ook nog even formeel vastpinnen. Het moet niet gekker worden!

  8. Richard,

    Dank voor jouw uitgebreide reactie.

    In ieder geval zijn wij het met elkaar eens dat de business de eigenaar hoort te zijn van de architectuur. De architect helpt slechts te formuleren wat de business bedoelt. De architect is een soort regisseur van het verbeeldingsproces van die eigenaar, een katalysator van zijn creativiteit.
    Dat eigenaarschap impliceert tevens dat als de IT niet goed gaat functioneren niet de architect de schuld krijgt maar de business. Als de architect iets schetst wat de business niet wil, moet de business nee zeggen en iets laten schetsen wat zij wel wil. Als de business het gevoel heeft dat de architect hen niet begrijpt of niet in voldoende mate ondersteunt dan moeten zij een andere architect nemen.

    Ik ben het roerend met je eens dat architectuur alleen niet voldoende is. Ik stel altijd in mijn lezingen dat het formuleren van een volwassen architectuur geen sinecure is, maar dat het opstellen van een realistisch transformatiepad naar de nieuwe situatie de echte uitdaging is. Als je geen haalbaar transformatiepad kunt schetsten, dan is de architectuurstudie verloren tijd, zonde van de centen.

    Ik verwacht niet dat een businessmanager op deze blog reageert, want dit zijn blogs voor de IT-community. Maar wellicht dat jij als Manager IT Delivery bij Telfort een zware businessmanager bij Telfort kan verleiden op deze blog te reageren
    Ik zal t.z.t. mijn boodschap ook in een businessblad of het CIO-Magazine proberen te zetten.

    Groet,
    Daan.

  9. beste Daan,
    Het gaat er om welke competenties helpen om grote complexe informatiseringsprojecten te laten slagen. Ik denk onder andere Overzicht, Inzicht, Abstractievermogen, Leiderschap, Toezicht. Bij het samenstellen van een team met een doel zorg je er voor dat deze kwaliteiten aanwezig zijn. Als het de “business” is die ze levert, prima. Als het de ontwerper is, ook goed. Doorgaans hebben zulke lieden echter andere prioriteiten en kwaliteiten. Architecten worden nu juist op deze competenties geselecteerd (hoop ik). En er in getraind.

    Maar goed, hoe het heet doet er natuurlijk niet toe. Noem het voor mijn part epibreren. Het zou kunnen dat architectuur hier en daar een slechte naam heeft. Eindeloze boekwerken, hele ingewikkelde en overvolle slides, weer een nieuw framework. Ik kan me er van alles bij voorstellen. Wellicht moet je daar dan (goede) architectuur bedrijven zonder het zo te noemen.

    En dan het nee zeggen. Daar wordt je niet populair van, nee, maar het moet toch af en toe. Immers, de visie kan niet gerealiseerd worden als het een ieder vrij staat om er van af te wijken. Toezicht is nodig, en daar behoren architecten niet voor terug te deinzen. Maar dan wel met mate, en met voor een ieder te begrijpen, duidelijke argumenten.

    Tenslotte die vermaledijde term “business”. Vroeger was ik business, tegenwoordig ondersteuning. Zijn mijn ideeën daardoor slechter geworden? Zijn mijn verstandelijke vermogens en mijn betrokkenheid daardoor afgenomen? Neen natuurlijk. Allen hebben de morele plicht en ook het vermogen om de organisatie verder te helpen. Samenwerken met respect voor een ieders specifieke kwaliteiten is het parool. Noem het voor mijn part een architectuurprincipe.

    Mijn stelling: al die nadruk op de belangrijke rol van de business werkt negatief voor het vak van architect. Het is zinloze etikettenplakkerij waar niemand beter van wordt.

  10. Daan,
    Je verhaal is, zoals gebruikelijk, uitdagend, en ik ben het met je verontwaardiging eens. Het inspireert mij tot de volgende beschouwing.
    We moeten misschien een onderscheid gaan maken tussen de architect en de “architectoloog”. Net als bij de crimineel en de criminoloog: de √©√©n is de dader, de ander beschouwt wat de dader doet. Zelf heb ik ooit een dergelijk onderscheid ervaren toen ik als musicoloog werkte: iedereen vroeg mij dan altijd welk instrument ik speelde, en dan moest ik uitleggen dat een muzikant muziek maakt, terwijl een musicoloog daar meestal alleen maar naar luistert en er over schrijft.
    Dat onderscheid helpt een beetje om het probleem dat je aanroert te ontwarren. Als we elkaar op het LAC ontmoeten en over TOGAF praten, acteren we als architectologen. Daar is op zichzelf niets mis mee, maar dan moet je wel weten wie je doelgroep is: de architect, en niet de business manager. Omdat het vak nog erg jong is, zoals je zegt, is dat ook heel erg nodig. Jouw blog schrijf je ook vanuit die rol, en ik vind de rol van architectoloog zelf bij tijd en wijle ook aantrekkelijk.
    Dat laat onverlet dat de meesten van ons daarnaast ook als architect acteren. Pas dan komt de doelgroep van de business in het vizier. Maar dan is het nog maar de vraag of het vak “architectuur” in de communicatie met die business managers zo belangrijk is. Net als bij de crimineel en de muzikant gaat het niet om het etiket, niet om het vak als zodanig, maar om het resultaat van de “daad”. In ons vak gaat het erom dat we de business helpen de juiste keuzes te maken. Het etiket architectuur is daar niet zo heel belangrijk bij.
    Ook hier helpt het om een onderscheid te maken, in dit geval tussen de business manager die als opdrachtgever fungeert (voor wie de keuzes belangrijk zijn), en de manager die dit proces van keuzes maken moet inrichten (meestal een stafmanager). Het is de stafmanager die je moet overtuigen van nut en noodzaak van een zekere professionaliteit die we architectuur noemen, bedoeld om de business manager van dienst te kunnen zijn. Een goede business manager weet dat natuurlijk ook, maar die moet je niet met de details van het vak vermoeien.
    En daarmee kom ik terug op je beginvraag: architectuur hoeft wat mij betreft niet door te breken bij de business managers, maar w√©l bij de stafmanagers. Dat we daarbij in een beginfase zitten, helemaal mee eens. Daarom hebben we als “architectologen” nog zoveel werk te doen.

  11. Beste Daan, een ietwat reflecterende reactie hieronder.
    Architectuur ansich bestaat al duizenden jaren. Het beroep architect is daarmee al duizende jaren aan (r)evolutie blootgesteld. En nog steeds zijn er architecten te vinden waarmee zowel opdrachtgever/klant moeilijk blijkt te kunnen communiceren.

    Zoals jezelf al aangeeft wordt architectuur in de IT sinds ca 40 jaar toepast. Een klein verschil met de hierboven periode en de overeenkomst zit m.i. in (een goede) communicatie. Het vinden van een gezamelijke taal en bijhorende beeldvorming die voor zowel goed resultaat als begrip kan zorgen.

    Juist het gemis van de gezamelijke basis vormt de reden voor veel ‘missers’ op allerlei vlakken. Juist daarom ontstaat er frustratie en ongebrip voor elkaar (En ja ik snap best dat dit een open deur is)
    Blijven communiceren en het vinden van een ‘common ground’ zal uiteindelijk voor begrip, acceptatie op allerlei vlakken en (r)evolutie zorgen
    Blijf prikkelen en blijf kritisch.
    Groet Wim

  12. Beste Daan,

    Op initiatief van mijn toenmalige ABN AMRO-baas Denis Hageman en onder de vluegels van pionier Niels Klinkenberg heb ik mij van 2000 tot 2004 mogen ontwikkelen tot Business Architect. Mijn analyse is als volgt.

    De business is per definitie geïnteresseerd in het behalen van bedrijfsdoelen, die uiteindelijk altijd vertaald kunnen worden naar financiële doelen. In grote ondernemingen wordt op het niveau waar over wezenlijke zaken wordt besloten veelal in termen van geld gesproken. Ik heb aan den lijve ondervonden dat je als business architect alleen een werkelijk serieus te nemen gesprekspartner kunt zijn wanneer je de taal van de business spreekt en die is financieel. Dit is mijns inziens de kern. Val me nou niet aan op wat daar op af te dingen valt, je kunt ieder waardevol denkbeeld doodnuanceren. Er zijn vast vele sleutels, maar dit is de loper die op alle sloten past.

    Winst is omzet minus kosten

    Investeringen worden via afschrijving of amortisatie uiteindelijk kosten. Door IT-kosten te laten stijgen kun je FTE-kosten afbouwen. Aan de omzetkant geldt dat de internetrevolutie nog immer niet is uitgeraasd en vele verdienmodellen op de proef stelt. Technology-push moet worden toegelaten om als bedrijf in te kunnen prikken op nieuwe vormen van dienstverlening die het verdienmodel van het bedrijf zelf agile maakt, zodat de kosten met de omzet kunnen fluctueren. Ruil dus je vaste lasten in voor variabele lasten die met je omzet mee schalen (ook downscaling). Dit zijn wat voorbeelden van financiële motieven die de Business Architect in zijn praktijk tegenkomt. Maar ik kan het fundamenteler formuleren.

    Dienstverlening vereist complexiteit accommoderen

    De business case voor dienstverlening is dat je dure complexiteit weghaalt bij je klant en industrieel wegtransformeert in jouw back-office. Logisch dus dat de Business haar omzet kan laten groeien door meer complexiteit in te sourcen. De Business is dan ook de ware bron van complexiteit, niet de IT. Je kunt kosten besparen door complexiteit te verminderen als Architect, maar je kunt het toegenomen complexiteitsaccommoderend vermogen van je bedrijf ook inzetten ten behoeve van meer of innovatieve dienstverlening. De reden dat dat laatste meestal gebeurt is dus een logisch gevolg van de fundamentele business case van dienstverlening. Dat is dus logisch zeggen we met Johan.

    Je bent geen effectieve Business Architect zonder financiële- en marketingkennis.

    Net als de Chirurg is de Business Architect niet snel klaar met zijn opleiding. Als je geen balans en verlies-en-winstrekening kunt lezen dring je niet gemakkelijk door tot de kernproblemen of kansen van het bedrijf. Als je geen kaas hebt gegeten van Management Accounting ben je geen volwaardig gesprekspartner voor de Directie. Zonder gedegen begrip van Marketing begrijp je onvoldoende van de omzetkant van het bedrijf. Natuurlijk weten we allemaal dat de Business Architect doende is de strategische en tactische doelen in samenhang te structureren en de IT-functie daarop aan te sluiten en te challengen. Maar als je mij vraagt wat er nodig is om de juiste boardroom access te krijgen als Business Architect, dan geef ik je het bovenstaande antwoord.

  13. Volgens mij ligt de sleutel bij onszelf. Dit noem ik ‘intunen op de business’. Dan gaat de rest vanzelf.

    Veel collega architecten trappen in de valkuil van het ‘overprofessionaliseren’ van ons vak en zijn daardoor de essentie verloren geraakt. Verbinden blijft de kern.

  14. Martin,

    Goed te horen dat jij in jouw architectuurpraktijk steeds meer situaties tegenkomt dat architectuur echt een dienend instrument wordt voor het businessmanagement.

    Ik ben dan geïnteresseerd van wie het initiatief uitging tot het overbruggen van de B-IT gedachtenkloof. En hoe dit proces is verlopen.

    In een van de voorbeelden die jij noemt, heb ik begrepen dat het ongeveer 5 jaar heeft gekost om de architectuur echt door de hele organisatie daadwerkelijk geaccepteerd te krijgen. En, met veel vallen en opstaan.
    Er zou veel geleerd kunnen worden van deze succesverhalen.
    Ik kijk uit naar jullie DYA dag.

    Groet,
    Daan.

  15. André,

    Dank voor jouw reactie. Wij zijn het grotendeels met elkaar eens.

    Jouw opmerking over principes wordt veroorzaakt door het feit dat wij een verschillende terminologie gebruiken. Wat jij hoofdprincipes noemt, noem ik (architectuur)relevante strategische uitgangspunten. Daaruit leid ik de (meeste) architectuurprincipes af.
    Die strategische uitgangspunten zijn natuurlijk herkenbaar voor het businessmanagement, hoop ik.

    Groet,
    Daan.

    PS Kijk eens naar mijn column in AG over architectuurprincipes. Deze staat ook in mijn literatuurlijst: http://www.rijsenbrij.net/academy/pagina5.html.

  16. Bert,

    Dank voor jouw opmerkingen.

    Die eindeloze boekwerken dienen om elkaar (architecten onderling) te imponeren (grapje), maar slaan echt niet aan bij de klant (lees: businessmanager).
    Als je een mooi huis wilt laten bouwen en je nodigt een architect uit om wat ontwerpschetsen te maken, dan vraag je nooit welke methodiek gebruik je en ben je wel gecertificeerd.
    Dus laten we dat in de digitale wereld ook niet meer doen. Probeer je klant niet te overladen met je slimme raamwerken (bv NORA) en je professionele methodiek (bv TOGAF), maar geef aan hoe je de klant meeneemt in het verbeeldingsproces met een aantal uitdagende architectuurvisualisaties.

    Ik denk dat er een ‘click’ moet zijn tussen de business/opdrachtgever en de architect, ze moeten op dezelfde golflengte zitten. Als die ‘click’ er niet is, moet de klant een andere architect nemen en de architect moet zeer zeker de ontwerpopdracht weigeren. Dat laatste schijnt moeilijk te zijn voor IT’ers in het algemeen en architecten in het bijzonder.

    Groet,
    Daan.

  17. Alcedo,

    Dank voor jouw bijzonder interessante reactie. Bedoel je met ‘architectoloog’ een docent architectuur (grapje)?

    Meen ik te bespeuren dat jij, net als ik, vermoed dat TOGAF door ‘architectologen’ in elkaar is gezet, zie: http://www.via-nova-architectura.org/opinions/discussions/togaf-het-universele-wondermiddel.html?

    In tegenstelling tot jou, vind ik dat een ‘architectoloog’ ook een open oog voor de business dient te hebben. Voor mij is architectuur geen l’art pour l’art. De zogenaamd intrinsieke schoonheid van architectuurformuleringen vind ik ondergeschikt aan het daadwerkelijke doel van de architectuur (orde & samenhang, slimme constructies en een inspirerende beleving).

    Wij moeten in de wandelgangen op het volgende LAC maar eens verder praten.

    Groet,
    Daan.

  18. Wim,

    Dank voor jouw aanmoediging ‘Blijf prikkelen en blijf kritisch’.

    Op het tiende LAC (2008) heb ik een key note mogen verzorgen met als titel ‘nieuwe generatie digitale architecten’. Ik heb daar ook een column over geschreven in AG, zie mijn publicatielijst: http://www.rijsenbrij.net/academy/pagina51.html.

    Dit jaar bestaat het NAF tien jaar. Als geestelijk vader van dat NAF hoop ik dit jaar een ‘state-of-the-art’ bepaling te kunnen uitvoeren aangaande architectuur. Daarbij wil ik extra aandacht schenken aan businessarchitectuur en informatiearchitectuur, de twee redelijk onderbelichte deelgebieden van ons vakgebied.

    Groet,
    Daan.

  19. Ben,

    Goed dat jij Niels nog eens in het zonnetje zet. Ik hoop dat hij de huidige stand van de businessarchitectuur nog eens wil bekijken. In mijn adresboek staan ruim 300 businessarchitecten met een zeer grote verscheidenheid aan architectuurpercepties.

    Jeff Scott, een van de topanalisten van het analistenbureau Forrester, heeft een paar jaar geleden gesteld dat het tijd wordt businessarchitectuur eens te herformuleren. Sinds die tijd heeft Forrester een zeer groot aantal papers het daglicht laten zien over dit boeiende deelvakgebied. Toch, heb ik als nuchtere, zakelijke Hollander het gevoel dat we nog een paar spaden dieper zouden moeten gaan. Wellicht dat een aantal businessarchitecten in Nederland en Vlaanderen mij daarbij kunnen helpen.

    Jij stelt dat ‘net als de chirurg de businessarchitect niet snel klaar is met zijn opleiding’, maar dat geldt m.i. voor elk soort van (digitale) architect. Een architect moet blijven leren en experimenteren anders wordt de uitoefening van zijn vak een saaie routineklas met dito resultaten.

    Groet,
    Daan.

  20. Paul,

    Dank voor deze korte, doch zeer waardevolle reactie.

    Ik neem aan de jij met ‘intunen op de business’ bedoelt luisteren naar de werkelijk vraag van de business; de vraag achter de vraag.
    Kan iemand dat leren of is dit vermogen een grondhouding die je van nature hoort te hebben als architect? Hoe hebben jullie dat bij Achmea geregeld?

    Jouw opmerking over ‘overprofessionaliseren van ons vak’ is cruciaal. Ik zeg altijd dat je moet zorgen dat je zeer professioneel bent in je vakgebied, maar dat je de klant i.c. de business niet moet vervelen met jouw professionaliteit.
    Als je die professionaliteit met alle geweld moet uiten, dan hebben we daar architectuurcongressen voor (grapje).

    Groet,
    Daan.

  21. Architectuur is in 90-er jaren opgekomen als een antwoord op de wens en noodzaak om grip te krijgen op heterogene technische omgevingen. Zoals Daan aangeeft spelen vergelijkbare vragen ook voor de huidige IT. Het fenomeen architectuur heeft zich ontwikkeld tot een mechanisme om greep te krijgen op systemen en hun relatie tussen de business en (voor een deel) op de business zelf. De scope voor architectuur is dus rap gegroeid. Daarmee de uitdagingen en de hoeveelheid stakeholders en dus de verwachtingen ook. De broek die werd aangetrokken door het fenomeen architectuur werd tamelijk groot. Opvallend is dat de oorsprong van architectuur in veel organisaties bekend bleef: de IT.

    Min of meer in parallel zijn ook andere antwoorden op de zelfde uitdaging ontstaan. Er zijn grote parameteriseerbare systemen zoals ERP en BPMS ontwikkeld. Dat het invoeren van dergelijke enorme systemen alleen mogelijk is als de deskundigen uit de business nauw betrokken zijn bij dit proces was direct duidelijk. Voor hen werden, anders dan bij architectuur, ook direct de voordelen geschilderd: jullie kunnen de IT aanpassen naar jullie wensen. Hiermee zijn dergelijke systemen direct gepositioneerd als een business issue.

    Ik ben het met Daan eens: architectuur is er (nog) niet in geslaagd om haar potentie waar te maken. In mijn beleven heeft dat, naast de enorme ambitie, te maken met het feit dat architecten moeten gaan begrijpen hoe de business, de informatiehuishouding en de IT in elkaar steekt. Omdat hiervan in vrijwel geen enkel bedrijf een zinvolle vastlegging bestond moest de architect dit ontwikkelen. Dit proces wordt ondersteund door en vastgelegd in modellen, volgens imponerende raamwerken. Het is voor een goed antwoord op de oorspronkelijke vraagstelling belangrijk dat deze modellen kloppen. Architecten hebben daarmee de behoefte om de modellen correct te laten zijn. Dat klinkt triviaal, maar is toch wezenlijk anders dan wat in het implementatieproces de ERP- en BPMS-achtigen gebeurt. Deze systemen beloven juist enorme flexibiliteit en een correct model als startpunt wordt niet echt belangrijk of noodzakelijk gevonden. Dit geeft een andere dynamiek in de samenwerking tussen de business mensen en architecten enerzijds en business mensen en ERP/BPMS invoerders anderzijds. Architecten willen en moeten het juiste model maken. Zij komen daardoor vaak in een positie dat ze, op basis van een onbetwistbaar degelijke methodische redenering, bij business mensen een keuze moeten forceren: goed kan maar op één manier. Dat is knap bedreigend. Wat als de verkeerde beslissing wordt genomen?
    Het resultaat van dit proces is vaak een verzameling complexe modellen van de huidige en de gewenste situatie: uitermate waardevol! Door de veelheid en complexiteit ook makkelijk intimiderend. Kortom zowel het proces van het opstellen van een architectuur als de resulterende architectuur kunnen voor alle betrokkenen gemakkelijk als bedreigend worden ervaren.

    In veel gevallen zijn systemen als ERP en BPMS er ook nog niet in geslaagd hun potentie waar te maken. De uiterst moeizame en langdurige implementatietrajecten zijn algemeen bekend. Evaluaties van geslaagde cq afgeronde trajecten geven ook een zeer uiteenlopend beeld van het succes van de invoering van een dergelijk systeem. Toch hebben deze trajecten, naast de standaardmodellen die worden ingebracht op basis van verzamelde branche kennis, een aantrekkelijke startpositie: communicatie met de business, vanaf het allereerste moment.

    Daar is in mijn beleven het succes voor architectuur te vinden: in een dialoog. De amorfe entiteit die we business noemen moet een duidelijke vraag kunnen formuleren: waarin wil men inzicht hebben én met welk doel én tegen welke inspanning? Als die helder zijn, mag een niet-passend architectuurantwoord inderdaad rücksichtslos worden afgewezen.
    Architecten moeten hun positie beter duidelijk maken, zodat de businessmanagers kunnen beseffen waarom en hoe architectuur voor hen nuttig kan zijn: een architectuur is geen doel op zich en niet het antwoord op al uw problemen; het helpt om te begrijpen hoe een organisatie en haar informatie- en IT-resources in elkaar zit en zou kunnen zitten. Een dergelijk beeld is (wellicht zelfs per definitie) ingewikkeld en intimiderend. En het is maar zeer de vraag of de business echt zit te wachten op een confrontatie met dat beeld; managers willen antwoorden op prangende vragen.
    De architect moet primair een communicator zijn die luistert naar de problematiek van de business, op de achtergrond zijn werk kan doen en zijn waardevolle modellen kan vertalen naar wat die betekenen voor een business beslisser, passend bij de verwachtingen van de business, zowel wat resultaat als proces betreft. In mijn beeld hoeft een architectuur zelf dus niet inzichtelijk te zijn voor niet-architecten. Een architectuur is daarmee ook niet per sé eigendom van anderen dan de architect (bedenk ook: wie gaat de architectuur onderhouden?). Het is de wezenlijk duale rol van een architect: het produceren van zijn gereedschap én het passend communiceren van antwoorden.

  22. Hajo,

    Goed om te verwijzen naar de blog van Erik.

    Het onderwerp ‘Outsourcing onder Architectuur’ wordt bestudeerd door een PON-werkgroep waarvan ondergetekende de voorzitter is.

    Een groot aantal organisaties als de uitbesteders ABNAMRO, Obvion, UWV, RDW, RWS en de providers HP, IBM, Ordina, Sogeti zijn bezig samen met de adviesbureaus Blinklane, KPMG, Quint en VKA de verschillende architectuuraspecten bij outsourcing, het opzetten van een SSC en het gebruiken van de Cloud in kaart te brengen.
    Wij laten ook nog een advocaat naar de juridische hardheid kijken van de cruciale architectuurproducten bij externe sourcing.

    Mogelijke vragen van architecten kunnen aan mij (daan@rijsenbrij.eu) worden gestuurd.

    Groet,
    Daan.

    Stelling: ‘Outsourcen zonder Architectuur, lijkt op autorijden zonder gordel. Het gaat wat makkelijker, maar als er een flinke klap komt, is de schade nauwelijks meer te overzien’

  23. Olaf,

    Dank voor jouw heldere uiteenzetting.

    Ik ben blij dat jij in andere woorden nog eens onderstreept dat het lijkt alsof de architectuur nog te veel blijft hangen in de IT.
    Gezien de push uit de IT is dat ook nogal verleidelijk, maar de uiteindelijke klant zit in de business. In die business wordt ook het geld verdiend.

    Nogmaals, dank voor jouw waardevolle aanvullingen,
    Daan.

  24. Dag Daan en anderen,

    Mooie blog en reacties. De oproep om succesverhalen te brengen brengt een dualiteit naar voren in mijn bestaan als Enterprise (e-)Business Architect.

    Ten eerste zijn er zeker succesverhalen. Succes is in die gevallen altijd normatief meetbaar gebleken teven vooraf helder verschafte financiële of daaruit afgeleide doelstellingen. De successen hebben mij eigenlijk altijd uitgedaagd om mijn vakgebied breed en organisch te benaderen.Waarom? Omdat de verschillende gradaties van volwassenheid van de organisatie, de dynamiek van de organisatie en de cultuur van de organisatie te allen tijde compenserend gedrag van mij vraagt. Business architectuur kan heel exact zijn als de omgeving dat toelaat maar heel vaak is het ook vertrouwen verdienen alvorens de architect zijn werk exacter kan maken (energie en draagvlak eisen van dat deel dat financieel en marketing stuurt).

    De successen hebben 1 stereotype kenmerk. Ze zijn allen opgehangen aan een business verander kalender die voortkomt uit waardemanagement. Vaak heeft dit vorm in een business informatie planning. Waar het vaak mis gaat is het invullen van de randvoorwaarde op belangrijke mijlpalen in het architectuurproces. De randvoorwaarde is wat mij betreft vrij eenvoudig. Zorg voor een concrete en meetbare target. Financiele resultaten of marketing resultaten (conversie) zijn hierbij van wezenlijk belang voor het creëren en behouden van draagvlak in een organisatie. Doe er trouwens niet te moeilijk en academisch over. Niemand is geboren om moeilijk te doen en abstract te communiceren. Maak er kunst van. Ken je eigen tekortkomingen in communicatie en zorg ook voor invulling van deze randvoorwaarde. Ten slotte kun je een abstracte waarheid modelleren maar die moet je in een fusie met de business mindset en jargon vermengen in een pakkende to-the-point presentatie. De vorm is hierbij net zo belangrijk als de inhoud is mij steeds weer opgevallen. Prachtig dat dit onderwerp zo wordt besproken. Dank je Daan!

    Gr,

    Marc Collet

  25. Marc,

    Dank voor jouw reactie. Ik zou nog wat willen aanvullen op de term ‘succes’.

    Naast een lijstje eisen over architectuur die ik met de klant opstel, maak ik meestal ook een lijstje CSF’s (critical success factors). Dan weten wij (de klant en ik) hoe in redelijke mate het succes van architecting (het architectuurproces) kan worden geborgd.

    Enkele algemene CSF’s:
    1. Daadwerkelijk commitment van de eigenaren.
    2. Daadwerkelijke betrokkenheid van het businessmanagement. Zorg dat businessmanagers leren denken m.b.v. architectuur, in het bijzonder architectuurvisualisaties.
    3. Hoge zichtbaarheid. Wees trots op je architectuur, laat aan iedereen zien wat je laat maken.
    4. Acceptatie en herkenbaarheid door IT’ers. Geen IT-project zonder praktische PSA. Kijk uit, maak van de PSA geen papieren tijger!
    5. Quick wins. De eersten liggen vaak op het gebied van een rationalisatie onder architectuur van het systemenlandschap.
    6. De architectuur dient een strategisch instrument te worden voor de business en de CIO.

    Ik ben het met je eens dat deze discussie zou moeten worden voortgezet in een fysieke bijeenkomst, bij voorbeeld op het LAC2012.

    Groet,
    Daan.

  26. Daan, en anderen,
    Dit weekend werd ik door Daan geattendeerd op deze blog. Omdat ik sinds enige jaren in het buitenland (als je Luxemburg buitenland wilt noemen) werk, volg ik niet meer alles wat in Nederland op architectuurgebied speelt. Edoch, vanuit mijn onderzoek blijf ik actief in het vakgebied.

    De discussie die Daan gestart is is denk ik erg belangrijk. Tegelijkertijd denk ik dat deze in eerste instantie toch begint vanuit “het middel” (architectuur) en minder vanuit de behoefte. In de discussie kom ik de behoefte kant deels tegen, maar ik denk dat dit scherper kan.

    Waarom hebben we architectuur nodig? Vergeet even “architectuur”. Organisaties hebben te maken met een toenemende complexiteit in termen van onderlinge relaties tussen diverse elementen. Tegelijkertijd worden organisaties geconfronteerd met de noodzaak om steeds sneller te kunnen veranderen. Een duivelse mix. Om het nog erger te maken, hebben ze ook nog eens te maken met allerlei eisen op het gebied van compliance, transparantie, etc.

    Deze “duivelse mix” heeft tot het gevolg dat het (senior) management van organisaties (hopelijk) wakker ligt van enkele zaken.
    1) Onvoldoende inzicht in de bestaande situatie. Dus geen inzicht in de huidige situatie, en de samenhang. Geen inzicht in impact analysis of “exposure to risk”.
    2) Veranderbeslissingen moeten nemen op basis van onvoldoende inzicht. Geen inzicht in impact van keuzes voor de toekomst.
    3) Onvoldoende kunnen beheersen van verandertrajecten en het bewaken/sturen op basis van impact op die zaken die van strategisch belang zijn.

    Ik gebruik hierbij 3x het woord onvoldoende. Daarmee verwijs ik naar het feit dat er “iets” zou moeten komen wat zorgt dat dat inzicht “voldoende” wordt. Maar het moet nu ook weer niet “overcompleet” worden. Just enough …

    Ik spreek ook niet over “da Bizznizz” en “da IT”. Ik zie een organisatie als een complex systeem (systeem in de originele zin des woord). Daar maken bedrijfsprocessen, diensten, producten, informatievoorziening, applicaties, IT infra, etc, onderdeel van uit. Overigens ben ik altijd wat verward als mensen spreken over “da Biznizz”. Bedoelt met dan het senior management of de bedrijfsprocessen?

    En architectuur? Ik denk dat het senior management een inhoudelijk stuurmiddel nodig heeft. Dus niet alleen project/programma management, maar juist ook inhoudelijke sturen. En hier komt een “oude plaat” van Daan naar boven. Een driehoek van krachten: strategie/programmamanagement/architectuur. Het middel architectuur moet zich richten op het ondersteunen van senior management om met de duivelse mix om te gaan. Daarbij zijn “de architecten” er wel voor verantwoordelijk om de benodigde inzichten te onderbouwen (de “ingewikkelde” architectuurplaten, die nodig zijn om de doelmatige rapportages te maken die de bestuurders in staat stellen afwegingen te maken), en om vanuit hun vakkennis en organisatiekennis suggesties te doen voor haalbare/effectieve toekomstscenario’s. Een mix van engineering en creativiteit.

    Groet,
    Erik Proper

  27. Ha Paul,

    Je haalt de woorden uit mijn mond en hebt het idee ook nog lekker compact geformuleerd. Met de toevoeging van Daan kan ik me er helemaal in vinden.

    Ik heb de afgelopen jaren gezien waar je als architect het verschil kan maken. Natuurlijk, dat zie je in succesvolle projecten (ja, ze bestaan wél) maar eerlijk gezegd is dat maar één en niet eens de belangrijkste uitingsvorm van een goede architectuur. Met slimme architecturen gaat alles beter. Geen reclame maar realiteit.

    De business moet ons daartoe dwingen. Laat die resultaten maar zien. En weet dan dat je pas waardering krijgt als je meerwaarde aangetoond is. Eerst scoren dan gehoord worden. Toen ik acht maanden geleden naar mijn nieuwe baan solliciteerde werd door een hoge lijnmanager de vraag gesteld “Waar heb ik eigenlijk zo’n dure architect voor nodig, het kan toch ook wel zonder?”. Mijn antwoord was een wedervraag: “Kunt u zich veroorloven om geen goede architect in dienst te hebben? Er zullen dagen -nee, zelfs maanden- zijn dat ik voor u niet zichtbaar ben. Dan wordt er wel zinvol gewerkt. Maar het zal u opvallen dat er af en toe een architectuurbesluit komt waarmee in √©√©n keer bijvoorbeeld vier ton wordt bespaard. Ik zou het risico persoonlijk niet nemen.”. Ik werd aangenomen.

    Met alle respect voor prachtige frameworks, tools en methodieken moeten wij er zelf voor zorgen dat we begrijpelijk communiceren. Verplaats je in het bedrijf waar je voor werkt, op een goed managementniveau, en schrijf dan begrijpelijk. Als jet niet uit kunt leggen dan klopt het ook niet. Architecten die voor architecten schrijven, dat schiet niet op. Niet richting business en nog minder richting IT. Leg dus eenvoudig uit waar het op staat, dat is de kunst.

    Het vakgebied is reuze onvolwassen. Dat zie je aan de variatie in hoe architecten hun werk doen, de producten die ze leveren, de impact die ze maken en de kwaliteit en hoogte van de opbrengsten. Daar zit ook een spagaat. Naar boven en naar beneden moet je begrijpelijk communiceren, op de architectuurlaag wil je zeer professionele en een hoge toetsbare kwaliteit leveren. Dat levert het risico van overprofessionaliseren waarbij de meest prachtige architecturen tot niets meer leiden. Wij moeten dat oplossen. Dat betekent slim werken en we moeten samen concluderen dat niet elke architect dat zal kunnen. Het vereist vaardigheden die niet iedereen gegeven zijn. Einstein zei: “Maak alles zo simpel mogelijk maar niet simpeler.”. Laat dat de uitdaging zijn!

    Hans van Buuren

  28. Erik,

    Dank voor jouw commentaar uit het verre buitenland. Ik ben het met jou eens dat de behoefte aan architectuur centraal zou moeten staan bij de verkoop van architectuur aan het business managemeent.

    Businessmanagers moeten gaan zien dat zij de impact van veranderingen nauwelijks kunnen overzien zonder architectuur. Businessmanagers/opdrachtgever moeten gaan beseffen dat zij niet adequaat kunnen sturen zonder architectuur als instrument. Pas als zij dit echt beseffen, dat willen zijn geen transformaties meer zonder architectuur.
    Wellicht nog effectiever zou zijn als in die verkoop van architectuur ook een stukje angst kan worden ingebouwd. De angst voor oncontroleerbare chaos als je geen architectuur hebt; de angst om een gevangene te worden van de dwangbuis van de IT als je geen toekomstvaste architectuur hebt.

    Groet,
    Daan.

  29. Hans,

    Het is goed dat jij als architect zelf stelt ‘ de business moet ons dwingen; laat resultaten zien’. Dat ‘zien’ wil ik graag heel letterlijk nemen, dus van ‘tell me’ naar ‘show me’. Geen dikke rapporten, maar overzichtelijke architectuurplaten. Architectuurplaten, waarin je expliciet kunt zien welke architectuurprincipes en architectuurconcepten gebruikt zijn.

    Ook interessant vind ik dat jij de uitdrukking ‘dure’ architect noemt. Aan de waarde van een architect wil ik ook graag eens een blog besteden. Ik denk dat bedrijven de waarde oftewel het externe tarief dan wel de salarisschaal waarin een architect hoort, zwaar onderschatten.
    Architecten maken veel uren die met een gematig tarief zouden kunnen worden beloond, maar zo af en toe stellen zij architectuurbeslissingen voor de vele tonnen zullen besparen. Voor die cruciale architectuurbeslissingen is dat gewone werk ook nodig.

    Groet,
    Daan.

  30. Beste Daan,

    Dank je voor je mail en het attenderen op deze blog. Een mooie uitdaging om een en ander weer eens aan te scherpen.

    In je blog “wanneer breekt architectuur eindelijk door in IT” vraag jij je het volgende af. “Hoe komen we nu uit dit verlammende wederzijdse onbegrip ? In mijn perceptie ligt de sleutel bij de business. Zij moeten r√ºcksichtslos architectuurbeschrijvingen / architectuurvisualisaties weigeren die zij niet zonder uitgebreide mondelinge toelichting van architecten kunnen begrijpen”. Ik zie dit wel anders. Ik denk dat architectuur teamwerk is en primair communicatie binnen steeds wisselende teams, en niet over visualisaties of beschrijvingen gaat.

    Je komt wel bij een kernvraag: waarom begrijpen IT en business elkaar niet? Vanwaar het wederzijdse onbegrip? Het antwoord is denk ik simpeler dan de oplossing. Dat zijn slechts hulpmiddelen om tot inzichten te komen, maar niet het einddoel op zich.

    De IT is een gefragmenteerde wereld. En in deze wereld spreken en bezigen we veel denk modellen en talen. De architect heeft een gereedschapskist om dit communiceren eenvoudiger te maken. Helaas is deze vergelijkbaar met een spreektaal als bijvoorbeeld engels of frans. Een taal leren kost tijd, maar is wel noodzakelijk om te communiceren. Een taal leren is vooral ook woordjes leren, en leren gebruiken. Dat geldt dus ook voor architecten, managers, ingenieurs, project uitvoerders. Een gemeenschappelijk taalgebruik is onmisbaar. Vandaar mijn pleit om vooral daar ook aandacht aan te geven en in te investeren. Gemeenschappelijk taalgebruik met gewone woorden, … glashelder.:-)

    Nu wil het geval dat iemand verantwoordelijk voor de business operatie, niet zo erg geïnteresseerd is in IT, maar wel in hulpmiddelen om succesvol te zijn. Dit vraagt het spreken met begrip van zaken. Begrip hoe zijn business in elkaar zit, en wat gereedschappen (bijv IT) daarvoor kunnen betekenen.

    De business architect heeft de gereedschappen om dit inzicht systematisch te ontwikkelen. Maar ja, dan ben je er nog niet. Het is in ieder geval niet effectief als je de artifacts die je daarvoor ontwikkeld hebt probeert uit te leggen. Of je nijptang laat zien. Je kunt wel een gesprek hebben over de impact van technologie voor zijn huidige business, maar de gereedschapskist blijft dicht. Daarvoor is wel nodig dat je het huiswerk gedaan hebt, i.c. de business begrijpen en relateren aan de mogelijkheden die de technologie biedt. En, hoe kan ik nu zorgen dat ik daar de tijd voor krijg? Tijd is geen issue. Begrijpen van je klanten (in dit geval de business) moet iedereen en dat hoort gewoon in je agenda als een structurele tijdbesteding. Er is alleen een maar, en dat is dat over het algemeen de meeste IT professionals geen business taal beheersen.

    Zo door redenerend lijkt het fair om te concluderen dat niet de IT naar de business moet gaan met zijn inzichten, maar dat er kennelijk iemand tussen hoort. Iemand die de gevolgen van technologische trends kan simuleren en begrijpen, en iemand die de business logica en dynamiek kan begrijpen. Maar vooral deze aan elkaar weet te koppelen. Daarvoor moet hij ook de dynamiek begrijpen, de dynamiek die ontstaat als je bijvoorbeeld alles mobiel maakt of in cloud services wil omtoveren. Dit verandert besluitvorming in de operatie, en verandert de IT operatie. Nieuwe kansen en nieuwe risico’s ontstaan. De inzichten die dat oplevert zijn van belang om een operatie succesvol te houden.

    Kennelijk ontkomen we niet aan drie schakels. En om dit nu gemakkelijk te maken, worden er standaarden verzonnen. Dat maakt het communiceren eenvoudiger. Dit leidt uiteindelijk tot kleine verhaaltjes, waar eventueel diagrammen aan ten grondslag liggen: ………deze kansen in de markt, en deze technologische ontwikkelingen samen geven de business de mogelijkheid om op een andere manier geld te verdienen. Hiervoor moeten de volgende uitdagingen worden overwonnen, enkele technologische en enkele culturele. En als dit in gepast change management plaatsvindt is er een business case voor te maken. Het oplossen van deze uitdagingen kan volgens de volgende scenarios, en daarvoor zijn de volgende implementatie projecten nodig………. Zo zou de communicatie over de afstemming van business en IT kunnen verlopen. En met het gereedschap dat de business architect heeft, kan hij de transformatie nog in hapklare brokken aanbieden.

    Is dit het werk van de business consultant of de enterprise architect? De BC heeft te weinig van de technologie, en de enterprise architect heeft weer te weinig van de business om deze conversatie met de business te voeren. Vandaar: de business architect.

    Je bent altijd goed in uitdagen, en dat is nu ook weer gelukt. Ik heb me door je blog laten verleiden om eens neer te zetten wat ik daar zelf nu van vindt. Daarvoor dank.

    Tot snel weer eens. Harry Hendrickx

  31. Hi Daan,

    De crux zit volgens mij in het feit dat het onduidelijk is waar een architect op kan worden aangesproken. Mensen die aanzienlijke verantwoordelijkheden dragen willen werken met mensen waar ze verantwoordelijkheden aan kunnen overdragen, en dan bedoel ik echt overdragen, die zorgen dat het geregeld wordt!

    En welke concrete verantwoordelijkheid draagt de architect nu eigenlijk? In het slechtse geval neemt de architect geen verantwoordelijkheid en vertoont hij ‘tribunegedrag’. Hij of zij geeft aan wat er niet goed gaat, anders moet, in strijd is met de richtlijnen etc.

    In het beste geval staat de architect in het veld, en zorgt hij of zij, meestal in teamverband, dat er een klus wordt geklaard. Wat is die klus? Volgens mij zijn er in essentie 2 mogelijkheden:
    1. een schets maken van de toekomstige situatie die kan dienen als kompas voor alle veranderinitiatieven in een organisatie, en die wordt gedragen door de belangrijkste en betrokken stakeholders in de organisatie.

    2. een ontwerp maken van een oplossing op hoofdlijnen, waarbij alle inhoudelijke risico’s zijn teruggebracht tot aanvaardbare nivo’s, zeg maximaal 5% van het budget voor de beoogde verandering. ‘Early risk detection and mitigation’ heet dat ook wel waarbij we risico’s ruim moeten zien: risico’s dat iets technisch niet werkt, niet binnen de tijd en budget gerealiseerd kan worden, niet onderhoudbaar is, niet voldoet aan uitgangspunten of principes etc.. Een architect steekt dus de thermometer in de contouren van de oplossing (die er meestal al wel zijn) en zorgt voor een uitwerking tot een oplossing die zonder al te grote risico’s gerealiseerd kan worden.

    Dus kompaswerk, en thermometer werk. Kompaswerk is typisch enterprise architectuur werk, thermometer werk is typisch solution architectuur of project/program architectuur werk.

    Op die rollen kan je mi een goede architect aanspreken. Andersom als je als RvB, directie of program management iemand hebt die die klus voor je kan klaren dan is dat hardstikke interessant, toch?

    Ik merk in ieder geval dat als ik dit vertel aan mijn clienten, en aangeef dat ze me op 1 van bovenstaande verantwoordelijkheden kunnen aansperken, ik meestal snel aan de slag kan. Nu is het vervolgens meer een kwestie van wat te doen om hier nog beter in te worden?

    Groet,

    Lucas.

  32. Harry,

    Dank voor jouw waardevolle kanttekeningen. Een korte reactie op enkele van jouw punten.

    Interessant punt dat je stelt dat architectuur primair communicatie behelst en niet over visualisaties of beschrijvingen gaat. Jij hebt gelijk dat visualisatie slechts een beschrijvingsvorm is van architectuur, net zo als story telling of role playing.
    M.b.v. architectuur wordt naar alle betrokkenen gecommuniceerd waar je met je IT-, met je digitale ondersteuning naar toe wil.
    Architectuur ondersteunt de communicatie tussen business en IT hoe in inhoudelijke termen de gezamenlijke transformatie zal verlopen, althans gepland is.

    Ik ben het met je eens dat IT een gefragmenteerde wereld is. IT leveranciers hebben in het algemeen geen belang bij de architectuur van de klant. Zij leveren aanlokkelijke mogelijkheden, die businessmanagers verleiden om ze snel toe te passen zonder rekening te houden met de totale samenhang. Dat probleem zien we nu ook weer boven de horizon verschijnen met cloud.

    Goed dat jij nog eens benadrukt dat je een architect moet zetten tussen de opdrachtgever uit de business en de bouwer. Een architect die in begrijpelijke taal kan spreken met zowel de business als de bouwer (en pakketleverancier, leverancier van clouddiensten).

    Jouw vraag businessarchitect of businessconsultant is interessant? Een klant van mij vertrouwde mij enige tijd geleden het volgende toe: ‘Als wij als business in een inhoudelijk dipje zaten bestelden wij een business consultent, als wij de behoefte hadden aan een inhoudelijke oplossing dan lieten wij een business architect komen. De laatste is wel wat duurder en kost wel wat meer doorlooptijd, maar levert uiteindelijk meer op’.

    Groet,
    Daan.

  33. Lucas,

    Dank voor jouw opmerkingen.

    Interessante opmerking over de verantwoordelijkheid van de architect. Als de architect zoals velen met mij vinden een centrale rol speelt tussen de opdrachtgever en de bouwer in het creatieve proces, dan dient hij expliciet zichtbaar te zijn. Als het IT-project een succes wordt straalt de glans mede op hem/haar af, als het mislukt mag ook iedereen weten wie de architect was die erbij stond.
    Ik heb de rijksCIO daarom geadviseerd om in zijn IT-dashboard duidelijk en expliciet te vermelden per project wie de opdrachtgever is, wie de lead architect en wie de bouwers. Dan kunnen wij als belastingbetalers zien wie er van ons geld bezig zijn.

    Aardig het onderscheid dat jij maakt tussen enterprise architect en solution architect, met resp. kompas en thermometer. Ik beschouw de enterprise (en ook de domein)architect als kaderzettend en de solution architect als de vormgever richting de bouwer.

    Groet,
    Daan.

  34. Daan Rijsenbrij: In mijn perceptie is de grote uitdaging voor architecten te zorgen dat architectuur daadwerkelijk wordt erkend door opdrachtgevers van IT-intensieve transformaties, door de business als noodzakelijk instrument om de impact van hun mogelijke beslissingen te kunnen overzien en voor de eindgebruikers van de IT om reële verwachtingen te kunnen koesteren over te bieden IT-functionaliteiten en de bijbehorende belevingswaarde.

    Ik denk dat hij daar heel goed de gewenste eindsituatie schetst. De grote vraag is natuurlijk, waarom is dat vrijwel nergens het geval?

    Daan Rijsenbrij: Hoe komen we nu uit dit verlammende wederzijdse onbegrip? In mijn perceptie ligt de sleutel bij de business. Zij moeten rücksichtslos architectuurbeschrijvingen / architectuurvisualisaties weigeren die zij niet zonder uitgebreide mondelinge toelichting van architecten kunnen begrijpen.

    Ik denk dat het probleem voor een groot deel ergens anders ligt. IT was bijna vanaf het begin al ingewikkeld en complex. En zowel IT (nieuwe technologie√´n) als Business (complexere economie en toegenomen regelgeving b.v.) zijn de afgelopen decennia ordes van grootte complexer geworden. Daarmee is het terrein van de Business-IT alignment in complexiteit ge√´xplodeerd. Die totale complexiteit gaat de meeste mensen te boven, of ze nu uit de business zijn of de IT. Zelfs de meeste architecten zijn slecht in complexiteit. Dat klinkt misschien vreemd, maar het zijn in mijn waarneming vaak degene die de complexiteit niet aan kunnen die de simpeler wereld van de architectuur als vakgebied verkiezen. Architectuur lijkt namelijk veel simpeler. Simpele regels en richtlijnen, simpele schema’s. “Jip en Janneketaal”. Architectuur niet als managen van complexiteit maar als vlucht uit de complexiteit. Om het nog erger te maken draaien de simplisten het zelfs om: zij die niet kunnen omgaan met de complexiteit roepen om het hardst dat die onderliggende complexiteit genegeerd moet worden en niet belangrijk is.

    Het effect van dergelijke architectuur is meestal zelfs schadelijk. Als er één oorzaak is voor megamissers die ik heb gezien is het het oversimplificeren en het werk van uit de complexiteit gevluchte architecten (als ze er al ooit aan geroken hebben). De bron van veel ellende: simplistisch onderbouwde keuzes die uiteindelijk in je gezicht ontploffen. En dat is uiteindelijk ook een hoofdreden dat architectuur niet wordt erkend door opdrachtgevers, niet gezien wordt als noodzakelijk instrument door de business en niet als te vertrouwen kennisbron door de gebruikers. Architectuur doet zelden wat ze beloofd heeft. De simpele keuzes ontberen een gedegen fundament en leveren weinig op. Daarmee is architectuur vaak feitelijk niet echt bruikbaar om dat resultaat te bereiken. En om oom Ludwig maar eens te parafraseren: iets dat geen gebruik kent is betekenisloos.

    Dus, zeker, de architecten moeten hun ‘gebruikers’ materiaal bieden dat begrijpelijk is. Maar dat geldt ook voor een dokter, die moet het uitleggen in een taal die de patient begrijpt. Dat betekent niet dat de dokter niet meer hoeft te kunnen dan de patient. En de dokter moet ook niet proberen op zijn kennisniveau te praten met de patient. Maar helaas hebben we in de architectuur weinig echt goede architecten. In analogie met de gezondheidswereld: wij hebben ziekenhuizen met weinig doktoren en steeds meer gezondheidseconomen, de ‘architectologen’ zoals Alcedo ze noemt. Op mijn enterprise architectuurfuncties solliciteren mensen met een bedrijfskundige opleiding of een MBA. Ik behandel een MBA als een diskwalificatie, als je die hebt moet je hem wat mij betreft elders in je CV wel gecompenseerd hebben met een duidelijke feeling voor complexiteit van de soort die je in de IT tegenkomt. Dat leer je niet op de opleidingen, want het gebrek aan tijd daar vertaalt zich in het omgaan met ‘toy problems’. Wat dat betreft zouden we de IT opleidingen moeten modelleren naar de medische: na de basisopleiding specialisatie en co-schappen om het echt te leren.

    Om met oom Edsger te spreken: ons vakgebied heeft de hoogste kwakzalverdichtheid van alle vakgebieden die er bestaan. Hij zij dat in de jaren 70, meen ik, maar het is nog altijd waar.

    De oproep dat architecten beter moeten communiceren en uitleggen doet mij denken aan de politicus die na slecht verlopen verkiezingen roept dat het beleid prima was maar dat ze het beter hadden moeten uitleggen. Het is vast een aspect, maar niet het belangrijkste aspect. En moet de business zich vooral concentreren op begrijpelijke plaatjes? Nee, dat is maar een deel van het verhaal. Die begrijpelijke plaatjes moeten komen uit diepgaand inzicht van de architecten, anders zijn ze alleen maar gevaarlijke simplificaties. Als er één ding is dat de business moet doen is zorgen dat ze doktoren hebben rondlopen en geen kwakzalvers. En dan moet je de positionering van die goede architecten nog goed inrichten (hoofdzakelijk in de business, niet er naast of er boven). Met die drie samen (communicatie, diepgang en positionering) kom je er wel.

    PS. Ik ben op dit blogartikel gewezen door de business. Hoewel ze dan niet zelf reageren, ze konden het verhaal kennelijk wel vinden.

  35. Gerben,

    Dank voor jouw uitvoerige reactie. Leuk dat jij op deze blog bent geattendeerd door de business, zoals jij in je slotzin vermeldt. Leeft de behoefte naar architectuur vanuit de business al echt bij APG? En waaruit blijkt dat? Welke vormen neemt dat aan?

    Waarom leeft architectuur nog vrijwel nergens bij de business?
    Omdat:
    1. Architectuur nog onvoldoende wordt geformuleerd in een manier waarop de business er wat mee kan.
    2. De business moet leren te denken en te handelen met behulp van architectuur.

    Voorts, zoals René Steenvoorden (CIO RABO bank, voorheen CIO Essent) in zijn architectuurinterview (zie: http://www.via-nova-architectura.org/de-cio-spreekt/de-cio-spreekt/de-cio-spreekt-ren-steenvoorden-cio-essent-5.html) stelde: ‘De IT’er is redelijk eigenwijs. En, de huidge architect is uitgevonden door de IT’er’.
    Trouwens, ik krijg wel eens het gevoel dat veel IT’ers dol zijn op complexiteit. De goede architect moet leren te genieten van eenvoud.

    Ik houd niet van de term ‘business-IT alignment’, volgens mij is die door IT’ers uitgevonden om grip te krijgen op de business. De business is geïnteresseerd in toekomstvastheid. Ontwerp een adaptieve onderneming gefaciliteerd door een adaptief applicatielandschap en een adaptieve infrastructuur. En als je dan ook nog medewerkers heb met een adaptief gedrag, kan je elk toekomstig scenario aan.

    Natuurlijk bestaat er inherente complexiteit. De kunst is om die naar benden te delegeren, naar een specifieke module of zelf doorsourcen naar de computer zelf.

    Voorbordurend op Edsger Wiebe Dijkstra heb ik een paar jaar geleden op verzoek van het maandblad Informatie een artikel geschreven in 2008 met de titel ‘Toen was vakbekwaamheid nog heel gewoon’, zie: http://www.rijsenbrij.net/academy/2008/Toen%20was%20vakbekwaamheid%20nog%20heel%20gewoon.doc.
    Maar ja, misschien zijn wij nog te onvolwassen voor het fenomeen IT; zie mijn publicatie in het maandblad Informatie: http://www.rijsenbrij.net/academy/2010/reflectie%20over%20de%20IT.pdf.

    Nogmaals, dank voor jouw kanttekeningen,
    Daan.

  36. Beste collega architecten,

    In alle reacties kom ik maar een keer woord Agile tegen. Erg goed dat problemen met architectuur hier zo goed benoemd worden, maar in Agile trajecten en organisatie zijn ze veel minder aanwezig. En dat zeg ik als (enterprise) architect. Er zijn inmiddels meerdere voorbeelden waar architectuur op een drastisch andere (Agile) manier bedreven wordt en omgeving wel blij mee is.
    Gezien steeds meer organisaties een stap naar Agile maken waar Business/IT alignement veel beter is, lijkt me onvermijdelijk dat architecten dat ook zullen moeten doen.

    gr., Viktor

  37. Victor,

    Volgens mij is bij agile-trajecten architectuur net zo belangrijk als bij een lineaire/klassieke ontwikkelstrategie. Wellicht zelfs meer nodig!

    Ik heb een tijdje geleden een uitgebreide IT-audit mogen uitvoeren bij een complexe vraagstelling die werd uitgeprogrammeerd met behulp van Scrum. Ondanks dat er integere, goed bedoelende professionals bezig waren, was de architectuur sterk onderbelicht. Dit is vragen om problemen!

    Ik zou wel eens willen zien wat jij bedoelt met een drastisch andere (agile) manier van architectuur bedrijven. Ik geef toe dat architectuurdetails pas tijdens de ontwikkeling worden ingevuld, maar dat vind ik niet drastisch anders.

    Dat professionals blij zijn met Scrum komt niet door Scrum, maar door de wijze waarop teamgewijze wordt gewerkt. Dit kan ik ook regelen bij een lineaire ontwikkelstrategie.

    Groet,
    Daan.

  38. Over het algemeen kan ik me in het artikel en de reacties wel vinden.
    Vanuit mijn eigen achtergrond en praktijk wil ik vanuit een volledig andere invalshoek 3 overwegingen ter overdenking meegeven die wellicht ook tot een antwoord op de vraag van Daan kunnen leiden.
    1. Architectuur sec is inhoud; Architectuur bedrijven in een goede samenwerking met de business is een proces. Heeft de architect van vandaag, naast zijn uiteraard goede inhoudelijke kennis ook de vaardigheden in huis om dit proces te beïnvloeden of sturen? Vanuit een proces benadering heb ik het dan over verander management, de vaardigheden om als architect(mens) daadwerkelijk in interactie te komen met de business (mens); zijn wereld en uitdagingen te begrijpen om daarna de vertaling te maken naar wat dit in architectuur betekent.
    2. Lange termijn versus korte Termijn. Mensen die architectuur bedrijven kijken naar vandaag, morgen en overmorgen; immers een IT landschap is niet “overnight” qua architectuur gewijzigd. Ik merk dat bij veel collega’s aan business zijde de focus veel meer op de korte termijn ligt: Zij moeten vandaag presteren, en morgen zien we wel weer verder! In de interactie met de business is het dus de kunst om hen mee te nemen naar overmorgen en een beeld te krijgen over de business strategie. In die dialoog is “business taal” vereist en geen “IT taal”. Een coalitie met collega’s van de staf afdeling business strategie kan daarbij behulpzaam zijn. Is het business beeld van overmorgen geschetst, dan is de winst dat dit in een proces met de business samen is verkregen (gemeenschappelijk ownership). De vertaling ervan naar een IT architectuur is dan het toetje op de taart wat de business eenvoudig zal accepteren.
    3. De menu kaart en het kookboek.
    Als ik in een restaurant kom ben ik geïnteresseerd in het menu, niet in het kookboek van de chef-kok.(dat is zijn vak). Probeer dus als architect je kookboek niet aan je klanten te verkopen want daar komt hij niet voor (en mocht het onverhoopt wel lukken dan neemt hij je baan over!) . Juist een geaccepteerde vertaling van Business strategie naar een IT architectuur (als basis voor projecten), dat is de “value add” van een architect. Die moet je niet verkopen maar wel het resultaat ervan.

    Zoals ik zei om te overdenken
    Peter Hermans

  39. Peter,

    Dank voor jouw 3 overwegingen.

    Soms zie ik collegae die jammer genoeg stellen dat architectuur een proces is. Ik ben het echter roerend met jou eens dat er een essentieel verschil hoort te zijn tussen de architectuur en het architectuurproces (ook wel aangeduid met ‘architecting’).
    Je hebt gelijk dat de belangstelling van de business wordt gewekt door een zorgvuldig, mede op hen gericht, architectuurproces. Maar het daadwerkelijke gebruik van architectuur door de business in hun eigen functioneren is afhankelijk van de toegankelijkheid van de architectuurbeschrijvingen. Althans, dat is mijn ervaring.

    Zoals jij stelt dient architectuur ook een instrument te zijn in de interactie tussen de architect(mens) en de business(mens). Daarom ben ik een fervente voorstander van architectuurvisualisaties als praatplaten op allerlei niveaus tussen allerlei stakeholders.

    Bij veranderingen is architectuur tevens een cruciaal instrument om de consistentie en coherentie te bewaken in een concurrent transformatie (concurrent impliceert hier een business verandering en IT veranderingen in samenhang).

    De business is jammer genoeg te vaak gefocust op de bonus onder de kerstboom. Maar zij verwacht eigenlijk wel dat als er een concurrent langs zij komt, hun organisatie die concurrent kan volgen. Dus dat de business niet de gevangene blijkt te zijn in de dwangbuis van het IT-landschap. Van de architect wordt daarom verwacht dat hij/zij voldoet aan de korte-termijn-verwachting van de business, met een open oog voor de continuïteit van de organisatie. Met deze uitdaging worstelen veel fysieke architecten (ik bedoel zij die steden, gebouwen, tuinen en interieuren ontwerpen) ook.
    In deze context moet ik vaak denken aan de lijfspreuk van Kees Jans (CIO van Schiphol): ‘Wat op Schiphol niet kan, mag op geen enkel vliegveld in de buurt kunnen’, zie:
    http://www.via-nova-architectura.org/de-cio-spreekt/de-cio-spreekt/de-cio-spreekt-kees-jans-cio-schiphol-group-3.html.

    Jouw laatste opmerking wil ik extra onderstrepen: ‘probeer als architect je kookboek niet aan je klanten te verkopen want daar komt hij niet voor’. Ik stel dat meestel nog wat harder: ‘Probeer de klant niet te overdonderen / imponeren met al jouw slimmigheid!’.

    Dus nog veel om te overdenken. Wellicht is er een behoefte om op het LAC daar eens een track aan te besteden.

    Groet,
    Daan.

  40. Lectori salutem!

    Met stijgende verbazing heb ik het stuk van Daan en de vele reacties doorgenomen. Ik begrijp (o.a. door zijn mail) dat Daan de knuppel in het spreekwoordelijke hoenderhok wil gooien en daardoor een bepaalde toon kiest. Laat ik dat ook eens doen.

    Volgens mij wordt de plank behoorlijk misgeslagen door constant “business” en “IT” tegenover elkaar te zetten. De reacties van Peter op 4-2, erik op 29-1 en Alcedo op 27-1 gaan wat mij betreft een betere kant op: architectuur gaat juist niet over business versus it, maar over het effectief functioneren van de enterprise als geheel.

    Om organisaties te helpen dat te bereiken zijn allerlei slimme dingen bedacht (het ‘architectoloog’ perspectief van Alced) zoals de diverse architectuurraamwerken, -talen, en -methoden die momenteel furore maken. Prima, maar laten we vooral niet vergeten dat het in de eerste plaats gaat om de beroemde ‘holistische kijk op organisaties’ (zoals Daan destijds zelf ook in zijn colleges aanstipte) waarbij we bruggen bouwen tussen de werkvloer en management, procesdenkers en informatie denkers, it-ers en ander volk.

    Overigens: mijn mening is dat we daar langzaam maar zeker met z’n allen steeds beter in worden. In veel organisaties wordt gesproken over de toegevoegde waarde van architectuur, net zo goed als er gesproken wordt over de toegevoegde waarde van procesmanagement, strategische planning etc.

  41. Bas,

    Met lichte verbazing heb ik jouw commentaar gelezen. Deze blog gaat primair niet over de noodzaak en de rol van architectuur, noch over ‘business vs IT’. Deze blog gaat over de lage interesse van de business voor dat deel van de architectuur dat hun functioneren raakt.

    Natuurlijk gaat volgens mij architectuur ook over samenhang in elke richting, dus ook tussen business en IT. Sterker nog als mijn collegeassistent aan de Radboud Universiteit bij mijn architectuurcolleges (http://www.rijsenbrij.net/archive2/index.htm), moet jij je ongetwijfeld nog herinneren dat ik het als hoogleraar digitale architectuur nauwelijks had over business vs IT, maar meer over het krachtenspel tussen strategie, architectuur en project-/programmamanagement. Mijn strategische driehoek die door jouw promotor prof. Erik Proper aan het begin van de discussie over deze blog nog eens werd aangestipt.

    Maar nu even over een andere boeg. Ik zie in jouw linked-in profiel dat jij nog steeds consultant, trainer en researcher bent bij BIZZdesign. Ik vind dat de tools van BIZZdesign, geënt op Archimate, een waardevolle bijdrage leveren aan het in kaart brengen van de business, de IT en de samenhang daartussen. Maar kan je mij eens een paar succesverhalen doen toekomen hoe de producten uit die tools daadwerkelijk en aantoonbaar hebben bijgedragen aan een groter enthousiasme voor architectuur bij de businessmanagers.

    Groet,
    Daan.

  42. Daan, goed om te lezen dat we dan toch op het zelfde spoor zitten enterprise architectuur als (strategische) discipline die waarde toevoegt door verschillende perspectieven op (verander)vraagstukken met elkaar te verbinden. De geciteerde driehoek is daar een prima voorbeeld van. Neemt niet weg dat “business” en “it” in het kader van deze discussie dus zinloze “kampen” zijn!

    Over voorbeelden waarin tools en produkten toegevoegde waarde bieden: zie de talloze gepublceerde case studies.

    Ciao

    P.s. ik herinner me onze samenwerking idd met veel plezier, tijd om het holistische perspectief daadwerkelijk in de praktijk te brengen

  43. Met zulke lange reacties wordt het animo om te lezen en te reageren snel minder :-).

    De vraag gaat over architectuur in IT, de reacties gaan weer veel over die “lastige managers”. Ik denk dat architectuur pas doorbreekt als architecten hun eigen vaktheorie wat loslaten en zich richten op hun echte taak: het realiseren realiseerbare oplossingen, en nee dat gaat niet over alleen projecten en IT systemen. Ook een enterprise architectuur gaat over het cre√´ren van oplossingen, maar dan wel het probleem zoals de manager/bestuurder het ervaart.

  44. Beste Daan,

    Ik denk het misschien zinvol is om eens op een andere manier tegen architectuur aan te kijken. Vandaar mijn ‚Äòkiss for architects‚Äô manifest op http://peterbakker.wordpress.com/the-kiss-for-architects-manifesto/ en een artikel met de titel “Infrastructure Architecture is way more important than Enterprise Architecture” op http://peterbakker.wordpress.com/infrastructure-architecture-is-way-more-important-than-enterprise-architecture/
    Dat laatste artikel heeft een interessant vervolg gekregen op http://stuartboardman.posterous.com/new-york-as-a-virtual-enterprise

    Met vriendelijke groeten,
    Peter Bakker
    (@pbmobi op Twitter)

  45. Hi Daan
    Binnen een bedrijf worden mensen meestal gewaardeerd om hun daden, niet zozeer om hun functiebenaming. Het leuke van het beroep architect (je mag het ook anders noemen, consultant of zo) is dat vorm kan geven aan verandering in een organisatie. Die bijdrage zal des te meer gewaardeerd worden als die aansluit bij de business doelstellingen. Randvoorwaarde is dus begrip van dat doel en van de context. Die business kan ook de ICT business zelf zijn: ik ken heel succesvolle infrastructuur architecten die deze business unit enorm vooruit geholpen hebben.
    Dat neemt niet weg dat architectuur een vak is met verschillende aspecten, zoals in meerdere reacties staan vermeld. Het succes van architectuur is echter direct gerelateerd aan de manier waarop de inhoudelijke werkzaamheden worden uitgevoerd, dus architectuurprocessen en diverse competenties (inlevingsvermogen, communicatieve vaardigheden etc.) zoals we die wel aan consultants stellen, maar niet altijd aan architecten. Als dat wel gebeurt dan zie je dat architectuur de brug kan slaan tussen de verschillende business onderdelen (IT is er daar één van) , en wel wordt gewaardeerd, en (op termijn) een positie krijgt dat ze serieus genomen wordt. Niet als gevolg van de functienaam, maar als gevolg van de daden.
    En ja, bij ons (PGGM) zijn er voldoende architectuur succesverhalen.
    We hebben aangetoond dat je met architectuur de bedrijfsstrategie zichtbaar ondersteund.DAt is ook door de business erkend en daar zitten mijn grootste sponsors. En.. vergeet niet, elke dag zul je je opnieuw moeten bewijzen. Met de functiebenaming alleen ben je er niet (net zoals bij vrijwel alle andere functies)…

    Groet
    Richard Lugtigheid, PGGM

  46. Hallo Daan, veel voorgaande reacties gaan in op details en oplossingen. Niet raar, want in ons vakgebied draait het om oplossingen en gaat het over details.

    Wat je schrijft is natuurlijk totale onzin met een kern van waarheid. Maar om een incompetente businessmanager te adviseren om zijn architect weg te sturen als hij, de businessmanager, het niet begrijpt, gaat misschien toch wat ver.
    Veel businessmanagers zijn volstrekt incompetent om een uitspraak te doen over architectuur. Er is in hun MBA-achtige opleiding ook onvoldoende of geen aandacht geschonken aan IT. Niet voor niets heeft Nijenrode sinds 2010 een MBA-opleiding waarbinnen elke vak aandacht is voor IT en de vraag moet worden beantwoord “wat doe ik met mijn IT”.

    Natuurlijk moet wij, als architecten, goed nadenken wat we een manager voorleggen. En niet alles is nodig. Ik denk niet dat er veel huizenkoper zijn die de constructietekeningen en berekeningen van hun huis in willen zien om er iets (wat?) van te vinden. Ze willen alleen weten wat de functies zijn en wat het kost, maar daarna willen ze toch graag de details in van de vorm en kleur van de kraan, de deurkrukken, de keukenkastjes, enzovoorts. Allemaal functionele zaken.
    Wij zullen ons moeten realiseren dat we met de manager praten over de functies zonder hem daarbij lastig te vallen over de details van de constructie. De manager moeten weten wat hij ermee kan en vooral ook wat niet.

    De medaille heeft dus de spreekwoordelijke twee kanten. In dit geval een functionele en een constructionele kant. Meer informatie over het functie- en constructieperspectief staat in het artikel van Hans Mulder en mij (Informatie oktober 2011: http://www.informatie.nl/Artikelen/2011/oktober/Basic_Enterprise_Engineering_Map.aspx of http://www.demo.nl/publications/cat_view/22-specialist-publications).

    De waarheid die jij beschrijft zit letterlijk tussen de functionele of constructionele benadering in. Het wegsturen van de architect leidt dus niet zonder meer tot een verbetering.

    Edward van Dipten

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here