Mijn vorige opinie over business-it alignment stopte ik abrupt met een quote van Lee Iacocca die stelt dat je niets aan producten en winsten hebt als er geen goed team is en tot die conclusie komt ook Gartner met de CIO agenda 2014 over digitale leiderschap. De vraag is of er nog wel sprake is van leiderschap als je telkens bij het kruisje tekent en de it vooral aanstuurt op contracten.
Business-it alignment gaat om de communicatie tussen business managers die de zakelijke besluiten nemen en it-managers die voor de it-invulling zorgen. Nu wordt de discussie niet gevoed met de juiste (geaggregeerde) gegevens en is communicatie een spelletje buzzword bingo. Zo becijferde Gartner in 2013 dat het volume aan business-it (schaduw-it) gestegen was tot 35 procent. Veel (software) asset managementsystemen schieten dus al tekort om compliant in licenties te blijven en dat is niet alleen verwijtbaar aan de it, want de business unitmanagers nemen steeds vaker it-beslissingen die onder de radar door vliegen.
Configuratie management
In de voorgaande opinie refereerde ik naar Gartner die stelt dat aandacht van de CMDB verschuift naar andere databases die gericht zullen zijn op capaciteit en prestatie. Cloud providers rationaliseren configuratie intelligentie (ci) inderdaad naar pay-per-use, it-governance wordt bij de afnemer gelegd. En dat knelt niet alleen met de complaince maar ook de operationele efficiency. Configuration management (cm) dient er namelijk voor om te zorgen dat organisaties zakelijke beslissingen kunnen maken, de juiste acties uitvoeren en dat producten of diensten overeenkomen met wat ze beogen te zijn bij elke stap van het proces. Met andere woorden, cm is weten wat we gisteren deden, wat we nu aan het doen zijn en wat we zullen doen in de toekomst. Het doel is om organisaties inzicht in redenering en het gezag achter elke actie te geven om ze te beschermen tegen de wet van Murphy.
Configuratie intelligentie
De wet van Moore trekt letterlijk en figuurlijk sporen door de it en volume aan machine gegenereerde data is enorm toe genomen. Terwijl de business verlekkerd naar beloften van big data kijkt wordt er vergeten dat business intelligence om het verbeteren van de operationele efficiency moet gaan en dus niet een abstracte wetenschap moet worden.
Ik zal nu niet zeggen dat alle problemen met configuratie management opgelost worden maar wat kritischer kijken naar de keuzen helpt wel. Logs liegen niet en geven inzicht in verleden, heden en de toekomst. Zeker als deze gecorreleerd worden en verrijkt met kennis uit andere bronnen, de relaties zitten vaak al in de gehanteerde naamgevingsconventies. Het over elkaar heen leggen van data uit de verschillende lagen van het beheer helpt bij het modelleren van de architectuur. Wie dit doet vanuit de techniek en de business ziet gauw de wezen, niet opgeruimde servers die overgebleven zijn van projecten. En door simpelweg de meest geraakte objecten te turven meestal ook al snel de kritische ci’s.
Due dilligence
Het modelleren van de architectuur en in kaart brengen van de risico’s hierin biedt zowel de business als de it voordelen. Toch wordt dit nog nagelaten en recent meldde de Rabobank na herhaaldelijke verstoringen doodleuk dat ze geen idee hadden hoe alles aan elkaar geknoopt is, maar dat de sla toch 99 procent is. Blijkbaar sturen ze de it daar aan met hetzelfde natte vingerwerk waarmee de interbancaire rente vastgesteld werd. Er wordt namelijk ook nog weleens vergeten dat ci’s van ondersteunend naar kritisch en vice versa kunnen gaan in de lifecycle.
Dat veel it-producten nu nog vraagtekens zijn in business continuïteit garantie (de bcg-matrix) zorgt dat overmachtsclausules steeds groter worden in de sla. Maar Lee Iacocca was daarover al duidelijk en dus is het wel handig dat bij modelleren misschien ook een controller aan het team toegevoegd wordt. Ervaring leert dat je dan pas echt klappen maakt om het business-it alignment probleem op te lossen.
Model-based configuratie management
Configuratie management is eigenlijk niet eens een it-proces want of je nu een raket of software maakt is niet belangrijk, het gaat hier om het vastleggen, zodat het product of de dienst onderhouden kan worden en daarmee doet wat het beoogd te doen gedurende gehele lifecycle. Doordat we steeds meer standaard componenten gebruiken zou dit juist makkelijker moeten worden dan moeilijker, tenminste als je het relationeel registreert. Aanname is de moeder van alle mislukkingen en er is dan ook niet zo zeer sprake van een ‘technology debt’ maar een gemis aan informatie. Als je vergeet dat Windows een platform is, dan geloof je ook dat configuratie management een product is in plaats van een discipline die door een framewerk met meerdere tools ondersteund wordt.
Het probleem met de CMDB is dat het een ITIL abstractie is. De CMDB is een denkbeeldige oplossing voor veel verschillende zaken zoals bijvoorbeeld:
– het bijhouden van services tbv. Sales
– het bijhouden van capaciteit tbv. Configuratie Management
– het bijhouden van assets tbv. Finance
– het vormen van een model van de actuele ICT architectuur tbv. architecten, Helpdeskmedewerkers, Technische specialisten, en iedereen die werkt met Incidenten, Problemen, Errors en Changes.
In de huidige Cloud architecturen speelt virtualisatie een grote rol en is de rate van changes veel hoger dan bij een niet-gevirtualiseede architectuur. Bovendien kan de deployment van nieuwe services veel sneller en massaler plaatsvinden dan binnen ouderwetse niet-cloud omgevingen. Vooropgesteld dat je dus een CMDB wil hebben, zal die real-time moeten zijn in de zin dat alle wijzigingen die in de realiteit plaatsvinden ook direct,real-time, naar de CMDB gepropageerd worden. Handmatig updaten heeft gewoon geen zin meer. Denk je eens in hoe je een SOA/BPM service zou moeten modelleren in de CMDB, bijvoorbeeld.
Maar waarvoor zou je een CMDB willen hebben als cloudprovider? En wat zou je als cloud provider minimaal vast moeten leggen ? Uitsluitend die gegevens die van belang zijn om de factuur naar de klant vast te stellen (de aangeboden en afgenomen capaciteit). En verder nog de gegevens mbt. de eigen assets bijvoorbeeld de hardware afschrijvingen en licentiekosten.
Changes binnen de cloud zullen over het algemeen een groot aantal componenten treffen, Het idee achter de cloud is immers dat alles standaard en uniform blijft teneinde de kosten laag te houden. Het is een illusie om te denken dat een CMDB daarbij een rol speelt en dat er vanuit de CMDB een Change-impactanalyse zou kunnen plaatsvinden bijvoorbeeld. Mensen die denken dat de CMDB zou kunnen assisteren bij het herleiden van incidenten naar problemen en van problemen naar errors (wat zowiezo een te mechanisch en primitief model is van het oplossen van technische problemen), hebben waarschijnlijk weinig echte harde technische ervaring.
Doordat veel klanten bij het overgaan naar de cloud tevens ook de eigen ICT afdeling hebben opgedoekt, hebben zij daarmee ook het zicht op de eigen ICT verloren. Zij zijn vaak niet eens meer in staat om zelf de de SLA te controleren en moeten blind varen op statistieken van de cloudprovider. Mestal ligt het probleemregistratiesysteem ook bij de cloudprovider en hebben de klanten geen toegang meer tot de historie van incidenten en problemen. De weinige technisch capabele mensen die nog bij de klant in dienst zijn, zijn veelal verworden tot papieren tijgers, hebben de systeemtoegang verloren en verliezen langzamerhand de parate kennis en/of stromen door naar hogere posities als architect of adviseur van de CIO.
De vraag is dan ook of er bij de business in de toekomst nog wel een goede besluitvorming, controle, beheersing (governance), innovatie en vernieuwing ten aanzien van ICT mogelijk is.
@Redactie
De oorspronkelijke titel luidde:
‘Configuratie management is business-IT alignment’
Verschil lijkt klein maar organisatorisch wordt probleem constant bij beheer gelegd terwijl het uiteindelijk een management probleem is.
“Er is te veel IT in IT Governance modellen” is een van de conclusies van een artikel van Wortmann en Kremer. Zeker als het gaat om de broodnodige IT alignment met de business. Ook bovenstaand is weer een benadering vanuit de IT processen.
Volgens is alignment pas echt mogelijk als het vooral vanuit de business komt. En daar schort het helaas te vaak aan.
@Derk
Ik ben het deels met je eens, het probleem wordt teveel met IT opgelost. Als je goed leest stel ik dat configuratie management NIET primair een IT proces is en een multidisciplinair team moet hebben – niet over elkaar maar met elkaar gaan praten.
De rol van de opdrachtgever in de IT wordt vaak diffuus doordat deze niet alleen klant is maar ook leverancier en daarmee uiteindelijk de eigenaar van problemen.
Leuk verhaal. Wat ik me afvraag is wat de invloed van BYOx is op dit geheel.
Mensen die zelf een PC of NAS aan het netwerk hangen (want dat is sneller geregeld dan via “IT”), eigen devices die aan het netwerk komen te hangen (met ongeregistreerde software) of software die op eigen devices geïnstalleerd wordt (want dan kan ik ook thuis werken) zijn allemaal factoren die het steeds moeilijker maken om een CMDB up to date te houden.
Een ander aspect wat meespeelt is dat CM vaak als ondersteunend gezien wordt, en daarmee als kostenpost/overhead. Veel managers die de handtekeningen moeten zetten hebben geen idee wat er op de achtergrond allemaal gebeurd om de gewenste controle te houden op de omgeving, zoals heel mooi verwoord in “weten wat we gisteren deden, wat we nu aan het doen zijn en wat we zullen doen in de toekomst”
@PaVaKe
BYO is al langere tijd een uitdaging met eerst nog floppy’s en nu complete SAN in zakformaat. Maar Do IT Yourself (DIY) oplossingen zijn een nog groter probleem, zeg maar de olifantenpaadjes waardoor meerdere CMDBs zijn ontstaan die meestal niet aan elkaar gelinkt zijn. Opmerking van Derk Kremer is leuk maar als er constant voor IT producten gekozen wordt dan wordt zijn stelling moeilijk houdbaar, HNW gaat tenslotte niet om typemachines en telramen.
Goed opdrachtgeverschap is volgens mij trouwens een al 13 jaar lopende discussie om nog terug te komen op: “weten wat we gisteren deden, wat we nu aan het doen zijn en wat we zullen doen in de toekomst”
@KJ
Een aardige publicatie van ISACA (COBIT) over het belang en de risico’s van CM in IT goverance:
http://www.isaca.org/Groups/Professional-English/test-topic-for-isaca-employeespbwb9qf12/GroupDocuments/Configuration-Management-Using-COBIT-5_res_eng_0913_4.pdf
Oud rapport uit 2001 naar aanleiding Motie Wijn aangaande zorgen rond onze vitale infrastructuur stelt dat je de beheerbaarheid verliest als je de controle erover uit handen geeft. Framework wat de overheid gebouwd heeft met papieren controles blijkt dan ook onvoldoende waarborgen te geven. Maar als je Microsoft opneemt in je Change Advisory Board is het natuurlijk nog maar de vraag of je een eerlijke change-impact analyse krijgt.
80% van de vitale infrastructuur is in handen van private partijen, zal maar niet uitrekenen wat het rendement is van de overige 20% maar wat je stelt over kennis is
helaas de droeve waarheid. Het kind is met het badwater weggegooid waardoor je een opdeling ziet tussen business-IT, welke meer om de content gaat en technische-IT die om de infrastructuur gaat. Cloud computing zie ik trouwens als windmolens, het levert energie maar ik zou de conventionele centrales nog maar niet uit zetten.
Ik stelde al dat je niet alle problemen met CM op kunt lossen maar je kunt ze wel beter classificeren en op grond van weloverwogen business beslissingen een besluit
nemen om deze op te lossen of als ‘known error’ te laten voortbestaan. Nu wordt nog vaak doorgemodderd met oplossingen van leveranciers die in de Change Advisory Board
zitten waardoor zowel de wens voor business-it alignment als om in ‘in control’ te zijn heel lastig wordt.
Ik kom nog weleens drieletterige (ECM/ERP/CRM etc.) oplossingen tegen die ooit door een business unit zijn geïntroduceerd en na reorganisaties of overname door een factor 100 of meer gebruikers belast worden. HW/SW assets die economisch nog niet zijn afgeschreven maar technisch verouderd zorgen vaak voor incidenten die redelijk eenvoudig zijn op te lossen.
@Ewout
Leuk stuk die COBIT link. Geeft goed aan hoe serieus men IT toen nog nam. Zo adviseert pagina 24 om 4 dedicated CM functies (!) in te zetten en is er nog een CI breakdown te vinden in fig. 14 op pg 39 van 33 verschillende systeemcomponenten. Voert mij weer terug in de tijd naar mijn eerste job waar er 2 man full-time bezig waren om de oneindige stapel changes te verwerken in Infoman (een prehistorisch mainframe Incident-, Problem- en CMDB-tool als er weer eens wat VTAM terminals waren verhuist.
Ik betwijfel dit soort CMDB’s nog bestaan en daadwerkelijk functioneren.
Wat de governance betreft: mijn persoonlijke verwachting is dat de business op termijn zal erkennen dat ze die rol zelf niet meer kan vervullen. Bij eventuele incidenten en fouten zal men in de toekomst gaan wijzen naar de cloudprovider. Zo zal de Rabobank dan gaan zeggen: onze functionaliteit werkt in principe, maar de transporteur van die functionaliteit laat het in dit geval afweten. Een beetje zoals de NS met Prorail omgaat.
@KJ … zelf ook tijd met Infoman mogen werken, waarbij we alle zelfs zover gingen dat de definities voor het aankomend weekend konden genereren.
In de CMDB zat dus inderdaad het verleden, heden en de toekomst,
Dit kon echter alleen maar omdat het mainframe hierarchisch opgebouwd is, en mensen niet zelf allerlei dingen kunnen verhuizen/toevoegen zonder dat dat gedefinieerd is aan de beheerszijde. Van de ene kant een starre omgeving en zo flexibel als een loden deur, maar van de andere kant daardoor wel zo stabiel als wat.
Wat CMDB betreft was het vroeger pro-actief, en vandaag de dag veel meer reactief, wat de toegevoegde waarde van CM niet ten goede komt helaas.
@PaVaKe
Dat klopt inderdaad, het grote voordeel van Infoman vond ik de onovertroffen shortkeys, waarmee je heel snel op een bepaalde plek in de applicatie terechtkwam.