Olvasom egyszer a virtualization.info-n az IDC épp aktuális jelentését, ebben az áll, hogy

“Microsoft saw its virtualization license shipments decline 16% year over year, due to the continued depreciation of Virtual Server 2005. However, Hyper-V showed a sharp increase of 54%, one year after its official launch and entrenching itself into 4th place while it cannibalizes itself into the number 3 position, past Virtual Server 2005.”

Rögtön utána olvasom a hwsw.hu-n a Microsoft negyedéves teljesítményéről az összefoglaló cikket, abban is ezt a részt:

“Különösen jól, mondhatni érthetetlenül jól teljesítettek a cég szervertermékei. A Servers and Tools divízió forgalma nem csökkent, hajszállal felülmúlta a tavalyit, ami az erősen megzuhant vállalati kiadások közepette egészen meglepő teljesítmény - az x86 szerverek fogalma például nagyjából ötödével eshetett vissza a negyedév során. A Microsoft a Windows Server, SQL Server és System Center termékek eladásainak erősödésével magyarázza a produkciót. Az üzemi nyereség 23 százalékkal 1,28 milliárdra erősödött.”

Köztudott, hogy a Microsoftnak nincs “virtualizációs” licence. Van neki Windows-a, a virtuális gépek, meg az alattuk dolgozó Hyper-V kiszolgálók felügyeletét pedig a System Center termékek látják el.

Most akkor kinek higgyen az ember? Az IDC piackutatásának vagy a Microsoft tőzsdei jelentésének?

Csak vicceltem.

Az előző részben azt taglaltam, hogy mérete ellenére a Microsoft viszonylag hamar felült a virtualizáció “vonatára”, de a ma is érvényben lévő stratégia csak évek alatt állt össze – körülbelül 2005-re. Kárhoztatták is eleget ezért. Azóta sok víz lefolyt a Dunán, a Microsoft pedig előrukkolt jópár termékkel, amely a virtualizációs üzlethez tartozik. A teljesség igénye nélkül – 2005 óta:

1. Virtual PC 2007; SP1; Windows Virtual PC
2. Microsoft Enterprise Desktop Virtualization (MED-V)
3. Softgrid 4.1; 4.2; App-V 4.5
4. Virtual Server 2005 R2; R2-SP1
5. System Center Operations Manager 2007; SP1; R2
6. System Center Configuration Manager 2007; SP1; R2
7. System Center Data Protection Manager 2007; SP1
8. System Center Virtual Machine Manager 2007; 2008; 2008 R2
9. Windows Server 2008 with Hyper-V; SP2; R2
10. Hyper-V Server 2008; SP2; R2
11. Microsoft Assesment and Planning 3.0; 3.1; 3.2; 4.0
12. Offline Virtual Machine Servicing 1.0; 2.0

Azt már nehéz jelezni, hogy a 2008 R2-ben connection broker található, meg a VDI megoldáshoz kiegészítő szolgáltatások. Szintén a 2008 része a RemoteApp (mint a prezentáció-virtualizáció alapja); hogy megújult a Microsoft Operations Framework; új "Infrastructure Plannig Guide”-ok jelentek meg a korábbi WSSRA helyett. Új licencek jelentek meg, mint a VECD, az SMSE, az SMSD, az ECI vagy a VDI. A desktop operációs rendszer is kiegészült új fejlesztésekkel, mint az RDP7. Végül de nem utolsó sorban úttörő lépéseket tett a Microsoft az SVVP program létrehozásával vagy azzal, hogy vállalati szabvánnyá tette a termékei számára a virtualizáció támogatásának követelményét, valamint meglepte a piacot a Linux IC nyílt forráskódúvá tételével.

Akárhogy is, a piac mégis csak a VMware utáni, második szereplőként tekint a Microsoftra. Sőt! Itt-ott felmerül, hogy tulajdonképpen a Microsoftnak rossz a virtualizáció. Most akkor fontos, vagy sem? Lehetőség, vagy veszély?

Meglátásom szerint a Microsoft úgy tekint a virtualizációra, mint az iparág egyik meghatározó trendje, amely az IT rendszereket alapjaiban alakítja át, és amely potenciálisan a teljes IT ökoszisztéma üzleti modelljét befolyásolhatja. Olyan alapvető innováció, amelyet nem lehet figyelmen kívül hagyni (Cisco), nem lehet ignorálni (Google), lebecsülni (Oracle), mellőzni (IBM). Ha nem tudod megakadályozni, akkor állj az élére! Értsd meg, tedd magadévá, használd fel arra, hogy átalakulj és túlélj. – Szerintem a Microsoft így tekint a virtualizációra. Belülről így látom.

Profitál-e a Microsoft a virtualizációból, és ha igen, hogyan?
Igen, profitál, méghozzá sokféleképpen. Rövidtávon:

• A szerverkonszolidáció és a Windows szerver licencelése miatt nőtt a magasabb hozzáadott értékű Datacenter verziók eladása. Ez jó az ügyfélnek, mert korlátlan számú virtuális gépet üzemeltethet processzoronként, és jó a Microsoftnak, mert homogénebb és korszerűbb infrastruktúrák jönnek létre, amelyekhez könnyebb újabb szoftvereket kínálni. Persze most éppen válság van, és ez a vasbeszerzéseken és ez a szerver operációs rendszerek értékesítésén látszik. Ezzel együtt én azt tapasztalom, hogy éppen a virtualizáció miatt a korábban frissítésvédelem (SA) nélküli kiszolgáló licenceket részben kidobják és új, SA-s licenceket vásárolnak az ügyfelek.
• Az alkalmazás- és a desktop virtualizáció a (Microsoftnál legalábbis) a nagyvállalati Windows licence-hez kötődik. Ez megint csak megújult architektúrát, korszerűbb rendszereket és a Windows licenceken keresztül árbevételt jelent.
• A virtualizáció belépési lehetőség (enabler technology) akár az adatközpontok, akár a desktop infrastruktúra felügyelet megújítására. Ha nyerünk egy virtualizációs tenderen, akkor az ügyfelek többnyire a teljes rendszerfelügyeletüket megújítják Microsoft alapon. Ha veszítünk, akkor – bár szerver licencek tekintetében nincs különbség – a menedzsment vonatkozásában árbevételtől esünk el. Világszinten a Microsoft ezen a területen relatíve jól muzsikál. Egyrészt a “Server and Tools” (S&T) üzletág szenvedte el a legkisebb visszaesést az utolsó, legdurvább negyedévben (-6%), éves szinten még növekedett is, másrészt a az S&T-n belül működő System Center részleg jó eséllyel pályázik a következő milliárd dolláros üzlet címre. Mindezt úgy, hogy mára mind a SCOM, mind pedig az SCCM a világ legnagyobb installált bázisával rendelkezik a maga kategóriájában, a Gartner elemzésekben pedig “Leader” illetve “Challenger” minősítéseket kapunk.

Mindezek azonban – bármennyire is jövedelmezők – csak részsikerek ahhoz képest, amit azzal lehet nyerni, hogy egy korszerű architektúrával és sikeres projekttel elnyerhető az ügyfél bizalma és “megbízható tanácsadóvá” (trusted advisor) lehetünk. A megbízható tanácsadó potenciálisan újabb és újabb üzleteket hozhat – hosszútávon.

A fenti előnyök “azonnaliak”. Azt gondolom azonban, hogy vannak hosszútávon jövedelmező dolgok is, amelyek jelenleg még akár viszik is a pénzt. Ilyen az Azure. Bizonyos, hogy az Azure rugalmassága mögött a virtualizáció (is) ott van. Hogy ez, vagy ilyen lesz-e a jövő informatikája, azt nem tudni. Annyi viszont bizonyos, hogy a jövő az automatizmus, az önhangoló, adaptálódó rendszereké. A Microsoft stratégiájából fakadóan ezek a termékek meg fognak születni. Ha az üzleti modell is releváns lesz a termékek mellett, akkor a Microsoft nem lesz vesztese a virtualizációs csatának.

Veszélyt jelent-e a Microsoft számára a virtualizáció?
Azt gondolom, hogy csak abban az esetben, ha a virtualizáció indukálta változásokat és a változások üzleti modellekre gyakorolt hatását a Microsoft nem ismeri fel. Mivel azonban ma már elég sok stratéga dolgozik a témán, és a Microsoft derékig benne áll a virtualizációs piacban, ennek az esélye kicsi. A virtualizáció jelentett múltban a Microsoft számára elmaradt bevételt, hiszen ha lett volna olyan “okos”, hogy a VMware helyett feltalálja az x86-os hypervisort, akkor a  VMware árbevételének java a Microsofthoz csengett volna. Ha azonban megnézzük, hogyan fest a Microsoft árbevétele az elmúlt harmincegynéhány évben, akkor ez nem látszik (Saját képeim a 2007-es MGXFY08-ról – a következő évben az árbevétel 60 milliárd dollár volt, majd a most záruló pénzügyi év végén 58,44 milliárd dollár volt, ez 3%-os csökkenés, a vállalat történetében először történt ilyen):

Külön érdemes foglalkozni a desktop virtualizáció témakörével. Sokan azt gondolják, hogy a virtualizáció egyúttal a Windows desktop, egyáltalán a Windows végét is jelentheti egyben. Ebben nem hiszek. A mai virtualizációs technológiák ugyan sokat gimnasztikáznak, de a végeredmény egy Windows gép becsomagolása és a használata. A Microsoft itt is veszíthet rendszerfelügyeleti árbevételt, de nem igazán látom, hogy tényleges Windows licence árbevételt veszítsen. – A böngésző ezzel szemben valód veszély a Windows világra, ez viszont nem témája ennek a cikknek.

Összegzés
A Microsoft számára a virtualizáció nagyon fontos. Óriási iparági trendnek tartjuk, egyúttal üzleti lehetőségnek is a rendszerfelügyelet és a felhő-informatika területén. Mivel a cég idejében meglátta mind a késlekedésből fakadó veszélyeket, mind a üzleti-potenciált, valójában a Microsoft a virtualizáció egyik nagy nyertese. Meglehet, hogy jelenleg még a VMware mögött, de a vele hasonló nagyságban lévő Cisco, Oracle és IBM előtt.

Bognár Attilának az előző cikkben feltett kérdése elgondolkodtatott. A Microsoft régóta itt van a virtualizációs piacon, de vajon mennyire fontos a cégnek ez a terület? Lehetőség, vagy inkább veszély? Ha lehetőség, akkor minek a lehetősége? Ha veszély, akkor milyen jellegű?

