Artikel

Architectuur en service management, een superduo!

Iedere service manager wil grip hebben op de ICT dienstverlening, en dus op het ICT landschap. Op een veelheid aan vragen uit de organisatie wil hij, het liefst met een druk op de knop, direct antwoord kunnen geven. Architectuur definieert hiervoor het raamwerk, maar dient dan wel gekoppeld te worden aan de veelheid aan bronnen van operationele beheerinformatie. En dat op een slimme manier, zodat “business intelligence voor ICT” werkelijkheid wordt. Architectuur is dan geen papieren tijger, maar de helft van een superduo.

Enterprise architectuur definieert vanuit visie, missie en strategie van een organisatie de inrichtingsprincipes, bedrijfsmodellen, producten & diensten en bedrijfsprocessen. Producten, diensten en bedrijfsprocessen verwerken informatie, en informatiearchitectuur houdt zich dan ook bezig met informatie-uitwisseling, en ter ondersteuning daarvan met het vaststellen en overeenkomen van berichtformaten en gegevensdefinities. Informatie wordt verwerkt door applicaties, en dus is een architectuur niet “af” zonder een applicatiearchitectuur waarin bepaald wordt welk samenspel van applicaties het leveren van de producten & diensten mogelijk maakt, de bedrijfsprocessen laat lopen en de informatiemodellen tot leven brengt. Applicaties maken gebruik van ICT infrastructuur, en dus dient ook de “infrastructuurarchitectuur” beschreven te worden. De architectuurlagen bepalen gezamenlijk hoe een organisatie doet wat deze moet doen.

Een snel verouderend boekwerk?

Maar al te vaak leidt de eerste, nuttige en noodzakelijke, vastlegging van de architectuurlagen tot een dik boekwerk dat vol trots wordt gepresenteerd en vervolgens in de boekenkast verdwijnt. “Zo is het, en zo moet het (worden)”. Er wordt vol energie gestart met de veranderplannen, en die plannen worden, deels of in z’n geheel, gerealiseerd. Alleen… het bijwerken van het boekwerk is veel werk. De ervaring leert dat het documenteren van de veranderingen niet of onvoldoende geschiedt, en voordat je het weet is het architectuurboekwerk verouderd. En als het verouderd is, dan wordt het niet meer gebruikt. Vastlegging van architectuur dient dan ook te worden geïncorporeerd in de change processen, voor grote en kleine changes. Dat is geen vernieuwend inzicht, maar het is wel een feit dat dit een flinke uitdaging is en blijft.

De kracht van een architectuurtool

Architectuurtooling kan helpen bij deze uitdaging. Standaard software zoals Microsoft Visio levert weliswaar mooie plaatjes op, maar geeft de architect geen grip op de complexiteit. Het zijn en blijven 1-dimensionale, puur grafische plaatjes. Dit terwijl je eigenlijk afhankelijkheden wilt kunnen benoemen, objecten en relaties attributen wilt meegeven, op een eenvoudige manier wilt kunnen in- en uitzoomen, plateauplanning c.q. road mapping visueel inzichtelijk wilt maken en queries wilt kunnen doen op alle in de onderliggende database opgeslagen informatie. Er zijn goede en eenvoudig hanteerbare architectuurtools voorhanden die dit zeer effectief ondersteunen.

Wanneer de architectuur in de tooling is ingevoerd, wat dan? De tooling maakt het onderhouden van de architectuurvastlegging gemakkelijk, onder meer doordat de gebruiker geattendeerd wordt op de diverse afhankelijkheden in en tussen de vier architectuurlagen. Desondanks wordt, vooral bij de kleine veranderingen, dit “bijwerken” nogal eens vergeten. Bijvoorbeeld: het upgraden van operating systeem Y van virtuele server X op fysieke server Z, zodat de beschikbaarheid van applicatie A voor bedrijfsproces B en dienst C omhoog kan naar 99,8%. Details? Ja, maar absoluut noodzakelijke details, want het zijn uiteindelijk de applicaties en de infrastructuurcomponenten die bedrijfsprocessen en informatiestromen mogelijk maken.

De normaalste vragen van de wereld

