Een jaar of zes geleden schreef ik een artikel voor een computermagazine over de al jaren gaande strijd tussen de business en it, zeg maar het business it-alignment probleem. De reden voor dat artikel was de toenmalige hype rond virtualisatie, omdat de business toch altijd weer als het kind op Sinterklaasavond is: vol verwachting klopt hun hart, wie de koek krijgt en wie de gard.
‘De vele technologische ontwikkelingen en snel veranderende manier van werken voeden de verwachting dat it snel, kosteneffectief en flexibel mee kan gaan in de nieuwe trends.’
Achter welk trends business aanloopt blijft voor de it altijd onduidelijk maar één trend die al een tijdje gaande is gaat om de wet van Moore. De technologische ontwikkelingen laten namelijk een trendbreuk zien. Zo schuurt die wet al een tijdje met de boekhouding omdat de technische erosie sneller gaat dan economische afschrijving, technologie die vandaag duur is kost morgen (bijna) niets meer. Dat zorgt dus voor een spanningsveld omdat de bedrijfseconomische benaderingen in de aansturing van de it hierdoor uiteindelijk altijd mank gaan. Een ander probleem is dat de meeste software architecturen geen gelijke tred houden met de techniek en veel applicaties hebben dan ook nog geen voordeel van de parallellisatie met multi-cores of uitschaling via virtualisatie. Batch georiënteerde architecturen bewegen wel richting transactie- en interactieve oplossingen maar die transities kosten tijd. Veel bedrijfskritische services zijn dan ook minder flexibel dan business denkt.
‘A majority of IT departments are deploying virtualization, but still most don’t feel comfortable with tools and technology they have in place to manage application performance or troubleshoot the virtual environment…when asked what the primary troubleshooting problem was, 78 percent said identifying the problem source.’ – Survey conducted by Network World
Luchtkastelen
Ik loop dus regelmatig tegen de perceptieverschillen aan omdat uitgangspunten bij projecten niet kloppen. Vertaling van sla’s naar de techniek gebeurt dan vaak ook nog op wonderbaarlijke wijze omdat virtualisatie ook nog weleens als een placebo gebruikt wordt tegen een chronisch tekort aan kennis. Dit niet alleen door de ‘technology debt’ die er in menige infrastructuur zit in de vorm van oude code, maar ook door het stelselmatig nalaten van capaciteitstesten. It lijkt aangestuurd te worden als oude de kinderserie Tita Tovenaar waar de tovenaarsleerling in haar handen klapte als de dingen niet gingen zoals ze wilde en alles stil stond.
Toen ik zes jaar geleden over het business-IT alignment probleem schreef voorzag ik dan ook al problemen met de hype van vitualisatie omdat deze vooral ging om service delivery en geen focus legde op service support, het stukje beheer dat vaak als personeelskosten in de boekhouding staat. Dit mede doordat de aansturing van de it steeds vaker gedaan wordt via asset management waar de relaties tussen de geregistreerde componenten ontbreekt. Hierdoor is het moeilijk om de waardeketens in de it te kunnen bepalen en hoewel enterprise architectuur (EA) dit probleem probeert op te lossen staat deze discipline echter op achterstand zoals Gartner ook stelt:
‘By 2016, 15 percent of organizations will integrate IT Service View with EA tools, up from a modest 1percent today.’
TCO of ToC
Nu gaat het naar mijn opinie hier dus niet om een asset management systeem waarmee vooral gestuurd wordt op de Capital Expenditures (Capex), de bedrijfseconomische aansturing van de it, die, zoals ik al stelde, mank gaat door een trendbreuk in de wet van Moore. Zo werkte het idee van een CMDB nog goed in batch georiënteerde architecturen, maar schiet het te kort in alle transactie gerichte oplossingen. Kosten voor het netwerk worden vaak niet eens doorbelast terwijl die belasting steeds meer toeneemt. Nu komt wijsheid pas met de jaren, zoals we ook tot ontdekking komen dat internet goedkoop is maar niet veilig. Kijkend naar de trend in de it lijkt het er dus op dat business zich zelf telkens opnieuw in de nesten werkt, omdat er niet verder gekeken wordt dan functionaliteit en kosten.
Mogelijk ten overvloede, maar de doorbelasting van resources zegt niets over de totale kosten van een services en al helemaal niets over de toegevoegde waarde. Een doelmatige (efficiënte) inzet van middelen is hierdoor dan ook lastig te beoordelen. Opmerkelijk vaak blijkt het reclaimen van resources achterwege te blijven waardoor virtuele omgevingen dus even statisch zijn als weleer, een lagere fysieke server footprint zorgt dan ook lang niet altijd voor lagere kosten.
‘In IT operations, all the hype is around configuration management databases as the means to solve all problems. Eventually, another management database related to performance and capacity will emerge.’ – Gartner.
Hypocris(i)e
Business it-alignment is vaak een zwarte pieten discussie door tradities in de boekhouding of organisatorische aansturing. De klaaglijn vanuit incident management helpt ook niet echt om dit probleem op te lossen, zeker niet als er geen aansluiting op de events vanuit de technologie is. De trend van oplopende resource belasting geeft een indicatie van een activiteit maar dat kan dus zowel een nieuw business initiatief als een aanval zijn. Beveiliging zorgt dan ook voor de nodige spanningen tussen business en it terwijl de kosten daarvan vaak onduidelijk zijn. De business kijkt ondertussen verlekkerd naar de speelgoedcatalogus van de cloud, maar zoals ik al aangaf zijn er nog wel enige perceptie verschillen. Afgelopen zes jaar bleken deze grotendeels voort te komen uit de processen die geen gelijke tred houden met de technologische ontwikkelingen. Dit betrof zowel business als beheer processen. Opmerkelijk vaak zijn de verschillen tussen perceptie en realiteit het grootst bij organisaties die hun it uitbesteed hebben. Uit het oog, uit het hart zorgt dan ook niet echt voor een betere relatie tussen de business en it.
‘In the end, all business operations can be reduced to three words: people, product and profits. Unless you’ve got a good team, you can’t do much with the other two.’ – Lee Iacocca
@Ewout
Klopt en mee eens. In de meeste produkten kan de klant kiezen wat er geadministreerd wordt. Wat wordt als een CI beschouwd is de vraag. Een compleet SAP systeem of ook de fysieke en virtuele servers waar het systeem op draait (die kunnen nogal eens wisselen), licenties, software stacks, routers, firewalls etc ? Zowiezo is het schier onmogelijk om de relaties tussen de CI’s bij te houden, dus het herleiden van een probleem naar diverse CI’s via de relaties ertussen, zit er niet in.
Wat er geadministreerd moet worden zijn de gegevens die worden gebruikt voor het opstellen van de factuur naar de klant.
– Welke services heeft de klant in gebruik
– Hoeveel : CPU, Memory en Disk is er gealloceerd per service
– Voor pay per use bijvoorbeeld : wat is het gemiddelde van de 3 hoogste CPU pieken. Maar uiteraard zijn ook de gealloceerde resources verdisconteerd in dat bedrag.
Wat betreft hardware afschrijvingen heb ik de indruk dat er, zolang er geen service degradatie plaatsvindt binnen de cloud een stuk langer gedraaid wordt op oudere hardware, omdat dat nu eenmaal meer oplevert.
De klant ziet vaak alleen het viruele OS en is zich niet bewust van de onderliggende hardware. Zolang een klant geen expliciete klachten heeft en de SLA niet wordt overschreden (hoewel daar vaak niet eens op wordt gemonitord door die klant) niets vervangen wordt.
@KJ
Een CMDB zou meer een template dan een product moeten zijn, de vraag wat je vastlegt is namelijk uiteindelijk weer afhankelijk van de best practice die je volgt.
Ik zal niet zeggen dat elk probleem is op te lossen als je de relaties weet maar wat meer inzichtelijkheid dan nu gebruikelijk zorgt wel voor meer inzicht. Of je dat aggregeerd van business naar service, van service naar applicatie, van applicatie naar platform en van platform naar configuratie of op een andere manier is niet zo belangrijk maar nu ontbreken deze koppelvlakken nog vaak.
Ook wel handig als je van de koppelvlakken weet wat ze kunnen, niet alleen in capaciteit en beschikbaarheid maar ook ondersteuning want aan de achterkant zijn er nog weleens SLA’s die niet kloppen met de verwachting.
@Ewout
Wat ik zie in onze cloud is dat voor ieder systeem wordt bijgehouden waar (op welke virtuele server) de bijbehorende services (applications en database) draaien op elk moment. Elke wijziging in de toestand die services (up/down verplaatsing naar andere virtuele server etc.) wordt automatisch bijgehouden zodat er een real-time image bestaat van de toestand van alle services. Vanuit de monitoring wordt voor iedere virtuele server de load uitgedrukt in CPU geaggregeerd per uur en per dag.
Billing geschiedt op basis van de 3 hoogste dagelijkse CPU percentages per maand. Hierin zit ook de aangeboden capaciteit als totaal verdisconteerd. Immers als klanten niets zouden gebruiken zouden ze in theorie niets hoeven te betalen, hetgeen uiteraard niet het geval is.
Aangezien de hardware onafhankelijk is van de gevirtualiseerde services, kan daarvoor een aparte administratie worden gevoerd tav. de afschrijvingen. Zoals gezegd heeft de klant hier geen zicht op en wordt oudere hardware langer gebruikt dan dat in conventionele omgevingen gebruikelijk was.
In het algemeen geldt dat een cloud bedrijf geen extra inspanningen doet boven op de SLA om de klant een financieel voordeel te bezorgen. De verhouding is zakelijk en de klant dient zelf in de gaten te houden of de kengetallen genoemd in de SLA niet overschreden worden.
Pro-activiteit is nul en bestaat niet meer. Iedere klacht wordt als een nieuw incident behandeld en opgepikt door iemand in het verre oosten. Slechts als je erg veel geluk hebt weet er iemand in de cloud een incident naar probleem te herleiden en er een oorzaak voor te vinden en die vervolgens te verhelpen. Meestal blijft het bij incidentbestrijding en wordt er gegrepen naar het verhogen van capaciteit, want dat is makkelijk en levert ook meer op.
Waar een conventionele ICT afdeling nog wel eens aandrong op applicatie en systeemonderhoud (patches/upgrades), blijft dit in een cloud meestal achterwege, vooral als de klant aangeeft daar geen trek in te hebben. Dit resulteert in een toename van IT-debt (http://www.gartner.com/newsroom/id/1439513).
Ondanks de virtualisatie blijkt het verhuizen naar een andere cloud toch vaak niet zo simpel en goedkoop te zijn als vaak wordt gesuggereerd. Het gevolg is dat een cloudbedrijf in staat is om zijn (kleinere) klanten behoorlijk onder druk te zetten.
Wellicht een wat somber verhaal, maar het is wat ik waarneem in de praktijk.
@KJ
Een cloud provider zit in de business van resources verkopen, liefst overgecommiteerd om marge per vloertegel te verhogen. Dat ze geen enkel belang hebben om het verbruik te verlagen is dus logisch want dat hoort bij het business model. Net als dat ze zich niet druk maken om de code die er op draait, zolang de rekening betaald wordt mogen het ook allemaal bogomips zijn want de chargeback is geaggreerd naar de service die ze leveren, niet naar de business service die de klant afneemt. Hetzelfde zie je met incidenten, de servicedesk wordt afgerekend op de tijd die besteed wordt en niet of de oplossing goed is maar ik had al wat over KPI’s gezegd.
Ik lees in veel van de reacties hierboven juist dé reden waarom business en IT vaak onvoldoende aligned zijn: we hebben het als IT nog altijd teveel over de techniek i.p.v. dat we op een afdoende manier de vertaalslag kunnen maken naar begrijpelijke concepten voor de business! Zoveel mogelijk in Jip-en-Janneketaal. We vliegen nog altijd teveel projecten vanuit een IT perspectief aan en we zijn nog altijd onvoldoende in staat om de juiste vragen te stellen aan de business en goed te luisteren naar de antwoorden. IT is immers geen doel op zich, maar een essentiële steunpilaar die organisaties zou moeten helpen hun bedrijfsdoelstellingen te verwezenlijken.
@Ralf
Als we het tegenwoordig over IT hebben zullen we onderscheid moeten maken tussen de business IT, welke om de overdracht van informatie gaat en de technische IT die zich meer richt op de infrastructuur om overdracht te faciliteren en in de breedste zin van het woord informatie te beveiligen. Je kunt niet stellen dat die overdacht van informatie zonder techniek kan, van grottekening tot infographic is het gevolg van de technologische ontwikkelingen.
@Ewout
Helemaal eens, maar ik zie gewoon dat die belangrijke brugfunctie tussen demand (business IT) en supply (technische IT) nog altijd onvoldoende ingevuld wordt bij veel organisaties.
@Ralf
Is gemis aan een brugfunctie niet mede het gevolg van de opdelingen die er gemaakt zijn en slechte (fact free) communicatie daar tussen?
De demand kant denkt nog weleens dat het lopende band processen zijn, waarbij alles in een gelijk tempo gaat aan de supply kant. In werkelijkheid is het meer Assemble-to-Order waarbij de verschillende halffabrikaten allemaal op andere snelheden lopen. Ik stelde al dat de vertaling van SLA’s naar techniek soms op een wonderbaarlijke wijze gedaan wordt, leveranciers beloven schaalbaarheid maar vertellen er niet bij dat horizontale of vertikale schaling twee compleet verschillende benaderingen zijn. Dat snapt technische-IT maar business-IT meestal niet omdat ze in functionaliteiten in plaats van capaciteiten denken.
@Ewout
Ongetwijfeld. Maar de business vraagt mijn inziens terecht om functionaliteiten, dus iemand moet die beide ’talen’ voor alle partijen begrijpelijk kunnen maken. Mensen die de juiste vragen kunnen en durven stellen aan en goed kunnen luisteren naar de antwoorden van zowel IT als Business. Functioneel Beheer is daar een goed voorbeeld van, maar wel met een solide IT achtergrond, flinke business- en procesmanagement kennis en bovenal de juiste soft skills. En dan met name dat laatste…
@Ralf
Ik zeg NIET dat de business onterecht om functionaliteiten vraagt, ik zeg alleen dat vertaling ervan naar mogelijkheden nog weleens scheef gaat. E-mail functionaliteit kun je op minimaal 3 manieren invullen, elk met een eigen belasting van de resources. Laat ik stellen dat ik nog weleens prachtige functionele ontwerpen zie die technisch ingevuld zijn op de meest inefficiënte wijze.