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.
@KJ
Dat CMDB nog uit stoomtijdperk komt, waarbij de informatie op rails kwam en niet op tijd zorgt ervoor dat er nog weleens verkeerd tegen het proces Configuratie Management aangekeken wordt. De link naar COBIT komt echter uit de tijd van nu omdat IT governance onmogelijk is zonder een configuration management systeem. Je kunt niet ‘In Control’ zijn als je niet weet wat je hebt en hoe dit aan elkaar gerelateerd is. Om complexe systemen beheersbaar te houden zul je niet alleen processen op papier moeten hebben maar ook de discipline om ze te volgen.
Het is een publiek geheim dat veel organisaties alleen op papier ‘In Control’ zijn door organisatorische olifantenpaadjes, er wordt in de praktijk vooral afgeweken van het proces dat de basis vormt van vrijwel elk beheerssysteem. De business is dan ook één van de grootste stakeholders van een goed configuratie management proces want verlies aan imago en veranderende wetgeving staan als business risico’s hoger genoteerd dan IT verstoringen.
Bij Knight Capital werkte de systemen perfect maar waren ze door slecht configuratie management in 45 minuten bankroet. Kan me ook foutje van Royal Bank of Scotland herinneren met vergaande gevolgen en zo zijn er nog wel wat meer grote en kleine voorbeelden die terug te herleiden zijn op slecht configuratie management.
@Ewout
In werkelijkheid is de informatie die jij met het woord CMDB aanduidt verspreid over verschillende bronnen. In een doorsnee SAP ERP Systeem bijvoorbeeld is de configuratie betreffende de SAP systemen opgeslagen in de LMDB van de Solution manager (een separaat type SAP System bedoeld voor maintenance en life-cycle support). De exacte software versies van al het maatwerk staan in het SAP Development Systeem. De cloud provider die SAP ERP systemen aanbiedt heeft zelf weer een real-time overview van deze services (welk systeem draait op welke VM die weer draait op welke hypervisor host) en de afdeling contracten heeft wellicht weer een applicatie waarin alle software licenses zijn geregistreerd etc etc.
Aangezien voor de complete IT governance meerdere partijen verantwoordelijk zijn (functioneel veelal de business, infrastructuur ligt bij de cloudprovider) is ook die informatie verspreid opgeslagen.
Verder denk ik dat de cloudprovider er ook een groot belang bij heeft om de controle te blijven behouden, want ook daar geldt dat reputatieverlies en mogelijke boetes en claims tengevolge van een datalek de nodige verliezen kunnen veroorzaken. Een cloudprovider heeft zelf tenslotte ook een business.
De CMDB is een abstractie omdat de gegevens die nodig zijn voor governance verspreid liggen opgeslagen zowel bij de business als bij de cloudprovider. Ik zie geen voordeel in het feit dat al die informatie in een enkele database zou zitten.
Je zou zelfs nog verder kunnen gaan en de ook governance kunnen uitbesteden:
http://www.zdnet.com/something-to-ponder-a-data-center-free-enterprise-7000029365/
@kj
Als eerste zei ik niet dat je één alles omvattende CMDB moet hebben, ik stelde dat CM uit een framewerk met meerdere tools bestaat. Het gaat dus om het linken en aggreren van informatie uit verschillende repositories welke niet eens een database hoeven te zijn. CMDB is dus meer een abstractie dan een database waarbij het wel handig is dat je informatie gestructureerd opslaat. Hoe gedetailleerd dat moet is afhankelijk van de rapportage naar de stakeholder waarbij ik me kan voorstellen dat een CIO minder en een architect meer detaillering wil.