Je moet als organisatie dus weten wat de afhankelijkheden tussen de architectuurobjecten zijn en wat de dienstenniveaus zijn om changes op een gecontroleerde manier door te voeren. Ook om antwoord te kunnen geven op wat volgens gebruikersorganisaties “de normaalste vragen van de wereld” zijn:

  • Welke applicaties zijn het belangrijkste? En voor welke bedrijfsprocessen?
  • Wat betekent dat voor de onderliggende infrastructuurcomponenten?
  • Wat betekent dat voor de dienstenniveaus?
  • Wat betekent dat voor de jaarlijkse beheerkosten (“total cost of ownership”)?
  • Welke overlap zit er in functionaliteit tussen applicaties?
  • Hoe vaak worden er functionele changes doorgevoerd?
  • Wat zijn de beste kandidaten om tot applicatierationalisatie over te gaan?
  • Wat is het budget voor die rationalisatie? En wat is de terugverdientijd?
  • Wat is de end-of-support datum voor een commercial-off-the-shelf applicatie?
  • Wanneer moeten we tot nieuwe licentieafspraken overgaan?
  • Hoeveel Microsoft SQL Server databases hebben we draaien?
  • Welke hardware en software onderhoudscontracten hebben we?
  • Hoeveel hebben we gebruik gemaakt van dergelijke contracten?
  • Wat zouden de investeringen zijn als we spare hardware aanschaffen?
  • Wat is de afschrijving als we besluiten over te stappen op cloud computing?
  • Welke fixes, patches en service packs zijn er uitgekomen?
  • Welke hebben we daarvan reeds geïmplementeerd?
  • Welke moeten we daarvan in het komende kwartaal implementeren?

Zo kunnen we nog wel even doorgaan. Iedere service manager wil, het liefst met een druk op de knop, antwoord kunnen geven op dergelijke vragen.

Koppelen met beheerinformatie

Architectuur is het raamwerk voor beantwoording van deze vragen. Zonder architectuur is er geen overzicht, en dus ook geen grip. Architectuur beschrijft de wereld in een model. En zoals we weten zijn modellen van de werkelijkheid nooit helemaal correct. De vraag is welke percentage correctheid nodig is. Als 100% niet kan, moet het dan 95% zijn? Of 90%? En welke informatie dient vanuit de dagelijkse service management operatie gekoppeld te worden aan de architectuur?

Door het juiste niveau van detail te kiezen kan enerzijds worden zeker gesteld dat de informatie voldoende waarde toevoegt, terwijl de benodigde inspanning om het model up-to-date te houden zo klein mogelijk is. Daarnaast hoeft informatie niet real-time te zijn. Het beantwoorden van bovengenoemde vragen is een tactische aangelegenheid. Als wijzigingen worden verwerkt in de operationele beheerdatabases inclusief de CMDB, kan er een periodieke (bijv. wekelijkse) koppeling plaatsvinden met het architectuurmodel. Hierbij kan meteen de informatie uit die verschillende beheerbronnen, o.a. op basis van de samenhang zoals bekend in het architectuurmodel, geverifieerd worden. Zo kan bijvoorbeeld “ontdekt” worden dat er infrastructuurobjecten “in het veld staan” die niet bekend zijn in de architectuurvastlegging. Of dat er afhankelijkheden zijn tussen applicaties die nog niet opgenomen zijn in de architectuurdocumentatie. Door informatie uit verschillende beheerbronnen aan elkaar te relateren kan architectuur gematched worden met de dagelijkse werkelijkheid en kan antwoord worden gegeven op veel van bovenstaande vragen. Hierdoor verkrijg je als service manager een integraal beeld van de werkelijkheid, zowel voor de momenten dat je behoefte hebt aan overzicht alsook voor de momenten dat er details nodig zijn. Zodat architectuur geen papieren tijger is, maar de helft van een superduo. Architectuur gekoppeld aan service management. Ik noem dat “business intelligence voor ICT”.

Categorie:   
Auteur(s)
afbeelding van marcsteenbergen
Marc Steenbergen
ValueBlue BV - Directeur

Marc Steenbergen, mede-directeur van ValueBlue BV, gespecialiseerd in ICT architectuur en “business intelligence voor ICT”.

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.