Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Configuratiebeheer is business-IT alignment

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5085562). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

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.

@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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×