Succesvolle architectuur
Redactie | Verschijningsdatum 01-01-2015 | 43x bekeken
Teneinde het gewenste bestuurlijk vermogen te verkrijgen blijkt het beter te werken als de verantwoordelijkheid van de bedrijfsspecifieke (functionele) elementen bij het meest betrokken bedrijfsonderdeel zelf wordt belegd. De verschillende bedrijfsonderdelen kunnen immers het beste zelf beoordelen welke functionaliteiten vereist c.q. gewenst zijn en hebben daarvoor meestal voldoende kennis en contacten ‘in huis’. Tegelijkertijd moet er dan wél voor worden gezorgd dat naadloos passende (infra)structurele voorzieningen beschikbaar zijn die dit ondersteunen.
Waarom blijkt uit de praktijk dat dit maar matig lukt? Wij hebben gemerkt dat het bekende inrichtingsonderscheid – onafhankelijk of afhankelijk – veronachtzaamd wordt. Het gaat namelijk niet om een informatie-inhoudelijk maar om een organisatorisch-bestuurlijk onderscheid. Het gaat erom wie de feitelijke beslissingsmacht heeft over welke onderdelen van de ICT en wie daarmee dus eigenaar van die onderdelen is en daardoor verantwoordelijk voor het functioneren ervan.
ICT is te beschouwen als een verzameling samenhangende en samenwerkende onderdelen. In ieder geval ligt dit in het blikveld van de architect. Een deel van die onderdelen – de functionele delen – zijn bedoeld voor die bedrijfsonderdelen die iedere dag weer opnieuw beslissen welke producten en diensten moeten worden geproduceerd en aan de klanten moeten worden geleverd. Een ander deel van die onderdelen – de infrastructurele delen – zijn verbonden met het type bedrijf en vormen de fundering van de informatievoorziening. Platformen, databases, ontwikkelomgevingen, uitwisselingsmechanismen veranderen niet van de ene op de andere dag – dat kán niet en dat wíl ook niemand. Daaruit volgt dat bewerkstelligd dient te worden dat deze infrastructurele onderdelen een andere eigenaar krijgen, met andere verantwoordelijkheden dan de functionele onderdelen. De architectuur dient rekening te houden met deze bestuurlijke consequenties, op straffe van vermenging van specifieke en algemene delen van de informatievoorziening en van ongewenste functioneringsrisico’s.
Bij architectuurontwikkeling ligt veelal de nadruk op functionele analyses en de daaruit voortkomende technisch-inhoudelijke gevolgtrekkingen en ‘oplossingen’. Dat resulteert dan in informatie- en technologie-georiënteerde redeneringen en in voorzieningen en werkwijzen die haaks op de bestuurlijke structuur kunnen staan en om precies die reden niet tot succes kúnnen leiden. Als algemene, infrastructurele ICT-voorzieningen anders worden gebudgetteerd, elders worden ontworpen en anders worden gerealiseerd en beheerd dan te doen gebruikelijk, zullen ze moeilijker van de grond komen en zal er weinig acceptatie voor zijn. Een dergelijke benadering wordt in de meeste ‘architectuurscholen’ node gemist. Let wel: het gaat niet om een of andere randvoorwaarde die aan een ICT-oplossing kleeft, maar om essentiële inperking van de ICT-oplossingsruimte vooraf. Het zal vooral om domeinoverstijgende onderdelen gaan, vaak voorwaardenscheppende zaken, zoals (bijvoorbeeld) security, datalogistiek of evidente overall-efficiencies voor platformen en netwerken. Lang niet alle vraagstukken zijn overigens domeinoverstijgend, al lijkt dat zo. Legacy bijvoorbeeld kan weliswaar een algemeen gevoeld vraagstuk zijn, maar moet toch echt door de veroorzakers worden aangepakt en opgelost – in veel gevallen zijn dat de verschillende organisatorische onderdelen!
Ten slotte: architecten zijn modellenmakers. Uit informatie- en procesanalyses worden patronen gedestilleerd op grond waarvan oplossingsvormen in beeld komen, die daarna aan organisatorische randvoorwaarden worden onderworpen. Zo ontstaan centraal georiënteerde ICT-voorzieningen in een federatieve organisatie of gedeconcentreerde faciliteiten in een centraal geleide organisatie – in beide gevallen: receptuur voor falen. Dit zou wel eens de belangrijkste reden kunnen zijn dat er zelden conform de architectuur wordt geïmplementeerd, omdat er vooral rekening wordt gehouden met een technische optimalisatie en niet met de bestuurlijk-organisatorische uitgangssituatie. Iedereen weet het: architectuur is geen doel op zich, maar louter een middel om onderdelen van de informatiehuishouding in samenhang op te delen. Voor een effectieve architectuur zijn echter óók andere criteria van belang. De, naar onze mening, meest belangrijke vraag is: wie kan er voor welke onderdelen in welke mate verantwoordelijk worden gemaakt? Architectuur zal immers vanuit de organisatorische realiteit overall-kwesties moeten aanvliegen en niet vanuit een of andere theoretische ICT-wereld, op straffe van verspilling van tijd en geld door gebrek aan acceptatie. De consequenties hiervan zijn tweeërlei.
• Knip de architectuur zodanig op dat je één bedrijfseenheid verantwoordelijk kunt maken voor een onderdeel. Met andere woorden: vermijd competentiekwesties, gedeelde verantwoordelijkheden en ongebruikelijke, dus onbeproefde, ontwikkelings- en exploitatievormen.
• Beperk de gemeenschappelijke onderdelen van de architectuur en beleg deze bij dát bedrijfsonderdeel dat het meeste belang heeft bij een gemeenschappelijke inrichting van dit onderdeel. Zo wordt de indeling conform de bestuurlijke en financiële lijnen van het bedrijf.
De ‘eerste orde’ automatisering is bij vrijwel alle organisaties achter de rug: administraties zijn geautomatiseerd, de logistieke procesketen wordt ondersteund, de etalage is (deels) gedigitaliseerd en de toonbank ook. De vervolgautomatisering is vaak ingewikkelder: allerlei vernieuwingen brengen ook nieuwe verbanden mee en vergen differentiaties en uitbreidingen in bestaande ketens, nieuwe processtappen en nieuwe ondersteuningswijzen. Het gaat niet om schaalgrootte-veranderingen maar om verfijningen in het net werk van werkwijzen en hun ICT-ondersteuning. Dat leidt dan niet zelden tot een technologiegedreven rechttoe-rechtaan realisatieopzet die geen rekening met organisatie- en omgevingsfactoren houdt. Daarbij wordt de structurele gevolgschade nogal eens onderschat. Advisering door gespecialiseerde externen – die de organisatie meestal nog niet kunnen ‘lezen’, maar wel snel moeten ‘scoren’ – versterkt dit effect.
De architectuuropdracht is naar onze mening dan ook: maak onderscheid tussen functionele onderdelen en (infra)structurele onderdelen van de informatievoorziening, op een zodanige manier dat het mogelijk is om voor ieder onderdeel één (en niet meer dan één) eigenaar aan te wijzen. Die eigenaar heeft dan de vrijheid om dat onderdeel naar eigen inzicht in te richten binnen de context van een aantal gedeelde en besloten architectuurprincipes. Met andere woorden: maak niet de theoretisch beste ICT-architectuur, maar maak een architectuur dat het beste werkbaar én bestuurbaar is.
• Structurele aanpassingen in de informatiehuishouding zijn vaak moeilijk door te voeren vanwege allerlei lastig omkeerbare relaties en vertakkingen, en daarom zullen structurele vereisten zwaar moeten wegen.
• Gemeenschappelijke voorzieningen reflecteren de besturing (governance) én zijn belangrijk voor de wendbaarheid.
• Ook structurele verbeteringen hebben een duidelijke en begrijpelijke business-impact en kunnen daarom als ‘driver’ van verandering dienst doen.
• Maak onderscheid tussen functionele voorzieningen en infrastructurele voorzieningen van de informatiehuishouding;
• Richt de functionele onderdelen van de informatiehuishouding zo veel mogelijk in langs de lijnen van het organisatorische landschap;
• Zorg voor gemeenschappelijke, infrastructurele nutsvoorzieningen die dit ondersteunen én die min of meer indifferent voor functionele veranderingen zijn.
• De organisatorische en bestuurlijke constellatie van het bedrijf moet uitgangspunt zijn bij het opstellen en uitwerken van de architectuur.
afdeling kan worden belegd, is dat optimaal. Lukt dat niet, door bijvoorbeeld niet toereikende budgetten, niet gevoelde noodzaak of niet geaccepteerde implementatie voor een geïntegreerde gecentraliseerde oplossing, dan moet worden gezocht naar wat wél en wat niet gemeenschappelijk haalbaar is. In plaats van een centraal datawarehouse kan standaardisatie van de data-uitwisseling worden nagestreefd, door het standaardiseren van ETL (Extraction, Transformation
and Load)1, metadata en datacatalogus. Daarmee komt dan tóch een meer geïntegreerde gemeenschappelijk aanpak binnen bereik: ‘bilaterale’ data-uitwisseling
wordt gestandaardiseerd, maar niet via centralisatie.
Noot:
[1] ETL: Extraction, Transformation and Load, is een groep technologieën die veelal gebruikt worden bij de koppeling tussen systemen, waarbij er gestreefd wordt naar een minimale technische en semantische koppeling.
Voorbeeld 2: de dertiende maand
Een schoonmaakbedrijf zoekt een financieel pakket. Keuze te over? Nee! Het is namelijk niet alleen de ‘financiële functie’ die de keuze bepaalt. Schoonmaak tikt op weekbasis: de planning is op weekbasis, de uitvoering ook en het personeel wordt per week uitbetaald. Een schoonmaakbedrijf heeft daarom een maand van 4 weken en een jaar van 13 maanden. Rapporteren-per-maand is dan ook vier-wekelijks rapporteren. De bedrijfsklok loopt bij schoonmaakbedrijven dus anders dan bij de meeste organisaties. Dat betekent dat de keuze voor een financieel pakket een wezenlijke organisatiekeuze is. Gewone boekhoudmaanden introduceren afrondproblemen, onnauwkeurige overzichten en leiden tot mistige besturing. In een bedrijfstak die het van de kleine marges moet hebben, is dat hinderlijk en niet aanvaardbaar. De functionele aspecten van de pakketkeuze gaan hier dus samen met de structurele, die van invloed zijn op verschillende andere bedrijfsdomeinen. Die structurele kant kan ons inziens niet als randvoorwaarde bij de inrichting van een of ander financieel pakket dienen, maar is een voorwaarde vooraf die de ‘short list’ van kandidaatpakketten bepaalt. Traditioneel naar ‘marktconforme’ oplossingen zoekend, wordt het belangrijkste organisatiekenmerk gemist!
Voorbeeld 3: de printstraat
Een grote verzekeringsmaatschappij kent een aantal verschillende productgroepen. We zoomen in op schadeverzekeringen en zorgverzekeringen. Omdat het bedrijf door een fusie tot stand gekomen is, is een aantal ICT-inrichtingskwesties actueel geworden. Er wordt bijvoorbeeld overwogen alle printwerk in één centrale printstraat af te werken en zo schaalgrootte voordelen te boeken. Dat stuit op een aantal organisatorische en technische bezwaren. Schadeverzekeringen worden dagelijks geprolongeerd: de inboedel wordt getaxeerd, een auto wordt vervangen, men verhuist, etc. Er is sprake van een min of meer continue stroom van nieuwe polissen, groene kaarten, e.d. en dat is redelijk goed te dimensioneren. Zorgverzekeringen worden per kalenderjaar bekeken en zorgen eindejaars voor ‘bulk’ print- en drukwerk. Het schadebedrijf en het zorgbedrijf verschillen trouwens in heel veel aspecten en kunnen hun klantenbestanden wellicht delen, maar daar houdt het mee op. Ze werken ook nauwelijks samen. Eén centrale printvoorziening is daarom waarschijnlijk geen goed idee: er is te weinig gemeenschappelijkheid en er is geen samenwerkingstraditie. De organisatorische afwegingen zullen in dit geval de technische ‘overrulen’. De beoogde efficiencyverbetering zal niet worden geboekt en de proces- en producttechnische verschillen bijten de voorgestelde centralisatie. Voordat de ondersteuning van het print- en drukwerk wordt ontworpen, zullen de karakteristieken van de processen en de eigenaren ervan dus moeten worden vastgesteld.
Voorbeeld 4: Procespatronen
Een succesvolle beurs- en congresorganisatie heeft de beschikking over een bekend ERP-pakket, dat maandelijks gedetailleerde rapportages produceert. Nader onderzoek brengt echter boven water dat de ERP-modules omringd worden door een groot aantal spread-sheets, waarmee de organisatie-onderdelen hun feitelijke operationele taken ondersteunen. De ERP-modulen zijn blijkbaar moeilijk benaderbaar, matig aanpasbaar, volgen de werkelijke dynamiek van de activiteiten maar moeizaam en kunnen niet voldoen aan de groeiende ondersteuningseisen en de krapper wordende tijdslijnen. Veel moet handmatig worden geregeld en tijdens ‘de spits’ van een beurs of een congres is het vooral het improvisatievermogen en ‘de telefoon’ en niet de actuele systeeminformatie waar men zich op verlaat. Zaaltoewijzing, vloerindeling, afspraken met exposanten over inrichting en voorzieningen, facilitaire ondersteuning, afspraken met gasten – het gaat om allerhande informatie die door het ERP-systeem niet betekenisvol bijeen wordt gebracht. Openstelling, bewaking, toegang e.d. is overigens maar in beperkte mate van het evenement afhankelijk: het moet áltijd worden geregeld, het liefst op een kwalitatief constante wijze. Na uitgebreide analyses oordeelde de financieel directeur dat het juist de processen van de organisatie zijn die het product vormen en dat planning, uitvoering en afrekening uit herbruikbare procesbomen bestaan. Tóen ging het rap. Bedenk: koninklijk bezoek vereist oranje lopers, extra bewaking, aanwezigheid van de directie, aparte vlaggemasten en nog veel meer, ongeacht beurs of congres. Alle regelingen die daarbij gelden en de prestaties die de organisatie moet leveren, kunnen in een procesboom worden uitgetekend. Voor de oud-strijdersbijeenkomst of de old-timersbeurs – bij koninklijk bezoek staat vast wat er gebeuren moet, wie het moet doen, welke leveranciers moeten worden ingeschakeld en hoe de ontvangst dient te verlopen. Alle facilitaire en operationele diensten kunnen hun blik hebben op dezelfde activiteitenstructuur, die verbonden is met deorganisatievloeren waar een en ander zich af moet spelen.
De gezamenlijke voorziening is dus gebaseerd op de notie van herhaalbare processen, onderverdeeld in deelprocessen, elk op hun beurt weer onderverdeeld in ... etc. en op de notie dat die processen gestandaardiseerd kunnen worden als ze zich in de praktijk hebben bewezen. Die procesbomen sturen alles aan, van planning tot afrekening en evaluatie – zie het voorbeeld hierboven van ‘koninklijk bezoek’. Op grond hiervan is pakketselectie uitgevoerd. Het nieuwe pakket vormt nu de basisvoorziening.
Capgemini, Ordina en Rabobank, waar hij verantwoordelijk was voor de architectuur van gegevensmanagement, datalogistiek, business intelligence en big data. Momenteel heeft hij een eigen bedrijf DeGouw Trainingen en is hij associate bij IT-eye.