Impact van de strategie op de architectuur

In de blogs Strategie concretiseren en Analyseren van de strategie besprak ik de stap “Wat betekent de strategie of een verandering daarin?”

Nu wij de strategie helder hebben gaan wij de impact daarvan bepalen op de architectuur. Een best practice hierbij is het capabilitymodel te gebruiken. 

Laten wij eerst bespreken wat een capability is. Volgens de BIZBOK® (Business Architecture Body Of Knowledge van de Business Architecture Guild) is een capability een bepaalde vaardigheid of capaciteit die een bedrijf kan bezitten of uitwisselen om een specifiek doel of resultaat te bereiken. Een capability definieert wat een bedrijf doet. Capabilities vertegenwoordigen de basisbouwstenen van een bedrijf.

Anders gezegd is een capability te beschouwen als de kennis, competenties, capaciteit, middelen (mensen, ICT-voorzieningen, budget) en ingerichte processen die nodig zijn om de waardeproposities van de organisatie te kunnen waarmaken. In value streams werk je uit hoe aan externe en interne stakeholders waarde wordt gecreëerd. De value stream geeft inzicht bij het bepalen van welke capabilities er nodig zijn.

Een voorbeeld van een capability is Klantmanagement. Het ‘managen’ van klantgegevens is nodig om producten en diensten aan klanten te kunnen leveren. Er zijn beheerprocessen voor klantgegevens en er is kennis nodig om dit volgens de privacy wet- en regelgeving te doen. Verder zal er een applicatie gewenst zijn, bijvoorbeeld een CRM-systeem, om de klantgegevens te beheren. 

Een capabilitymodel toont alle capabilities in één plaat, verdeeld over drie lagen. Dit zijn de primaire klantgerichte capabilities, de bestuurlijke en de ondersteunde capabilities. Het geeft een overzicht van wat de organisatie zou moeten kunnen èn doen om haar doelstellingen te behalen.

De overheid hanteert in de Nederlandse Overheid Referentie Architectuur (NORA) en de daarvan afgeleide NORA-dochters voor gemeenten, provincies, rijksdiensten, enzovoort, in plaats van een capabilitymodel, een bedrijfsfunctiemodel. Deze is op vergelijkbare wijze te gebruiken als een capabilitymodel. Waar hieronder over ‘capabilities’ of ‘capabilitymodel’ gesproken wordt kan dus ook ‘bedrijfsfunctie’ respectievelijk ‘bedrijfsfunctiemodel’ gelezen worden. 

Een capabilitymodel is stabieler dan een organisatiemodel. Menige organisatie reorganiseert om de drie tot vijf jaar en ‘kantelt’ de organisatie naar een nieuwe inrichting van verantwoordelijkheden. Wàt er gedaan moet worden blijft echter hetzelfde. Het ‘hoe’, in de vorm van processen, zal wellicht wel wijzigen door de nieuwe organisatie-indeling. Ook kunnen capabilities uitbesteed worden aan ketenpartners. Een uitbestede capability blijft echter onderdeel van het capabilitymodel als deze nodig is om de bedrijfsvoering te kunnen doen. Zo zijn bij een webshop de capabilities voor transport en bezorging dikwijls uitbesteed, maar zijn ze een essentieel onderdeel van het van klant-tot-klant-proces.

Een capabilitymodel is dus door de tijd heen stabiel en is daarmee een handige kapstok binnen de architectuurrepository, bijvoorbeeld in een ArchiMate-tool. De capabilities kun je relateren aan organisatieonderdelen of ketenpartners, aan processen, aan rollen en competenties, aan te beheren bedrijfsobjecten, aan wet- en regelgeving en aan ICT-voorzieningen die dat ondersteunen. De capability is zo een spin in het web. Bij een reorganisatie hoef je veelal alleen de mapping van de capabilities op de organisatie aan te passen. 

Dit maakt het capabilitymodel een ideaal model om de impact van een bepaalde strategiewijziging te bepalen. Dit doen wij in de regel met behulp van heatmapping. Hierbij geven wij in kleuren aan wat de mate van impact is van de strategische plannen. In welke capabilities zal geïnvesteerd moeten worden om de doelen te kunnen bereiken? In de praktijk loop je alle capabilities van de organisatie af en bepaal je in hoeverre een capability goed ingevuld is om de strategische doelen van de organisatie te helpen realiseren. Het is dus naast een impactanalyse ook een duiding van de kwalitatieve invulling van de capabilities.

De kleurstelling is redelijk standaard: Rood is problematisch en urgent. Oranje betekent problemen maar niet ernstig. Geel houdt in dat het suboptimaal is, terwijl groen aangeeft dat het voldoet. Soms wordt ook paars gebruikt in het geval de capability nog ontbreekt, terwijl dit geen urgent probleem is. Als laatste kleur is er wit, voor als de capability niet geëvalueerd is. Dit gebeurt als de duiding van de capability niet relevant is voor de impactbepaling.

De heatmap geeft in één model aan waar er iets gebeuren moet. Een meer genuanceerd beeld ontstaat als je de capabilities niet als geheel een kleur geeft, maar deze beoordeelt op de volgende vier aspecten:

• Visie: Is er een duidelijke en haalbare visie op hoe de capability ingevuld zou moeten worden?
• Organisatorisch: Functioneert de capability goed in relatie tot de organisatiedoelen?
• Functionele waarde van de ICT-ondersteuning: is de functionaliteit van de ICT-voorzieningen binnen de capability toereikend?
• Technische waarde van de ICT-ondersteuning: is de techniek up-to-date, onderhoudbaar en kwalitatief goed?

Per capability krijg je dan vier kleuren die aangeven op welke aspect en in welke mate er iets moet gebeuren om de strategische doelen te realiseren.

Bijvoorbeeld van de capability Partner Relation Management is onduidelijk wat de organisatie van ketenpartners en leveranciers wil bijhouden, is de verantwoordelijkheid hiervoor niet duidelijk belegd, is de MS Access database functioneel ontoereikend om dit duurzaam goed uit te voeren en is er bovendien maar één medewerker die begrijpt hoe de database is ingericht. Dit resulteert dan in de onderstaande duiding. Links in ArchiMate met de component ‘assessment’ als duiding, rechts in PowerPoint, wat richting management vaak een wat beter te communiceren model is.

Als architect ga je vervolgens het gesprek aan met het management om de duiding te verifiëren en te bepalen in welke capabilities geïnvesteerd gaat worden en welke prioriteit dit heeft.

In de volgende blog “Bepalen van oplossingsrichtingen” ga ik in op hoe de heatmap gebruikt wordt om een (bijgestelde) doelarchitectuur te bepalen.