Iedere service manager wil grip op ict-dienstverlening, en dus op het ict-landschap. Op vragen uit de organisatie wil hij, liefst met een druk op de knop, direct antwoord geven. Architectuur definieert hiervoor het raamwerk, maar dient gekoppeld te worden aan bronnen van operationele beheerinformatie. En dat op een slimme manier, zodat 'bi 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 en 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 procent. 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 welk percentage correctheid nodig is. Als 100 procent niet kan, moet het dan 95 procent zijn? Of 90 procent? 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 (bijvoorbeeld wekelijkse) koppeling plaatsvinden met het architectuurmodel. Hierbij kan meteen de informatie uit die verschillende beheerbronnen, onder andere 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'.
Herkenbaar verhaal uit één van mijn functies in het verleden.
En weet je wat nu het mooiste zou zijn: als de informatie in de CMDB dusdanig compleet en betrouwbaar is, dat je op basis van die gegevens de architectuurplaat kunt genereren.
Hiermee wordt je CMDB een “single point of control”, wat essentieel is voor het kunnen managen van zowel de CMDB als de architectuurplaat.
Hiermee kun je ook beter voorkomen dat ergens vergeten wordt één van de overzichten bij te werken na een wijziging.
Het is een terechte constatering dat servicemanagement en architectuur wel eens wat nauwer mogen samenwerken.
Ik ben het nog meer eens met de opmerking van PaVaKe hierboven, dat de CMDB als centrale informatiehub binnen geheel IT kan fungeren…
Eenvoudig is dat echter niet, met datakwaliteit en -eigenaarschap als voorname aandachtspunten. Als het al lastig is om binnen technisch beheer alle informatie consistent te delen (met bv een virtuele CMDB), hoe krijg je dan al die andere relevante IT-partijen hierin mee? Projectmanagers, ontwerpers, testers, ontwikkelaars…om nog maar te zwijgen over architecten. Al deze partijen moeten een antwoord krijgen op de vraag “what’s in it for me”?
@PaVaKe, 13-08-2011 21:31
Ik heb nog nooit een betrouwbare CMDB gezien in de praktijk. Lees eens : http://www.itskeptic.org/itil-cmdb-skeptic
@Kees
Die ervaring deel ik (gelukkig) niet.
Ik heb in het verleden bij het oude Philips rekencentrum gewerkt in de mainframe-netwerk hoek.
Hier hadden we een CMDB, op basis waarvan de netwerksoftware (een beetje te vergelijken met host- en routertabellen in de TCP/IP wereld) wekelijks of op aanvraag gegenereerd werd.
In de CMDB was zowel de historie van het netwerk te vinden, maar ook de reeds geplande wijzigingen. Middels het weeknummer konden we vooruit plannen, en op basis van het weeknummer de nieuwe stand van zaken genereren.
Dit vereiste een behoorlijke discipline binnen de organisatie, maar dit werd deels ook afgedwongen door de opzet van het mainframe: “hiërarchisch en alles gedefinieerd”.
Leuk detail: ik praat hier over halverwege jaren 90, dit mechanisme was toen al enkele jaren in place.
@Paveka
Ja, maar dat was vroeger in de mainframetijd idd. Ik werkte toen met IBM’s Infoman en daar stond inderdaad elke VTAM node keurig in. Later kwamen de client server systemen en met de internet ontsluiting de proxy servers, firewalls, routers etc etc. Voor zelfs een middelgrote organisatie is het tegenwoordig gewoonweg niet meer mogelijk om bij te houden wat er aan soft- en hardware draait. Een hierarchie als het mainframe is door de veelheid van verschillende leveranciers, protocollen, architecturen en besturingssystemen niet meer mogelijk. Zowel het modelleren als het bijhouden van de consistentie van een CMDB blijkt in de praktijk een utopie te zijn.
Door de inherente inconsistentie van de CMDB blijft de meerwaarde ervan uit.
@Kees
Inderdaad, wij gebruikten ook Infoman 😉
Maar ik bestrijd dat het nu niet meer mogelijk is.
Het probleem zit hem vandaag de dag in organisatie en manier van werken:
– de printers worden beheerd door partij A
– de servers door partij B
– het netwerk door partij C
– de storage door partij D
En vervolgen willen we de medewerkers ook nog de mogelijkheid geven om alle van huis meegebrachte rommel (x-pads, smartphones etc) op het netwerk aan te sluiten.
In theorie kun je hier heel goed een CMDB voor maken, maar organisatorisch is het gewoon niet mogelijk al deze partijen op elkaar aan te sluiten zonder de hoofdprijs te betalen voor dataconversie om alle beheerssystemen op elkaar aan te laten sluiten.
Wat dat betreft had de hiërarchische opbouw van het mainframe zo z’n voordelen
Het komt mij voor dat in dit artikel gesproken wordt van architectuurlagen waar architectuurviews worden bedoeld. Aangezien een architectuur altijd al meerdere lagen impliceert is het verwarrend om iedere vermelde architectuur opnieuw te beschouwen als een architectuurlaag. Nu is het zeker verleidelijk om de opgesomde verzameling architecturen – enterprise architectuur, informatiearchitectuur, applicatiearchitectuur en infrastructuurarchitectuur – te beschouwen als een 4-lagen-architectuur maar dat maakt de zaak om 2 redenen onduidelijk.
In de eerste plaats wordt gesuggereerd dat Enterprise Architectuur (EA) vooral de businessview van de architectuur beschrijft; in de literatuur betreft de EA juist de verzameling van alle views die binnen een organisatie wordt gehanteerd voor het inrichten van de informatievoorziening. Tegenwoordig beperkt EA zich tot 3 hoofdviews, te weten:
– Business View: bedrijfsarchitectuur
– Functional View: informatie- of applicatiearchitectuur
– Technology View: technologie/infrastructuurarchitectuur.
Niet toevallig corresponderen deze views precies met de toepassingsgebieden van de bekende frameworks BiSL, ASL en ITIL.
In de tweede plaats wordt een 4-lagen-architectuur juist beschouwd als een volgende stap in een evolutie van multitier-architecturen, die leidt tot een ontkoppeling van gebruikersinterface, procesflow, bedrijfslogica en bedrijfsgegevens, hetgeen mogelijk wordt gemaakt door het toepassen van service oriëntatie (SOA). Deze 4-lagen architectuur doet zich met name voor binnen de Functional view, zodat applicatiearchitecturen zich inmiddels hebben ontwikkeld tot gelaagde service-architecturen. De gebruikersorganisatie (Business View) heeft verder geen interesse in architectuurlagen en services en zal liever spreken van bedrijfsgegevens, bedrijfsfuncties en gebruikersschermen.
Is lees in de reacties het nodig over een consistente CMDB. Laat ik beginnen met de stelling dat zonder een solide CMDB er maar marginaal sprake kan zijn van sturing op de kosten, TCO inzicht en kwaliteit van service management.
Er wordt erg ingewikkeld over gedaan, en de praktijk is dat je zelden een fatsoenlijke CMDB tegenkomt. Ik zie de volgende redenen:
1) Veel service-management systemen zijn voor een goede CMDB te rigide
2) men gaat de CMDB onderhouden vanuit processen (handmatig), en de theoretische processen blijken niet te werken (in de praktijk!)
3) men maakt onvoldoende gebruik van de beschikbare “infrastructuur intelligentie die beschikbaar is.
Alle infrastructuren hebben een schat aan CMDB informatie in zich. Denk aan de info in alle management en beheersystemen. Het enige wat ontbreekt is dat men een CMDB / Service-management oplossing heeft die hier goed mee kan integreren om die waardevolle data te gebruiken en via interfaces icm “business rules” de CMDB geautomatiseerd te onderhouden.
Is het dan niet mogelijk??
Jawel, ik heb inmiddels bij 2 multinationals tegen low cost binnen 1 jaar een geautomatiseerde CMDB ontwikkelt (beiden in Service-Now). De vruchten die men plukt zijn enorm. Naast kostenbesparingen (directe), is er ook TCO inzicht ontstaan, en klant facturatie (en interne doorbelasting) zijn aantoonbaar correct). Inmiddels wordt de CMDB zelfs gebruikt om beheeractiviteiten aan te sturen want inconsitenties rollen nu zo uit de CMDB (automatisch).
Het kan dus wel, maar je hebt wel senior management nodig die dit begrijpen en die erin geloven.
Als specialist op dit gebied geef ik graag meer tekst en uitleg aan geinteresseerden.
Andre bal:
cmdb-regisseur.com