Dwarse concerns

De kwestie

In stakeholder workshops komt de vraag of een archITect zelf óok een stakeholder is, met enige regelmaat op tafel. Op het eerste gezicht is lijkt die vraag misschien triviaal, maar bij nader inzien is het niet zo eenvoudig om er een eenduidig antwoord op te geven. Wat is er aan de hand?

Veel archITecten ervaren het als hun verantwoordelijkheid om een hoogwaardig systeem te ontwerpen, een systeem dat bijvoorbeeld een zekere duurzaamheid heeft en dat goed past in zijn omgeving. Anders gezegd, zij voelen zich verantwoordelijk om binnen projecten een zeker tegenwicht te bieden tegen een al te sterke korte-termijn focus.

Er zijn allerlei concrete thema's waar archITecten traditioneel veel belang aan hechten. In een workshop dragen zij vaak onderwerpen aan als onderhoudbaarheid, hergebruik, het toepassen van standaarden, beveiliging en betrouwbaarheid. Soms zijn hiervoor – al dan niet na enige discussie – binnen de organisatie andere stakeholders te vinden die de primaire verantwoordelijkheid dragen. Denk maar aan zaken als beheerbaarheid (IT manager), cost-of-ownership (owner) en beveiliging (security officer). Maar er zijn ook punten waarvoor dit niet zo duidelijk ligt. Voorbeelden van dergelijke concerns zijn thema's als toepassen van architectuurprincipes, herbruikbaarheid of consistentie tussen de systemen. Maar zijn zulke architectuurwaarden daarmee dan ook automatisch architectuurconcerns? Dreigen archITecten dan niet de vergaarbak te worden van alle concerns die niet bij andere stakeholders belegd kunnen worden?

Wat te doen?

Sinds de IEEE in 2000 zijn “recommended practice for architectural description of software intensive systems” publiceerde, is er een breed geaccepteerd model (zie figuur) voor het maken van een architectuurbeschrijving. In dit model worden zaken als stakeholders, views, viewpoints, modellen en een architectuur gedefinieerd en met elkaar in verband gebracht. Het aardige is dat dit model impliciet ook een blauwdruk voor het architectuurproces in zich draagt: het daagt archITecten uit om met hun stakeholders in gesprek te gaan over hun concerns, en een architectuurbeschrijving op te splitsen in losse views die specifiek gericht zijn op een (groep) stakeholder(s). Het leidt er als het ware vanzelf toe dat een voorgestelde oplossing wordt besproken in termen van de mate waarin het de verschillende concerns van de verschillende stakeholders adresseert. Uiteraard hebben verschillende mogelijke oplossingen voor verschillende stakeholders verschillende voor- en nadelen. Je mag dan verwachten dat een er alternatief wordt uitverkoren dat het best gebalanceerd is.

De praktijk leert dat dit keuzeproces niet zelden een complex steekspel oplevert. Het hoort bij de rol van de archITect om in dat spel, in de zoektocht naar een voor alle partijen aanvaardbare oplossing, de bemiddelende diplomaat te spelen. Als je tot je door laat dringen wat dat voor consequenties heeft, dan wordt meteen duidelijk waarom een archITect die rol niet kan spelen als hij zelf al te expliciete belangen heeft bij een bepaalde uitkomst. Het is namelijk belangrijk dat je als archITect op zo'n moment boven de partijen staat en zelf geen partij in de onderhandeling wordt. En daarmee ligt de vraag op tafel wie er dan wel moet opkomen voor de typische architectuurconcerns.

Het ingewikkelde van deze kwestie is dat typische architectuurconcerns het karakter van cross-cutting concerns hebben – het zijn concerns die interfereren met de overige concerns. Dat maakt het onderhandelingsproces op zich al ingewikkeld. Een paar voorbeelden.

1. Hoewel iedereen rationeel kan accepteren dat het beter is als een website een hoge mate van consistentie heeft, is het tegelijkertijd lastig – en soms buitengewoon vervelend – dat het je beperkt in de mogelijkheden om je user interface zo goed mogelijk af te stemmen op de functionaliteit die je te bieden hebt, of dat het je dwingt om een terminologie te hanteren die je zelf misschien anders gekozen zou hebben, of dat je moet aansluiten bij een content management systeem dat amper voldoet aan de cruciale requirements.

