Vloeibare relaties

SQL is ongetwijfeld één van de baanbrekende standaarden van de software-industrie. De officiële standaard dateert uit 1986; inmiddels is SQL:2006 alweer de zesde versie. En SQL is springlevend. Het is zonder meer knap om in een industrie die zo in beweging is een standaard te ontwikkelen die al zo lang zo algemeen wordt gebruikt. Toch heb ik de indruk dat er een tot op heden onbenut verbeterpotentieel verborgen zit in deze populaire standaard. Het is de hoogste tijd voor een

Zoektocht door de tijd

SQL is sterk verbonden met het relationele model van wijlen Edgar Codd. Deze legendarische Britse wetenschapper publiceerde in 1969 al een artikel onder de titel "A Relational Model of Data for Large Shared Data Banks" [1] waarin de theoretische basis werd gelegd voor de relationele databases van vandaag de dag.

SQL is primair nog steeds een querytaal. Er zullen maar weinig IT-ers fronsen bij de aanblik van een statement als

SELECT *
FROM Medewerker
WHERE Salaris > 10.000
ORDER BY Geboortedatum;

Het relationele model is gebaseerd op tabellen, zoals de tabel “Medewerker” in het bovenstaande voorbeeld, en de relaties tussen tabellen, bijvoorbeeld tussen “Medewerker” en “Afdeling”. De tabellen representeren de entiteiten die in een bepaald probleemdomein relevant zijn. Een bedrijf heeft vestigingen en vestigingen hebben medewerkers. De relatie tussen een medewerker en een vestiging noemen we in het dagelijks leven een dienstverband. Zo'n dienstverband kun je als een aparte entiteit modelleren. Helaas is er niet voor alle relaties tussen entiteiten een ingeburgerd begrip voorhanden. Het is dan ook niet echt gebruikelijk om zulke relaties als een entiteit te onderkennen.

Integrity Constraints zijn formele regels die erop gericht zijn om de consistentie tussen data in verschillende tabellen te bewaken. Stel dat een vestiging wordt gesloten; dan ligt het voor de hand dat er ook geen medewerkers meer in dienst zijn bij die betreffende vestiging. Met een constraint kun je voorkomen dat er medewerkers in de database voorkomen die een relatie (i.c. dienstverband) hebben met een vestiging die niet meer bestaat. Net zo goed kun je met zo'n constraint bewaken dat een valuta, bijvoorbeeld de gulden, niet verwijderd mag worden zolang er nog facturen in de database voorkomen die in guldens zijn opgesteld.

Tot zover gesneden koek. Appeltje eitje. Kind kan de was doen. Toch meen ik een fundamentele beperking in het relationele model op het spoor te zijn. En nog wel eentje die in heel veel systemen tot nodeloze complexiteit leidt of tot een vervelende beperking van de functionaliteit.

Wat mij namelijk al vele jaren verbaast is het ontbreken van het concept van tijdgebonden relaties in het relationele model – en vooral het gebrek aan discussie daarover. Het lijkt een impliciete aanname dat relaties tussen entiteiten altijd vast zijn. Toch zie ik in de praktijk heel veel relaties die je eerder vloeibaar zou kunnen noemen. Een paar voorbeelden.

• Een bedrijf heeft gedurende een bepaalde periode een zekere vestiging

• Een medewerker heeft gedurende een bepaalde periode een dienstverband met een vestiging van een bedrijf

• Een medewerker heeft gedurende een bepaalde periode een bepaald salaris

En als je je er eenmaal bewust van bent, dan zie je ineens overal dit soort tijdgebonden relaties.

• Een artikel heeft gedurende een bepaalde periode een prijs

• Een artikel heeft ook gedurende een bepaalde periode een leverancier

• Een artikel is gedurende een bepaalde periode in een assortimentsgroep ingedeeld.

Iedereen die wel eens te maken heeft gehad met het fenomeen terugwerkende kracht, of juist vooruitwerkende kracht, zal hoogstwaarschijnlijk tegen soortgelijke relaties zijn aangelopen. Wellicht dat hij of zij zich nog herinnert dat het best lastig is om dit soort relaties goed te modelleren. Ik ken zelfs mensen die spontaan in de stress schieten bij het horen van het woord peildatum.

Nu is het op zich binnen het relationele model best te doen om een relatie tussen twee entiteiten tijdgebonden te maken. Wat je kunt doen is – in plaats van een enkelvoudige relatie tussen twee entiteiten – een driehoeksrelatie modelleren, waarbij in één entiteit de tijdvakken vastliggen die voor de relatie tussen de twee andere entiteiten gelden. Dus zoiets als in bijgaande afbeelding.

Er zit wel een klein nadeel aan zo'n constructie. Eenvoudige queries vertalen zich in SQL al snel in een behoorlijk ingewikkelde syntax met joins tussen de tabellen en conditionele where-clauses om af te testen of de begindatum van het dienstverband wel in het verleden ligt en de einddatum van het dienstverband ofwel nog niet is ingevuld, ofwel tenminste in de toekomst ligt. En gaat het nog maar om de simpele vraag naar een lijst met medewerkers per vestiging op een bepaald moment in de tijd. Zodra het iets ingewikkelder wordt, bijvoorbeeld de leverancier van een artikel (tijdvak 1) in een assortimentsgroep (tijdvak 2) per filiaal (tijdvak 3) op een bepaald moment in de tijd, dan heb je al te maken met drie verschillende tijdvakken, en evenzovele relatie-entiteiten, en explodeert een SQL query al snel tot tot een lengte die niet meer op een A4-tje past.

Zou het nou niet mogelijk zijn om SQL net iets slimmer te maken, om dit soort veel voorkomende relaties beter te ondersteunen? Zou het concept van tijdsnuggere relaties eigenlijk geen pijler onder het relationele model moeten zijn?

Om over te peinzen

Het is niet zo moeilijk om te bedenken hoe een tijdsnuggere SQL query er ongeveer uit zou moeten zien. Je zou al een eind in de richting kunnen komen met

SELECT *
FROM Medewerker
ON Datum
WHERE Salaris > 10.000
ORDER BY Geboortedatum;

Het is ook niet zo moeilijk om je voor te stellen dat een query preprocessor zo'n query automatisch zou kunnen expanderen naar een geldige SQL query met bijbehorende where clauses. En als we dan toch bezig zijn, dan weet ik er nog wel een paar. Neem nou de lijst met medewerkers uit het afgelopen jaar per filiaal

SELECT Medewerker.naam
FROM Filiaal, Medewerker
DURING (20070801; 20080731)
GROUP BY Filiaal;^*

Het kan toch niet zo moeilijk zijn om uit een dergelijke syntax eenduidig de conclusie te trekken dat het alleen om medewerkers gaat die in de opgegeven periode voor een filiaal hebben gewerkt? Of neem de lijst met omzet per maand van alle filialen die gedurende de gehele afgelopen 12 maanden omzet hebben gemaakt – de zogenaamde vergelijkbare omzet.

SELECT SUM (Omzet.bedrag)
FROM Filiaal, Omzet
DURING ALL (20070801; 20080731)
WHERE Omzet.datum >= 20070801
AND Omzet.datum <>^*

Deze is al een stukje lastiger te verwerken, omdat “ergens” de kennis vast moet liggen dat de during clause in dit geval ziet op het tijdvak dat het filiaal binnen het bedrijf actief was – dus iets betekent als

WHERE Filiaal.Startdatum <= 20070801 AND ( Filiaal.Einddatum >= 20080731
OR Filiaal.Einddatum = NULL)

En omdat dit nog relatief simpele voorbeelden zijn, zal het nog best het nodige denkwerk vereisen om een syntax te bedenken die in alle gevallen werkt. Toch ben ik er heilig van overtuigd dat er voor dit soort logische relaties ook een logische notatie te bedenken moet zijn. En dat het tijdvakconcept tot een standaard construct in relationele databases kan worden verheven. Het is wat mij betreft de hoogste tijd dat daar eens een degelijk proefschrift aan wordt gewijd.

Trouwens, als je er even over piekert, dan valt er op dit gebied nog veel meer te automatiseren. Stel je voert in dat een medewerker vanaf 1 januari een hoger salaris krijgt. Een slimme computer zou dan begrijpen dat dit automatisch betekent dat het lopende salaristijdvak moet worden afgesloten op 31 december – dit soort salarissen sluiten elkaar immers uit. Op dezelfde manier zou je kunnen bedenken dat als een medewerker benoemd wordt tot productmanager van een productgroep, deze rol voor de huidige medewerker ophoudt. Of als een artikel vanaf een bepaalde datum in een bepaalde assortimentsgroep valt, het niet meer in de huidige groep thuishoort. Ik zie dus veel potentie voor een automatisch gegenereerde tijdvakconstraint.

Zo'n automatisme geldt overigens niet voor alle relaties – niet alle relaties zijn mutually exclusive. Eén artikel kan op één moment in de tijd misschien best meerdere leveranciers hebben, net zo goed als één medewerker op één moment in de tijd best voor twee verschillende afdelingen kan werken. Aan de andere kant, een filiaal waar de laatste medewerker uit dienst gaat kan hoogstwaarschijnlijk gesloten worden, net zo goed als een artikel dat zijn laatste leverancier verliest best uit het assortiment genomen kan worden (of vice versa) en zo goed als voor een assortimentsgroep die wordt afgesloten alle tijdvakken van artikelen die aan die groep zijn gekoppeld best automatisch beëindigd zouden kunnen worden. In deze laatste gevallen zie ik nog een ander patroon, namelijk dat van de subperiode. Je kunt een algemene regel bedenken dat de periode van een dienstverband altijd moet vallen binnen de periode dat het organisatieonderdeel waarmee het wordt aangegaan bestaat. Of dat een prijs van een artikel alleen maar loopt binnen het tijdvak dat een artikel in het assortiment zit. Ook dergelijke tijdvakconstraints, die bij een UPDATE of een INSERT het leven aanzienlijk zouden kunnen vergemakkelijken, zouden relatief eenvoudig uit een tijdsnugger datamodel te genereren kunnen zijn. Maar dan moet er ook nog wel even een tijdsnuggere modelleertaal bedacht worden...

