De rol van de ict-architect binnen organisaties gaat de komende jaren volledig op de schop. Dat stelt principal consultant enterprise architectuur Marlies van Steenbergen van Sogeti in haar boek ‘DYA: Van inzicht naar impact: de architectuur voorbij. ‘Van een blok in beton gegoten voorschriften voor ict-projecten, gaan we naar een handvol principes die de kern weergeven van wat nodig is voor de organisatie.’
Het boek van architectuur-specialiste Marlies van Steenbergen wordt gepresenteerd op de twaalfde zogeheten DYA-dag op 26 april 2013 in Houten, waar ict-dienstverlener Sogeti zo’n tweehonderd architecten bij ict-eindgebruikers bijeen heeft gebracht. Het boek geeft organisaties inzicht in de nieuwe rol van enterprise architectuur in een wereld waarin verandering de enige constante is.
Voorheen draaide architectuur in de ict om methoden, processen en in beton gegoten pagina’s vol geschreven voorschriften voor de inrichting van een ict-project. Van Steenbergen pleit in haar boek voor architectuur als stuurinstrument voor het behalen van beoogd bedrijfsresultaat. Daarvoor moet architectuur worden beperkt tot een handvol principes die de kern weergeven van wat nodig is voor de organisatie. Om de slag naar resultaat te maken, moet architectuur zorgen voor verbinding tussen mensen en doelen.
Het DYA-model is door Sogeti ontwikkelt en inmiddels uitgegroeid tot een standaard die overal ter wereld wordt toegepast. Het model bevat vier processen die het hele traject van strategievorming tot realisatie beslaan. Deze processen helpen om de architectuur in te richten, zodat het resultaat de business slagvaardig bedient, tegen acceptabele kosten. De samenhang tussen businessarchitectuur, informatiearchitectuur en technische architectuur wordt daarbij gewaarborgd.
Bestaansrecht
Architectuur is belangrijk voor de slagvaardigheid van organisaties, stelt Van Steenbergen. ‘Maar een goed architectenteam is niet langer voldoende. Architectuur moet een praktisch bruikbaar stuurmiddel worden. Dat vereist samenwerking, interactie, eigenaarschap en vertrouwen in organisaties. Als dat niet gebeurt, dan voorzie ik dat ict-architectuur niet langer bestaansrecht heeft.’
In het boek pleit de auteur voor focus op het totaal, zodat de directie het juiste stuurinstrument in handen krijgt dat nodig is, terugkeer naar de essentie en realiseren van verbinding tussen mensen en doelen. Het boek geeft praktische handvatten hoe dit te realiseren. Zo wordt de verschuiving van sequentieel werken naar interactief werken beschreven: in plaats van vooraf voorschrijven, architectuur interactief toepassen.
Van rules naar principles
Verder vertelt het boek hoe de architectuurfunctie verschuift van een rule-based naar een principle-based instrument, niet meer alles centraal uitschrijven maar zorgen dat de organisatie beslissingen neemt op basis van een beperkt aantal kernwaarden en -keuzes. Ook geeft de auteur praktische tips hoe de verschuiving kan worden gemaakt van van controleren naar loslaten; niet meer alles zelf willen bepalen tot aan het ontwerp van een ict-project toe maar durven overlaten aan collega’s.
Tijdens de twaalfde DYA-architectuurdag in Hotel Van der Valk in Houten delen Rabobank, DB Schenker en Provincie Noord-Brabant hun ervaringen met ruim tweehonderd aanwezige ict-architecten. Zo laat de Rabobank zien hoe architectuur met een beperkte set principes eenvoudig is toe te passen in een voortdurend veranderende omgeving. Met de titel ‘Van samenhang naar verbinding’ staat de DYA-dag in het teken van het bestuurbaar maken van complexe verandertrajecten.
“Van Rules naar Principles”. Is de een niet onlosmakelijk met de ander verbonden? Principes lijken mij op zich zelf staand moeilijk te automatiseren.
Wat is hier nieuw aan?
In beton gegoten voorschriften hadden en hebben niets te maken met architectuur maar met engineering die uitmondt in harde bestekvoorschriften.
Uiteraard zijn er altijd een aantal z.g. architecten geweest die eigenlijk engineers waren en dus ook zo opereerden.
Er is een betere term voor wat hier als “principes” wordt geroepen, namelijk richtinggevende uitspraken. We kunnen natuurlijk wel een academische discussie gaan voeren over de termen, maar het gaat er natuurlijk om wat de verandering van de (ICT)-Architect gaat inhouden.
De stelling dat veel (ICT)-Architecten in het verleden alles in beton gegoten hebben, is misschien ook wat hard. Er zullen heus wel wat organisaties zijn waarbij dat zo werkte, maar ik kan mij herinneren dat in voorkomende gevallen er compleet van de “architectuur” werd afgeweken (als de “Business” dat gewoon dicteerde, of beter de “Business” de (ICT)-Architect volkomen negeerde).
Er vinden een aantal veranderingen (in verschillende tempo) plaats die de rol van de (ICT)-Architect veranderen:
– het migreren van van (een top-down, hiërarchische) organisatie naar (zeer kleine label core) organisaties met veel satellieten van uitbesteed werk erom heen
– de compleet veranderende arbeidsmarkt, waarbij in een veel hoger tempo werk word aangeboden en verdeeld in kleinere veel hanteerbare brokken
– en de dooddoener, standaardisatie, standaardisatie, standaardisatie
cloud en moblity zijn voor mij de eerste pogingen om dat te bewerkstelligen, niet vanuit een standaardisatie motief, maar nog
steeds commercieel
De ICT(Architect) zal dus:
– de (ICT) Architect moet steeds meer “de taal van het toepassingsdomein (bijv. zorg, energie, gemeente, etc…)” spreken, zonder in 2 vakgebieden optimaal deskundig te zijn
– de ICT (Architect) en eigenlijk de (Enterprise) Architect moet het inhoudelijk geweten van de organisatie worden (de meeste architecten hebben mandaat totdat het spannend wordt)
– ook binnen de Architectuur wereld moeten we nu eindelijk eens gaan kiezen voor 1 alsomvattende methode (standaardisatie motief) Het is voor een buitenstaander gewoonweg niet te begrijpen.
– met Marlies volledig eens dat de impact veel relevanter is dan de vorm en functie (dat zijn alleen maar instrumenten). Maar impact vereist volwassenheid van de organisatie om daadwerkelijk een “inhoudelijk geweten te willen hebben”.
Voortschrijdend inzicht dat stelt dat oude architectuur niet werkt lijkt me geen garantie voor de toekomst geven. Tenslotte horen we dit soort verhalen ook over ITIL waar ook boeken over vol geschreven zijn. En inderdaad is verandering een constante maar in principe nog niet een verbetering.
Een laissez faire architectuur waarbij principes achteraf aanpast worden naar de werkelijkheid lijkt me eerder op reageren dan regeren, het verbuigen van de waarheid. Regel van meten is weten, gissen blijft missen is dan ook niet inwisselbaar want bestuurbaarheid kan niet zonder controleerbaarheid.
Principes zijn de fundamentele keuzes die een organisatie maakt. IT Architectuur principes zijn afgeleide van business principes. Dat deze principes als regels worden gezien is op zich niet fout. Immers een principe is een uitspraak van een bepaalde keuze en wordt als zodanig gehanteerd. Het maken van principes is een kunst op zich omdat men regels en principes met elkaar gemakkelijk kan verwarren.
Een voorbeeld van Principles, Concepts, and Patterns voor (in dit geval) Private Cloud vind je hier: http://social.technet.microsoft.com/wiki/contents/articles/4346.private-cloud-principles-concepts-and-patterns.aspx
Met deze nieuwe aanpak voor het ontwikkelen van enterprise architecturen wordt beslist een aantal stappen in de goede richting gezet; ik noteer:
* van rules naar principes,
* van controleren naar loslaten,
* van sequentieel werken naar interactief werken.
Samengevat vindt hier een verschuiving plaats van een rule-based Anglo-Amerikaanse aanpak naar een principle-based Europees/Rijnlandse aanpak en dat is een ontwikkeling die alleen maar valt toe te juichen.
Het is ook in lijn met een door mij eerder geformuleerde stelling dat …
“we binnen de ICT (maar ook binnen de business) meer moeten denken in doelen (lees ook: diensten/services) en minder moeten denken in feiten, regels, procedures en processen”.
Toch heeft het vakgebied van de Enterprise Architecture (EA) nog een zeer lange weg te gaan. De stelling dat we leven in een wereld waarin verandering de enige constante is, is regelrechte onzin: verandering is pas mogelijk dankzij zijn.
De vraag hoe architectuur kan zorgdragen voor de verbinding tussen mensen en doelen kan pas worden beantwoord als het vraagstuk van de Enterprise Ontology voldoende is opgehelderd. Zoals de Engelstalige aanduiding voor dit vraagstuk al aangeeft is ook hier een verschuiving naar een Europees/Rijnlandse aanpak noodzakelijk.
@Jack
Het Rijnlands model is volgens mij ook al achterhaald, de half-om-half oplossing van theoretische regels en praktische laissez-faire, dat maakt EA uiteindelijk als een ‘welstandscommissie’ van Hollands polderen waar altijd onenigheid blijft tussen de dominees en kooplieden.
Ik denk niet dat de rol van de architect direct, en zeker niet in isolatie, moet veranderen, maar de manier waarop de afnemers (gebruikers), de ontwerpers en bouwers (zeg IT team) en de architect samenwerken. En elk op hun eigen gebied de autoriteit hebben om een iets toe te voegen aan het geheel. Het is niet zo dat de architect geen goed werk levert, maar dat deze wordt genegeerd vanwege geld, tijd of andere argumenten. Handhaven van architectuur bijvoorbeeld is altijd heel lastig. Dus samen veranderen zou beter zijn. Daarnaast denk ik in alle gevallen dat iets in beton gieten nooit een goed idee is; zeker niet in deze tijd. Dus het ont-regelen is sowieso goed, maar zal niet tot succes leiden zodra er aan de samenwerking niets gebeurt.
De rol van de ict-architect binnen organisaties gaat de komende jaren volledig op de schop. Eens!. Sterker nog hij zal geleidelijk aan in z’n geheel verdwijnen, juist omdat de ict-architectrol net als in de bouw alleen maar door onafhankelijke externe deskundigheid integer en correct kan worden ingevuld. Dus zonder verstrengelde belangen!.
Samen met de interne ict-afdelingen zijn de interne ict-architecten de kalkoenen voor de kerst. Zij beperken juist de klant- of eigen organisatie-doelstelligen om zolang mogelijk hun oneigenlijke ict-rol te kunnen blijven spelen.
Architecten geven vorm aan doelstellingen ( eisen & wensen) van de klant. Ze geven vorm aan de rol die een klant (organisatie, persoon) wil spelen in onze informatie maatschappij. De ict-architect zorgt in z’n/haar ontwerp ervoor dat er mogelijkheden geschapen worden om deze doelstellingen te behalen en te beschermen. Principles zijn vastgelegd in standaarden weer net als bij de bouw in NEN-normen ( ISO,IETF etc).
Er bestaat geen ict-architectrol binnen de vraag- of aanbod organisaties. Als je een dakplatenleverancier een architectrol geeft krijg je een huis met een heel groot dakoppervlak. Als een medewerker de architectrol heeft dan krijg je een huis waar vooral medewerkers veel ruimte krijgen en zeker niet de organisatiedoelstellingen.