Verschillen tussen business en IT

Voor het beheren van technologie is samenwerking nodig tussen business en IT maar deze gaat vaak stroef. Hoe komt dit eigenlijk en hoe kunnen we hier mee omgaan? Hieronder een situatie waarin de communicatieproblemen duidelijk naar voren komen.

“Een bekende uitspraak van IT`ers is: ‘Als de kastjes maar zoemen en de lampjes groen zijn’. Wanneer de kastjes zoemen en de lampjes groen zijn, gaat IT er vanuit dat de dienst werkt en dat de kwaliteit van de techniek optimaal is. Dit terwijl alleen bevestigd is dat de afzonderlijke elementen werken. Wanneer er vervolgens veel telefoontjes bij de business binnenkomen dat de dienst niet goed werkt, is er een probleem. De lampjes zijn immers groen bij IT dus deze zal de problemen ontkennen.”

In dit artikel worden een tweetal verschillen tussen business en IT uitgelicht waardoor samenwerking wordt bemoeilijkt.

Focus
Een IT-afdeling is gefocust op kostenbeheersing en een Business afdeling is gefocust op genereren van de inkomsten. Dit leidt er toe dat business en IT praten in verschillende termen en werken met verschillende doelen wat communicatie bemoeilijkt.

Cultuur
De medewerkers van een IT afdeling worden vaak getypeerd als ‘nerd’ en hebben zeer specifieke diepgaande kennis over techniek. Dit leidt bij de IT`ers tot het denken in systemen, netwerken, programmeertalen en protocollen. De medewerkers van de businessafdeling zijn veelal vlotte, verbaal vaardige personen met kennis van marketing, bedrijfsmodellen en –processen en inzicht in de wensen van de klant. Business en IT mensen zijn vaak verschillende mensen met verschillende kennis en interesses.

Dit zijn natuurlijk niet alle verschillen tussen business en IT. Wanneer je meer voorbeelden of verschillen weet te benoemen graag reacties in de comments!

Tips voor capaciteitsplanning van Flickr

In totaal staan er meer dan vier miljard foto’s op Flickr en daar komen elke minuut zo’n 5000 foto’s bij. Om deze groei in goede banen te leiden is er een goede capaciteitsplanning nodig. Hiervoor verantwoordelijk is John Allspaw, Operations engineer van Flickr.

Op basis van zijn ervaringen bij Flickr heeft John een boek geschreven. In dit boek staan een groot aantal tips en trucks uit de praktijk van capaciteitsplanning. In deze post worden een aantal van deze tips uitgelicht.

Veiligheidsfactor
Elke infrastructuur heeft een limiet aan pagina’s die het kan serveren. Zoek met behulp van goede tools, metrieken en complete, gedetailleerde data deze limieten. Bereken deze limieten op basis van data uit de productieomgeving om het plafond accuraat te kunnen berekenen. Bedenk daarnaast tevens een veiligheidsfactor. Het plafond min de veiligheidsfactor is de eigenlijke grens die je zou moeten hanteren. John stelt dat 15% een goede veiligheidsfactor is. Deze factor kan vervolgens incidentele pieken in de vraag opvangen.

Voorspellen
Maak gedetailleerde voorspellingen van de capaciteit van de infrastructuur door verschillende gebruiksdata te combineren en gebruik te maken van statistische modellen. Het product hiervan moet de tijd zijn dat de huidige infrastructuur nog vooruit kan.