Mocht je door dit pleidooi geïnspireerd zijn geraakt, dan weet ik alvast een prikkelende stelling voor je proefschrift.

Het is de hoogste tijd dat de tijd dat SQL de tijd niet in de gaten had tot de verleden tijd gaat behoren.

Hora est.

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 8^ste in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

^* Deze voorbeelden zijn bewust gesimplificeerd.

[1] Codd, E.F: "A Relational Model of Data for Large Shared Data Banks"; Communications of the ACM 13 (6): 377–387, 1970.

Naakte SOA

Jim Webber komt de eer toe om als eerste – of op z'n minst één van de eerste – software analist publiekelijk zijn afkeer geuit te hebben van een “fat SOA”. Zijn levendige en amusante bijdrage aan de Qcon 2007 conferentie onder de titel “Guerilla SOA” [1] heeft ongetwijfeld velen aan het denken gezet. De laatste weken zijn vele industrie-goeroes hem in zijn voetsporen gevolgd. Onder hen bekende namen als Martin Fowler [2], David Linthicum [3] en Joe McKendrick [4]. Het onderwerp prikkelt op z'n minst de creativiteit. Kwalificaties als “Manboobs”, vergelijkingen met “Junk Food” en woordgrapjes als “Enterprise Service Busted”, “Erroneous Spaghetti Box” en “Same Old Atrocity” zijn niet van de lucht. Het lijkt wel een collectieve actie van de softwareontwikkelaars en -architecten gericht tegen de grote boze leveranciers met hun dikke, dure middleware. Tijd voor een dieet?

Het debat

Een naakte SOA is een “back to basics” architectuur. De gedachte is even sympathiek als simpel. Het web is de beste architectuur die het vakgebied tot nu toe heeft voortgebracht. Sir Tim Berners-Lee heeft als geestelijk vader van het web een voorbeeldige prestatie verricht. Het web is schier oneindig schaalbaar, en het biedt een platform voor applicaties die in de verste verte niet te voorzien waren. Waarom zouden we het dan nu moeilijk maken met een ESB?

Het web is van nature één en al middleware. En de grote kracht van het web is dat het zo dom is. Berners-Lee heeft heel bewust voor gekozen voor een oersimpele architectuur. Hij wilde bijvoorbeeld het probleem van de “broken links” niet door het netwerk op te laten lossen. Dat kunnen de gebruikers van het netwerk veel beter zelf doen. In Europa zouden ze zoiets het subsidiariteitsbeginsel noemen – probeer de verantwoordelijkheid voor het oplossen van een probleem zo dicht mogelijk bij de bron te leggen. En applicatie­ontwikkelaars met een integratieprobleem hebben een meer dan begrijpelijke weerzin tegen het oplossen van zo'n probleem op enterprise niveau (waarschijnlijk nog meer dan met enterprise technologie).

Het web als middleware is goed, het is bewezen, dus wie nog betere middleware aan de man wil brengen moet van goede huize komen. En als “betere middleware” alleen zou betekenen dat er intelligentie in het netwerk wordt gesmokkeld die innovaties tegengaat en die dus de oerkracht van het web ondermijnt, dan zou het inderdaad tijd worden om de stormbal te hijsen.

Toch zijn er ook geluiden dat leveranciers niet zelden al te gemakkelijk als zondebok voor jammerlijk mislukte SOA-projecten worden gebruikt. Het is nou eenmaal verleidelijk om de schuld van zulke mislukkingen buiten de eigen organisatie te zoeken. Ik heb zelf nog geen enkel SOA-project gezien dat is mislukt puur vanwege falende technologie. Ik ken wel projecten die zijn mislukt omdat er overspannen verwachtingen waren van de magische vermogens van technologie om architectuurproblemen te verhelpen. Typische voorbeelden van het “Same Old Architecture” probleem. Iedere keer als dezelfde architecten die een bestaand architectuurprobleem niet hebben kunnen voorkomen geacht worden om het op te lossen, dan is de kans niet denkbeeldig dat ze opnieuw in dezelfde valkuilen vallen.

Het is de verdienste van David Linthicum [5] om al zeker 10 jaar onvermoeibaar te hameren op het gevaar van “vendor driven architecture” [3], [6-9]. Hij laat ook geen gelegenheid onbenut om erop te hameren dat een succesvolle transformatie naar een SOA geen tactische operatie is die in een projectvorm tot een goed einde kan worden gebracht, maar dat het een strategische keuze moet zijn die een verandering van lifestyle vereist. In die zin is het domweg opbergen van de bestaande inter-application spaghetti in een blackbox met het label ESB inderdaad een recept voor ellende. Maar is dat nou de schuld van de leveranciers?

De naakte waarheid

Hoe zat het ook al weer. David Chappel – de auteur die het begrip ESB groot heeft gemaakt – stelt het zo: “The ESB provides a highly distributed, event-driven Service Oriented Architecture (SOA) that combines Message Oriented Middleware (MOM), web services, intelligent routing based on content and XML data transformations” [10]. Afgezien van het gebruik van het woord “architectuur” als synoniem voor “infrastructuur” beschrijft dit de kern van de ESB-propositie. De ESB als glueware, met een rijkdom aan functionaliteit om componenten en services losjes (“loosely”) te koppelen.

Oracle beschrijft een ESB als “the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA)” [11]. IBM houdt het op een “infrastructure service that provides robust communication, intelligent routing, and sophisticated translation and transformation of services” [12].

ESB is dus geen oplossing voor een architectuurprobleem. Het is een tool om makkelijk bestaande applicaties van een service-interface te kunnen voorzien, om makkelijk composiete services samen te kunnen stellen en om bepaalde governance­taken te centraliseren. In een ideale wereld zou je waarschijnlijk geen proprietary ESB willen gebruiken. Vendor-lock-in's zijn nooit aan te bevelen. Misschien kun je zelfs wel stellen dat het niet wenselijk is om in een green-field situatie een ESB als concept te gebruiken. Complexiteit voorkomen is altijd beter dan complexiteit beheersen, niet waar?

Een ESB kan naar mijn mening wel degelijk helpen om bijvoorbeeld een legacyprobleem op te lossen. Zie het maar als een stap in een migratie­strategie. Als een truc om gedurende de vlucht de lekke band van een vliegtuig te plakken. Noem het van mij part een “One-night stand”. Weggooiarchitectuur desnoods. Een noodzakelijk kwaad. Maar zie een ESB als een nuttig instrument om problemen die in de loop van de jaren zijn gegroeid te tackelen. Een ESB is niet de bron van de organisatorische en architecturele problemen. Dan is het toch raar om leveranciers te verwijten dat hun EBS die niet kan oplossen?

Een paradigmaverandering gaat altijd gepaard met vallen en opstaan. Het was zo bij de invoering van relationele databases, het was zo met de adoptie van het web en het is zo bij de transformatie naar enterprise architectuur. Succesverhalen en mislukkingen wisselen elkaar af, maar uiteindelijk vinden we met z'n allen een balans die de industrie een hoger plan brengt. Daarbij hebben technologische innovaties altijd een rol gespeeld en er is geen enkele reden om te denken dat zoiets dit keer niet zal gebeuren. De “peak of inflated expectations” [13] ligt inmiddels achter ons, zo veel maakt dit debat wel duidelijk. We zullen de “trough of disillusionment” nog doormoeten om te ontdekken welk potentieel ESB's op termijn zullen bieden, dan wel hoeveel of hoe weinig kleren een effectieve SOA infrastructuur nodig heeft.

Een ding is zeker. Een typische eilandorganisatie met een bijbehorende archipelarchitectuur zal heel wat weerstand moeten overwinnen voordat het zich een cultuur van bruggenbouwen en samenwerken eigen heeft gemaakt. Op termijn is het opsplitsen van zulke organisaties het enige alternatief voor synergetische samenwerking. Wat dat betreft is de markt ongenadig.

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

Bronnen

[1] http://www.infoq.com/presentations/webber-guerilla-soa

[2] http://www.infoq.com/presentations/soa-without-esb

[3] http://weblog.infoworld.com/realworldsoa/

[4] http://blogs.zdnet.com/service-oriented/

[5] http://www.davidlinthicum.com/WhoWeAre.html

[6] David S. Linthicum: “Enterprise Application Integration”; Addison-Wesley, 1998.

[7] David S. Linthicum: “B2B Application Integration: e-Business-Enable Your Enterprise”; Addison-Wesley, 2000.

[8] David S. Linthicum: “Next Generation Application Integration”; Addison-Wesley, 2003.

[9] http://www.davidlinthicum.com/paperspresentations.html

[10] David A Chapel: “Enterprise Service Bus”; O'Reilly, 2004.

[11] Vimmika Dinesh et al: “Oracle® Enterprise Service Bus Quick Start Guide 10g”; Oracle website, sept 2006.

[12] Naveen Balani: “Model and build ESB SOA frameworks”; IBM website, mrt 2005.

[13] De Gartner Hype cycle wordt onder andere bechreven op wikipedia, zie http://en.wikipedia.org/wiki/Hype_cycle.

Impedantie Matching

Bedrijfsarchitecten hebben als functie om te analyseren en te adviseren hoe je bedrijfsfuncties het beste in kunt richten. Evengoed hebben applicatiearchitecten zo’n functie voor applicatiefuncties en infrastructuurarchitecten voor infrastructuurfuncties. Het wordt pas lastig als men zich gaat afvragen wie nou in staat zou zijn om de architectuurfunctie zélf in te richten. Het is dan ook niet verwonderlijk dat het ontwikkelen van de bedrijfsarchitectuur van de architectuurfunctie vaak een moeizame bevalling is. Het functioneren van deze bedrijfsfunctie laat dan ook wel eens te wensen over. Het zou meer dan jammer zijn als dit het prille vakgebied zou belemmeren in zijn ontplooiing. In deze column wordt daarom vanuit een organisatiekundig perspectief betoogd wat de unique selling point van enterprise architectuur is.

Het Ontwerp van de Architectuurfunctie