2. Vanzelfsprekend kan het handig zijn dat de opgeleverde services vanuit verschillende bedrijfsprocessen aangeroepen kunnen worden. Maar om dan in een extra schil om een ingekochte webservice, ten behoeve van een zogenaamde canonicalisatie, een gemeenschappelijke taxonomie te moeten implementeren, dat kost wel een hoop extra tijd, geld, performance en bovendien – die vervelende conversies gaan immers nooit in alle gevallen helemaal goed – is het ook nog eens een extra bron van projectrisico's en incidenten.

3. De gemeenschappelijke corporate user directory bevat net niet die informatie die in het dagelijkse gebruik zo handig zou zijn – en dat terwijl de geselecteerde applicatie zelf al voorziet in een volledig functionele user database. Zonde! Maar ja, eenmalig besparen op een integratie-inspanning in het project zou daarna dan wel structureel extra werk op het gebied van provisioning en user management betekenen. Wat is wijsheid?

De kwestie is duidelijk. Hoe zwaar mag een project-overstijgend belang wegen ten opzichte van een specifiek projectbelang?

De best practices die we kennen onder de term «Werken onder architectuur» vereisen onder meer een duidelijke «separation of concerns» binnen het architectuurproces zelf. Het scheiden van verantwoordelijkheden dus, hetgeen betekent dat de archITect die binnen het project opgesteld staat om de regie te voeren over het totale ontwerpproces – van stakeholder analyse via architectuurschetsen tot detailbeschrijvingen – een andere persoon zou moeten zijn dan de archITect die waakt over de project-overstijgende belangen. Er is in principe niets op tegen dat een enterprise architect als één van de stakeholders betrokken is bij de fundamentele besluitvorming binnen projecten. Er is ook helemaal niets op tegen dat een enterprise architect, net als alle andere stakeholders, de mogelijkheid heeft om een beslissing waarmee hij zich niet kan verenigen voor te leggen aan een architecture board. De architecture board zal dan in zijn wijsheid, rekening houdend met alle belangen, een oordeel moeten vellen. Of die beslissing wel of niet in het voordeel van de enterprise architect uitvalt behoort af te hangen van de kwaliteit van de argumenten.

De project-architect zal zich daarentegen zeer terughoudend op moeten stellen in zijn standpunten over controversiële onderwerpen. Dat kan ook betekenen dat hij niet al te enthousiast de enterprise architectuur kan propageren. Er is uiteraard wel een natuurlijke lijn tussen de enterprise architect en de project-architect – waar mogelijk zal een project-architect zijn voorstellen in harmonie met de enterprise architectuur ontwikkelen. Waar geen keuze gemaakt hoeft te worden, is tenslotte ook geen grond voor een conflict. Slimme project-architecten kunnen dus door hun voorwerk veel lastige discussies voorkomen en ze kunnen door hun bemiddeling draagvlak creëren voor een oplossing. Met een goede stakeholder analyse kan een complex besluitvormingsproces soms verbazingwekkend eenvoudig tot voor iedereen bevredigende resultaten leiden. Daarmee hebben project-architecten in de praktijk toch veel invloed op de besluitvorming, misschien wel meer invloed dan ze gehad zouden hebben als ze zelf formeel verantwoordelijk waren gesteld voor het behartigen van de architectuurbelangen.

Tenslotte een vraag om mee naar huis te nemen. Als enterprise architecten verantwoordelijk gesteld worden voor een categorie van concerns in het bedrijf, zou er dan ook geen mechanisme moeten zijn waarmee wordt vastgesteld hoe succesvol ze daarin zijn, en zou succes niet evenzeer beloond moeten worden als andere stakeholders voor hun successen beloond worden?

In deze kwestie wordt een actueel architectuurthema op een scherpe manier geanalyseerd. Het is de 3^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.