Kezdetek
Az egész – szerintem – azzal kezdődött, hogy a Microsoft létrehozta az MSN-t, 1995. augusztusában. Ekkor kezdődött annak a szerverparknak a kiépítése, amely 1998-ban kiegészült a Hotmail-lel, 1999-ben az MSN Messengerrel és még sorolhatnánk. Az egyre nagyobb szerverpark egyre komolyabb kihívást jelenthetett üzemeltetési szempontból. Gondolom részben ezért, részben meg a rendszerüzemeltetési piac vonzása miatt a Microsoft 2000 őszén licence megállapodást kötött a NetIQ-val, 2001-ben pedig kiadta a “Microsoft Operations Manager 2000” nevű terméket, amelynek legfrissebb utódja a “System Center Operations Manager 2007 R2”. Biztos vagyok benne, hogy a MOM 2000 nagy előrelépés lehetett a maga idejében, de gondolom azt is lehetett látni, hogy az óriási adatközpontok sokezer vagy sok tízezer szerverrel, elképesztő üzemeltetési feladatot jelentenek. (“For scale-out environments, management is not just important -- it's fundamental, and we're making it a major area of investment for Microsoft” – forrás innen.)

2001. egy másik szempontból is fontos éve. Ekkor jelent meg az 1998-ban alapított VMware nevű cég VMware ESX (Elastic Sky X) rendszere. A VMware, akárcsak a Google vagy Softricity, egy dotcom cég volt, amely – szemben a tényleges lufi vállalatokkal – egy valóban zseniális ötletet valósított meg, sőt, a lufi kipukkadása előtt az ESX-szel belépett a nagyvállalatokhoz, és a Google-höz hasonlóan óriásit alakított a maga területén. (Csak az időrend kedvéért: 1997-ben jelent meg egy Virtual PC nevű termék a Connectix-től Mac-re.)

A Virtual PC, meg a VMware Workstation – bár izgalmas termék volt – nem hozott földrengésszerű változást. Az ESX azonban más volt: aki tudta, hogy mi a hypervisor (mert tanulta az amerikai egyetemen, vagy éppenséggel használt a hatvanas években olyan az IBM gépeken), az hamar rájött, milyen potenciál van egy ilyen megoldásban és milyen változást hozhat egy adatközpont életében. Szerintem a Microsoft erre 2002. táján jöhetett rá, mert 2003 elején felvásárolta a Connectix-et, egy hónappal később pedig bejelentette a Dynamic System Initiative kezdeményezését. Későn történt mindez? Az első Xen is 2003-ban jelent meg, a Virtual Iron 2005 környékén fordul elő először a hírekben. A Sun Solaris container 2005-ben debütált. 2004. decemberi hír, hogy a RedHat és a Novell beépítik a Xen-t a saját rendszereikbe. Ha figyelembe vesszük a Microsoft méretét, diverzifikált erőfeszítéseit, azt kell mondani, hogy viszonylag gyorsan reagált az iparági változásokra. Persze nem szeretném azt állítani, hogy a Microsoft pontosan tudta, milyen lesz a jövő. De a sejtések nem voltak rosszak. Annyi bizonyos, hogy 2003 áprilisában a Direction on Microsoft által megjelentetett “Microsoft Management Roadmap Update” még nem tartalmazza azt a szót, hogy “virtual”, csupán azt, hogy a MOM és az SMS egy közös jelzőt kap, ez lesz a “System Center”. Egy évvel később megjelent a dolgozat frissítése, amely már megemlíti a Virtual Server-t is, de még érdekesebb az, amit a DSI-ről és az SDM-ről lehet olvasni. A 2004-es d dolgozat egyébként így kezdődik:

“Systems management is becoming a major priority at Microsoft: by the end of 2004 the company will deliver several new and substantially enhanced management products and technologies, and all development teams for systems management are now organized under a single leader, Kirill Tatarinov. While details about its radical and long-term Dynamic Systems Initiative (DSI) remain sketchy, the company will continue taking incremental steps to incorporate systems management into its entire business product line. These changes will deliver important benefits to customers even as work on DSI churns away in the background.”

Érdekes dolgok találhatók már ekkor a DSI-ról:

“A precise definition of the DSI is still evolving, but the company envisions it as a radical change in the way applications are developed, deployed, and operated over their life cycles. Most important: rather than support manageability through add-on, generic management products that incorporate little or no knowledge of specific applications or hardware, manageability will be built into applications, system software, and hardware from the outset.

DSI will accomplish this with a common management infrastructure that spans all elements needed for an application to function properly, and a System Definition Model (SDM) that will provide a Microsoft-standard method for building management knowledge into each hardware or software component during its design. Each component will have its own SDM, an XML document with all the information required to manage that component, including dependencies on OS components or other services, definitions of settings that can be configured through OS policy, definitions of variables and counters required to monitor the health of the component, and so on. Among other things, this will enable a new breed of business applications that use SDM information to form operational policies, and management tools which can detect when the overall system departs from those policies and flag what caused the departure.”

Mit is csinál a SpringSource?…

Visszatérve a Microsofthoz: a teljes kép, és az a fajta stratégia, amit ma is látunk, 2004 végén állhatott össze, és 2005. áprilisában hírdette meg a cég. Ekkor jelentette be, hogy hypervisort fog a Windows szerverekbe építeni; hogy a System Center termékcsalád képességeit kiterjeszti a virtualizáció irányába stb. stb.

Hogy hová csúcsosodott ki az DSI, az SDM, a virtualizáció (Hyper-V), a System Center és a Visual Studio együttesen? Nos, mindezen kezdeményezések, szabványok, termékek, szoftverek együttese tette lehetővé, hogy olyan szolgáltatások indulhassanak el a Microsoftnál, mint a Windows Azure.

Ah, és még valami: Igen, ezt is Hyper-V támogatja. Biztos, hogy nem érett még a nagyvállalatokhoz?

Folytatom

Ki a fene az a Joe Wilcox? – gondolhatjátok most páran. Nos, ő egy újságíró, és az EWEEK-en több blogot is vezetett. Ezek egyike a Microsoft-Watch. 2006. novemberében vette át a feladatot, és azt gondolom, hogy nagyon magas szinten végezte a munkáját. Az ő írásai révén értettem meg például:

• hogyan működik a Microsoft, mint üzleti vállalkozás.
• miért fontos a keresés témaköre
• miért fontos a mobil informatika
• hogyan működik a Microsoft marketingje
• milyen hibkat követett el a Microsoft a Vista piacra dobásakor és hogyan igyekszik azt elkerülni a Windows 7 bevezetése során.
• stb. stb.

Nem mondom, hogy mindig egyet értettem vele, de a gondolatai segítettek eligazodni nem csak a Microsoft, de a teljes IT iparág világában. Joe kritikusan, de igazságosan írt a Microsoftról, precízen elemezte az üzleti eredményeit, kommentálta a reklámjait, megjegyezte a vezető jóslatait, aztán megnézte teljesülnek-e. Fantasztikus módon ismeri a cég belső szerkezetét, vezetőit, elemzéseket írt, amikor valaki távozott, amikor valakit előléptettek, vagy átcsábítottak a konkurenciától.

Hát, most kirúgták. Recesszió van. Azt hiszem túl értékes a tudása, hogy egy másik orgánumnak ne kellene, úgyhogy előb-utóbb újra írogatni fog majd. Azért mégis sajnálom: munkanélkülésig, bizonytalanság – kemény világ, velünk is megeshet.

Ha látom majd hol bukkan fel jelezni fogom.

És még valami: több mint 100 webnaplót követek – néhányat nagyon alaposan, néhányat csak felületesen. Viszont csak 5 RSS előfizetésem van a mobiltelefonomban. A Microsoft-Watch az egyik – volt.

Miután megismerkedtünk a VDI rendszerek felépítésével és azokkal az előnyökkel, amelyet egy VDI rendszer hordozhat magában, most nézzük meg, milyen projekt kockázatokkal kell számolnunk a bevezetés során. Elöljáróban jelzem, hogy bár a cikk negatív kicsengésűnek tűnhet, ez a kockázat-feltárás jellegéből adódik. Az Interneten sok eufórikus cikk és bejegyzés olvasható a VDI-ról, s miközben világos, hogy a megoldásnak van helye a nap alatt, érdemes szembenézni a korlátaival és a megvalósítási lehetőségével, mert csak így lehet sikeres VDI projektet véghezvinni.

A kockázat mértéke több tényezőtől is függhet, én ezek közül négyet elemzek:

• Az informatikai szervezett érettségi szintje
• A tervezés
• A technológa
• A megváltozó folyamatok

Infrastruktúra érettség
Az Infrastruktúra optimalizációról már volt szó korábban is a webnaplóban, de nem árt az ismétlés. Eredetileg egy 2004-es Gartner kutatási dokumentációban született meg az infrastruktúra érettségi modell fogalma (Később az anyagot 2007-ben frissítették). Ezek szerint egy informatikai szervezet az alkalmazott technológia, a bevezetett folyamatok és a szervezeti tagok képzettsége szerint hat érettségi szintbe sorolható. A Microsoft átvette a Gartner eredményeit, és – egy egyszerűsített formában – alkalmazni kezdte. Az átmenet a két módszertan között jól következő az alábbi ábrán:

Az eredeti hat szintből négy lett, a lényeg azonban változatlan maradt. A Microsoft fogalmak mellett maradva egy IT szervezet lehet:

• Alapszinten – amikor a folyamatai koordinálatlanok, a tevékenységek túlnyomó része pedig kézzel végzett.
• Standardizált – alapszintű folyamatokkal és belső szabványokkal, de korlátozott automatizációval.
• Racionalizált – erősen szabályozott folyamatokkal, kiterjedt automatizációval, iteratívan rögzített üzemeltetői tudással.
• Dinamikus – Teljes automatizmussal, dinamikus erőforrás-használattal, az üzleti igények diktálta szolgáltatási szintekkel és automatikusan rögzített üzemeltetői tudással.

Három infrastruktúra optimalizációs modell létezik: a CoreIO (alap infrastruktúra), a BPIO (Üzleti produktivitás) és a APO (Alkalmazásfejlesztés). Számunkra a CoreIO a lényeges. Az alapinfrastruktúra modell több. ún. képességre (capability) és alképességre (sub capability) oszlik. A képességek az alábbi ábrán láthatók:

A képességek közül egy, a “Desktop, Device és Server Management”, további négy alképességre bontható:

• Desktop Management
• Virtualizáció
• Server Management
• Mobile, Device Management

Egy VDI bevezetés, ha nem is egyforma mértékben, de minden CoreIO képességet érint. A felhasználók azonosításuk alapján kapnak virtuális gépet; a desktopok felügyelete teljesen átalakul, a vékonykliensek megjelenésével “Device Management” feladatok jelennek meg; a WAN optimalizációval a hálózat-felügyeleti feladatok változnak, a centralizált, szerver alapú virtuális gépek, valamint a központosított felhasználói adatok pedig a mentési és helyreállítási folyamatokat érinti alapvetően. Egy sikeres VDI implementáció az adott IT szervezetet racionalizált vagy dinamikus szintre emeli. Ugyanakkor látni kell, hogy az érettségi modell azt is kimondja: nem lehet bizonyos érettségi fázist elérni egy képességben anélkül, hogy előbb ne szereznénk érettséget (értsd: tapasztalatot, tudást) más képességekben. Egy konkrét példával: hiába implementáltunk jól egy VDI projektet egy profi desktopos és virtualizációs csapattal, ha a hálózatfelügyelet nincs megfelelő szinten, akkor a szükséges WAN optimalizáció nem fog kielégítő szolgáltatási színvonalat nyújtani – tehát a távoli felhasználóink elégedetlenek lesznek a projekt végeredményével.

Mindebből már körvonalazható az érettségi szint kockázatra gyakorolt hatása: minél éretlenebb egy szervezet, annál valószínűbb, hogy nem rendelkezik kellő üzemeltetési tapasztalattal, megfelelően lefektetett folyamatokkal és képzett emberekkel, amelyek a VDI implementálásához és üzemeltetéséhez szükséges. És fordítva: minél érettebb egy IT szervezet, annál nagyobb a valószínűsége, hogy ilyen összetett informatikai fejlesztést is sikeresen végrehajtson.

Mindebből az következik, hogy az éretlen szervezeteknél elbuknak a VDI projektek? Egyáltalán nem, viszont nagyobb a valószínűsége, hogy a projekt nem akkor és nem úgy, sőt lehet, hogy egyáltalán nem térül meg. Egy konkrét példa itt olvasható. Köznyelven: ha valaki sokat markol, keveset fog. Milyen módszerekkel lehet csökkenteni ezt a kockázatot:

1. Az érettségi szint növelésével. A VDI projekt számos eleme VDI nélkül is releváns. Ilyen például az alkalmazás-virtualizáció vagy a WAN optimalizáció. Egy részelemnek a megvalósítása nagyobb sikerrel kecsegtet, miközben fel is készít egy későbbi VDI projektre.
2. A projekt céljainak/hatókörének szűkítésével. Szűkíthető a VDI projekt például azzal, hogy csak egy telephelyre, vagy csak bizonyos szervezeti egységre vonatkozóan vezetjük be. Csak bizonyos alkalmazásokat biztosítunk ezzel a technológiával, vagy például katasztrófa esetére hozzuk létre.

Az informatika érettségéből fakadó kockázat hatékonyan csökkenthető, de nem költségmentesen. Az érettségi szint növelése lényegében a VDI projektek elhalasztását jelenti, míg a kitűzött célok szűkítése azt jelentheti, hogy a lecserélni kívánt desktop infrastruktúra részben vagy egészben a helyén marad, továbbá a beruházás méretgazdaságossága megkérdőjeleződhet. (Érdemes-e 100 virtuális gép kedvéért ilyen rendszer felépíteni?)

Tervezés
A VDI projektek kapcsán számos tervezési hiba elkövethető, amelyek azután a projekt sikerét alapvetően befolyásolják. Néhány ezek közül:

1. VDI Windows XP alapokon. Minden Microsoft szoftvernek meghatározott támogatási életciklusa van. Üzleti szoftvereknél az általános támogatási időszak 5 év, a bővített támogatási időszak további öt év, ezt követően csak önkiszolgáló online támogatás vehető igénybe. A Windows XP ebből a szempontból még kivétel is, hiszen a 2001.-es megjelenést követően nem 2006-ban, hanem jelen évig, pontosabban 2009. április 14.-ig tart az általános támogatási időszak, majd ezután 2014. április 8.-ig a meghosszabbított támogatás. Vagyis a jövő hónaptól nem várható, hogy a Microsoft a terméket bármilyen módón fejlessze (például új távoli asztal protokollal.) Ezen túlmenően az esetleges kompatibilitási problémákra készülő javításokhoz is csak azok férnek hozzá, akik ezért külön karbantartási díjat fizetnek. Tekintettel arra, hogy, a VDI rendszerek erősen fejlődő megoldások, szinte bizonyosan várható, hogy a projekt részeként előálló infrastruktúrát egyszer, vagy akár többször frissítjük, a desktop operációs rendszer esetleges előkerülő hibáit viszont a gyártó már nem – vagy csak pénzért javítja.

A Windows XP operációs rendszer alkalmazása még egy veszélyt rejt magában. A VDI megoldások sokszor építenek a memória túlfoglalásra, vagyis arra, hogy az összes futó virtuális gép memóriaigénye nagyobb, mint a fizikai kiszolgáló tényleges memóriája. Ez – többek között – azért lehetséges, mert a hypervisor figyeli az egyes virtuális gépek memória-lapjait, a közösekből pedig csak egyet tárol. Mivel sok azonos operációs rendszer fut egyszerre, a közös lapok valószínűsége nagyobb, tehát a memória túlfoglalás hatékonyabb, ergo nagyobb virtuálisgép- sűrűséget és kisebb hypervisor farmokat lehet kialakítani. Mindez azonban nem igaz a Windows XP-t követő újabb Windows operációs rendszerekre (Vista, Windows 7), mivel azokban alapértelmezetten működik az “Address Space Layout Randomization” (ASLR) nevű kártékonyí programokkal szembeni védelmi mechanizmus. Az ASLR “mellékhatása” az, hogy gyakorlatilag nincsenek közös memória-lapok, így egy operációs rendszer váltása a farm erőteljes bővítését igényelheti.

2. VECD licencek. Gyakori hiba hogy a projekt nem veszi figyelembe, miként kell licencelni a virtuális desktopokat. A közkeletű vélekedéssel ellentétben sem az OEM, sem bármely nagyvállalati licenc-szerződés upgrade desktop rendszere nem telepíthető jogszerűen virtuális környezetbe csak akkor, ha a végfelhasználó berendezéshez (a monitorral, egérrel, billentyűzettel stb. ellátott készülékhez, amelyről a végfelhasználó a virtuális gépet elérni) hozzárendeltünk egy “Vista Enterprise Centralized Desktop” licencet. A VECD ára függ attól, hogy a szervezet milyen érvényes Microsoft keretszerződéssel rendelkezik, a teljes költség pedig jelentős tétel lehet a VDI projekt során. A VECD licenc-konstrukcióról ebben a bejegyzésben lehet többet megtudni.
   
3. WAN vonalak optimalizálása nélkül. A ma elérhető leghatékonyabb protokollok sem képesek a jelenlegi desktopokat megközelítő felhasználói élményt nyújtani a nagy késleltetésű és viszonylag kis sávszélességű WAN vonalakon, ezért elengedhetetlenek a WAN optimalizálók. Ilyen eszközök használatbe vétele azonban nem kis költség. Egy banki rendszerben akár többszáz kis telephely is előfordulhat, vagyis legalább ennyi (sőt a központi eszközöket beleszámolva még több) WAN optimalizáló készülék üzembe állítása jelentősen növelheti a VDI rendszer kezdeti költségeit. Az optimalizálás elhagyása viszont nagyobb és hektikusabb sávszélesség használatot jelent – gyengébb felhasználói élménnyel párosulva. (Érdemes megjegyezni, hogy a WAN optimalizálók átvezetnek a Brach Office rendszerek kialakításának témaköréhez. Amennyiben nem sikerül a távoli telephelyeken teljes mértékben felszámolni a PC-ket, úgy azok további forgalommal terhelik a vonalakat. A WAN optimalizálók használata lényegében megkerülhetetlen lesz. Ekkor azonban már nem lehet csupán a VDI rendszer szempontjai szerint kiválasztani a megfelelő eszközt, hanem figyelembe kell venni a megmaradó PC infrastruktúra igényeit is.)
   
4. WAN vonalhasználat intenzitásának növelése. Kevesen gondolnak bele, hogy a VDI rendszer kiépítése sok tekintetben adatforgalom koncentrációt jelent. A PC-k az egyes perifériákkal saját I/O kapukon, hálózatos szemmel: dedikált csatornán, garantált sávszélességen és kis, de legalábbis pontosan ismert késleltetéssel kommunikálnak. A VDI rendszereknél előkerülő átirányítási  technológiák révén az egyes I/O csatornák (soros port, párhuzamos port, USB kapuk stb.) forgalma egy közös, nem garantált sávszélességű, változó, jellemzően nagyobb késleltetésű vonalra terelődik. Ha teljes desktop kiváltást szeretnénk megvalósítani, akkor olyan adatforgalom megjelenésével is tervezni kell, amelyek korábban akár meg sem jelentek ethernet csatornákon. (Képbeolvasás, biztonsági webkamera stb.)
   
5. WAN vonalak alternatív útvonal nélkül. Mivel VDI desktopokhoz csak hálózaton át lehet hozzáférni, kritikus tervezési tényező az alternatív útvonalak tervezése. Sokan azt gondolják, hogy természetes a redundáns WAN vonalak biztosítása. Ez azonban egyáltalán nem biztos. Kiterjedt WAN hálózat esetén ez roppant költséges. Másrészről a sok WAN vonal kellő statisztikai alapot ad annak becslésére, hogy egy adott telephely vagy telephely típus milyen gyakorisággal esik ki, illetve nagyjából meghatározható az is, milyen károkat okoz a kiesés. Ezekből adódik, hogy hol kell és hol nem kell alternatív útvonalakat biztosítani.
   