Dashboard
Maak een mooi dashboard waarop resterende capaciteit en het resterend aantal dagen voordat er actie nodig is. Dit helpt jezelf, collega`s en management om inzicht te krijgen in de capaciteit zonder direct in de data te hoeven duiken.

Lopende bottleneck
Er is altijd een bottleneck. Het oplossen van een bottleneck leidt alleen tot een verplaatsing ervan. Focus dus niet alleen op de bottlenecks maar bekijk de infrastructuur als geheel.

Zet onderdelen uit
Wees voorbereid om onderdelen uit te schakelen wanneer het capaciteitslimiet wordt bereikt. Bij Flickr zijn er 140 items die uitgeschakeld kunnen worden om de belasting van de servers te verlagen. Dit geeft je handgrepen tijdens panieksituaties.

Je ontkomt niet aan verstoringen
Aan verstoringen ontkom je niet dus zorg dat je hierop voorbereid bent. Als verstoringen optreden zorg dan dat je de bezoekers een mooie pagina kan laten zien met een nette boodschap. Vertel je bezoekers tevens wat er aan de hand is, dat wordt over het algemeen gewaardeerd.

LinkedIn groep

Voor een meer gericht contact met de NLCMG community is er een LinkedIn groep. Deze staat bekend onder de naam NLCMG. Aanmelden is eenvoudig, maar wel gemodereerd.

In de LinkedIn groep worden ook links naar interessante andere sites en nieuwsitems geplaatst. Deze blog blijft wel actief, omdat dat voor een groter publiek (en nieuwkomers) interessant is.

Meldt je dus aan bij de LinkedIn groep!

IT business alignment

Hoe krijgen we de IT opgelijnd met de business? Hoe kunnen business en IT het eens worden over de kwaliteit van de IT? Als we naar incidenten in de dienstverlening kijken zien we dat die vaak worden veroorzaakt door defecte of overbelaste componenten. Het maakt daarbij niet uit of dat een technisch falen is of een configuratiefout.

De kwaliteit van die componenten is natuurlijk best uit te drukken in getallen. Denk daarbij aan de benuttinggraad van een server of netwerkverbinding. Het zal duidelijk zijn dat een te hoge benutting kan leiden tot vertraging in de dienstverlening. Maar hoe hoog is te hoog voor de business?

De kwaliteit van de business is bijvoorbeeld te meten door naar klanttevredenheid te kijken. Maar wanneer wordt de klant of gebruiker ontevreden als de applicaties steeds langzamer gaan lopen of regelmatig uitvallen? Klanttevredenheid laat zich moeilijk vertalen naar technische prestatie-eisen.

Daarom kijken we steeds vaker naar applicatie prestaties, in plaats van technische prestatie. De responstijd van de dienstverlening in interactie met de gebruiker is een maat (of metric) die zowel door de business als door de techniek begrepen kan worden. Dat is dus een goede kandidaat om de business IT alignment mee vorm te geven.

Zie voor meer achtergrond over application performance management en manieren om het in te richten mijn artikel De inrichting van service level agreements in ketens, verschenen in ITSMF Jaarboek IT beheer, 2002.

Logo voor NLCMG

Enkele enthousiastelingen hebben een concept logo ontworpen voor de NL CMG afdeling. Het resultaat is momenteel te zien bij de LinkedIn groep, die te zien is via deze link. Nu is de tijd om daar nog commentaar en suggesties bij te leveren.

Performance problemen in de praktijk

Een van de manieren om ons vak te profileren is om 'success stories' te schrijven over projecten waar u trots op bent. Dat is een mooie manier om aanpak en resultaat te presenteren. Uw bijdrage publiceer ik graag, desgewenst onder uw naam. In de tussentijd zal ik een van mijn eigen voorbeelden geven.

Een jaar of wat geleden werd ik betrokken bij een personeelsinformatiesysteem dat tijdens de uitrol steeds trager werd, maar niet voor alle soorten gebruik. De applicatie kende een PC deel, dat over het netwerk met servers communiceerde. Bij het intakegesprek bleek men al verschillende hypotheses voor het probleem te hebben, maar geen daarvan verklaarde alle verschijnselen.

Onze aanpak was toen om systematisch alle bronnen van performance problemen op te sommen: de desktop, het netwerk en de servers. Voor elk van deze hypotheses richtten we een meting in. Dat klinkt trouwens makkelijker dan het is.

Conclusie uiteindelijk: er waren inderdaad twee problemen. Door onhandig programmeren werd steeds een hele tabel over het netwerk naar de PC gestuurd. Dat werd trager naarmate de uitrol vorderde, omdat die tabel steeds groter werd. Verder was de software aan de PC kant gewoon erg veeleisend. Uiteindelijk moest de applicatie flink worden herschreven.

Meten van Web 2.0 toepassingen

Moderne Web 2.0 sites en social networking toepassingen worden steeds afhankelijker van andere services. Zo zijn er allerlei programma's die rechtstreeks op de Twitter API (programmeer interface) werken. Als de Twitter API het niet of langzaam doet, hebben die dus een probleem.

WatchMouse heeft vandaag een nieuwe dienst gelanceerd die laat zien hoe verschillende van deze API's het doen. De dienst heet api-status.com, en de Twitterstoring van vandaag is te zien op deze pagina.