Artikel

Beheren of beheersen? Richtinggevende principes

Architectuur als pragmatische richtlijn en niet als keurslijf

IT Service Management en Architectuur bevinden zich in een spanningsveld. De één wil stabiliteit en continuïteit, de ander verandering en verbetering. En allebei hebben ze zo hun charmes en bestaansrecht. Architectuur leeft al ‘in de wolken’ en de IT Service Manager staat tot aan zijn knieën in de modder van de werkelijkheid. Komt er wateroverlast of houdt de droogte aan? De vraag is nu hoe kunnen we de afstand tussen deze twee vakgebieden verkleinen en praktisch architectuur bedrijven, zodat de business tot volle wasdom komt?

Architectuur heeft verschillende verschijningsvormen, allemaal met eigen voordelen en karakteristieken. Analyseren, conceptualiseren en visualiseren zijn de instincten van de architect van vandaag. En zet je een paar architecten bij elkaar, dan kunnen ze heel snel virtueel opschakelen en de complete wereld van morgen definiëren. Enterprise Architectuur vormt hier wellicht de eredivisie. Met een redelijk arsenaal aan methodes en gereedschappen komen er dan doorsnedes over bijna elke gewenste dimensie. “Zo moet het. Introductie van de nieuwste technieken en alles geïntegreerd!”: de progressieve lijn.

IT Service Management heeft nu enkele ITIL-generaties achter zich en lijkt volwassen te zijn geworden. Maar een nadere beschouwing geeft toch een beeld van enkele groeipijnen op juist de dynamische elementen van het dienstenlandschap. Change Management gaat nog redelijk, maar als het aankomt op innovatie blijkt het hier en daar nog wel moeilijk. Voeg daar nog aan toe dat de huidige generatie IT-managers is opgeleid (dat hebben we zelf gedaan) vanuit een managed omgeving dogma dat tegen ‘lastige’ eindgebruikers beschermd moet worden. Dan is toch sprake van een conservatieve lijn.

En toch horen ze bij elkaar. Maar hoe overbruggen we deze progressieve en conservatieve lijnen?

Doel van architectuur

Architectuur is een tamelijk ongrijpbaar begrip. Wat is het nou? Waar kan ik het vastpakken? Een definitie van architectuur als “De fundamentele organisatie van een systeem bestaande uit haar componenten, hun relatie met elkaar en de omgeving en de principes die haar ontwerp en evolutie richting geven”, is waarschijnlijk volledig correct, maar helpt niet bij het zieltjes winnen van mensen uit de praktijk.

Dan het doel van architectuur. Als het al moeilijk is om te definiëren wat het is, hoe kan ik dan bepalen wat ik er aan heb? En als bijv. een selecte groep architecten centraal aan de gang gaat, lopen ze met de beste bedoelingen te ver voor de muziek uit en treedt de klassieke fout van het verwisselen van doel en middel makkelijk op.

De IT-organisatie karakteriseert deze architectuurproducten dikwijls als ‘duur behang’. En omgekeerd wordt de operatie gekenschetst als ”Ze willen het ook niet”. Beide opvattingen zijn begrijpelijk, maar dragen niet bij tot toenadering.

Als we het doel van architectuur nu eens wat pragmatischer insteken, dan levert dat meteen meer begrip op in de IT-organisatie. En zij moeten het allemaal toch maar realiseren en onderhouden. Het doel van architectuur kunnen we bijvoorbeeld omschrijven als:

  • referentie en richting voor IT-activiteiten (onderhoud, uitbreiding, optimalisatie, ontwikkeling);
  • referentie en richting voor IT-besluiten (moet, mag, mag niet);
  • transparantie bevorderen tussen vraag en aanbod.

Waarbij referentie en richting voortkomen uit de doelstellingen en prioriteiten van de bediende business. En dit geldt dan voor nieuwe dingen, gebruik van het huidige en opruimen van het oude.

Principes

Architectuur hoeft dus helemaal niet ver uitgewerkt te worden in detail noch in conceptuele correctheid voor alle mogelijke situaties om toch praktisch toepasbaar te zijn. Het gaat primair om de referentie en de richting.

Het betekent dat we de 80-20-regel mogen gebruiken bij de opstelling van architectuur, maar van de andere kant ook dat de architectuur niet bekritiseerd en afgeschoten mag worden op al haar details. En dit is eigenlijk wat in de gewone samenleving als ‘principe’ wordt gebruikt. Dat is gewoon handig. Een principe is een kernachtige formulering van de handelingsregel op basis waarvan acties worden uitgevoerd en besluiten worden genomen. Een principe representeert daarmee referentie en richting, maar geeft ook de gedachte hierachter weer.