De management goeroe Eliyahu Goldratt heeft er zijn levenswerk van gemaakt om de boodschap te verkondigen dat het zinloos is om in alle bedrijfsfuncties tegelijkertijd een beetje te investeren – het eindresultaat dat zo kenmerkend is voor doorgaans enerverende budgetteringsrondes. Goldratt wordt niet moe om erop te wijzen dat deze praktijk vooral verspilling bevordert. Bedrijven zouden volgens zijn «theory of constraints» in plaats daarvan moeten kijken naar de knelpunten in de processen, en er heel gericht in investeren om die knelpunten op te lossen [1].

Het architectuurproces – het geheel van activiteiten die we in het Nederlands zo bloemrijk omschrijven met de term «werken onder architectuur» – staat bij veel organisaties volop in de belangstelling. Als je de belangstelling voor publicaties, congressen en opleidingen op het gebied van enterprise architectuur en IT Governance als maat neemt, dan wordt er ook volop in het architectuurproces geïnvesteerd.

De architectuurfunctie wordt meestal beschouwd als een “inrichtingsfunctie”. Het speelt een rol in de vertaling van de strategie (“richten”) naar de operatie (“verrichten”). Denk aan concrete activiteiten als productontwikkeling, procesverbetering, herstructurering en systeemontwikkeling. De architectuurfunctie wordt uitgevoerd als onderdeel van een concreet ontwikkelings- of verbetertraject en de archITect houdt zich uit hoofde van die functie op allerlei niveaus en terreinen bezig met

1. het analyseren van stakeholders en hun concerns
2. het verkennen van oplossingsalternatieven
3. het faciliteren van de keuze voor een oplossingsalternatief
4. het creëren van draagvlak voor het gekozen oplossingsalternatief
5. de ontwikkeling van het gekozen oplossingsalternatief begeleiden
6. het gebruik van het gekozen oplossingsalternatief evalueren
7. het in kaart brengen van verbeterpotentieel

Misschien valt het u op dat dit taken zijn die ook al uitgevoerd werden toen er nog niemand was die de titel “archITect” droeg. Daar is op zich weinig tegen in te brengen. Het spreekt vanzelf dat in de gevallen waarin geen van de direct bij een vernieuwing of verbetering betrokkenen de functie “architect” bekleedt, vaak een of meerdere personen vanuit een andere rol deze taken uitvoeren. Het gaat bij werken onder architectuur dan ook niet persé om nieuwe taken, maar om het expliciet benoemen van deze specifieke combinatie van verantwoordelijkheden.

Het lastige van het inrichten van een architectuurfunctie is dat deze functie raakt aan het ontwikkelen van de strategie en tegelijkertijd raakt aan het ontwikkelen van concrete oplossingen – zoals producten, systemen en platformen. Maar al te vaak is er in de praktijk sprake van een inpendantie mismatch tussen de processen op deze terreinen. Ze “geleiden” veranderingen met een andere snelheid. Het overbruggen van die mismatch is misschien wel de grootste uitdaging bij het vormgeven van de architectuurfunctie.

Om over te Peinzen

Veel organisaties worstelen ermee dat investeringen in enterprise architectuur lastig in concrete business initiatieven onder te brengen zijn. Het probleem laat zich van verschillende kanten te benaderen. De investeringen in enterprise architectuur renderen als het goed is bij meerdere business initiatieven. Veranderingen en vernieuwingen worden makkelijker, beter of sneller te realiseren. Maar als meerdere stakeholders ervan profiteren, waarom wordt de investering dan afgewenteld op de eerste gebruiker? Waarom moet de eerste die beweegt het risico dragen? Is het wel te verkopen dat dit initiatief door de verbreding van de scope meer (management)tijd gaat kosten?

Als het dan zo onaantrekkelijk is om als eerste een architectuurvernieuwing te adopteren, dan zou het gevolg daarvan kunnen zijn dat dit soort fundamentele verbeteringen maar moeizaam tot stand komen. Dan zou de perceptie kunnen ontstaan dat investeringen in enterprise architectuur vooral afleiden van de hoofdzaak. Als het nemen van zulke risico’s ook nog eens onvoldoende wordt beloond, of als er geen duidelijke verantwoordelijkheid wordt belegd, dan bestaat de kans dat managers zich gaan richten op andere prioriteiten. Maar worden er op die manier dan geen gezonde business kansen gemist? Kunnen zulke investeringen gedurende langere tijd ongestraft achterwege blijven? Zou dat op langere termijn de gezondheid van de organisatie niet kunnen ondermijnen?

Het inrichten van een aparte functie voor “enterprise architectuur” beoogt een uitweg uit dit dilemma te bieden. Het is een mechanisme om een verantwoordelijkheid te creëren voor de functies en voorzieningen die het belang van één bedrijfsdomein overstijgen. Dat betekent dat de opdrachtgevers van business innovaties de functies die hun eigen verantwoordelijkheidsgebied overstijgen voortaan over kunnen laten aan een afdeling die daarvoor speciaal geëquipeerd is. Natuurlijk roept zo’n centrale functie tal van nieuwe besturing­vragen op, maar het is tenminste een nobele poging om een begin te maken met het oplossen van de geschetste problematiek.

Het valt te bezien of het inrichten van enterprise architectuur een modegril van voorbijgaande aard is, of dat er anno 2008 dieperliggende redenen zijn waarom het organiseren van een architectuurfunctie op enterprise niveau noodzakelijk is geworden. Persoonlijk ben ik van mening dat de noodzaak voor het organiseren van een architectuurfunctie alles te maken heeft met het definitief afscheid nemen van het silo denken. Of het nou Service Oriented Architecture heet, of Business Process Reengineering, of misschien Complex Event Processing, het zijn allemaal varianten op het thema “slimmer structureren van de informatiefunctie”. Met meer synergie, meer consistentie en meer slagkracht als resultaat.

Het onderscheiden van de bedrijfslaag, de applicatielaag en de technologielaag als aparte aandachtsgebieden in de architectuur is een beproefde manier om zo’n slimmere structuur vorm te geven. Maar deze drie lagen hebben van nature elk een eigen dynamiek c.q. een aparte impedantie; denk bijvoorbeeld maar aan de verschillende discussies die rondom het thema ‘outsourcing’ op de verschillende lagen worden gevoerd – vaak met elk hun eigen uitkomst. Het voorkomen van een mismatch tussen deze lagen rechtvaardigt niet alleen, maar vereist zelfs een andere aanpak, een andere manier van samenwerken. "Werken onder architectuur" is hiervoor juist geknipt. Dat blijkt keer op keer uit de ervaringen van structurele verander- en verbeterinitiatieven.

Is het feit dat veel organisaties vandaag de dag worstelen met een nijpend legacy-probleem trouwens geen voldoende indicatie dat zij hun architectuurfunctie in het verleden misschien onvoldoende hebben belicht?

Effectief en efficiënt innoveren is tegenwoordig voor veel bedrijven van cruciaal belang. Investeringen in de architectuurfunctie zijn dus indachtig het gedachtegoed van Eliyahu Goldratt vooral van belang als de architectuur een bottleneck vormt in het innovatieproces – het proces van ontwikkeling van nieuwe functies en verbetering van bestaande functies. Als de bestaande architectuur vernieuwingen en verbeteringen in uw organisatie beperkt in plaats van stimuleert. Dat plaatst investeringen in architectuur meteen in de relevante business context. Innovatievermogen. Hoe beter het is gesteld met uw architectuur, hoe groter uw innovatievermogen is. En hoe slechter uw architectuur in elkaar zit, hoe slechter u in staat bent om te vernieuwen en te verbeteren.

Dus mocht u ooit de vraag krijgen wat u als archITect nou eigenlijk doet, dan weet u nu het antwoord. Als architect werkt u aan het verbeteren van het innovatievermogen van uw organisatie. Een «mission statement» om trots op te zijn, vindt u niet?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 7^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

[1] Eliyahu M. Goldratt, Jeff Cox: “The Goal: A Process of Ongoing Improvement”; North River Press, 1984.

De Midoffice Mythe

Toen de meeste mensen nog gewoon in een fabriek werkten, waren er twee soorten medewerkers – fabrieksarbeiders en kantoorpersoneel. Je droeg al naar gelang je positie of een ranzige overall, of een schoon overhemd – bij voorkeur met een hagelwit boordje. Dat was duidelijk.

Toen de dienstensector opkwam, kwam er behoefte aan een nieuwe tweedeling. De mensen die in de vuurlinie stonden – de medewerkers met klantcontacten, bijvoorbeeld achter het loket van een bankfiliaal – werden ingedeeld bij de frontoffice, en de mensen die op de achtergrond hun werk deden – medewerkers van de administratieve organisatie en de stafdiensten – hoorden even vanzelfsprekend bij de backoffice. In de wandelgangen werd het vaak zo samengevat: de frontoffice verdient het geld, en de backoffice maakt het op.

Wat zou de midoffice hieraan nog kunnen toevoegen?

Common Sense

Oorspronkelijk werd IT vooral gebruikt om taken uit de backoffice te “automatiseren” – niet voor niets is de term “administratieve automatisering” in zwang geraakt. Sinds de e-commerce en e-business ontwikkelingen speelt IT steeds nadrukkelijker ook bij de frontoffice taken een rol. Klanten kunnen op de website on-line bestellingen doen, problemen melden en met een beetje geluk ook zelf oplossen. Dankzij straight-through processing in de geautomatiseerde back-office is menselijke tussenkomst soms niet eens meer nodig. Goed, je kunt nog betogen dat de “content managers” van vandaag op een indirecte manier het klantcontact verzorgen, dus eigenlijk moderne frontofficers zijn, maar strikt genomen hebben zelfs zij nu een ondersteunende taak.

De laatste tijd lees je met enige regelmaat de term midoffice – vooral in relatie tot de elektronische overheid. Dan gaat het doorgaans om allerlei IT-systemen die de coördinatie en afstemming van de overige IT-systemen regelen. Systemen die niet klant-gericht zijn, en niet administratief van aard zijn, maar die integreren en orchestreren. In software-engineering termen zou je het al snel over middleware hebben, wellicht nog wat aangevuld met typische enterprise services. De “enterprise service bus”, de “business rules engine” en de “business process management engine”, dat soort systemen.

