EA in ‘Vallei van Vergetelheid’

EA in ‘Vallei van Vergetelheid’
Enterprise-architectuur lijkt haar belofte als stuurmiddel om samenhang in ontwikkelingen te bewaren en bewaken, niet waar te maken. Wat zijn hiervoor redenen? De vraag op dit moment is: moeten we als community nog de ‘Helling van Verlichting’ zien te bereiken, of zijn we met enterprise-architectuur definitief in de ‘Vallei van Vergetelheid’ beland?
De scope van enterprise-architectuur wordt meestal ongeveer omschreven als: “De samenhang tussen organisatie, bedrijfsprocessen, informatie, applicaties en technische infrastructuur.” Enterprise-architectuur heeft dan tot doel: “Het door middel van richtinggevende uitspraken (zoals doelen, principes en standaarden) en modellen bereiken van structuur en samenhang in een bepaalde omgeving.” 1 Doelen en principes worden afgeleid van de visie en strategie van de organisatie.
Impliciet zit in dit soort definities van enterprise architectuur de premisse verborgen, dat een organisatie een eigen visie en strategie ontwikkelt, en op basis daarvan eigen richtinggevende uitspraken over de eigen organisatie, bedrijfsprocessen, informatie, applicaties en technische infrastructuur. 2 Hoewel dit niet per se het geval hoeft te zijn, worden deze opvatting wel breed gedeeld. Het probleem zit vooral bij het woord ‘eigen’. Momenteel is daarvan namelijk om allerlei redenen steeds vaker geen sprake meer en die ontwikkeling zal alleen maar sterker worden.
1. Eigen visie en strategie
Niet alle organisaties bepalen hun eigen visie en strategie. Sterker nog: steeds minder organisaties doen dat. Veel overheidsorganisaties streven ernaar een regie-organisatie te worden. De uitvoering wordt uitbesteed, maar de visie en strategie rond het uit te besteden werk worden door de regie-organisatie bepaald; wie de aanbesteding wil winnen, heeft deze maar te volgen. Iets vergelijkbaars gebeurt met organisaties, die zogenaamde disruptive automation beschikbaar stellen, zoals Uber en Airbnb. Zij bepalen visie en strategie en ontwikkelen op basis daarvan een platform, dat beschikbaar is voor de uitvoerders. Dus ook hier: wie strategische keuzes maakt, voert die niet uit.
Wat moet een uitvoerder dan op dat domein met zijn eigen enterprise-architectuur? Wie de uitvoering wil gaan doen, heeft zich maar te voegen naar de visie en strategie van de aanbieder. Heeft iemand ooit meegemaakt, dat een organisatie niet mee ging bieden op een opdracht, omdat de visie, strategie en enterprise-architectuur van de aanbiedende partij niet strookt met die van henzelf? Ik niet.
2. Eigen organisatie
Terecht vindt steeds meer automatisering plaats in ketens over meerdere organisaties heen. In de productie, de logistiek en de zorg is dat al lang normaal. De overheid volgt. Een voorbeeld daarvan is de aanpassing/uitbreiding van het berichtenverkeer in de zorgsector met berichten (en bijbehorende infrastructuur) van en naar gemeenten in het kader van de decentralisatie van de AWBZ en de Jeugdzorg.
Het gevolg daarvan is, dat vergaande standaardisatie plaatsvindt. Op het oog alleen over de informatie-uitwisseling, maar impliciet daardoor ook over het proces. (En in toenemende mate ook expliciet: het Inlichtingenbureau – het knooppunt tussen gemeenten en het portaal voor de zorgsector – is bezig de ketenprocessen te analyseren en op basis daarvan nieuwe berichten in de processen tussen gemeenten en zorgleveranciers te definiëren.)
Hierdoor is de speelruimte van de eigen organisatie in een ketenproces beperkt en heeft de organisatie steeds minder invloed op het proces, de informatievoorziening en de technische infrastructuur van een keten.
Ook hier is de toegevoegde waarde van enterprisearchitectuur beperkt. De concern-architectuur van een gemeente deed er bij de inrichting van de informatievoorziening in de keten rond de decentralisatie van AWBZ en Jeugdzorg maar weinig toe, belangrijker voor succes was dat de landelijke standaarden werden geïmplementeerd. Een gezamenlijke enterprise-architectuur voor de gehele keten in de definitie zoals hierboven heeft toegevoegde waarde, maar voor een klein stukje in de keten, is die waarde beperkt.
3. Eigen ICT
Enterprise-architectuur als proces (‘werken onder architectuur’) is vaak geïmplementeerd met de ICT-afdeling als slagboom: als je PSA niet is goedgekeurd, mag je voorziening niet op onze infrastructuur landen. Dit werkt niet meer. Iedere medewerker kan apps en voorzieningen in de cloud gebruiken. Businessmanagers, die comfortabel in de fase business-silo’s vertoeven, kopen met hun eigen budget SaaS-oplossingen voor hún afdeling.
Dit gedrag wordt versterkt doordat de technologie erg snel verandert. De ICT-afdeling kan de ontwikkelingen nauwelijks bijhouden en slaagt er al met al soms onvoldoende in dienstverlenend te zijn. De term ‘schaduw IT’ is in dit verband veelzeggend. Allerlei redenen dus, waarom er steeds minder sprake is van eigen ICT.
Enterprise-architectuur als middel voor het bereiken van structuur en samenhang, komt kortom steeds vaker in de knel of kan slechts gebrekkig geïmplementeerd worden en dreigt hierdoor een papieren tijger te worden. Twee recente artikelen in de AutomatiseringGids beschreven hiervoor overigens ook nog andere redenen: referentie-architecturen zijn te abstract en principes zijn onvoldoende waardevol en daardoor moeilijk te
handhaven. 3
Maar, alsof dit allemaal niet voldoende is, er zijn ook andere problemen.
4. Methoden snappen organisaties niet
In een eerder artikel 4 heb ik een aantal problemen met de in Nederland gangbare methoden voor enterprise-architectuur gesignaleerd. Belangrijkste bezwaar: methoden zijn te veel ‘one size fits all’. Alsof er geen verschillen tussen organisaties bestaan! Dat wordt heel snel cultuur genoemd, terwijl er ook een aantal simpele, structurele kenmerken zijn, die zouden moeten leiden tot een andere manier van positioneren van enterprise-architectuur. Een hele simpele is: waar in de organisatie wordt de strategie bepaald en geïmplementeerd? Mintzberg 5 geeft hierop een helder antwoord: soms in de top, vaker overal en/ of nergens.
En maak niet de fout te denken dat dit gedrag op een dag “overgaat” als de organisatie volwassener wordt. De wijze van coördineren en strategie bepalen en implementeren zit in het DNA van een organisatie. En zoals een eik nooit een bamboe wordt, zo zal een ‘adhocracy’ nooit een machinebureaucratie worden (andersom soms wel...).
Methoden voor enterprise-architectuur houden hiermee totaal geen rekening. Die doen nog steeds net (en misschien is het bij hun klanten ook echt zo) alsof visie en strategie in alle organisaties topdown worden vastgesteld en geïmplementeerd. Een ander structuurkenmerk is de mate van volwassenheid van enterprise-architectuur.
Veel organisaties opereren nog steeds (en waarom ook niet?) als business-silo’s. Maar business-silo’s hebben niet de kunde – in termen van processen voor onderhoud en beheer – om gestandaardiseerde infrastructuren te besturen. Laat staan dat ze organisatiebrede gegevens- en processtandaardisatie aan kunnen. Ze gedragen zich immers niet voor niets als business-silo’s! Iedere technische oplossing die geavanceerder is dan één applicatie voor één functioneel domein, vereist van hen een manier van besturen, die zij niet beheersen. Innovatieve projecten mislukken om deze reden. Voor de goede orde: ik zeg niet dat een architect in dit type organisaties niets bij te dragen heeft.
Wél dat methoden voor enterprise-architectuur hiervoor te weinig oog hebben: bij organisaties met een bepaalde volwassenheid hoort een bepaald type architectuurproducten en governance, die bij andere typen organisaties niet werkt. Methoden voor enterprise-architectuur zouden een toolbox moeten aanbieden met daarin instrumenten en governance voor verschillende typen organisaties met ook nog oog voor verschillen in volwassenheid. Momenteel moeten we het allemaal maar zelf bedenken… En dat brengt ons vanzelf op het volgende probleem. Dat kunnen we niet goed.
5. Architecten snappen organisaties niet
Architecten hebben zelf ook vaak weinig begrip voor de (on)mogelijkheden van de organisatie en voor wat een organisatie moet kunnen en doen om een bepaalde technologie te besturen, in te richten, te beheren en onderhouden. Technisch kan misschien alles, organisatorisch niet. Een prachtig voorbeeld wordt gegeven door De Gouw en Truijens 6. Het betreft een centraal georganiseerd datawarehouse voor een organisatie die nota bene een vereniging met zelfstandige onderdelen is.
Architecten houden volgens hen bij hun ontwerpen te weinig rekening met de bestuurlijke structuur van een organisatie. Een datawarehouse onder centraal ‘gezag’ in een gedecentraliseerde organisatie – waar centraal gezag per definitie ontbreekt of zwak is – gaat niet werken. Dergelijke structurele kenmerken van een organisatie moeten volgens de Gouw en Truijens vóóraf gebruikt worden om de oplossingsruimte in te perken. Hun advies: “De organisatorische en bestuurlijke constellatie van het bedrijf moet uitgangspunt zijn bij het opstellen en uitwerken van de architectuur.”
Mocht je die constellatie als architect willen veranderen: Bart Stofberg 7 schrijft dat er maar twee soorten constructies zijn, namelijk katten en wasmachines. “Als je het gedrag van een wasmachine wilt veranderen, pak je de tekening, je verwerkt je plan in je tekening en je voert de verandering door. Klaar. Als je het gedrag van een kat wilt veranderen, dan stel je jezelf een veranderdoel, je onderneemt acties en kijkt wat het effect is van die acties. Daarna stuur je bij, je kijkt naar het effect en je stuurt nog een keer bij. Enzovoort. Tot je na een tijdje constateert dat je 80 procent van je doel hebt behaald en dat dat al heel mooi is.” Enterprise-architecten handelen vaak alsof organisaties centraal aangestuurde wasmachines met een eenduidig bouwplan zijn. Terwijl het juist de katachtige kenmerken van een organisatie zijn, die uitmaken of enterprise-architectuur resultaten boekt of niet, ook bij ICT-projecten (wasmachine) in niet-centraal aangestuurde organisaties.
Een ander voorbeeld: bijna ieder architect maakt een analyse van het applicatielandschap met een bedrijfsfunctiemodel, omdat dat zo prettig implementatie-onafhankelijk is en daardoor langer mee kan gaan. Prima analyse, smeuïge presentatie, complimenten! Maar: het bedrijfsfunctiemodel is een model voor de onderbouwing van applicatierationalisatie en het standaardiseren van infrastructuur. En deze doelstelling is niet iets wat zomaar breed gedragen wordt door organisaties, die een adhocracy zijn (Mintzberg) of in de fase business-silo’s zit. Daar geldt gewoon: ieder probleem zijn eigen systeem en de rest koppelen we later wel. In de gekozen modelleertechniek zit dus impliciet een beleidskeuze, die niet herkend en ondersteund wordt door de organisatie, waardoor het model zelf ook nooit gaat leven. Zij zíen hun organisatie eenvoudigweg niet op die manier. (En dat heeft niets te maken met de visualisering!) Er is kortom sprake van een opstapeling van onvolkomenheden die ertoe leidt dat enterprisearchitectuur maar in een beperkt type organisaties effectief geïmplementeerd is, waarde toevoegt en resultaten haalt. Is er dan geen enkele hoop meer?
6. Inrichten van informatiestromen Ik weet eerlijk gezegd nooit zo goed wat enterprise-architecten doen. Ik ontwerp de enterprise namelijk niet. Ik zit wel regelmatig aan tafel bij het MT maar niet om de strategie te bepalen of over wel of niet uitbesteden mee te praten. Ik adviseer hen over hun informatiestromen (de integrale processen met bijbehorende informatievoorziening en techniek plus de implementatie daarvan in de organisatie): welke impact hun plannen en ideeën daarop hebben, welke kaders ervoor ik uit hun beleid destilleer, wat de consequenties van wet- en regelgeving zijn voor de inrichting ervan, wat je ermee moet doen om systeemgerichte controle mogelijk te maken, et cetera.
Dit haal ik niet uit een methode, maar dat is normaal gezond verstand, een brede algemene ontwikkeling, omgevingsbewustzijn en oog voor de katachtige aspecten van de organisatie. Verouderde referentie-architecturen, principe- en richtlijnenboekhouders, grote ego’s en mensen die alles voor een wasmachine aanzien, dragen meestal weinig bij aan mijn adviezen of ontwerpen.
En dat is erg jammer voor ons vak. Want veel van ons beschikken over een unieke combinatie van competenties, waar iedere soort organisatie voordeel van kan hebben. Temeer om dat er een aantal meer dan interessante ontwikkelingen op ons af komen. Om te beginnen het Internet of Things8. Volgens het adviesbureau Gartner zullen in 2020 26 miljard apparaten aan het internet der dingen verbonden zijn. In de zorg wordt al geëxperimen teerd met domotica en robots in het kader van langer thuis. Die kunnen in principe een schat aan nuttige gegevens opleveren.
Wat gaan we met al die gegevens doen? Gaan we die delen? Met wie? Is die data veilig, correct, tijdig? Aspecten van privacy en gegevensbeveiliging worden steeds kritischer omdat de infrastructuur van de organisatie, die voor de gegevensverwerking verantwoordelijk is, steeds meer versnippert. Helaas is ook datamanagement notoir onderbelicht in de gangbare methoden voor enterprisearchitectuur. De Datamanagement Body of Knowledge (DAMA BOK) is voor een architect vele malen interessanter dan welke methode voor enterprise-architectuur dan ook.
“De scope van de informatievoorziening van een organisatie wordt groter, en raakt een groter wordend aantal diverse partijen met ieder hun eigen belang en dynamiek. De mogelijkheden om de bijbehorende IT in z’n geheel centraal te plannen, ontwerpen en runnen wordt navenant kleiner.” 9
In plaats daarvan onderzoekt Joep Creusen in zijn artikel nieuwe paradigma’s om de informatievoorziening op te delen in hanteerbare brokken. Open data-architectuur is zo’n paradigma, met ‘linked data’ als mogelijke techniek voor het vastleggen van semantiek. De verdeling tussen gegevensproductie en gegevensconsumptie staat centraal in een open data-architectuur: weet als organisatie waar je corebusiness ligt en laat de rest over aan je partners.
7. Radicale agenda voor de komende jaren Aan de ene kant leiden meer gegevens en nieuwe (koppel) technieken tot steeds meer en rijkere informatiestromen over organisaties heen. Fascinerende mogelijkheden doen zich de komende jaren voor, die voorzien in een maatschappelijke behoefte en daarom snel geadopteerd zullen worden. Aan de andere kant speelt de ‘eigen’ enterprise-architectuur een steeds kleinere rol. Voor een deel is dit onvermijdelijk, als gevolg van de ‘schakel in de keten’ ontwikkelingen. Voor een deel zijn de enterprise-architecten daaraan zelf debet, omdat ze onvoldoende concrete resultaten hebben geboekt en niet vaak genoeg algemeen erkende waarde toevoegen voor hun organisatie. En we worden daarbij onvoldoende geholpen door onze methoden.
Wil enterprise-architectuur mét de bijbehorende methoden en dito dienstverlening van leveranciers niet in de Vallei van Vergetelheid raken, dan zullen we als community een radicale agenda moeten voeren en enkele grote stappen moeten nemen:
• Informatiestromen moeten integraal worden ontworpen op aspecten als proces, gegevens/ informatie, techniek én implementatie. Het verandervermogen van de organisatie, niet wat technisch kan, moet uitgangspunt zijn van succesvolle architecturen en dient een prominent onderdeel van de PSA te zijn.
• Daarom moet ook de specifieke organisatori sche en bestuurlijke constellatie rond een informatiestroom uitgangspunt zijn voor de architectuur. Daarover is dan wel meer kennis nodig.
• Er moet dus meer onderzoek worden gedaan naar de patronen in besluitvorming rond informatiestromen, gerelateerd aan de structuurkenmerken van verschillende typen organisaties of samenwerkingsverbanden.
• Dit moet leiden tot meer inzicht in patronen die passen bij allerlei typen organisaties en de volwassenheid van hun architectuur, en tot inzicht in de best practices van architecten, die effectief zijn in een dergelijke omgeving.
• Er is daarnaast veel meer aandacht nodig voor data-architectuur. Informatie vormt de kern van informatiestromen en moet ook de kern van architecturen zijn. Hoe een architectuur met data als ordenend principe eruitziet, moet worden uitgewerkt. We moeten met elkaar ook goed beseffen dat de huidige enterprise-architecturen en branchereferentie-architecturen veelal te weinig rekening houden met alle bovenstaande aspecten. Er is altijd een forse vertaalslag naar de realiteit en het verandervermogen van de organisatie nodig, waardoor ze zelden daadwerkelijk gerealiseerd worden. Zij zullen daarom moeten worden herijkt. Architecten zelf hebben veel meer kennis van veranderprocessen en meer gevoel voor (de katachtige) verhoudingen in en om een organisatie nodig om succesvol te kunnen zijn.
Methoden voor enterprise-architectuur moeten zich om al deze redenen de komende paar jaar in een hoog tempo aanpassen. Methoden dienen architecten handvatten te geven om de juiste dingen te doen in verschillende organisatorische contexten en daarmee succesvol te zijn. Momenteel is dat onvoldoende het geval.
Dit alles zal leiden tot minder pretenties, meer resultaat en erkende toegevoegde waarde. Als dit lukt, dan zullen we de Helling van Verlichting met elkaar bereiken. Slagen we hierin niet, dan is de Vallei van Vergetelheid ons verdiende loon.
 