6. A felhasználói adatok centralizációja. A PC-k adatközpontba kerülésével és a felhasználói adatok/beállítások PC-től való elválasztásával jelentős mennyiségű dokumentum és egyéb állomány kerül központi adattárolókra. A tervezés során többnyire egy átlagos kvóta-mérettel szoktak számolni, ám a felhasználók szokásai eltérőek, ezért az általuk tárolt adatok mennyisége erősen szóródhat. Mindenképpen azzal kell számolni, hogy jelentősen nő a tárolt adatok mennyisége. A tervezés során gyakran kihagyják a tárolórendszerek deduplikációs mechanizmusának implementálását, amely pedig mind az adattárolás hatékonyságát, mind pedig egy esetleges storage-replikációt jelentősen gyorsíthat. Erős dilemma elé állítja a tervezőket a felhasználók személyes állományainak tárolása (képes, zenei és videó állományok). Megtartásuk jelentős adattárolási többletet okozhat, használatuk pedig a WAN vonalak sávszélességét pazarolhatja. A tárolás megtagadása viszont a felhasználók “lázadását” eredményezi, amely a projekt sikerét kockáztathatja.
   
7. Hálózaton nem tárolható állományok. Különös problémát vet fel – és tipikusan tervezéskor figyelmen kívül hagyott – az olyan állományok tárolása, amelyek hálózaton meghajtón nem helyezhetők el (pl. PST fájlok hálózati meghajtón tárolva nem támogatottak), vagy nem érdemes őket ott tárolni (Access adatbázisok). Ezek az állományok belső indexelő illetve lekérdező mechanizmusokkal rendelkeznek, amelyek lokális PC-re optimalizáltak. A felhasználói adatok operációs rendszertől való elválasztása során megoldást kell keresni az elhelyezésükre vagy felszámolásukra. Többféle megoldással kezelhető a probléma, de mindegyik újabb gondokat vet fel. A VMware View-ban például lehetőségünk van a felhasználók állományait külön virtuális lemezen tárolni, majd azt dinamikusan becsatolni a virtuális desktopba. A megoldás előnye, hogy “helyi” állományokról beszélhetünk, hátránya, hogy a vállalati kereső/indexelő szoftverek elől elrejtjük az információkat. A tényleges megoldás a sziget-adatbázisok felszámolása lenne, ez azonban nem könnyű. A helyzet nehézségét jó érzékelteti, hogy például egy neves autógyár gépein több, mint 100 000 Access adatbázist leltároztak fel, ebből több, mint 10 000-et egy évben belül hoztak létre.
   
8. Vékonykliensek felügyelete. Tipikusan “elnézett” tervezési feladat. Ha a meglévő desktopokat valódi vékonykliensekkel váltjuk fel, azok felügyeletéről – leltár, firmware-frissítés stb. – gondoskodnunk kell. Ha tehetjük, akkor a meglévő konfiguráció menedzsment szoftver érdemes felhasználni, de ha erre nincs mód, akkor egy párhuzamos felügyeleti rendszert kell kialakítani. Ez a rendszer ugyan rontja a VDI megoldás ROI-ját, de elengedhetetlen, mivel a desktop operációs rendszerek változásával változhat a távoli asztal protokoll is, amelynek a kliens oldali komponensét a vékonykliensek tartalmazzák.

Technológia
Napjaink egyik legfontosabb VDI kérdése, hogy vajon létezik-e már mindazon feltétel, amely a desktopok teljes kiváltását lehetővé teszi. Kockázat oldalról megfogalmazva: milyen technológiai kockázatokkal kell számolnia annak, aki teljes desktop kiváltást szeretne megvalósítani?
A cikkel kapcsolatos szakirodalom tanulmányozása alapján alapján azt gondolom, hogy egyértelmű a szakmai konszenzus: ma még nem lehet a desktopokat teljes egészében kiváltani. A szakértőknek abban tér el a véleménye, hogy vajon az áttörés közel van-e, vagy távol, vagy esetleg el sem jön, és a VDI egy lesz a szerver alapú közpotosított rendszerek (SBC) közül. A VDI szállítók természetesen lelkesek, de még az ő álláspontjuk között is markáns különbségek figyelhetők meg. A VMware szerint a VDI alapvető és forradalmi változás, a desktop paradigma vége. Mivel azonban a cégnek nincs prezentáció-virtualizációs kiszolgálója, ezért a VMware szerint a VDI-nak kevés köze van a hagyományos terminál szerveres megoldásokhoz. A Citrix ellenben úgy gondolja, hogy a VDI az SBC rendszerek kiegészítője és kiteljesítője – naná, hogy a zászlóshajó XenApp mellett ez nem is lehet másként. Végül a harmadik jelentős piaci szereplő, a Microsoft szerint a VDI ugyanúgy részigényeket kielégítő megoldás marad, mint a terminál kiszolgálók, az elosztott architektúra paradigma pedig még egy darabig marad.
Egy bizonyos, hogy az idei VDI rendszereknél az alábbi technológia korlátok (veszélyek) fennállnak, előfordulhatnak:

1. Nem minden alkalmazás futtatható SBC környezetben, vagyis terminál szerveren, vagy VDI desktopokon. Jelenleg a grafika-intenzív alkalmazások (autocad, archicad) valamint a multimédia-alkalmazások (média lejátszók) egyáltalán nem, vagy csak speciális körülmények (például LAN kapcsolat megléte) esetén futtathatók bármilyen SBC rendszeren. Tegyük rögtön hozzá ugyanakkor, hogy éppen ez az a terület, amely a közeljövőben alapvetően változni fog: a Wyse TCX, a Treadici vagy a Microsoft Calista fejlesztések megoldják, de legalábbis túlnyomórészt orvosolni fogják a mai technológia korlátokat. Érdemes megnézni, mit tud ma az ICA protokoll, és mit egy RDP, ha a Wyse TCX technológiája segíti.

2. Nem minden alkalmazás virtualizálható. Láthattuk a VDI rendszerben az állapot nélküli desktopok egyik fontos feltétele a rajtuk futó alkalmazások virtualizálása és igény szerinti gyors terítése. Azzal viszont kevés terv számol, hogy jelentős lehet azon alkalmazások száma, amelyet nem lehet virtualizálni. Ezeket vagy eleve a lemezképbe kell építeni, vagy utólag kell telepíteni hagyományos módszerrel. A “hagyományos” két dolgot is jelent: a virtualizált alkalmazások terítésének megteremtése mellett meg kell tartani a fizikai szoftverek telepítési (frissítési, eltávolítási, leltározási stb.) módszereit és rendszereit is – ez rontja a VDI megtérülését. Másrészt számolni kell az alkalmazások inkompatibilitási problémáival, amely végső soron a rendszerlemezképek szaporodását eredményezheti.
   
3. Az eszközátirányítás nem mindig valósítható meg. A PC-khez a legkülönbözőbb szabványú I/O kapukon keresztül mindenféle külső eszközt csatlakozathatunk. Amikor a PC helyett távoli asztalon dolgozunk, akkor azt szeretnénk, hogy a helyi eszközhöz csatlakoztatott periféria a távoli asztalon is elérhető legyen. Az eszközátirnyítás viszonylag jól megoldott terület – de a projekt kockázatát épp ez a viszonylagosság okozza. A soros és párhuzamos portok átirányítását minden protokoll tudja – de például a DOT4 portokét – nyomtató/scanner/fax multifunkciós gépek kedvence – nem. Az ICA protokoll átirányít USB eszközöket Windows XP esetén is, ha viszont Microsoft RDP-t használunk, akkor a plug and play eszközátirányításhoz a kliens oldalon Vista Enterprise vagy Ultimate, a VDI oldalon pedig szintén Vista szükségeltetik (lásd korábban a Windows XP-re épülő VDI kockázatait). A teljes desktop kiváltáshoz mindenképp számba kell venni az átirányítandó eszközöket (soros port, párhuzamos port, USB eszközök, nyomtatók, scannerek, faxok, multifunkcionális készülékek, POS terminálok, webkamerák, digitális fényképezőgépek, smartkártya, beléptető rendszerek, adatgyűjtők stb. stb.) és alapos tesztelést kell végezni, miként működik – elfogadható sávszélesség használat mellett – az átirányítás.
   
4. Az eszközátirányítás költséges lehet. Még ha sikerül is minden eszköz átirányítását technológiai szempontból megoldani, akkor is adódhatnak “nem technológiai” jellegű problémák. Képzeljünk el egy munkafolyamatot, amelyben egy távoli irodában (WAN vonal, kis sávszélesség)  6-10 oldalas szerződéseket, kérelmeket, dokumentumokat stb. kell bescannelni. Ha nincs is akadálya a képolvasásnak, mindenképp vizsgálatot igényel, milyen sávszélességre van szükség. Ha a beolvasott képek nagy adatmennyiséget jelentenek, akkor vagy lökésszerűen terheljük a hálózatot, vagy sokáig tart a képanyag feljuttatása a VDI gépbe. A “sokáig” mértékét a felhasználónak kell eldönteni. Ergo: a VDI implementálása nem pusztán technológiai mutatvány: az üzleti folyamatokra kiható átalakítás, tehát csak a végfelhasználók intenzív bevonásával lehet megvalósítani.
   
5. Eszközátirányítás és vonalszakadás. A PC dedikát I/O csatornáin ritkán tapasztalható “hálózat kiesés”, nem így a VDI környezetben. Fel kell mérni, hogy vannak-e olyan alkalmazások, amelyek folyamatosan használnák a vonalakat (ahogy tették azt az I/O csatornákkal a PC-k esetén), és tesztelni kell, hogyan viselkednek kisebb illetve nagyobb vonalszakadáskor.
   
6. Protokoll implementáció. Gyakran előfordul, hogy a vékonykliensekkel való takarékoskodás jegyében olyan változatot sikerül megvenni, amely az RDP protokoll nyilt forráskódú változatát tartalmazza. Ez kétségkívül olcsó megoldás, ám nem veszi figyelembe, hogy az rdesktop jelenleg még csak az RDP 5-ös funkciókészletét tartalmazza,, ezért a 6.0-ás és 6.1-es képességek (és ezek közé tartozik a plug and play eszközök átirányítása) nem működnek.

Változó folyamatok
Végezetül vegyük végig, hogy egy VDI projekt implementációja során milyen informatikai folyamatok változnak meg, és mit jelent ez a változás.