Maar hoe vertaalt zich dit in bedrijfskundige termen? Bestaat er een afdeling, liefst eentje die nog geautomatiseerd kan worden, die tot taak heeft om de frontoffice met de backoffice met elkaar samen te laten werken? Of is zo'n nieuwerwetse term op de keper beschouwd toch weer baarlijke IT-

Flauwekul?

Een klein onderzoekje is meteen ontluisterend. Er is op internet geen definitie van het begrip midoffice te vinden. Zelfs Bayens en Lankhorst wagen zich in “De Midoffice ontrafeld” (http://www.via-nova-architectura.org/artikelen/tijdschrift/de-midoffice-ontrafeld.html, 2008) niet aan een definitie. Dan maar wat dieper gegraven.

De aloude Webster Dictionary definieert in de online versie de term backoffice als “of or relating to the inner workings of a business or institution”. Frontoffice wordt gedefinieerd als “the policy-making officials of an organization”. Sic.U leest het goed. De enige echte front-office wordt volgens deze definitie gevormd door de beleidsmakers.

Gelukkig geeft de Business Dictionary een heel andere interpretatie. De frontoffice is “Marketing, sales, and service departments that come in direct contact with the customers, and liaise with the back-office (administrative) departments to maintain a two-way flow of information”. Techweb maar eens geraadpleegd. “front office refers to systems that deal directly with the customer such as order processing” en “back office refers to systems that do not deal directly with the customer”. Gelukkig maar. Webster is gewoon niet helemaal bij de tijd. Dus kunnen we veilig uitgaan van de conceptie dat de front-office klantgericht is, en de back-office intern-gericht.

Maar hoe zit het dan met de midoffice? Die komt zelfs in de TechEncyclopedia (met meer dan 20.000 IT termen) niet voor. Volgens het programmabureau elektronische gemeenten EGEM gaat het bij de midoffice om de systemen die de frontoffice systemen en de backoffice systemen aan elkaar knopen:

“Het mid office als architectuurconcept bevindt zich tussen het front- en back office. Het front office vormt de presentatielaag van een organisatie naar de buitenwereld; alle interactie daarmee speelt zich af in het front office. In het front office worden verschillende kanalen onderscheiden, zoals een callcenter, website en balie. Het back office daarentegen vormt het hart van de organisatie waar zich onzichtbaar voor de buitenwereld de primaire (gegevensverwerkende) processen afspelen. Het mid office fungeert daarbij als koppelvlak voor de verschillende front- en back office systemen.” (uit: Marktverkenning mid office systemen, 26 november 2004).

Bayens en Lankhorst gaan in hun enthousiasme nog een stap verder. Zij zien naast een ESB ook het BPM-systeem en een Operational Datastore (ODS) als onderdeel van een midoffice. En dat is dan nog maar de dunne variant. Want de “dikke midoffice” bevat ook nog een CRM-systeem, een Document Management Systeem en een Workflow Management Systeem. Een “totaal-bouwdoos” voor een “moderne SOA”. Slik.

Hier maken de auteurs naar mijn idee toch echt een denkfout. Omdat een workflowsysteem een workflowmodel kan executeren is het workflowsysteem zelf nog geen applicatie geworden – althans geen gebruikersapplicatie. Dat is op z'n best het workflowmodel zelf. En die zit normaal gesproken niet in een suite van een leverancier. Die moet tenslotte op de specifieke omstandigheden van de organisatie afgestemd worden. Zoals het in bepaalde architectuurkringen wel heet: “Today there are two things in life you cannot buy: love and an SOA”. Met ander woorden: de leverancier van een workflow-managementsysteem levert technologie – geen architectuur en geen gebruikersapplicatie. Dat een workflowmodel misschien niet in een derde-generatie computertaal is geschreven, maar op een alternatieve manier is gecodeerd, betekent op zichzelf nog niet dat zo'n workflow-engine niet gewoon een interpreter zou zijn. Niet veel anders als een webserver die PHP kan interpreteren.

Wat een midofficesysteem heet te zijn, zit feitelijk helemaal niet “tussen” de klantgerichte en de interne, administratieve systemen in – zoals de naam suggereert. Het is in mijn ogen technologie die beide soorten systemen faciliteert. Het zit er als het ware onder. De in Amerika gangbare term 'SOA platform' met 'enterprise services' is dan ook veel logischer. Inderdaad, het klopt dat zo'n 'SOA platform' functioneel steeds rijker wordt. Eerst werd het platform verrijkt met zaken als “middleware”, applicatieservers en met database management systemen en nu zijn we zo ver dat we een platform hebben met een rules engine, een document management systeem, een orchestratieservice. The rich get richer. Zo gaat dat nou eenmaal. Maar een platform blijft een platform.

Dat we het platform of de enterprise services in architectuurplaatjes graag in een tussenlaag platslaan, omdat dat nou eenmaal makkelijker tekent, soit. Dat het daarbij op de keper beschouwd niet zo zeer gaat om de enterprise services, maar de “scripts” die daarop worden uitgevoerd, dat wil ik ook nog wel voor lief nemen. Maar laten we toch alsjeblieft stoppen met voor die laag de verwarrende kreet 'midoffice' te gebruiken.

Er speelt nog iets anders. In enterprise SOA-plaatjes wordt de informatieruimte – met een knipoog naar het “3-tier model” uit de software architectuur – vaak opgedeeld in drie lagen:

• een applicatielaag – de gebruikers-georiënteerde onderdelen (de “presentation tier”)

• een services cloud – de gegevensverwerkende en beslissingsondersteunende onderdelen (waarin de “application tier” en de “data tier” tegenwoordig broederlijk opgaan)

• een lijmlaag – de integratiecomponenten, inclusief de 'command and control' onderdelen

In dit verband worden ook wel de termen frontofficesystemen en backofficesystemen gehanteerd (veelal 'gemakshalve' afgekort tot 'frontoffice' en 'backoffice'). Systemen met een gebruikerinteractie zijn frontofficesystemen en services zonder gebruikerinteractie zijn backofficesystemen. Een volstrekt begrijpelijke terminologie – de “gebruiker” van een applicatie neemt in het denken de plaats in van de “klant” van een organisatie. En ik wil ook nog best wel toegeven dat de term midofficesysteem in díe context prima op z'n plaats kan zijn.

Toch blijft het risico op verwarring onverminderd groot. Een gebruiker die in de backoffice werkt, gebruikt per definitie een frontofficesysteem om toegang te krijgen tot de backofficesystemen. Daar moet je IT-er voor zijn om dat te kunnen begrijpen. En in enterprise architectuurmodellen betekent de term “backoffice” in de organisatieview dan iets totaal anders dan in de “softwareview”. Verwarrende terminologie, daar hebben we wat mij betreft al meer dan genoeg van.

Misschien is deze discussie wel een goede aanleiding om een terminologie te ontwikkelen die nog niet belast is. Wie durft een suggestie te doen? Ter inspiratie: ik houd het voor mezelf tot nader order op de Podiumzone (populair: de P-Zone), de Atriumzone (A-zone) en de Origozone (O-Zone). Maar ik sta natuurlijk absoluut open voor betere suggesties.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 5^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

Lerende architecten

Architecten zijn vaak betrokken bij innovatie en vernieuwing. Er ontstaat ergens in de organisatie een idee, dit moet op allerlei manieren onderzocht worden, en alleen als het een vruchtbaar idee lijkt, tot een oplossing gebracht worden. En als het aan de architecten ligt, dan moet de oplossing natuurlijk onder architectuur gerealiseerd worden. Over wat dit precies behelst verschillen de lezingen echter.

De kwestie

Don Tapscott heeft in zijn visionaire boek “the Paradigm Shift” al in 1993 een werkmodel geschetst voor werken onder architectuur. Het bestaat uit vier stappen, te weten:

1. Reimage – het ontwikkelen van een visie

2. Restructure – het structureren van een oplossing

3. Realize – het ontwikkelen en in gebruik nemen

4. Renew – een continue verbetering

Het zal u misschien opvallen dat Tapscott zich hierbij heeft laten inspireren door de bekende Deming-cyclus (“plan-do-check-act”). Er zijn in elk geval ook vier fasen en het is beide gericht op een lerende organisatie.

In 2001 kwam Sogeti onder het kopje DYA – Dynamische Architectuur – met een eigen model. Dit bestaat uit drie stappen, te weten:

1. De Strategische Dialoog – het bepalen van de business doelen

2. Architectuur Services - het opstellen en bewaken van de architectuur

3. Ontwikkelen (z)onder architectuur – het realiseren van de business doelstellingen

De parallel tussen deze twee modellen is op zich opvallend. De strategische dialoog is bedoeld om een gemeenschappelijke visie te ontwikkelen. Architectuur Services geven structuur en kader aan de oplossingen. En de daadwerkelijke realisatie wordt onder architectuur gebracht als de rol van de architecten niet beperkt is tot het beschrijven van de architectuur. Tegelijkertijd is het kenmerkende verschil in het achterliggende denkmodel opmerkelijk. Waar Tapscott veel waarde hecht aan het leren van fouten in en het continue verbeteren van eenmaal gerealiseerde oplossingen, ontbreekt dit in het DYA denkmodel volledig. Als de oplossing gerealiseerd is, dan hebben de Dynamische Architecten hun taak naar behoren vervuld.

Gemiste kans

Het verschil tussen de modellen is wellicht te verklaren uit het feit dat Sogeti, de organisatie achter het DYA-model, een leverancier is, die het moet hebben van het uitvoeren van projectgebonden activiteiten, en betrekkelijk lastig geld kan verdienen aan de structurele activiteiten die voor continue vernieuwing nodig zijn. Het structureel analyseren en verbeteren van het bestaande applicatieportfolio is immers eerder iets voor de gecommitteerde 'insiders' binnen een bedrijf, dan voor tijdelijke 'inhuurkrachten' van buiten. Maar daarom hoeft de architectuurcommunity zich nog niet bij deze omissie neer te leggen. Er werken tenslotte ook tal van gerenommeerde architecten als 'insider' bij bedrijven en instellingen. Is continue vernieuwing een relevante activiteit voor architecten? Zou het in het architectuurproces een plaats moeten krijgen? Zo ja, hoe geeft je dat dan vorm? Of zouden alle architecten zich uit hoofde van hun functie moeten concentreren op projecten met een afgebakend doel en een beperkte looptijd?

Als het leren van de gemaakte keuzes een doel is – en waarom zouden architecten niet van praktijkervaringen kunnen leren – dan ligt het in elk geval erg voor de hand dat er na het opleveren structureel een serieuze analyse wordt gedaan van de goede en mindere aspecten van de architectuur. In hoeverre was de project-start-architectuur doelmatig? Was hij correct, volledig en niet voor misverstanden vatbaar? De antwoorden op die vragen zijn ongetwijfeld leerzaam. Een end-of-project review lijkt dus een nuttig instrument om de architectuurfunctie te verbeteren. Maar is het voldoende?

Vanuit een business perspectief is de belangrijkste vraag waarschijnlijk of de gekozen architectuur adequaat is. Met andere woorden: is het op basis van de gekozen architectuur mogelijk gebleken om de business doelstellingen daadwerkelijk te realiseren. In de praktijk zal het niet vaak voorkomen dat deze vraag al aan het einde van een project beantwoord kan worden. Immers, na het invoeren van een nieuwe IT-oplossing verloopt er doorgaans de nodige tijd voordat de business doelstelling daadwerkelijk en volledig is gerealiseerd – al was het maar omdat de impact op de organisatie (waaronder de beheerorganisatie) nog moet blijken. Dat betekent ook dat er na verloop van tijd mogelijk nog belangrijke lessen te trekken zijn uit de praktijk van het levende systeem. Echter, alleen als architecten bereid en in staat zijn om een serieuze post-project review te doen, kan er van die – ongetwijfeld weerbarstige – praktijk daadwerkelijk geleerd worden.

Maar zelfs in het geval dat de business doelstelling volledig is gerealiseerd, dan wil dat nog niet zeggen dat het denken hoeft op te houden. De wereld is continu aan het veranderen. De markt ontwikkelt in een hoog tempo en de technologische mogelijkheden nemen met de dag toe. Het kan, met andere woorden, niet zo veel kwaad om periodiek en structureel te evalueren of de bestaande oplossingen nog wel adequaat zijn in de huidige situatie. Het overleven van de concurrentiestrijd vereist een mate van fitheid die zonder een gezonde portie beweging domweg niet houdbaar is.

Natuurlijk is het niet eenvoudig om dit te organiseren. Veel architecten worden geleefd door de 'hartbeat' van projecten. En zeker in het geval van inhuur is de betrokkenheid van de architect bij de organisatie vaak van beperkte duur. Maar zolang de architectencommunity niet om te beginnen de ambitie uitspreekt om een lerende discipline te willen zijn, dan gaat het zeker niet lukken om oplossingen te vinden voor dat soort organisatorische problemen. Misschien zouden we eens een business architect moeten vragen hoe je zo'n nijpend probleem nou het best zou kunnen oplossen?

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

Requirements Optimization

Het rapport “Lessen uit ICT-projecten bij de overheid; Deel B” schetst een vrij mild beeld van de IT-debacles die de afgelopen jaren bij de Nederlandse overheid zijn gepasseerd. Dat kon ook bijna niet anders, want er bleken geen betrouwbare gegevens beschikbaar die scherpere conclusies zouden kunnen onderbouwen. De belangrijkste conclusies gaan noodgedwongen over het verzamelen van “betrouwbare gegevens over tijd, omvang, beschikbare mensen en kosten” op basis van “definities over kostensoorten en begin- en eindpunt van projecten”.

De Kwestie

Deel A was nog zo veelbelovend begonnen. Een scherpe analyse: “ICT-projecten van de overheid [worden] vaak te ambitieus en te complex [...] door de combinatie van politieke, organisatorische en technische factoren. Bij deze te complexe projecten is er geen balans tussen ambitie, beschikbare mensen, middelen en tijd”. Politici, ambtenaren en leveranciers blijken vanuit geheel verschillende belangen allemaal aan te sturen op het vergroten van de omvang en (dus) het verhogen van de complexiteit van projecten. Er is geen of weinig ruimte voor concessies aan het ambitieniveau – alles moet vanaf het eerste begin in alle gevallen volledig correct, volledig betrouwbaar en volledig geautomatiseerd verlopen.

Deze requirements frenzy is heel herkenbaar. Ook in het bedrijfsleven komt het niet zelden voor dat het resultaat van een requirementsstudie een eenvoudige optelsom van alle eisen en wensen van alle stakeholders beschrijft – met enig geluk zijn de meest opzichtige tegenstijdigheden er nog uitgehaald. Opdrachtgevers lijken te redeneren dat als je op voorhand al concessies aan het eisenpakket doet, de leverancier zijn best niet gaat doen om een zo goed mogelijke oplossing te realiseren. De leverancier heeft op zijn beurt geen enkele baat bij het versimpelen van de opdracht. Immers, hoe meer functiepunten en hoe meer technologische vernieuwing, hoe hoger het omzetpotentieel.

Het is niet moeilijk om in te zien dat beide redeneringen kortzichtig zijn. Projectrisico's nemen meer dan evenredig toe als het aantal en de complexiteit van requirements toenemen. Hogere projectrisico's vertalen zich onvermijdelijk in langere doorlooptijden, hogere kosten en grotere afbreukrisico's. Planningen van grote, complexe projecten hebben van nature een hoog speculatief gehalte. Dus, als opdrachtgever en leverancier het succes van een project zouden willen bevorderen, dan zouden ze tegen-intuïtief moeten handelen, door actief de complexiteit van het project maximaal terug te managen.

Helaas is matigheid een deugd die in moderne projectorganisaties nauwelijks wordt gewaardeerd. Kleine, simpele oplossingen met een hoge impactfactor, leveren nauwelijks interessante financiële of reputationele prikkels op. Het is jammer dat de rekenkamer daar niet op heeft gewezen. Het stelselmatig belonen van ongewenst gedrag – zowel van bestuurders, ambtenaren als leveranciers – is tenslotte een belangrijke bron van geldverspilling. Een beloningssysteem dat meer rekening zou houden met “value for money” zou dan ook een voordehand liggend advies zijn geweest.

De rol van de archITect

ArchITecten hebben iets met Requirements. Requirements zijn de belangrijkste grondstof voor architectuurproducten. Dat zie je bijvoorbeeld ook terugkomen in TOGAF, waar Requirements Management het centrale proces in de Architecture Development Method (ADM) is. In de woorden van the OpenGroup: “the ADM is continuously driven by the requirements management process”.

Het cruciale woord in deze definitie is “continuously”. Het is zaak dat gedurende het ontwerpproces de ambities continue op de haalbaarheid worden afgestemd. In de loop van het traject ontstaan nieuwe inzichten, waardoor de onzekerheid afneemt en er scherper gekozen kan worden tussen functionaliteit, kwaliteit, kosten en duur van het project.

Het is een verspilling van energie (dus tijd en geld) om aan het begin van zo'n traject een omvangrijke requirementsstudie te doen en op basis daarvan de specialisten aan het werk te zetten. Het werkt veel beter om in een verkennende fase op basis van een beperkte set aan globale requirements een archITect te vragen een aantal alternatieve oplossingsscenario's te schetsen. Zulke schetsen zijn namelijk prima hulpmiddelen om requirements aan te scherpen en om gerichte haalbaarheidsonderzoeken te doen. Zo'n haalbaarheidsonderzoek kan prima in de vorm van een bescheiden project uitgevoerd worden en is een uitstekend hulpmiddel om onzekerheden te elimineren en risico's te reduceren.

Architecten kunnen in de loop van het proces een waardevolle rol spelen bij het helder formuleren en het valideren van requirements. Requirements krijgen op deze manier de kans om geleidelijk, in balans met het ontwerp van de gewenste oplossing, te evolueren. Ze zijn niet langer een bron van conflict, maar een mechanisme voor wederzijdse afstemming. En daar is iedereen bij gebaat.

Requirements Optimization zou een goede term kunnen zijn om een dergelijke werkwijze te beschrijven. Risico's minimaliseren door requirements te optimaliseren. Zo krijg je een maximaal resultaat tegen minimale kosten. En dat is niet alleen voor ministers interessant!

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 8^ste in een reeks die op dit weblog gepubliceerd zal worden.

Kies je kleur

Kleurenleer

Een aantal jaren geleden bleek uit een beknopt en alles behalve representatief onderzoekje dat er in de praktijk minstens vijf verschillende rolmodellen voor succesvolle archITecten bestaan.

• De constructieve architect: denkt vanuit oplossingen, focust op technologie, gericht op structuur

• De directieve architect: neemt verantwoordelijkheid namens opdrachtgever, zijn wil is wet, gericht op resultaat

• De coachende architect: concentreert zich meer op het groepsproces dan het eindresultaat, hij faciliteert, gericht op leren

• De creatieve architect: stelt uiterlijke schoonheid boven effectiviteit, hij provoceert, gericht op beleving

• De visionaire architect: weigert de huidige praktijk en technologie als beperking te accepteren, hij inspireert, gericht op innovatie

In diezelfde tijd maakte Leon de Caluwe school met zijn kleurentheorie. Hij hanteert een palet van vijf kleuren als evenzovele stijlen voor het aanpakken van veranderingsprocessen.

• Blauwdrukdenken is een planmatige, deterministische manier van veranderingen aanpakken. Projectmatig en methodisch werken zijn typische instrumenten. Principes worden tot stuurinstrument verheven.
• Geeldrukdenken is gebaseerd op machtsdenken – een commandostructuur en directieven zijn kenmerkend – 'Guerilla tactieken' zijn een geaccepteerde praktijk.
• Groendrukdenken stelt de lerende organisatie centraal. Het fenomeen ‘coaching’ is karakteristiek. Reviews en assessments zijn populaire middelen.
• Rooddrukdenken gaat om het verleiden en stimuleren van mensen. Het bewust creëren van voorwaarden en kansen is kern van de benadering. Empowerment is een doel op zich.
• Witdrukdenken vindt zijn oorsprong in de chaostheorie: een nieuwe orde ontstaat spontaan – maar inherent onvoorspelbaar – door het bestaande evenwicht bewust te verstoren. Buiten de bestaande kaders treden wordt tot kunst verheven. Inspiratie staat centraal.

Merk op dat deze theorie – die na uitgebreid wetenschappelijk onderzoek tot stand is gekomen – een frappante overeenkomst vertoont met de classificatie van architecten. Indirect zou je dit kunnen zien als een onderbouwing voor de eerdere vijfdeling.

Om over te peinzen

De vijf verschillende soorten architecten zijn niet voor niets als “rolmodellen” getypeerd. Het zijn archetypen van architecten die in de praktijk effectief zijn gebleken. Ze vertonen een voorbeeldgedrag waarvan andere architecten iets zouden kunnen leren.

Architecten realiseren zich als geen ander dat het gedrag van een systeem goed afgestemd moet zijn op de omgeving van het systeem. Dat geldt in dit geval natuurlijk ook. Niet ieder gedrag is in iedere omgeving even effectief. Het is dan ook raadzaam om de omgevingsfactoren goed in kaart te brengen, en het gedrag daarop af te stemmen.

Architecten hebben van nature een bepaalde stijl van werken. In termen van de Caluwé heeft iedereen een bepaald kleurpatroon in zich. Sommigen zullen zichzelf bijvoorbeeld herkennen als overwegend rood, wit of blauw. Je kunt op internet ook een digitale zelftest doen. Hiermee kun je vaststellen of je zelfbeeld klopt.

Nou is het best mogelijk om je natuurlijk gedrag een beetje bij te kleuren. Zeker als je je heel goed bewust bent van het verschil tussen het voor de omgeving meest effectieve gedrag en je natuurlijke gedrag, dan kun je heel gericht werken aan het vergroten van je effectiviteit. Het schijnt zelfs zo te zijn dat als je voldoende positieve feed-back krijgt op je gedragsverandering, dat dit uiteindelijk wordt geinternaliseerd. Je natuurlijke gedrag kun je op die manier veranderen. Werkt dat echt zo? Je kunt dit in principe met behulp van de digitale zelftest eenvoudig zelf controleren. Vul de test maar eens in met de antwoorden die je tien jaar geleden zou hebben gegeven...!

Niet alle kleurverschillen laten zich even gemakkelijk overbruggen, laat daar ook geen misverstand over bestaan. Soms moet je als professionele architect tot de jammerlijke maar onvermijdelijke conclusie komen dat je in een bepaalde omgeving op dat moment gewoon niet past. Dat is altijd nog beter dan je volkomen onbewust van de mismatch tussen jouw en je omgeving voort te modderen; ofwel gefrustreerd raken omdat het maar niet lukt om je omgeving aan te passen aan jouw gedrag.

Als het je gaat om het vergroten van je effectiviteit in de rol van archITect, dan kan het zoeken van een omgeving die beter past bij je eigen kleur dus net zo goed een slimme strategie zijn als het aanpassen van je gedrag aan de kleur van de omgeving. Het is maar dat je het weet.

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 6^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

Kill your managers

In de software architectuur laait van tijd tot tijd het debat op over de wenselijkheid van gecentraliseerde sturing van processen en het gevaar van “control objects” en “managing services”. De kracht van oplossingen als DNS en UDDI ligt juist in het ontbreken van een centrale regelmeester. De laatste tijd lijkt in enterprise architecturen de balans juist weer wat door te slaan naar meer en strakkere controle op de uitvoering van processen. De op allerlei terreinen aangescherpte regelgeving zal daar mede debet aan zijn. Meer controle wordt door architecten haast vanzelfsprekend vertaald in centrale componenten in de architectuur die als een spin in het web alles monitoren en niet zelden ook ongewenst gedrag uitfilteren. Service georiënteerde architecturen zijn in zeker zin een moderne poging om op enterprise niveau meer grip te krijgen op proces- en informatieflow.

De controleparadox

In het verleden zijn er verschillende technieken ingezet om een controlefunctie in de enterprise architectuur te engineeren. Een “integration broker” is feitelijk een centrale hub die het mogelijk maakt om controle uit te oefenen op het verloop van het berichtenverkeer tussen applicaties. Een workflow managementsysteem is een toepassing die een complex werkproces opdeelt in een stroom van taken die aan medewerkers worden toebedeeld. Het is niet zo moeilijk in te zien dat workflow management vereist dat er ook een informatiestroom tussen de medewerkers is. Binnen een systeem is dit geen al te prangend issue, maar zodra medewerkers verschillende systemen gebruiken om hun taken uit te voeren – en in het bijzonder als de medewerkers voor verschillende organisaties werken – is dit niet per definitie triviaal. De ervaringen met technieken als integration brokers en workflow management systemen zijn opmerkelijk gelijksoortig: het werkt heel aardig voor de eenvoudige, voorspelbare, sterk gestandaardiseerde processen; maar zodra het wat minder eenvoudig wordt, dan worden de beperkingen al heel snel tamelijk knellend. Er is een single point of control – met alle nadelen vandien – dat zich doorgaans uiterst rigide gedraagt. De gebruikers zien zich dan al gauw gedwongen om buiten het systeem om wegen te vinden om gewoon hun werk te doen. En met het oprukken van informatietechnologie in steeds complexere processen vraagt dit om een slimmere benadering.

Sommige organisaties realiseren zich dit terdege. Er is nog geen consensus over de vraag hoe dit probleem te tackelen. Industrialisten zijn geneigd om de producten en de processen zo te ontwerpen dan de variatie minimaal is en de verwerking mede daardoor tot in de kleinste details voorspelbaar wordt. De huidige six sigma golf zal niet vreemd zijn aan de populariteit van deze benadering. Anderen stellen juist dat je je met je procesmodel zou moeten richten op die 80% van de gevallen die je gemakkelijk kunt “vangen”. De uitzonderingen zouden dan gewoon moeten “uitvallen” en als handwerk afgehandeld moeten blijven worden.

Het grappige is dat het juist voor die zaken die niet zijn voorzien, of in elk geval niet passen in een standaard verwerking, controle op de uitvoering op z'n plaats is. Ga maar na. Vanuit het oogpunt van risico management moeten er controlemechanismen worden ontwikkeld die waarborgen dat er altijd inzicht is in de huidige staat van de risico's en die het verhinderen dat er onbezonnen risico's worden genomen. “Societé Generale” en “Barclays” dienen als afschrikwekkend voorbeeld van wat er mis kan gaan als deze mechanismen falen. Vanuit het oogpunt van compliancy moeten er corporate governance mechanismen ontwikkeld worden die de betrouwbaarheid van de informatievoorziening van het bedrijf moeten garanderen. De namen “Enron”, “Worldcom” en “US Food Service” zijn onlosmakelijk verbonden met even zovele boekhoudschandalen. In alle gevallen waren de betrokkenen betrekkelijk eenvoudig in staat om de bekende procedures te omzeilen. Je zou je kunnen afvragen of de wedloop tussen de controleurs en de overtreders met gecentraliseerde controlemechanismes wel te winnen valt. Is het in de praktijk niet zo dat met name goedwillenden er last van hebben en kwaadwillenden er vaak al te gemakkelijk omheen blijken te kunnen? En wie controleert eigenlijk de controleurs?

De uitweg uit de paradox

“Kill your Managers” is een bekend architectuurpatroon dat mogelijk kan helpen bij het vinden van een uitweg uit het dilemma. Het is onder de naam “Blackboard pattern” al 1996 beschreven door Frank Buschmann et al in “A System of Patterns”. Het komt er in de kern op neer dat je ervoor moet zorgen dat relevante informatie die in het proces ontstaat altijd op een geeigende plek wordt gepubliceerd. Vervolgens moet je erover nadenken wie er op welk moment toegang behoort te hebben tot die informatie. Tenslotte kun je in een apart proces deze informatie verwerken. Die verwerking kan een mix van geautomatiseerde en handmatige controles zijn. Daarbij is het goed voorstelbaar dat de controles niet altijd voorspelbaar hoeven te zijn. Het onvoorspelbare karakter van controles maakt het voor kwaadwillenden immers een stuk lastiger om ze te omzeilen. Inderdaad: het inbouwen van een zekere mate van onzekerheid in het proces maakt de effectiviteit van de controle sterker en juist niet zwakker. En voor het hoofdproces is het een verademing dat goedwillende medewerkers niet meer te pas en te onpas lastig gevallen worden door managers die zich zonder al te veel kennis van zaken met de uitvoering willen bemoeien.

“Kill your Managers” is een architectuurpatroon dat nog niet zo vaak wordt toegepast bij het ontwerpen van complexe processen. Dat is jammer. Het is een effectieve manier om de concerns “uitvoering” en “controle op de uitvoering” te scheiden. Het is bovendien uitermate schaalbaar en flexibel. Misschien wordt het alleen nog niet altijd goed begrepen wat de kracht van dit patroon is. Zie het als “op het proces zitten” in plaats van “in het proces”. Een goede manager zit niet “ín”, maar “óp” het proces. Dat kan iedereen toch begrijpen?

Het is niet altijd helemaal te voorkomen om een manager in enigerlei vorm in een architectuur op te nemen. Er kunnen hele goede redenen zijn om bepaalde zekerheden af te dwingen. Een access control manager is een typisch voorbeeld. In die gevallen werkt een asynchrone controle nou eenmaal niet. Het principe “kill your managers” moet dus niet al te dogmatisch toegepast worden. Maar onthoud dat als je architectuur echt niet zonder een manager kan, dat dan het tweede deel van de hoofdregel in werking gaat, namelijk: “if you definitely need your manager, be sure to keep him as stupid as possible”. Want niets is zo vervelend als een manager die slimmer probeert te zijn dan zijn medewerkers.

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 4^de in een reeks 'uncommon sense' die op dit weblog gepubliceerd zal worden.

Scheiding der machten

De cartoonist Gregorius Nekschot heeft zich – bedoeld of onbedoeld – in het middelpunt van de discussie over vrijheid van meningsuiting gemanoeuvreerd. Hij is met veel bombarie opgepakt door de politie en heeft anderhalve dag in voorarrest gezeten vanwege zijn cartoons. Er wordt alom schande gesproken over deze behandeling, die ook inderdaad wel wat onevenwichtig overkomt. Voorlopig werkt de hele actie van het OM vooral – en waarschijnlijk onbedoeld – als een enorme publiciteitsstunt voor het werk van Nekschot.

De Kwestie

Het is bepaald niet de eerste keer dat traditionele burgerlijke vrijheden – zoals de vrijheid van drukpers – in het licht van internet ter discussie worden gesteld. Het is decennialang onomstreden geweest dat iedereen alles moest kunnen publiceren wat hij wilde. Maar dat was vroeger, toen alleen nog een betrekkelijk overzichtelijke elite van politici, kunstenaars en opiniemakers toegang had tot de media. Vandaag de dag vergt het nauwelijks investeringen om je eigen columns, cartoons, songs of filmpjes op internet te publiceren. En dankzij sociale netwerksites is een virale marketingcampagne ook al geen raketwetenschap. De ultieme democratisering van de media lijkt een feit.

Deze ontwikkelingen hebben er tevens toe geleid dat de publicist zijn eigen uitgever is geworden. En dat is niet alleen iets waar we met z’n allen aan moeten wennen – de politici voorop – het is ook iets dat tot nadenken zou moeten stemmen. Een uitgever is in zeker zin kwetsbaar. Hij kan niet zomaar alles uitgeven. Een uitgever is onderworpen aan de wetten van de markt. Hij moet immers geld verdienen aan zijn uitgaven en moet op z’n minst aan zijn goede naam denken. Het is daarom impliciet een traditionele functie van een uitgever om zaken als fatsoen en de goede smaak te bewaken. Dit heeft in het verleden aanleiding gegeven tot tal van conflicten tussen publicisten en uitgevers – zowel bij omroepen als bij uitgevers. Pas nu blijkt dat dit spanningveld feitelijk een pijler was onder de burgerlijke vrijheden.

Spanningsvelden zijn nuttig. Sinds Montesquieu de Trias Politica heeft verkondigd – de scheiding van wetgevende, uitvoerende en rechtsprekende macht – weten we dat eigenlijk al. Het is ons met de paplepel ingegoten. De spanning tussen de machten levert een heleboel stress op, het is inefficiënt en niet te besturen, maar tot nu toe hebben we domweg nog geen beter politiek/maatschappelijk systeem kunnen bedenken. Kennelijk gaan efficiënt en effectief niet altijd samen. Denk maar eens aan het proces van de evolutie: tijdrovend en verspillend, maar het leidt wel tot ontwikkeling.

De rol van de architect

De triade wetgevende, uitvoerende en rechtsprekende macht zien we in volwassen IT-projectorganisaties – die hebben nagedacht over ontwikkelen onder architectuur – eigenlijk altijd wel op de één of andere manier terug. Het ligt voor de hand om de opdrachtgever als de wetgever te zien, een projectmanager als de uitvoerder en wie anders dan de enterprise architect in de rol van rechter (dit hoeft overigens niet de enige rol te zijn die een enterprise architect bekleedt). Dat zou een gezond spanningsveld moeten opleveren, waarbij we natuurlijk wel moeten bedenken dat een rechter te allen tijde gebonden is aan het uitvoeren van wetten en regels die door de wetgever vastgelegd zijn. Dat zou dan ook moeten betekenen dat zaken als architectuurprincipes, bestemmingsplannen, enterprise architecturen en technologiebeleid pas opgelegd mogen worden als ze door de geëigende bestuursorganen bekrachtigd zijn.

En de project-architect? Een project-architect is primair adviseur, van de project manager, de opdrachtgever en de enterprise architect. Dit is misschien op papier geen al te machtige positie, maar in de praktijk is het – als het goed is – uitermate invloedrijk. Juist omdat een project-architect zelf geen stakeholder is, zijn enige concern is immers het creëren van zo veel mogelijk draagvlak onder de stakeholders, kan hij als geen ander bemiddelen tussen partijen en langs die weg tot evenwichtige oplossingen te komen. Daarbij is het de kunst om vage compromissen te vermijden, maar juist aan te sturen op creatieve win-win situaties. En dat hij in zo'n creatieve oplossing “iets van zichzelf” mee ontwerpt, wordt over het algemeen juist erg op prijs gesteld.

En hoe het nu verder moet met de burgerlijke vrijheden en het internet? Daar is vast het laatste nog niet over gezegd. Maar het lijkt wel vast te staan dat er een herwaardering gaat komen voor de stille kracht op de achtergrond. Want de efficiëntie van vele rollen in één hand leidt slechts zelden tot echt effectieve processen.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 7de in een reeks die op dit weblog gepubliceerd zal worden.

Gartner voorspelt melt-down Microsoft

Hè hè, het wordt nu eindelijk erkend. Windows is uit z'n krachten gegroeid. Gartner zegt het zelf:

“Windows collapsing under its own weight; Radical change needed” (zie: http://blogs.zdnet.com/BTL/?p=8428). Dat laat tenminste niets aan duidelijkheid te wensen over.

Common Sense?

Windows Vista is berucht om z'n geheugenhonger. Het is niet ongebruikelijk dat er na het vers opstarten van een machine, zonder dat er nog één applicatie is gestart, al in de buurt van 1GB aan geheugen in gebruik is. Er zijn dan ook al tientallen processen gestart, waarvan alleen de overhead van het context switchen vaak al zo'n 10% van de beschikbare processorcapaciteit vergt. Voor niets!

Windows is niet slim ontworpen – dat staat nu wel vast. Dat valt niet zozeer aan de software engineers van Microsoft te wijten, het is eerder een indicatie van het onvermogen van het vakgebied om technieken te ontwikkelen om slim met het potentiële vermogen van computers om te gaan. Vergelijk het eens met een biologisch systeem. Er zullen toch maar weinig mensen zijn die durven te stellen dat een PC met Windows Vista slimmer is dan de slimste mens. Toch?

Het complete menselijk genoom bevat zo'n 3 miljard baseparen (volgens de laatste wetenschappelijke inzichten om precies te zijn 2,86 gigabasen; zie: http://www.strategicgenomics.com/Genome/index.htm). Omdat één base – A, C, T of G – in twee bits uit te drukken is, kunnen er 4 baseparen in één byte. Het menselijk genoom kun je dus in 750 miljoen bytes opslaan. Een snelle rekensom leert dat dit ongeveer 715 Megabytes is. Sta daar eens even bij stil. De genetische code van een mens is kleiner dan de code van Windows Vista. Dan moet er in Windows toch iets een beetje suboptimaal zijn...

Windows Vista bevat onmiskenbaar een grote hoeveelheid legacy code – code die eigenlijk niet meer wordt gebruikt, maar nog wel aanwezig is. Genetici noemen dat junk-DNA. De schattingen lopen een beetje uiteen, maar van zo'n 80-90% van het DNA is in elk geval geen functie bekend. En van het overgebleven is natuurlijk nog maar een klein gedeelte dat voor intelligentie in de hersenen en de waarneming van de zintuigen codeert. Hoe simpel kan intelligentie zijn?

Er zijn op dit moment zo'n 30.000 genen bekend. Genen bestaan uit exons en introns. Exons coderen voor eiwitten, en zijn dus functioneel, introns worden uit het m-RNA verwijderd voordat het eiwit wordt gevormd. De totale hoeveelheid exons staat voor slecht 10MB aan code.

Nog een statistisch gegeven. Het menselijke brein bestaat uit ongeveer 1 miljard neuronen, elk met gemiddeld 10.000 synapsen. Het is niet onredelijk om te veronderstellen dat een synaps minstens één bit aan informatie bevat. Dit maakt samen 1,2 Terabyte; aardig vergelijkbaar met de opslagcapaciteit van een moderne PC. We noemen het allebei 'geheugen'. De verschillen in gebruik zijn echter groot.

Microsoft denkt traditioneel problemen op te kunnen lossen door meer functionaliteit toe te voegen, beter te testen en nog meer mensen bij de ontwikkeling te betrekken om de complexiteit daarvan te kunnen beheersen. De schaalbaarheid van dit model blijkt nu fundamentele beperkingen te hebben.

De Paradox

Als computers ooit zo slim als mensen zouden moeten worden, of misschien wel slimmer, zouden we dan juist niet moeten streven naar een veel simpeler operating systeem en veel minder betrouwbaar geheugen? Zou je met dommere computers geen slimmere systemen kunnen bouwen?

De conventionele manier van ontwerpen schiet vroeger of later tekort om de volgende generatie van complexe systemen te ontwikkelen. Functionele decompositie – het opsplitsen van een complex probleem in een verzameling minder complexe problemen – heeft zo zijn beperkingen. Hoe logisch deze methode intuïtief ook lijkt, het resulteert keer op keer in onhanteerbaar complexe systemen zoals Windows en Office. Bij een bedrijf als Intel hebben ze dat misschien al eerder ingezien. Er is een grens aan hoe complex je een processorkern kunt maken. Niet voor niets zijn de architecten van Intel al jarenlang druk bezig met de ontwikkeling van multi-core processoren.

Er moet voor software ook dringend gezocht worden naar een betere ontwerpmethode traditionele. Er zijn fundamenteel andere architectuurprincipes nodig om de software engineering op een hoger plan te brengen. Het is natuurlijk niet voor het eerst dat er daarbij gezocht wordt naar inspiratie in de natuur. Het vakgebied van kunstmatige intelligentie heeft een respectabele traditie opgebouwd – en zeker ook enkele doorbraken bereikt. Het wordt tijd dat dit doordringt in de mainstream van de software engineering.

Het meest markante verschil tussen computers en intelligente dieren is het belang van opvoeden. Dieren hebben een ingebouwde basisintelligentie, maar zijn ook in staat om veel van hun intelligentie te verwerven in een sociale context. Het is bekend dat dieren die buiten zo'n sociale context opgroeien betrekkelijk hulpeloos door het leven gaan.

De ander kant van diezelfde medaille is dat – zoals iedere ouder weet – opvoeding niet altijd gegarandeerde resultaten heeft. Kinderen gedragen zich niet altijd zoals ouders zouden willen. Er zijn zowel evolutionaire als sociale mechanismes ontwikkeld om ongewenst gedrag te corrigeren. Daarbij gaat het belang van de groep altijd boven het belang van het individu.

Er is ook een groot voordeel in het experimenteren met onaangepast gedrag. Van tijd tot tijd is er een individu die grenzen weet te verleggen, die dingen doet die anderen nooit zouden hebben bedacht of gedurfd, maar die wel succesvol zijn. Grensverleggend gedrag dat de groep op een hoger ontwikkelingsniveau brengt. Dit soort doorbraken kun je niet verwachten als alle individuen alleen maar voorgeprogrammeerd gedrag vertonen.

Zouden de engineers van Microsoft hier iets van kunnen leren? Zouden echte intelligente systemen minder voorgeprogrammeerd moeten zijn, en meer kans moeten hebben om te evolueren? Zouden de architecten van Microsoft wat kunnen leren van de architectuurprincipes achter simulatiespellen zoals 'Evolution: The Game of Intelligent Life'? Zou het fundamenteel beter zijn om ongewenst gedrag te bestrijden, dan om het te voorkomen? Moet Microsoft meer sociologen in dienst gaan nemen?

De sleutel ligt mogelijk in zogenaamde emergente systeemeigenschappen die in grootschalige, gedistribueerde systemen kunnen 'verschijnen'. Die zijn lastig voorspelbaar, maar daarom niet minder krachtig. Zodra we als architecten leren te denken in vrijheidsgraden in plaats van voorspelbaarheid, dan openen zich mogelijkheden waarvan we nu alleen maar kunnen dromen. En het paradoxale is dat er dan 'vanzelf' dynamische, vitale oplossingen zullen ontstaan die intelligenter, functioneler en betrouwbaarder zijn dan de huidige, voorgeprogrammeerde systemen.

Vergezocht? Wie had in 2000 durven te voorspellen dat er een jaar later een simpel programmaatje zou verschijnen dat binnen een paar jaar de wereld zou veranderen? Een user-generated encyclopedie met jaarlijks honderden miljoenen unieke bezoekers (per april 2008 staat de stand op 684 miljoen); meer content dan welke traditionele bron dan ook, en net zo betrouwbaar als (maar actueler dan) de beste encyclopedie? De Wikipedia software is charmant eenvoudig en de totale operationele kosten bedragen niet meer dan $2 miljoen per jaar – $0,3 cent per unieke bezoeker. Als dat geen 'big bang for bucks' is...

Stel je nu een voor dat de Linux-community in staat zou zijn om het OS op te delen in simpele 'pagina's' - of – in biologische termen – 'cellen'. En stel je voor dat er een mechanisme zou zijn om clusters van zulke cellen te bundelen tot 'organen'. Stel dat er communities ontstaan die hun eigen unieke 'organisme' samenstellen op basis van zulke organen. 'Organismen' die 'opgevoed' worden door een netwerk van meer ervaren 'exemplaren'. 'Soorten' die concurreren op een open markt, waar verschillende soorten de verschillende 'ecologische niches' bezetten en alleen de meest succesvolle op termijn kunnen overleven. Het zou volgend jaar al zover kunnen zijn.

Misschien doet u er goed aan om tijdens de komende vakantie eens zo'n evolutie-simulatiespel mee te nemen. Wie weet levert het een Eureka moment op. En anders in elk geval een hoop fun.

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 3^de in een reeks uncommon sense die op dit weblog gepubliceerd zal worden.

Multifocale projecten

Een vergrootglas past bij een projectmanager, net zo goed als een architect graag de verrekijker hanteert. Waar een projectmanager zich concentreert op kortetermijn resultaten, laat de architect zich niet zelden afleiden door visioenen over toekomstige verten. Projecten worden ingericht om in een zo kort mogelijke tijd en tegen zo laag mogelijke kosten een zo goed mogelijk resultaat te halen. Architecten hebben moeite om zich in zo'n project te manifesteren.

Een typische projectmanager stelt aan het begin van het project een business case op, waarin het projectbudget, de planning en de beoogde resultaten worden vastgelegd. Tevens wordt een raming van de met behulp van de projectresultaten beoogde besparingen en/of extra inkomsten gemaakt. In veel gevallen wordt de prioriteit van een project mede bepaald op de geschatte terugverdientijd. Om een hoge prioriteit te krijgen is het dus zaak om de opbrengsten zo hoog mogelijk in te schatten en de kosten zo laag mogelijk in te schatten. Geheel zakelijk verantwoord.

Binnen het project wordt er vooral op gestuurd dat de kosten in de hand worden gehouden. In het gunstigste geval wordt de business case in de loop van het project bijgesteld als de geplande opleverdatum of de geraamde uitgaven overschreden dreigen te worden. Voortschrijdend inzicht ten aanzien van de opbrengsten, de business benefits, leidt daarentegen zelden of nooit tot een heroverweging van de business case. Projecten zijn er om zo efficiënt mogelijk projectresultaten te leveren.

Flauwekul!

De laserscherpe focus op het leveren van projectresultaten staat niet zelden op gespannen voet met de eigenlijke belangen van de opdrachtgever. Neem nou de HSL-zuid. Het projectteam dat verantwoordelijk was voor het aanleggen van het nieuwe spoor is al lang klaar. Toch rijdt er nog steeds geen trein. Hoe dat komt? Er is voor de HSL-zuid een nieuw beveiligingssysteem aangelegd. Dat betekent dat er alleen maar nieuwe treinstellen op kunnen rijden. Die zijn er nog niet. Iedereen wist – of kon weten – dat dit zou gaan gebeuren. Maar de ijzeren logica van projecten zorgde ervoor dat de verschillende project­managers dit probleem bewust buiten hun project hebben gehouden. Het was zo logisch geweest als de nieuwe spoorlijn niet alleen het nieuwe, maar ook het bestaande beveiligingssysteem zou bieden. Dat had het project ongetwijfeld complexer en duurder gemaakt, en het zou misschien wel een paar weken later opgeleverd zijn. Maar dan hadden er ook jaren eerder treinen kunnen rijden en zou het nieuwe spoor nog decennia flexibeler in te zetten zijn geweest. Zo zijn projecten in de praktijk wel vaker penny-wise and pound-foolish.

De oorzaak is een veelvoorkomende weeffout in projectorganisaties, namelijk dat projectmanagers hun decharge krijgen als de projectresultaten zijn opgeleverd. Dit leidt onvermijdelijk tot – vanuit het perspectief van de opdrachtgever – ongewenst gedrag. Het leidt er namelijk automatisch toe dat een projectmanager er alles aan gaat doen om te sturen op kosten en tijd – dat heeft hij namelijk in de hand – en heel gemakkelijk concessies doet aan de opbrengstkant van de balans. De traditionele verantwoordelijkheid van een projectmanager is bedrijfsmatig gezien fundamenteel fout. Hij is waarschijnlijk de enige manager in de organisatie die alleen verantwoordelijk is voor de uitgaven, en niet voor de inkomsten. Met andere woorden: de verantwoordelijkheden van een projectmanager zijn niet in balans.

Een projectmanager zou eigenlijk verantwoordelijk gesteld moeten worden voor het realiseren van zijn business case – niet alleen de uitgaven, maar ook de inkomsten. Dan zou hij een eerlijke afweging kunnen maken tussen investeringen en de rendementen. Een beetje meer investeren om veel meer rendement te halen zou dan net zulk logisch gedrag worden als het verwerpen van een kleine besparing als dat een een grote aanslag op het rendement zou doen.

De agenda voor de architect

Omdat architecten van nature een tegenwicht vormen tegen een al te sterke focus op de korte termijn, is hij ook een logische bondgenoot voor het compenseren van de bijziendheid van de traditionele projectmanager. Omgekeerd kan een projectmanager de architect genezen van zijn verziendheid. Samen hebben ze de multifocale blik die het belang van opdrachtgevers maximaal kan dienen.

Een multifocale blik zal echter ook ondersteund moeten worden door een multifocale methodiek. Prince2, de dominante methodiek voor het managen van projecten, biedt in principe meer dan voldoende aanknopingspunten om multifocaal te werken. Er hoeven slechts wat accenten verschoven te worden.

Prince2 werkt met fasen en stadia - “stages”. Iedere overgang leidt tot een rapportage aan de stuurgroep – bijvoorbeeld een “project brief” of een “end stage report”. Dit zijn ideale momenten om multifocaal te kijken naar de voortgang van het project, en op basis van zo'n multifocale blik het project bij te sturen. Feitelijk zou het neerkomen op een periodieke review van de business case; waarbij niet alleen de kostenkant, maar uitdrukkelijk ook de opbrengstenkant tussentijds wordt geëvalueerd. Zo'n multifocale rapportage zou door de projectmanager en de architect in gezamenlijkheid opgesteld moeten worden en voorzien moeten worden van een advies aan de stuurgroep over de te nemen acties. Dat zou nog eens een creatieve invulling zijn van 'onder architectuur ontwikkelen'.

Als deze praktijk ook na het opleveren van de traditionele projectresultaten consequent wordt doorgezet – in Prince2-termen tijdens een “post-project review”, dan zal ook het doelmatig inrichten van een nieuwe of gewijzigde werkomgeving op de projectagenda komen te staan. Met andere woorden: een project wordt dan ook beloond voor een soepele implementatie in de organisatie – en gestraft voor een moeizame implementatie.

Eigenlijk is het heel simpel. Als de business case voor een project uitgaat van het bereiken van structurele besparingen of nieuwe inkomsten, dan is het project pas geslaagd als deze zijn gerealiseerd – en het is pas mislukt als zeker is dat ze niet (meer) te realiseren zijn. Tot die tijd is het aan de stuurgroep om leiding te geven aan het veranderingsproces, en zijn de projectmanager en de architect waardevolle krachten om dat proces in goede banen te leiden.

Deze flauwekul bespreekt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 4^de in een reeks flauwekul die op dit weblog ontzenuwd zal worden.