Ria van Rijn (riavanrijn@atelierhelder.nl) is senior informatie architect bij Atelier Helder Informatie Architecten BV. Bert Dingemans en Joep Creusen hebben haar bij dit artikel geholpen met hun feedback.
 
[1] Rijn van, R, et al (2013). Wegwijzer voor methoden bij enterprise
[2] “.. in een bepaalde omgeving” kan in principe iedere scope hebben. Zo is de definitie ook bedoeld. In de praktijk hebben enterprise architecturen – de naam zegt het al – en referentie architecturen de
[4] Rijn van, R (2013). One size fits not all. Informatie, oktober.
[3] Maat, M, e.a. (2015). Waak voor een te hoog abstractieniveau. AutomatiseringGids, 26 augustus. En Rommes, E (2015). netwerk en gegevens kunnen uitwisselen.”
[5] Mintzberg, H. Structures in fives: designing effective organizations. Prentice Hall. architectuur. 2e herziene druk, Van Haren Publishing.
[6] Gouw de, T. & Truijens, J (2015). Succesvolle architectuur. Informatie, januari/februari.
[7] Stofberg, B (2015). Een mislukt IT-project is geen IT-project. AutomatiseringGids, 20 mei.
[8] Wikipedia geeft als definitie: “Een voorgestelde ontwikkeling van het internet, waarbij alledaagse voorwerpen zijn verbonden met het scope van de organisatie als geheel. Domein architecturen en Project Start Architecturen (PSA) hebben een smallere - en afhankelijk van het onderwerp soms een bredere – scope.
[9] Creusen, J (2014). Open data-architectuur. Informatie, november. Principeverslaving verzwakt architectuur. AutomatiseringGids, 18 juni.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag