Sinds de eeuwwisseling (en da’s dus al weer een heel tijd) zie je steeds vaker dat enterprise architecturen gebaseerd worden op “capabilities”. Daarbij is “capability” regelmatig niet of vaag gedefinieerd. Of het lijkt nogal op andere concepten uit het architectuurdenken. Hieronder wat verduidelijking…

Capability volgens TOGAF

Laten ik maar direct met de deur in huis vallen: TOGAF (The Open Group Architecture Framework) kent het begrip Capability en definieert het als “An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.”. Wat mij betreft is dat een prima omschrijving. Je ziet ook direct waarom dit concept veel in moderne enterprise architecturen wordt gebruikt: een capability wordt high-level beschreven, en bestaat uit een combinatie van zowel processen, mensen als technologie. Daardoor kun je er aan modelleren en over praten zonder direct in details te verzanden.

Capability als een “wat” beschrijving

Het begrip Capability heeft veel gemeen met concepten die we al veel langer kennen in het enterprise architectuur denken. Een capability is namelijk een zogenaamde “wat” beschrijving van een concept: het beschrijft “wat” er gedaan wordt, of “wat” er moet kunnen, maar laat (nog even) buiten beschouwing “hoe” het precies gedaan wordt. Daarmee lijkt een Capability verdacht veel op een Bedrijfsfunctie (Business Function), een applicatiefunctie (Application Function) of andere functies uit het klassieke architectuurdenken. Voorbeeld: als een architectuur de bedrijfsfunctie “Inkopen” bevat, zegt dat vooral dat de organisatie aan inkopen doet. Om te weten hoe ze het doet, kijk je naar de beschrijving van het inkoopproces. Daar wordt beschreven welke stappen doorlopen worden om in te kopen. Een bedrijfsfunctie is dus “wat” een organisatie kan, een bedrijfsproces beschrijft “hoe” het gebeurt. Ander methodes hebben het ook wel over het verschil tussen “zingeving” (het waarom en het wat) en “vormgeving” (het hoe).

Wat maakt een Capability beter dan een bedrijfsfunctie

Waarom denken we tegenwoordig liever in Capabilities dan in bedrijfsfuncties? Ik denk dat het enerzijds vooral is om aan te sluiten bij internationale literatuur en hoe de grote adviesorganisaties enterprise architectuur aanpakken. Anderzijds zie je dat in het klassieke architectuurdenken bedrijfsfuncties alleen kunnen bestaan uit sub-bedrijfsfuncties. De rijkheid die we aan een Capability willen geven, past dan gewoon niet in een bedrijfsfunctie(model).

Een interessante onderbouwing geven de consultants van Bredemeyer Consulting in hun presentatie “Enterprise Architecture As Business Capabilities Architecture”: we hebben een rijker idioom nodig, want “we kunnen technologie niet negeren bij het ontwerpen van een bedrijf, en we kunnen het bedrijf ook niet negeren bij het ontwerpen van technische oplossingen”. Volgens hen is een Capability “a combination of business processes, people (organization, knowledge and skills, culture), technology solutions, and assets (facilities, funds, etc.) aligned by strategic performance objectives”. Wat zij toevoegen aan de definitie van TOGAF is dat je voor een Capability expliciet vastlegt aan welk strategisch doel(en) het bijdraagt. Zij stellen dan ook dat een capability wordt gedefinieerd via de uitkomst die je wilt bereiken, en classificeren ze o.a. in “differentiating” en “essential supporting” capabilities.

Bredemeyer lijkt het begrip “business function” niet te kennen, dus zetten ze “capability” vooral af tegen “bedrijfsproces”. En dan komen ze tot de volgende voordelen:

  • Bron van strategische differentiatie
  • Vergemakkelijkt verandering doordat iedere capability als een aparte eenheid opgepakt kan worden (bijvoorbeeld als epic in een agile proces)
  • Is een groepering van verschillende soorten elementen met een hoge samenhang. Daardoor goed te gebruiken voor kennisdeling en afstemming, samenwerking en high-level roadmapping
  • Zorgt bij de inrichting van de capability dat de gebruikte technologie een business probleem oplost

Capability en Enterprise Design

Capabilities zitten als concept niet in de Intersection framework stack van Enterprise Design. Toch zijn ze daar wel degelijk op te plotten, door ze te beschouwen als een combinatie van de Business (“customer value gained” & “change desired”) en Function (“requirements for the outcome of a design initiative”) frames. Maar het is in de praktijk gewoon makkelijker om over Capabilities te praten. Iets dat EDA ook onderkent, en wat ze opvangen door hun Enterprise Design aanpak aan te vullen met de “Milky Way” methode van IRM. Een methode waar naast de Core Value Flow ook de Business Capabilities van een organisatie expliciet in kaart gebracht worden.

Kortom, enterprise architectuur op basis van business capabilities is een handige manier om alle belanghebbenden te laten (mee)praten over strategische initiatieven zonder te verzanden in vage uitspraken en/of technische details. Het is ook goed in te passen in bestaande architectuurmethodes en in Enterprise Design. Vooral doorgaan, zeg ik.

Tags: , , ,