Structuur van een principe

De algemene structuur van een principe is weergegeven in onderstaande tabel. De vragen ‘Wat’, ‘Waarom’ en ‘Dus’ zijn hulpmiddelen om een principe goed te omschrijven, de rationale expliciet te formuleren en ook de consequenties te duiden.
 

Omschrijving Wat Vervoer op basis van elektrische aandrijving heeft de voorkeur boven fossiele brandstofaandrijving
Rationale Waarom Omdat elektrische voertuigen minder vervuilen
Omdat elektrische voertuigen minder lawaai maken
Implicatie Dus Hebben we elektriciteit nodig
Hebben we elektrische auto’s nodig
Hebben we oplaadpunten nodig

Als we de referentie en richting van de business kunnen formuleren in principes kan IT (net als de andere ondersteunende diensten) hieraan referentie en richting ontlenen. Voegen we hierbij de professionele input vanuit het IT-domein, zoals best practices, technologieën en marktinformatie, dan zijn we er.

Of niet? De principes bieden weliswaar referentie en zijn richtinggevend, ze representeren geen actie. Onderhoud, optimalisatie, uitbreiding en ontwikkelingen gebeuren niet vanzelf. Dus moet het IT-domein met de principes in de hand haar omgeving analyseren en activiteiten definiëren. Deze roadmap is dan haast ‘als vanzelf’ in lijn met de zakelijke prioriteiten en biedt transparantie over en weer. Bij elke activiteit is dan duidelijk waarom het gedaan wordt. Geen discussies meer over ‘Waarom moet dat nu?’, ‘Kan dat niet eerder?’ en ‘Is dat niet te duur?’

Principe en roadmap synthese

De stappen voor het opstellen van de principes en het afleiden van de roadmap is weergegeven in figuur 1.

Figuur 1: Principes en roadmap synthese model

1. Synthese: Sleutelvragen

De sleutelvragen worden opgesteld op basis van de algemene visie van het bedrijf. Bijvoorbeeld ‘Sluit de IT-functionaliteit aan bij de functionele vraag van de business?’ Of ‘Zijn de wettelijke verplichtingen geborgd?’ De vragen reflecteren de wens/noodzaak tot verbetering en dus de sense of urgency voor veranderingen. Bovendien geeft het aan wat de gepercipieerde maturity van de dienstverlening is en daarbinnen de maturity van het architectuur onderwerp. Indien er geen sense of urgency is of als de maturity van de dienstverlening al hoog is, is de voorgenomen principebenadering niet de juiste en verdient een meer uitgebreide en diepere architectuurmethodiek de voorkeur.

2. Synthese: Business principes

IT is een dienstverlening aan het bedrijf; het is een staffunctie. Het is een belangrijke succesfactor om dit te (blijven) realiseren: IT bepaalt niet, ze volgt. De business principes moeten dan ook puur vanuit de business geformuleerd worden en geen dienst, techniek of implementatie keuze bevatten.

In de praktijk is de input voor de synthese dikwijls impliciet aanwezig. Strategische documenten, zoals jaarplannen of een meerjarenvisie, bevatten illustratieve proza, maar hieruit moeten expliciete principes worden gedistilleerd. Interviews helpen om te duiden wat de beleving van de mooie strategische plannen in de organisatie is. Er is een risico dat de strategie meer voor de marketing dan voor de uitvoering gemaakt is. Het opstellen van de principes is op zichzelf dan al een goede exercitie om zaken helder te krijgen. Verschil in inzicht en interpretatie zijn erg gemakkelijk te voeden en een lekker provocatief principe om duidelijkheid te krijgen helpt.

Bijvoorbeeld een opmerking als ‘Kwaliteit staat bij ons hoog in het vaandel’ kan beleefd worden als alleen toepasbaar voor het product. Maar net zo goed kan het van toepassing zijn voor de ondersteunende diensten, leveranciers, de werkomgeving, de milieubelasting van de verwerking van het product na zijn productieve leven etc. Explicieter is: ‘Kwaliteitszorg is een verantwoordelijkheid van alle processen van ons bedrijf’. Omdat kwaliteit wordt bepaald door alle schakels in de keten en omdat iedereen belangrijk is. Dus moeten alle diensten kwaliteit definiëren, meten en managen.

3. Synthese: IT-principes

De principes van een onderliggend domein, zoals IT, worden uiteraard gevoed door de business principes, maar ook door de professie van het domein zelf: technologieën, best practices, standaarden en marktontwikkelingen.