1. Desktopok telepítése. A folyamat kettéválik, amennyiben gondoskodni kell a felhasználóhoz kerülő végberendezésről, illetve biztosítani kell a megfelelő alkalmazásokkal ellátott virtuális desktopot. Az végfelhasználói berendezések kihelyzése, mozgatása, cseréje a PC-hez képest akkor egyszerűbb, ha a PC nem állapot nélküli, vagyis a felhasználó beállítása és vagy adatai géphez kötöttek. Az előny az állapot nélküliségben rejlik. Ezen felül a vékonykliensek kevesebb mozgó alkatrészt tartalmaznak, ezért – általában – kevesebbet hibásodnak meg. (Viszont az üzemeltetői tapasztalatból állíthatom, hogy éppen úgy meghibásodnak: ethernet kártyák mehetnek tönkre villámláskor, tápegységek pukkannak el, I/O kapuk pöckei törnek le stb. stb. A merevlemez viszont nem száll el – mivel nincs). A vékonykliensek hosszabb élettartama miatt a kihelyezés/mozgatás/csere feladatok csökkennek, és gyakran a végfelhasználóra bízhatók. A VDI oldalon a desktop provizionálás automatizálható – ez a VDI rendszerek legkiforrottabb képessége.
2. Desktop életciklus. A virtuális gépek életciklusa egészen más, mint a PC-ké. Dinamikusan jönnek létre és – megint csak: ha állapot nélküliek – dinamikusan szűnnek meg. A dinamizmushoz viszont igazítani kell néhány rendszert, például az Active Directory-t, ahol garmadával állhatnak a megszüntetett munkaállomás fiókok, vagy a hardver-szoftver leltárt végző alkalmazások, amelyekkel tudatnunk kell, mely gépek nem léteznek már. (A jobb VDI rendszerek ezt a munkát elvégzik). Ugyancsak felül kell vizsgálni (Vista és Windows 7 klienseknél), miként működik a termékaktiválás. Ha a gépek életciklusa 30 napnál rövidebb, akkor tiltani kell az aktiválást, ha ellenben hosszabb, akkor KMS-t kell üzembe állítani.
3. Alkalmazások telepítése. Felül kell vizsgálni az alkalmazások telepítési rendszerét. Az összes virtualizálható alkalmazást célszerű virtualizálni, és dinamikusan felhasználóhoz rendelni. A nem virtualizálható szoftvereket viszont vagy lemezképbe kell ágyazni, vagy pedig a hagyományos disztribúciós módszerrel el kell juttatni a virtuális desktopokra. Amit lehet, érdemes terminál környezetben futtatni, mert nagyobb felhasználói sűrűséget érhetünk el – tehát olcsóbb rendszert hozhatunk létre. Mindez precíz szoftverkezelési rendszert, jól működő hardver/szoftver leltárt, helyesen implementált változáskezelést igényel.
4. A felhasználói adatok tárolása. A korábbi felhasználói szabadságfok valószínűleg csökken. Szabályozni kell – technológiai eszközökkel is! – hova menthetnek adatokat a felhasználók, illetve azok az adatok/állományok milyen típusúak lehetnek. Kvótarendszert kell felállítani, a végfelhasználókat pedig oktatni kell, hogyan gazdálkodhatnak a nekik fenntartott tárterülettel. Az ilyen jellegű incidensek számának növekedésére kell számítani. Kellően nagy szervezet illetve projekt esetén a helpdesk munkatársak száma felülvizsgálandó (Persze célszerű a projekt “eredő” incidens-szám változásával kalkulálni. Itt épp nő az incidensek száma, máshol – a szabályozottságból fakadóan – valószínűleg csökken.)
5. A felhasználói beállítások tárolása. Szinte bizonyos hogy a legkisebb VDI projekteket leszámítva minden esetben be kell vezetni a felhasználókat követő beállításokat (Romaing profiles). A profilok kezelése történhet az virtuális desktopok operációs rendszereinek beépített képességeivel vagy egy profile menedzsment eszközzel. Az beépített eszközök olcsóbbak, de jónéhány problémát nem oldanak meg (Last write wins; profile növekedés; betöltési idő; virtuális alkalmazások stb. stb.). Emellett minél régebbi operációs rendszerről van szó, annál több korláttal rendelkezik a profile-kezelés (lásd: Windows XP-re épülő VDI). A Profile menedzsment eszköz persze drágább, de néha része egy gyártó VDI megoldásának, lásd Citrix.
6. Mentési eljárásrend. A PC-kről bekerülő jelentős mennyiségű adat mentését a mentési eljárásrendbe be kell vonni. Ma már rendkívül sok olyan technológi létezik, amelynek segítségével terabájtok mentése is viszonylag gyorsan megoldható szinte folyamatos jelleggel, ezek a megoldások viszont pénzbe kerülnek, és kicsi a valószínűsége, hogy a VDI projekt keretében meg lehetne oldani. Mindenesetre a tárolási és mentési eljárásrendeket a becsült adatnövekedés függvényében felül kell vizsgálni, és gondoskodni kell, hogy a mentési időablak továbbra is elfogadható maradjon.
7. OS frissítés. A mesterpéldányos virtuális gép használatával lehetővé válik, hogy az egyetlen mesterpéldány frissítésével minden virtuális gépre azonnal frissítés kerüljön – ezt mindenki tudni véli, pedig nem így van. A mesterpéldány mindig csak olvasható, módosításával minden belőle származó virtuális gép megszűnik, vagy, a régi gépek nem látják a frissítést, csak az újak. Jól meg kell tehát tervezni a virtuális gépek életciklusát, hogy adott időn belül minden régi gép eltűnjön és csak újak maradjanak. Azt már alig szokták megemlíteni a gyártók, hogy a frissítések kezelésénél nem a telepítés a legdrágább mozzanat, hanem a frissítések tesztelése. Ebben a tekintetben NEM kapunk segítséget a VDI rendszerektől. 
8. Alkalmazások frissítése. A virtualizált alkalmazások frissítéséhez más eszközök szükségesek, mint a fizikai alkalmazásoknál megszokottak. A virtuális alkalmazásoknál – jelenleg - manuálisan kell újranyitni, és frissíteni az alkalmazás-csomagot. Implementációtól függ, hogy ezt mely gyártó hogyan támogatja. A frissítések jelenthetik a csomagok teljes újratöltését vagy csupán a különbségek disztribúcióját. A lényeg: a frissítés folyamata és munkaszükséglete változik, nő.
9. Biztonsági események gyűjtése és egyéb külső elvárásoknak való megfelelés. A jellegüknél fogva dinamikus VDI rendszerek implementációja során számolni kell külső szabályozó szervek egyedi elvárásainak megjelenésével. Tipikus példa lehet erre a biztonsági események gyűjtése, illetve belső támadások, jogszerűtlen adathozzáférések vizsgálatának lehetősége. Amennyiben mondjuk fél évre visszamenően képeseknek kell lennünk meghatározni, hogy ki mikor honnan milyen adathoz fért hozzá, akkor ez nehézségekbe ütközhet egy VDI rendszerben, hacsak nem toljuk ki legalább fél évre a virtuális gépek törlésének határidejét. A probléma viszonylag könnyen orvosolható, de költséges lehet  - tárterületet kell biztosítani.

A folyamatok változásával kapcsolatos projekt veszélyek paradox módon viszonyulnak a projekt megtérüléséhez.: minél kisebb a változó folyamatok száma, annál nagyobb a siker esélye, annál kisebb a kockázat – ám annál kisebb a megtérülés is. Minél teljesebb VDI rendszert építünk, annál gyökeresebb átalakuláson kell átesnie a folyamatainknak is, több kockázattal, de egyben jobb megtérüléssel kecsegtetve.

Nem az IT-n múlik….
A cikk terjedelmes volta ellenére is bizonyára bőven maradtak fel nem tárt kockázatok a VDI projektekkel kapcsolatban. Egy fontos –kultúrális jellegű – veszélyt viszont még nem említettem. A korábbi bejegyzésben röviden összefoglaltam, hogyan került a PC a vállalati informatikai rendszerbe és miként vált elsöprő erővel új paradigmává az elosztott architektúra. A kezdeményezők a felhasználók voltak, az “elszenvedők” pedig az informatikusok. A felhasználók kezelhették a saját adataikat, önállókká válhattak, a korábbiakhoz képest szabad kezet kaptak. Az informatikusok viszont kevésbé voltak képesek felügyelet alatt tartani a rájuk bízott eszközöket, és a új biztonsági, üzemeltetési feladatokkal szembesültek.

Az Informatikus-végfelhasználó ellentét – ha más-más igényszint mellett – ma is fennáll. De ma már nem csak önálló munkáról, hanem bárhonnani hozzáférésről, rugalmas konfigurációról, multimédia-támogatásról, összetett kommunikációs eszközök biztosításáról is szó van.

A VDI rendszer többnyire az informatikusok elképzelése arról, hogyan kell munkakörnyezetet biztosítani a végfelhasználóknak. Hogyan kell “rendet tenni a káoszban”, ellenőrizni azt, ami “kicsúszott a kezünkből”. Az informatikusok forradalma. Vagy ellenforradalma? Hagyjuk a politikai címkéket! A VDI projektek óriási hátrányból indulnak, ha nem felhasználók kezdeményezik és nem az ő igényeiket elégíti ki. Az ítéletet végső soron ők mondják ki: elfogadják, ha meggyorsítja a munkát és megkönnyíti a folyamatokat; elutasítják ha akadályokat gördít eléjük és visszalépésnek érzik. Végső soron a felhasználók döntenek – nem előre, hanem utólag. És ha nem kapják meg, amit szeretnének, akkor a VDI ugyanarra a sorsra jut, mint a mainframe-ek. Eltűnik.

A legjobb projekt-kockázat csökkentő módszer: a felhasználók bevonása a projektbe. A lehető legnagyobb mértékben.

Pár héttel ezelőtt azt álmodtam (nem nevet!), hogy a CISCO fel fogja vásárolni az EMC-t, és vele együtt annak korona-ékkövét a VMware-t. Másnap reggel el is újságoltam ezt a kollégáknak felsorolva pár érvet. Hozzáteszem, fogalmam sincs sem a CISCO, sem az EMC piaci értékéről. Azt hiszem a CISCO nagyobb, mint az EMC, de ez nem is számít.

Miért vásárolná fel? Nos, szerintem az elsődleges szempont az, hogy a virtualizáció megkérdőjelezheti a “The network is the platform” állítást: egyre több gép kerülhet egy fizikai vasra, kevesebb hálózati portra lesz szükség, a switchek intelligenciája meg beköltözik a hypervisorba. Ez eddig nem túl jó a CISCO-nak. Ha ehhez még hozzáteszem, hogy a cloud computing előretörésével erőteljesen kiürülnek majd a vállalati adatközpontok, a meglévő kapcsolatok pedig egyszerűsödnek, akkor ez megint nem jó hír. Végül ha meggondolom, hogy a cloud computing hosszú távon a hang- és videó hívásokat is átalakítja/elköltözteti – nos, ez kész viharfelleg a cég felett. Hacsak…

