de rol van de Architectuur bij IT Portfolio management

Vaak wordt het denken in IT Architecturen / 'Werken onder architectuur' gezien als hobby van puristen. De oorzaak hiervan ligt in de haast die men heeft bij het opleveren van oplossingen (Solutions). Maar het denken in 'Solutions' impliceert dat men slechts in actie komt als er problemen zijn die opgelost moeten worden. Dat is een tamelijk passieve en reactieve kijk op de rol van IT.

Gaat men echter uit van de toegevoegde waarde die IT aan de organisatie kan en wil leveren, dan ontkomt men niet aan het maken van blauwdrukken die voor langere termijn bruikbaar zijn. Deze blauwdrukken worden vastgelegd en onderhouden in de Architectuur beschrijvingen.

Gaan we weer uit van de Architectuur Matrix, dan bevindt de IT Services Portfolio zich op het snijvlak van de Business en de IT in de alledaagse werkelijkheid.

Het overgrote deel van de communicatie tussen de Business en IT gaat over de performance van de IT Services Portfolio. Denk hierbij aan beschikbaarheid, helpdesk support, beveiligingsaspecten, kosten per eenheid, etc.

Daarnaast gaat het ook over de inhoud van de IT Services Portfolio. Denk daarbij aan de beschikbare functionaliteit en hoe die past bij de wensen van de gebruikers. Deze inhoud komt vaak tot stand door een directe interactie tussen de gebruiker en de IT ontwikkelaar. Deze laatste werkt een oplossing uit voor een probleem van de gebruiker. Echter op deze wijze ontstaat op den duur een lappendeken van toepassingen (= solutions = applicaties = apps) en de onderhoudslast hiervan neemt grootse vormen aan.

Als wij echter wat afstand nemen van de dagelijkse problemen en gaan werken met de abstracte modellen van wat we eigenlijk willen bereiken, worden de verbanden tussen processen, gegevens en de technologie voor de ondersteuning hiervan duidelijker. Met name de rol van de gegevens in de organisatie is hierbij van cruciaal belang. Uit mijn praktijk weet ik dat organisaties die een lange termijn verbeterplan hebben gebaseerd op een goede gegevensanalyse, met een significant lager onderhoudsbudget voor hun ICT uit de voeten kunnen.

De Information Ownership Matrix speelt hierbij de belangrijkste rol op het snijvlak van Business Architecture en IT Architecture. Deze matrix bepaalt nl. de ontkoppelpunten in de IT architectuur, waardoor er een groter schakelvermogen in de IT ontstaat.


Uiteindelijk is het de Project Portfolio die de verandering moet gaan realizeren. Elk project moet dus op inhoud gemanaged worden vanuit de doelarchitectuur. De requirements moeten niet alleen getoestst worden op de werking van de Business Processes maar ook op het in acht nemen van de Information Ownership.

De uitwisseling van gegevens met andere componenten in de IT architectuur kan dus niet door 'eenvoudige copy en paste' oplossingen, maar moet gerealiseerd worden vanuit de principes van 'single version of the truth', 'role based access' en 'open database connect (ODBC)'. Dit soort functionaliteit hoort in de Database Management Systems (DBMS) laag van de architectuur te worden opgelost en niet in de applicatie laag.


Kijken wij naar IT Portfolio Management met in acht neming van de rol van de Architectuur voor de langere termijn dan zijn er 2 aandachtsgbieden voor het management:

1. Het managen van de Inhoud van de Portfolio
Deze taak zal veelal belegd zijn bij een kleine groep van specialisten die op ad hoc basis aan de projecten deel neemt en waar nodig bij stuurt en de contacten over de inhoud tussen de verschillende projecten onderhoudt. Zij zijn ook de gesprekspartner met (externe) Leveranciers van IT Diensten als het gaat om de inhoudelijke samenhang in de IT Services Portfolio.

2. Het managen van de Performance van de Portfolio
Dit is zowel voor de IT Services Portfolio als de Project Portfolio een standaard management taak. Hier zijn inmiddels de nodige 'Key Performance Indicators (KPI's)' voor beschikbaar in de literatuur.