Als de business het principe formuleert dat de organisatie snel en flexibel wil anticiperen op marktontwikkelingen moet IT dat vertalen naar iets als het ‘IT-dienstenportfolio is flexibel’ en ‘IT is proactief innovatief’.

4. Analyse: Principe relaties

Tijdens de analyse worden de geformuleerde principes beschouwd ten opzichte van elkaar. Hierin zijn wederom de business principes leidend. De IT-principes worden beoordeeld op prioriteit en hun mogelijke strijdigheid met de business principes.

Als de business formuleert dat innovatief onderzoek belangrijk is, kan een IT-principe als ‘Standaardisatie van de IT-middelen heeft de voorkeur’ hier mee conflicteren. Opnieuw is het expliciet maken van deze ‘spanning’ goed voor de referentie en de richting. Als dan iemand van Research & Development vraagt om een niet-standaard middel kan dat wel, maar de uitzondering en de consequenties (kwaliteit, kosten, support) liggen dan heel duidelijk bij de vraagzijde.

De analyse leidt tot een principe-matrix, waarin aangegeven wordt welke IT-principes noodzakelijk zijn (bijvoorbeeld via een MoSCoW duiding) om de business principes te realiseren en welke kunnen leiden tot spanningen.

5. Controle: Sleutelvragen

Met de principes op tafel worden de eerder opgestelde sleutelvragen nagelopen om te zien of ze beantwoord kunnen worden. Indien een vraag niet te beantwoorden is vanuit de principes is de lijst met principes nog niet compleet of is de sleutelvraag wellicht niet relevant.

6. Synthese: Projecten

De huidige situatie van de IT-dienstverlening versus de principes biedt een delta waarop een activiteit kan worden geformuleerd. En soms is dat een project. Soms kan het ook eenvoudigweg een besluit of een richtlijn voor de beheerafdeling zijn. In de praktijk zijn voorbeelden van IT-afdelingen die nogal ‘ticket en catalogus gedreven’ niet onbekend. Er gebeurt niets als er niet eerst een ticket ingelegd wordt in de centrale helpdesk en een aanvraag voor iets nieuws kan lang duren. Dit is begrijpelijk, want het komt voort uit de ‘IT-opvoeding’ van de laatste decennia. Maar inmiddels is de business flink opgeschakeld in snelheid van handelen en zijn de gebruikers nu kenniswerkers met een grote bewegingsvrijheid. Een richtlijn aan bijvoorbeeld de tweede lijn support om eerst oplossend en dienstverlenend te handelen en later zelf een ticket in te leggen om het incident management proces op orde te houden, is al een grote stap vooruit. Daar is helemaal geen project voor nodig.

Deze stap resulteert in een lijst met mogelijke projecten. Het huidige projectenportfolio (als die er is), kengetallen die de omgeving beschrijven (hoeveel van wat is er?) en marktontwikkelingen dienen als input.

7. Synthese: Planning

De geformuleerde projecten worden uitgezet tegen de principes. Hoe past een project bij de verschillende principes? Daarnaast wordt een gewone risicoanalyse van de projecten verricht. Dit geeft dan een overall indruk van de prioriteiten en ook een logische sequentie van de projecten.

De volgende stap is de projecten in de tijd uit te zetten en de roadmap is gevormd. Hierbij speelt wel de capaciteit een rol. Maar het kan ook goed zijn dat een principe zo belangrijk is dat extra capaciteit kan worden aangerukt.

8. Synthese: Borging

De voorgaande stappen geven een pragmatisch pad naar een roadmap, die gedragen wordt door de business. Deze moet óók onderhouden worden. En niet alleen de roadmap, ook de onderliggende principes.

Processen voor het onderhoud van de principes en de roadmap dienen te worden belegd bij de verschillende rollen en individuen in de organisatie. Ook moet dit in de jaarkalender worden opgenomen.

Conclusie

Het synthetiseren van principes en een roadmap is een pragmatische vorm van het ‘doen’ van architectuur. Voorwaarde is een maturity match tussen IT Service Management en de Architectuurfunctie, beiden dienen niet te hoog te zijn.

De methode resulteert in een aantal architectuurproducten: business principes, IT-principes en een roadmap. Architectuur blijft hiermee een middel en geen doel. Het is een middel voor het geven van referentie en richting voor IT-activiteiten en -besluiten. Bovendien ontstaat transparantie in wat waarom en wanneer gebeurt.

Rest nog een proactieve communicatie...

Categorie:   
Auteur(s)
afbeelding van harrypotma
Harry Potma
Atos - Global Lead Transformation Methodologies

Harry Potma is werkzaam bij Atos als Global Lead Transformation Methodologies.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.