Hacsak nem maga a CISCO ül a felhő közepén. Mi is kell ehhez? Hálózat – ok, ez van. Hpervisor – VMware. Storage: EMC. És végül: szerver.* De nem a szerver hardver a platform, ezt tudják CISCO-éknál. Nem is a storage, hanem… hanem az operációs rendszer, vagyis: a VMware. Amelyik piacvezető a jelenlegi virtualizációs üzleti területen és az egyik – ha nem a – legjobb kandidáns, hogy a cloud computing korszak vezető szoftverrendszere legyen.

Pár hete megálmodtam. Mostanában meg terjed a pletyka.

-----------------------

* – Persze, kell ehhez még alkalmazás, meg kapcsolódási/programozási felület, nem akarom én ezt túlegyszerűsíteni, de a mondandóm szempontjából ez most nem fontos.

Steve Ballmer a Microsoft jelenlegi vezérigazgatója, 2000 január óta tölti be ezt a posztot. Steve Ballmer minden idők egyik legsikeresebb menedzsere. A világ legnagyobb szoftvercégét vette át Bill Gates-től, és ezt a státuszt mindezidáig megtartotta. Bárki bármit mond, sikeres stratégiát alakított ki,  hogy a Microsoft megőrizze a pozícióit az Opens Source termékekkel folytatott versenyben, és megkezdte a cég átalakítását, hogy a hirdetési piacon versenyre kelhessen az új riválisokkal. Amikor átvette a céget, az éves árbevétel kb. 22 milliárd dollár volt, a 2008-as pénzügyi évben, amely 2008. június 30-cal zárul, ez vélhetően 60 milliárd lesz, tehát nyolc év alatt az árbevétel megháromszorozódott. A teljes iparág Mindeközben a Microsoft szervezete sokkal rugalmasabb, mint a hagyományos versenytársaié (Pl.: IBM). Egyes becslések szerint az MS IT az IT világ 40%-át befolyásolja közvetve vagy közvetlenül, saját termékei és partnerhálózata révén. A mai IT világban ismert valamennyi üzleti modellt alkalmazza a cég (hagyományos szoftvereladás, open-source, hirdetés) minden szegmensben versenyez és minden szegmensben igyekszik platformot építeni.

A cég belül (minden hibája ellenére) a szervezés egyik mintapéldája. A stratégia lebontása egyénekre, a balaced scorecard alkalmazása, a termékfejlesztés minőségbiztosítása, a vállalati tudás kezelése mind-mind olyan dolog, amit messze jobban csinál a Microsoft mint a környezete és a hozzá hasonló nagyok.

Steve Ballmer tevékenysége, módszerei, a víziói és annak megvalósuásai, döntései (a jók és a rosszak is) tankönyvekbe kerülnek majd és menedzser palánták fogják tanulni. Akár megdobáljuk őt, akár nem.

Három és fél nap oktatás és másfél óra vizsga után véget ért az ITILv3 Foundation tanfolyam. Ritka jó helyre sikerült beiratkoznom. Remek téma, jó tananyag, tömény napok. És végül, de nem utolsó sorban: nagyon-nagyon jó előadók. Sarkadi-Nagy István az itSMF Magyarország elnöke, Krauth Péter pedig elnökségi tag. Mivel nap mint nap előadok, tudom, hogy egy ilyen 'performansz' milyen mélységű tudást jelent. Jellemző az előadókra, hogy még az előző cikkben említett, motiválatlan résztvevők is teljes elismeréssel nyilatkoztak, hasznosnak és jónak minősítve az átadott ismereteket. Örömmel nyugtázom, hogy tévedtem.

Akik nekiugranak: a tanfolyam naponta 8 óra, másfél órás blokkokkal, egy órás ebédszünettel. Az anyag nagyon tömény, és bár az előadók a gyakorlati példák említésével mindent megtesznek, hogy az absztrakt fogalmak ne süssék ki az agyunkat, a nyolc óra eléggé megterhelő. Minden napra van házi feladat, egy próbateszt kitöltése. A kapott tananyag alapos átolvasásával a teszt könnyedé kitölthető. Azt a tanulási módszert követtem, hogy minden nap a teljes anyagot elolvastam. Ez ugyan azt jelentette, hogy egyre hosszabb olvasnivalóm volt, a teszek is egyre szélesebb témát öleltek fel, a többszörös ismétlés pedig meghálálta magát.

A vizsga 1 óra + 15 perc a nem angol anyanyelvűeknek. Nekem mindennel együtt elég volt 1 óra. Negyven kérdésre kellett válaszolni 65% felett kell teljesíteni a bizonyítvány megszerzéséhez. Úgy érzem jól sikerült a vizsga. Az értékelést Londonban (esetleg Hollandiában?) végzik, az eredeményre pár hetet várni kell.

Mit ér a ITIL Foundation tudás? A becslések szerint ma kb. 1000 szakembernek van ilyen végzettsége. Ez nagyon kevés ahhoz képest, hogy hányan dolgoznak az IT iparban, de még akkor is, ha csak az üzemeltetőket számítjuk. Egyelőre tehát ez versenyelőny. Hosszabb távon azonban ez lesz a belépő. Ha nincsenek meg az ezirányú ismereteid, be sem léptél a szakmába.

A tanfolyamra sokféle módon érkeztek az emberek. Átalakul a cégük, ITIL alapokon szervezik meg a munkájukat; a tanácsadói tevékenységéhez szükséges a tudás, a cége beiratta; szeretne értékesebb lenni a munkaerőpiacon, meggyőzte a főnökét. Végül van egy cégtől néhány rendszergazda: küldték őket, ki tudja miért, hát jött.

A motiváltság az érkezés történetével egybevág. Aki maga nézte ki magának a tanfolyamot, aki előrelépésnek tekinti az itt megszerezhető tudást, azok lelkesen követik a témát. Akiket küldtek, annak kötelező. És tudjátok, hogy az milyen. Igazából azon gondolkodik, hogy vajon miért is került ő ide, hiszen neki ehhez semmi köze. A főnökei úgyis felette és nélküle döntenek. Az ő feladat a gépek telepítése. Azt, hogy hogyan meg miért, majd megmondják neki. Történetesen ismerem a céget és az informatikáját is. Tipikus, frusztrált munkahely, alacsony motivációval, mellőzött IT-vel.

Pedig szándékból nincs hiány. Nem az ördögtől való eretnekség rendszergazdákat ITIL tanfolyamra küldeni. Sőt, sőt! De most itt ül három ember, több, mint fél millió forintért, csakhogy ők nem akarnak itt ülni. Ők csak fogaskerekek közé szorult munkások, és amíg valaki meg nem simogatja a buksijukat és egyet nem ért velük, hogy "igen, jajj, ti szegények, tényleg milyen rossz nektek", addig duzzogva nem is hajlandóak mások lenni. Nem emelik fel a fejüket, nem kell nekik a szélesebb horizont. Sehová sem vezető sajnálat kell nekik.

Pedig az ITIL ilyen mélységére minden rendzergazdának szüksége lenne, még akkor is, ha a cége nem foglalkozik ilyen ajánlásokkal. Ugyanis - tetszik, nem tetszik - mindenki egy folyamat része. Csak rajtunk múlik, hogy ezt a folyamatot meg szeretnénk-e ismerni, vagy sem. De ha nem ismerjük meg, akkor javítani sem tudunk rajta. Márpedig a rossz folyamatok újratermelik a frusztrációt.

A jó szándék ellenére ez a mag most szikes talajra hullik, és a cég, mint már annyiszor korábban, megint rosszul költötte el a pénzét.

Miközben éppen megjelent a Microsoft Operations Framework 4.0, a héten végre-végre eljutottam egy ITIL Foundation tanfolyamra. Már a MAL-os időszakban is szeretetem volna egy ilyen képzésen részt venni, de előbb a Windowsos vizsgák jöttek, azután sok munka, végül a MAL anyagi helyzete nem engedte. A Microsoftos aklimatizálódás után viszont az első adandó alkalmmal (értsd: amikor megkérdezték tőlünk, hogy milyen képzésen szeretnénk rész venni) jelentkeztem. Ráadásul nem is a v2, hanem már a friss, v3-as metodológia szerint.

Az ITIL egy valamikor a nyolcvanas években, az angol kormány által kidolgozott IT üzemeltetési módszertani ajánlás volt, amely mára az IT szolgáltatások teljes életciklusára vonatkozóan tartalmaz javaslatokat, legjobb gyakorlatokat. Ez az IT üzemeltetők "bibliája". De nem csak az. Az IT üzemeltetés egy viszonylag fiatal szakma, az ITIL tudatosan vállalja, hogy fogalmakat definiál és használ következetesen. Vagyis, aki az ITIL-t érti, az más szakértőkkel "egy nyelven beszél". Számomra, bár éppen nem üzemeltetek, azért fontos a részvétel, hogy az ügyfeleknél még precízebben fogalmazhassak, a termékeinket pedig az ITIL szemüvegén át is nézhessem; hevítve a várakozásokat, ha valahol jók vagyunk, és hütve, ha valahol elmaradtunk volna.

A tanfolyamot az IQSoft-Jon Brice szervezte, Krauch Péter és Sarkadi-Nagy István tartja. Három és fél nap a tananyag átbeszélése, a végén egy másfél órás vizsgával. Ha sikerül, akkor ábrán látható piros modult elvégeztem. Ez az alapozás, a legfontosabb fogalmak tisztázása, a teljes rendszer felületes áttekintése. Az ITIL képzés során pontokat lehet gyűjteni. Ma egy ITIL Expert (fekete doboz) minősítéshez 22 pontra van szükség. Az mostani tanfolyamhoz tartozó vizsga 2 pontot ér. Ebből nagyjából lehet azt is látni, hogy milyen mélységet jelent. Az zöld dobozok 3-3, a szürkék 4-4 pontot érnek, végül a rózsaszínhez tarozó vizsga 5 pontot. Egy piros-zöld-rózsaszín útvonallal tehát összejön a 22 pont.  A mostani tanfolyam 200 000 Ft + kb. 40 000 Ft a vizsga. Minde dobozhoz külön tanfolyam és vizsga van. El lehet képzelni, hogy egy darabig még nem sok ITIL szakember szaladgál az utcán.

A résztvevők változatos helyekről jöttek: IT Outsource vállalat; gyógyszeripari cég, gyógyszeripari beszállító; áramszolgáltató és informatikai tanácsadó cég, amely épp üzemeltetési módszertani tanácsokat ad majd az áramszolgáltatónak. Többnyire nagyvállalatok, vagy azoknak dolgozó partnercégek munkatársai. Ez jelzi az ITIL jelenlegi státuszát is. Bár a legjobb gyakorlatok gyűjteménye, és elvileg vállalati mérettől függetlenül használható, sőt az ITIL megalkotóinak szándéka is, hogy bármilyen szervezti méret esetén alkalmazható legyen, valójában nagyvállalatok tudják jól implementálni, meg persze az IT kiszervezésből élő cégek. Sőt leginkább ők, mint ahogy azt az ISC-ben tett látogatásomkor is láthattam.

Folyt. köv.

Az előző cikkben "lazán" kijelentettem, hogy a biztonság területén évekkel a versenytársaink előtt járunk. Gál Tamás javított - helyesen - atekintetben, hogy az első szerver operációs rendszer, amely igazán profitált a Microsoftnál bevezetett Security Development Lifecycle folyamatból, a Windows Server 2003 SP1 volt. Ez némi utánajárásra sarkallt, és találtam egy gyöngyszemet: The First Step on the Road to More Secure Software is admitting you have a Problem. A cikk arról szól, hogy a Microsoftnál bevezetett SDL tette lehetővé, hogy az XP-hez képest csökkenjen a biztonsági rések száma a Vistában. Meg arról, hogy a probléma megoldásának első lépése: elismered a problémát.

No, akkor soroljuk fel a puzzle elemeket:

• A Microsoft 6 évvel ezelőtt indított el a vállalaton belül egy kultúrális változást, amelynek lényege, hogy minden fejlesztő, tevékenysége minden pillanatában a kód biztonságosságát helyezze előtérbe (Nem azt mondom, hogy a biztonság korábban elhanyagolt terület volt, inkább azt, hogy nem volt kellően hangsúlyos)
• A kultúrális változás egyik következménye az SDL bevezetése. Ez egy folyamat, amelynek eredménye a lehető legbiztonságosabb kód. A "lehető" egy mozgó valami, a processz pedig 6 éve finomodik. Minden elkövetett biztonsági rés után módosítják a folyamatot, hogy a kétszer ne kövessék el ugyanazt a hibát.
• Egy ilyen folyamat nem másolható könnyen a versenytársak által: minden konkurensünknek ugyanúgy át kell esnie a tanulási folyamaton.
• Ha neked van valamid, ami a többieknek nincs, és a piacon azt felhasználhatod, akkor azt a valamit úgy hívják: versenyelőny.

Rakjuk össze: a Microsoftnak van egy nehezen másolható versenyelőnye a biztonságos kód fejlesztése területén. (Árnyalja a képet a Microsoftról kialakított negatív percepció.)

Porter megnyalhatja a tíz ujját, olyan tankönyvi példa ez. És remélem most már nem lóg a levegőben, miért mondom, hogy évekkel a versenytársak előtt járunk.

(Az idézett cikkből van még egy ugrás az eredeti forrásra, Jeff Jones biztonsági blogjának egy cikkére. Innen letölthető a Vista első évének története - biztonsági szempontból. Ez az a kimutatás, amit már fél évvel ezelőtt is publikáltak. Nos, íme az 1 éves adatok. Gyönyörűen látszik, mit tud az SDL folyamat. A PDF végén a FAQ igen érdekes.)

Úgy szeretném, ha a webnaplóm fele ilyen cikkekből állna, mint ez a mostani. Bevallom -12 óra időm van ezt a bejegyzést megírni, mégis rá kell szánnom némi időt, mert a jövő szempontjából meghatározó eseményt nem lehet szó nélkül hagyni.

Tehát a hír: úgy hírlik, hogy a Citrix felvásárolja a Xensource céget. Ahhoz, hogy ennek a jelentőségét megértsük íme egy kis villámtalpaló a virtualizáció technológiákból. (Az x86-os rendszerekre koncentrálva)

A legelső megjelent technológia a Citrix grafikus terminál szervere volt még 1995-97 táján. Lényege, hogy a grafikus megjelenítés máshol történik, mint ahol az alkalmazásokat futtatják. Eleinte ezt nem tekintették virtualizációs megoldásak, csak az utóbbi egy-két évben, többek között a Microsoft által következetesen használt terminológia révén vált ez a módszer a virtualizációs megoldások egyik formájává. A lényeg: a mai fogalmaink szerint "prezentáció virtualizáció" technológia a Citrix alapképessége (core-competence), és úgy szokás a Citrixre tekinteni, mint ezen szegmens legerősebb szereplőjére. A Citrix nagy kihívója a Microsoft a maga "Terminal Server" megoldásával, amely nem önálló termék, hanem a Windows kiszolgálók beépített képessége.

1998-ben indult a VmWare, amely először hozott ki a piacra Intel processzoron futó, szoftveres (érts: telepítendő alkalmazás) hardver-partícionáló alkalmazást. Először a "Vmware workstation", később a "GSX Server" és "ESX Server" termékekkel jelentek meg - ez utóbbi kettő a szerverek felosztását végzik. A munkaállomás- és szerverhardver virtualizáció koronázatlan királya jelenleg a Vmware. Követőik közé tartozik a VirtualIron, a Microsoft és a Xensource is. Ez a technológiai szegmens (tulajdonképpen kettő: munkaállomás és szerver!) kevésbé érett, mint a prezentációs, mivel igazán csak 2003-2004 táján kezdtek az igazn érett megoldások piacra kerülni.

Még fiatalabb technológiai trend az "alkalmazás-virtualizáció". Itt arról van szó, hogy egy alkalmazást úgy becsomagolunk, mintha egy gombóc lenne - gyakorlatilag egyetlen fájlba. Ezt a fájlt másolással a munkaállomásra juttathatjuk, majd ott futtathatjuk. Az alkalmazások így nem zavarják egymást, továbbá az operációs rendszert sem. A végeredményt egy valódi, igény-szerint települő alkalmazáshalmaz. A piacvezető szerepet itt a Softricity játszotta, amíg fel nem vásárolta a Microsofft. A követők közé tartozik az Altiris (ma már Symantec), az Appstream és az Ardence (ma már Citrix)

A virtualizációs technológiák előnye, hogy az egyes informatikai rétegeket finoman elválasztják egymástól, ezáltal az gyorsan cserélhetővé válnak, az egész rendszer pedig kevesebb hibával, nagyobb rendelkezésre állással és jobb reakciókészséggel működhet.

A virtualizáció történetéről a virtualization.info RADAR és ROADMAP oldalain lehet tájékozódni.

A fontosabb játékosok hamar rájöttek, hogy a virtualizáció hatalmas előnyöket hozhat a felhasználóknak, ugyanakkor alapvetően átalakíthatja az erőviszonyokat a szoftveriparban, ezért mindenki hamar kialakította a maga stratégiáját. Ebben - és azt hiszem nem vagyok elfogult - a Microsoft élen járt. Az elsők között, ha nem a legelsőként beszélt komplex holisztikus virtualizációs stratégiáról bevonva a technológiai terminus alá a "terminal server" megoldást, a Softricity felvásárlásával pedig megszerezte az alkalmazás-virtualizáció szegmensben a vezető szerepet. A fenti ábra jobb oldalán látható még egy fontos rublika, amiről nem esett szó, ez pedig a menedzsment. Mind a gyártók, mind pedig a felhasználók hamar rájöttek, hogy a virtualizált környezetben a felügyelet az achilles sarok. Mivel a virtualizáció előnyei hatalmasak, ezért az ipar teljes mértékben adoptálni fogja, vagyis egy idő után tömegtermék lesz, tehát az ára drasztikusan esik majd. A virtualizációs megoldásokat gyártó cégek ekkor a menedzsment irányába mozdulhatnak, onnan szerehetnek profitot. A virtualizációs csata sok tekintetben menedzsment-csata. Csakhogy az ezirányú képességeket meg kell szerezni. A megszerzést pedig jelentősen befolyásolja a kezdeti kiindulópont.

Összegezzük a fentieket egy táblázatban, ahol a Citrix, a Microsoft, a Xensoure és a VmWare szerepel a cikk címében említett egyesülés nélkül. A táblázatban a számok az adott szegmensben elfoglalt relatív erőt jelképezik, nagyjából a jelenlegi ipari közmegegyezés szerint

A felügyelet értékelése azért nehéz, mert valamennyi szereplő nagyon jó menedzsment megoldásokkal rendelkezik a saját termékeinek menedzselésére, általános menedzsment terméket viszont csak a Microsoft gyárt, vagyis csak neki van lehetősége a virtualizáció-menedzsmentet ÉS az általános IT üzemeltetést egyetlen platformra pozícionálni. Másrészről maga a virtualizáció-menedzsment sem egy kiforrott megoldás és az olyan területeken, mint a fizikai-rendszerről virtuálisra konvertálás, a virtuális gépekhez kapcsolódás automatizálása (Connection broker) vagy a gyors, portál alapú üzembehelyezés még mind-mind gyerekcikpőben jár. A nagy szereplők vagy felvásárolnak (pl. a VmWare a Propero-t), vagy fejlesztenek (pl.: a Microsoft a Virtual Machine Manager-t)

 
Microsoft: teljes portfólió, jól artikulált stratégia

Az Xensource-nál szereplő 5-ös szám még magyarázatot érdemel: a Xensource megoldása alkalmas a desktop virtualizációra, nem nem jellemző az ilyen használat. Vannak viszont más cégek (pl. Parallels), amelyek erősek ezen a téren, de a többiekhez nem érnek fel erőben, ezért nem is szerepeltetjük.

Most nézzük meg a táblázatot a Citrix-XenSource egyesülés után

Látszik, hogy a Citrix olyan képességeket szerez, amelyekkel korábban nem rendelkezett, egyúttal a Xensource a vállalatméret növekedésével komolyabb kihívást jelent majd a másik két szereplőnek. De pontosan kinek mekkorát?

A VmWare-nek nincs prezentációs, illetve alkalmazás-virtualizációs megoldása, tehet egy lábon áll. Ezt frontálisan támadja a Microsoft Windows Virtualizáció technológiája, amely 2008-ban, legkésőbb 180 nappal a Windows Server 2008 után jelenik meg. A Microsoft nem akar kétséget hagyni, hogy a szerver-virtualizáció területén a LEGJOBB kíván lenni. Ezt meg is kell tennie, mert csak így védheti meg installált szerver bázisát. A cél elérése érdekében a Microsoft már most olcsóbb, mint a VmWare (A Virtual Server ingyenes, a Datacenter Edition pedig olcsóbb, mint a VmWare megoldás), a Windows Virtualizációval pedig vagy beéri, vagy pedig nagyon megközelíti technológiai fejlettségét tekintve a VmWare-t, ha ugyan el nem hagyja bizonyos funkciókkal.

A Microsoft a Windows Server 2008-al ugyanakkor nagyot lép előre a prezentáció-virtualizáció terén is, ezzel erőteljes nyomás alá helyezve a Citrixet az ő hazai pályáján. Ha ehhez hozzátesszük, hogy vannak technológiai szituációk, ahol az alkalmazás-virtualizáció a prezentáció-virtualizációva versenyez, akkor láthatjuk, hogy a Citrixnek új utakat kell keresnie, mert mindkét erősségénél új helyezet van kialakulóban (Látható, hogy a Microsoft mindenkit a maga területén igyekszik felülmúlni) A Citrix-Xensource egyesülés jó lehetőség, hogy a Citrix új területet találjon a növekedésre, mive a saját területen a Microsoft ezt korlátozza. Az új lehetőség viszont a VmWare pályája - vagyis a VmWare kettős nyomás alá kerülhet.

Ezzel az egyesüléssel tehát a Citrix és a Microsoft nyerhet, a VmWare pedig veszíthet. De a Microsoftnak nemcsak ezért jó ez a hír. A Xensource cég volt a Xen, mint nyílt forrású technológia fő fejlesztője. Ha ez a kapacitás kiesik, vagy a Citrix már nem kívánja felajánlani az erőit a nyílt forrású közösségnek, akkor a RedHat és a Novell, amelyek a Xen-re alapozták a maguk virtualizációs stratégiájukat, hosszú időre (ha nem véglegesen) lemaradnak. A virtualizációs csata elvesztése viszont az operációs rendszerek "háborúját" is eldöntheti. - Ez utóbbi gondolat nem csak bennem, hanem a virtualization.info szerkesztőiben is megszületett.

És mindez miért fontos: azért, mert most dől el, hogy az elkövetkezendő tizenöt-húsz évben ki lesz a meghatározó szerepű a vállalati IT infrastruktúrát szállító vállalatok közül.

1. Onnan jön a pénz, tehát onnan fogalmazódhatnak elvárások
2. A szállítók ezekből a mérnökökből fognak majd élni, nem csoda, ha alakítani akarják az oktatást. Nagyon jól teszik
3. Azért is a szállítókhoz kerülnek ezek a hallgatók, mert ők meg is fizetik őket.
4. A szállítók - lévén hogy az IT eladásából élnek - adnak rá, hogy értsenek az IT-hez. A vevő cégek többnyire nem az IT-ből élnek, csak többnyire használják azt, és az IT általában nem túl magas presztízzsel bír. Ebből azonnal adódik a munkahely vonzási képessége
5. Végül: tessék támogatni a főiskolás (akárhogy, nem csak pénzzel) máris bele lehet folyni az oktatás irányvonalába.

• Level 0 - Kaotikus (Chaotic)
• Level 1 - Követő (Reactive)
• Level 2 - Megelőző (Proactive)
• Level 3 - Szolgáltató (Service oriented)
• Level 4 - Értékteremtő (Value creation)

Itt van Arisztotelés szelleme: nem értjük, ezért kategorizáljuk, így érthetvé válik. A kategóriákhoz most akkor tulajdonságokat lehet rendelni, például a kaotikusra vonatkozóan:

"az IT szervezet kialakítása és üzemeltetése a minimális tudatosságot is nélkülözi"

"az informatikai szervezet nincs tisztában a felügyelendő infrasturktúra pillanatnyi állapotával, kizárólag a felhasználóktól jövő hibabejelentések alapján - vakrepülésben - próbálja felügyelni és karbantartani azt.'"

"A tipikus felügyeleti eszköz a kockás füzet"

A Reaktív kategóriában:

"már megtalálhatók  az alapvető felügyeleti eszközök (esemény és hibakezelés), így a hibák általában a végfelhasználói hívások előtt észlelhetők"

A megelőző kategóriában:

"Ezen a szinten álló vállalatok már folyamatok alapján szervezik informatikai működésüket, amelyek lehetővé teszik a potenciális problémák kivédését, vagy legalább hatásuk mérséklését"

És a többi, és a többi, a cikk itt olvasható (illetve itt kellene olvashatónak lennie) Az igazi csattanó a végén:

"a fenti besorolás szükségképpen szubjektív, s a legtöbb vállalati és informatikai szervezet nem is sorolható be feketén-fehéren egyik kategóriába sem. Alkalmazásonként, platformonként és szervezeti egységenként végletesen eltérő kép bontakozhat ki az elemző szeme előtt"

Hát igen. Konklúzió: Itt vannak a kategóriák, de persze nem jók, nem is lehet őket használni, mert szubjektív, mert eltérő az eredmény stb. stb. Most hogy van ez?

Mert azt meg szintén Arisztotelész mondta (talán a Metafizikában), hogy "ugyanarról a dologról nem állíthatsz valamit és egyidejűleg annak az ellenkezőjét"

Az ember mindig mindent magára vesz. Akkor azt mondja: a mi rendszerünk "kaotikus" lenne, mert például nincs olyanunk , hogy egységes hibakezelés - mint alapvető felügyeleti eszköz, sőt még helpdesk sincs. Nem: még kaotikusak sem vagyunk, mert nincs kockás füzetünk sem.

ilyenkor megy el a kedvem az ilyen módszertanoktól. Mert persze a fenti ellentmondás három mondattal feloldható. Tessék:

1. A vállalatoknak vannak kritikus folyamataik, és kevésbe meg még kevésbé azok.

2. Az IT szervezetek általában ismerik a folyamatokat és azok fontosságát

3. Az kritkussággal arányos módon, továbbá az előforduló hibákkal szintén arányosan igyekeznek felügyelni a rendszereiket és a rendszerkomponenseiket.

Példa: 

1. A kritikus rendszer: ERP. A működéséhez kell: az ERP szoftver; az adatbáziskezelő; a vas; a helyi hálózat; a WAN vonal; meg persze a távoli PC
2. A leggyakoribb hibák: WAN vonal szakad; vonal túlterhelődik; adatbáziskezelő leáll; PC merevlemez tönkremegy
3. "Menedzsment eszközök": Egy kis szoftver, amely pingeli a távoli routert, ha nem válaszol, akkor SMS-ben riaszt. Egy SNMP lekérdező, amely nézi a vonaltúlterhelés, ha 5 percig 90% fölött van, akkor riaszt. Egy szolgáltatásfigyelő, amely nézi, hogy az adatbáziskezelő nem száll-e el; egy tartalék PC feltelepítve. Költség: Egy PC-nyi.

Kérdés: kb hány százalékos lesz a rendelkezésre állás? Mennyi lenne a "menedzsment" eszközök nélkül? Szerintem a rendelkezésre állás - tudományos rekeszizom alapján - kb. 20-30% lenne rendszergazda nélkül.  60-80% lenne rendszergazdával, de a fenti eszközök nélkül. Végül a "menedzsment" eszközök ezt felvihetik akár 90-95%-ra is. Persze minden attól függ, hogy előforulnak-e olyan hibák, amelyek "nem a leggyakoribbak". Pl.: egy switch tönkremegy. Ha nincs tartalék, akkor egy-két napig áll a rendszer. De a swtichek nem mennek tönkre általában. Ez esetben meg 95% a rendelkezésre állás.

A példe a Pareto elvet is modellezi: a problémák 80%-át a költségek 20%-ával meg lehet oldani. A maradék 20% megoldásához kell (kellene) a költségek maradék 80%-a.

És akkor megérkeztünk: költségek. Vajon informatikai érettség az, amikor egy cégvezetés X Ft-ot áldoz valamire és nem Y-t? Nem az IT szervezet, hanem a teljes cég! Informatikai érettség az, ha egy üzleti folyamatnak elég a 70%-os rendelkezésre állás? Nem éppen.

  Ami az ITIL-t illeti, szerintem a következő feltételek mellett van létjogosultsága:

• A cégvezetés fizet azért, hogy ne csak valószínűleg legyen 80% a rendelkezésre állás, hanem biztosan. (Szándékosan alacsony számot írtam). A kettő között ugyanis jelentős az árdifferencia.
• Az IT képes továbbra is differenciálni - a kritkusabb folyamatoknak mindig arányosan nagyobb prioritást adhat, mint a többieknek, beleértve a szolgáltatás minőségét is.
• Az ITIL-t bevezető tanácsadó meg tudja mondani - a fenti menedzsment eszközöknél jobb ár/érték arányt produkálva - hogy mit kell tennie és mit kell vennie az IT szervezetnek. (Mert az ITIL - jellegéből adódóan - nem mondhatja meg)

Azt gondolom, hogy ezeken bukik el az ITIL elterjedése jelenleg: a folyamatok átszervezése után ugyanis többletköltség keletkezik a garantált szolgáltatási szint miatt, a folyamatok bevezetését végző tanácsadók díja miatt és a megvásárolandó felügyeleti eszközök miatt. Ha ez nem térül meg belátható időn belül - kis cégeknél egy év! - akkor nem foglalkoznak a dologgal. És a kör be is zárult, mert épp a kicsi cégeknél hosszabb a megtérülés, olyan hosszú, hogy még az outsourcing sem viszi le egy év közelébe. Nagyobb vállalatoknál meg az a kérdés, hogy mekkora a kritikus határ? 500 felhasználó? 1000? Szerintem valahol ekörül, de inkább ezer felett.

A cégvezetés ritkán fizet valószínűség helyett a garanciáért. Ki szeret biztosítást fizetni?

Végül: a bevezető tanácsadó - Magyarországon mindenképp - nem képes beleélni magát a megrendelő helyzetébe és össze vissza ajánlgat mindent, amit a megrendelő vagy tud használni, vagy nem. Legalábbis az én tapasztalatom ez.

Vagyis: szép-szép ez az ITIL, de nem csak az IT szervezet "érettségén" múlik, hogy alkalmazzák-e. Sokkal inkább múlik a cég profilján, gazdasági szükségletein, méretén, a tanácsadók rátermettségén. Végül, és csak végüll a szükséges anyagi erőforrások meglétén.

A Gartner besorolást pedig el kell felejteni.