Az alkalmazások és a platformok elsőbbségi kérdésének és a két fogalom kölcsönhatásának vizsgálatakor hasznos dolog tetszetős elméleteket gyártani, illetve a mikor és a hogyan módszertanát felállítani. Nem szabad azonban megfeledkezni a „Mennyiért?” kérdés feltevéséről sem.
Az informatika mára ugyanolyan iparág, mint bármelyik, itt is újabb és újabb megoldások keletkeznek. Hetényi László, a Budapesti Főpolgármesteri Hivatal főinformatikusa szerint nyugodtan hasonlíthatjuk például a gyógyszeriparhoz, csak az IT-ben az adagok nagyobbak. Minden új gyógyszer jobb, mint az előző, mindegyiknek van mellékhatása, és bár egyre több pénzért, de gyógyul az a szerencsétlen beteg, igaz, a végső megoldást majd a halála hozza el. Ugyanakkor, ha örökké élnénk, megtalálnánk a legjobb gyógyszert is.
Tyúk–tojás szindróma
Addig is sok vállalat informatikai igazgatója teszi fel magának a kérdést, hogy a szoftverbevezetéseknél előbb a hardverplatformot kell-e kialakítani, erre tegyék- e rá az alapszoftvert, vagy pedig előbb foglalkozzanak az alkalmazással, és ehhez igazítsák hozzá a platformot. Igazából ez a két megközelítés kölcsönhatásban van egymással, és az ügyfél valójában üzleti modellt választ, ehhez próbál informatikai rendszereket kialakítani –
boncolgatja a kérdést Klotz Tamás, az Oracle Hungary marketingigazgatója. Ez azt jelenti, hogy az adott cég az első körben megnézi, milyen iparági alkalmazások léteznek, ezek mennyire elérhetők, s mennyire illeszthetők az elképzelt üzleti modellbe. A horizontális alkalmazások esetében (például a vállalatirányítási rendszereknél) már letisztultabb a kép, de még így is nagyon széles a választék.
A probléma ott merül fel, hogy egy vállalatnak többnyire széles tevékenységi köre van, s ezekhez több alkalmazás is társul. Tehát ha egy cég kiválasztotta az iparág-specifikus alkalmazást, el kell gondolkodnia azon, hogy ezt milyen technológiára építse, és miként tudja
összekötni más alkalmazásokkal. Itt merül fel az integráció kérdése, amikor is nagyon erősen előtérbe kerül az alkalmazást futtató platform. Ettől a platformtól függ ugyanis az egész rendszer kialakításának a sikere. Lehet tehát platformot választani, viszont az alkalmazást is úgy kell megválasztani, hogy az funk-cióiban megfeleljen.
Lehet fordított is a megoldás, azaz egy cég modern, lehetőleg szolgáltatás alapú architektúrára (SOA) épülő platformhoz választ alkalmazást. Teszi ezt annak érdekében, hogy egy állandóan változó világban rugalmasan alakítható üzleti modellen tudjon dolgozni. A választást mindazonáltal mindig az iparági alkalmazás szem előtt tartásával fogja megtenni.
Kezdetben vala…
Mindebből kitűnik, hogy a platform és az alkalmazás erőteljes konvergenciájáról kell beszélni – folytatja Kovács András, az Iqsys technológiai igazgatója. Az elmúlt évek informatikai fejlődése megmutatta ugyanis, hogy nem szabad csak alkalmazásokban gondolkodni, ehelyett a platformot kell előtérbe állítani.
Kezdetben a vállalatok mindenfajta alkalmazást vásároltak (ERP-t, szakági szoftvercsomagokat), és ezeket szigetszerűen működtették. A világ felgyorsulásával és a kommunikációs lehetőségek kiszélesedésével (internet, mobiltelefon) az üzleti élet szereplői már egyre kevesebbet érintkeztek egymással hagyományos levél és fax útján. Igen ám, de a vállalati folyamatok túlmutatnak a részlegeken, s attól, hogy rendelkezésre áll egy ERP-rendszer, egy internetes nyilvántartó rendszer és különféle szakági rendszerek, egy rendelés még nem fog végigmenni rajtuk.
Ekkor a vállalatok nekiláttak, hogy pont–pont kapcsolattal összekössék a rendszereket – ám a világ ettől csak még bonyolultabb lett. Például egy bankban előfordulhat, hogy egy adminisztrátor felhasználóként ötfajta képernyővel is dolgozik, és a másik oldalon az üzemeltető csak az alkalmazások összekötéséből származó káoszt látja. Pedig arra van szükség, hogy a folyamatok ne csak a vállalaton belül menjenek végig az üzleti részlegek között, hanem a partnereket is valós időben lehessen az üzleti folyamatokba bevonni. Mindezt azonban sem a csomagalkalmazások, sem a többi, önálló üzemeltetésű rendszer nem teszi lehetővé.
És eljő a SOA
Az iparág válasza a problémára a SOA volt. Ennek az architektúrának a jóvoltából különböző szoftverek – legyenek csomagok, egyedi fejlesztések vagy külső szoftverszolgáltatások – olyan alkalmazásokká kapcsolhatók össze, amelyek lefedik az igényeket. Az így létrejövő egységes szolgáltatásorientált architektúrában már nem az egyes alkalmazásokban bújnak meg az összeköttetést biztosító elemek (adatok, jogosultságkezelés, integrációs logika stb.), hanem a központi infrastruktúrában kapnak helyet. Ezeket számos olyan vezérlő- és metaadat egészíti ki, amelyek révén együtt kezelhető lesz az egész bonyolult konglomerátum, azaz könnyen összekapcsolhatóvá válnak az iparági és általános vállalatirányítási rendszerek, valamint az egyedileg kifejlesztett alkalmazások.
A vállalati informatikában szükséges képességeket különbözőképpen lehet biztosítani. Lehet általános, szabványos alkalmazáscsomagokkal, ám ezek nem fedik le a vállalat igényeit, különösen nem versenyhelyzetben – hacsak testre nem szabják.
Az egyes cégek alaptevékenységeinek esetében – ahol a cégnek meg kell különböztetnie magát, gyorsan kell reagálnia a piaci változásokra – az alkalmazásokat egyedi fejlesztéssel kell létrehozni, de kívülről is igénybe lehet venni szolgáltatásként. Minden vállalatnak, intézménynek el kell döntenie, hogy az üzleti támogatáshoz szükséges képességeket honnan és milyen forrásból szerzi be.
A SOA infrastruktúrája lehetővé teszi, hogy a meglévő rendszerekből és külső funkciókból gyorsan és viszonylag költséghatékonyan tudjuk felépíteni azokat az üzleti folyamatokat támogató alkalmazásokat, amelyekre nap mint nap szükség van.
Az alkalmazás és a platform konvergenciája abban figyelhető meg, hogy nemcsak a platform-, hanem az alkalmazásszállítók is erőteljesen szorgalmazzák a SOA-t. Sorra jelennek meg például a szolgáltatás alapú üzleti alkalmazások (lassan már a kisebb fejlesztőcégek is rákapnak), amelyekben a fent említett képességek szabványos, a vállalati folyamatokba beépíthető módon jelennek meg. Az alkalmazások funkciói elérhetők a csomagon belül és kívülről is, kapunk hozzá egy szabványos, workflow-val vagy üzletifolyamat-kezeléssel (BPM) összekapcsolt folyamatot is. Ha ez nem felel meg, akkor módosíthatjuk, illetve a funkciókat, képességeket más folyamatokba is bekapcsolhatjuk.
Összhangzattan
Az alkalmazás vagy/és platform kérdése mindazokat a stratégiai és taktikai kérdéseket felveti, amelyek előfordulhatnak egy vállalatnál vagy intézménynél az informatikai üzemeltetés mindennapi gyakorlatában – mondja Horváth János, a Magyar Hivatalos Közlönykiadó vezérigazgató- helyettese, aki szerint a témát három aspektusból érdemes megragadni.
A legkritikusabb elem az informatikai eszközök élettartam-összhangja. A rendszer elemei különböző életkorúak, hiszen általában nem egyszerre telepítették őket, s ez a tény, különösen nagy szervezeteknél, hatalmas fejtörést okozhat az informatikusoknak, amikor választásra kerül a sor. Az összhang megteremtésének hiányosságain még a legjobb ITIL-technikák sem segítenek.
Másodszor, minden informatikai rendszer irányítója szeretné, ha nem függne a beszállítóktól. Ennek szellemében olyan platformokat kell létrehozni és működtetni, amelyen senkinek sincs kiszolgáltatva – bár ez sem könnyű dolog.
A harmadik lényeges aspektus a felhasználó befogadóképessége. A szállító ugyanis abban a helyzetben van, hogy töviről hegyire ismeri integrált rendszerét, hiszen éveken, évtizedeken át fejlesztgette. A felhasználóknak viszont gyakran néhány nap alatt kell megtanulniuk, aztán később a gyakori változtatásokat is el kell sajátítaniuk, s az idők folyamán anynyira elveszítik a fonalat, hogy a végén már nem is érdekli őket, mi történik.
Tudni kell tehát kezelni a változásokat, mind a folyamatok, mind az emberek vonatkozásában, s az informatikusnak olyan közeget kell teremtenie, ahol ezekre a változásokra fogadókészség mutatkozik. Az emberek ugyanis még mindig sok olyan helyen dolgoznak, ahol alacsony a munkakultúra, a szervezési kultúra és a motiváció.
Egyszerű felület
Amikor elkészül egy csomagalkalmazás, három irányból próbálják meg összehangolni. Az egyik irány, hogy rugalmasan képezze le az üzleti folyamatokat, a másik, hogy a tranzakciókból kinyert információkat előkészítse a döntéshozatalhoz üzleti intelligencia jellegű kiterjesztésekkel, s a harmadik, hogy mindezt egyszerű felhasználói felület közbeiktatásával, minél jobb megoldással tegye – reagál Klotz Tamás.
Fontos tehát, hogy egy rendszert, egy platformot ne csak informatikai szempontból lehessen jól üzemeltetni, hanem jól összehangolt is legyen. Erre az egyértelmű válasz a SOA, amely megmondja, hogyan kell létrehozni és integrálni rendszereket. Ha egy kész alkalmazáscsomag SOA-platformra épül, akkor könnyebb lesz megfelelő felhasználói felületet kialakítani és az integrációt megvalósítani. Azokat a kérdéseket kell inkább feltenni, hogy miként kell mindezt megcsinálni, mikor lesz aktuális, van-e már SOA-platformra épülő kész, iparág-specifikus alkalmazáscsomag.
Amikor a SOA alkalmazásával kapcsoljuk össze a különálló rendszerek funkcióit új folyamatokká, akkor a felhasználók már csak egy egységes, könnyen kezelhető rendszert érzékelnek, mert egy workflow-val támogatott, egységes felhasználói felületet használnak.
Erre jó példa egy banki front-end rendszer, ahol a SOA alapú integráció előtt adott esetben négy-ötféle képernyővel is bajlódniuk kellett, és esetleg csak a munkaköri leírásból silabizálva tudták elvégezni a teendőiket – véli Kovács András. Ami pedig a rendszerek és eszközök élettartamát illeti, a SOA lehetővé teszi, hogy a meglévő rendszerek ritkán változó funkciói sokáig megmaradjanak, az üzleti versenyképességet befolyásoló funkciókat pedig gyakrabban lehessen változtatni, azaz eltérő életciklusú komponenseket – meglévő rendszereinket és újonnan fejlesztett szolgáltatásokat – kapcsoljunk össze egy folyamatban. Mindezt a munkafolyamat-kezelő és felhasználói felület fogja össze.
A SOA lényege, hogy az IT-vezetés, az üzleti vezetéssel együttműködve, a szigetrendszerű üzemeltetés helyett egységesen kezelje a teljes informatikai vagyont, s döntsön arról, mit tart meg hosszú távon, s mit cserél le, módosít hamarosan. Persze, csak azokat a rendszereket kell bekapcsolni a SOA-ba, amelyek részlegek közötti vagy a vállalaton kívülre irányuló folyamatokat kezelnek, azokat nem kell, amelyek csak egy üzleti területet szolgálnak ki.
Az államigazgatás mint mostohagyerek
Az egységesítés problémája mindazonáltal nem újdonság, csak éppen koronként más megoldás került előtérbe. „Először jöttek az integrációs szoftverek, később a workflow-ra esküdtek, most pedig a SOA az egyedül üdvözítő. Vajon öt év múlva miről fogjuk azt mondani, hogy a végső megoldás?” – teszi fel a költői kérdést Hetényi László, hozzátéve: a SOA nagy talánya, hogy informatikai vagy gazdasági problémákra ad-e választ. Szerinte alapvetően közgazdasági problémákról van szó, nevezetesen, hogy egy vállalat vagy intézmény milyen hatékonysággal költ pénzt informatikai eszközök vásárlására. „Mivel zöldmezős beruházás ritkán akad, a cégek általában valamilyen folyamat közepén fognak hozzá az öszszehangoláshoz, amikor kiderül, hogy az elődök mindent rosszul csináltak, de mi ismerjük a varázsszert, s mindent helyrehozunk” – mutat rá a szakember a szokásos menetrendre.
Aztán itt van a szabványos, iparág-specifikus alkalmazások kérdése is. Az üzleti világ számos ágazatában már működnek jól bevált megoldások, a honi államigazgatásban azonban lámpással kell keresni a szabványos célalkalmazásokat – így aztán nincs mihez hozzárendelni a hardver- vagy valamilyen más platformot. Mindazonáltal választani a szakmai és a közgazdasági szempontok együttes mérlegelése után kell: meg kell nézni, menynyi pénz áll rendelkezésre, és ezért mit lehet kapni.
Nem árt hosszabb távra tervezni, s bár ez az államigazgatásban szinte lehetetlen, meg kell kísérelni meghatározni, hogy milyen szintű szolgáltatásokat akarunk megvalósítani, támogatni, mennyi idő alatt és milyen módon. S ha sikerül, ehhez már hozzá lehet rendelni szabványokat, szabályokat, belső eljárásokat – beleértve a szoftver- és a hardverarchitektúrát, a humán erőforrást, az üzemeltetést is. A magyarországi közigazgatás dolgát az is nehezíti, hogy míg a nyugat- európai önkormányzatok költségvetésük 4 százalékét költik informatikára, ez az arány nálunk kevesebb, mint 0,5 százalék.
Tovább árnyalja a helyzetet, ha egy állami feladatokat ellátó intézményt több, korábban félig-meddig önálló szervezetből gyúrnak össze – árnyalja a kórképet Király Pál, a Földmérési és Távérzékelési Intézet információvédelmi megbízottja. Ilyenkor a részlegek, illetve ezek vezetői ragaszkodnak saját hardvereikhez és alkalmazásaikhoz, így nehéz véghezvinni az integrációt. A másik probléma, hogy az állam elvárja: az intézmény kifogástalanul és magas szinten teljesítse feladatát, ám ehhez nem biztosít elégséges erőforrást; így a vezetők nem azon gondolkodnak, mit és hogyan fejlesszenek, hanem azon, hogy az intézmény miként élje túl az évet.
SO(H)A-napján?
Még szkeptikusabb álláspontra helyezkedett a hazai SOA-kezdeményezésekkel kapcsolatban Gálfi Zoltán, a KFRT Számítástechnikai Zrt. értékesítési igazgatója. Szerinte a kifejezést át kellene alakítani Software Oriented Help Architec-ture-ré, s akkor a rövidítés jelezni fogja, mikor valósul meg a koncepció az eredeti formában Magyarországon. Tehát soha, mivel nem oldja meg azokat az alapvető problémákat, amelyekkel Magyarországon az alkalmazásinformatika küszködik. Ennek két fő eleme a pénz, valamint a határidők szűkössége, s – mivel a polcról levehető termékek piacát a multik uralják – ehhez hozzájönnek még a lokalizáció nehézségei.
Gondot jelent a multinacionális hardver- és szoftvergyártók – talán akaratlan – összejátszása is. Az új hardvereken ugyanis már nem futnak hatékonyan a régi szoftverek, ezért meg kell venni a szoftver új változatát; s ez igaz fordítva is: az új változatú program nemigen szereti a régi hardvert, így azokból is újabbat kell beszerezni. A sietve piacra dobott alkalmazások ráadásul tele vannak hibával, így az implementálást kiforrott és lokalizált, azaz másfél-kétéves változatokkal érdemes végezni. A nagy bevezetési projektek évekre elhúzódnak, s így nem lehetetlen, hogy mire a végére érnének, már kezdhetik is a „verzióváltást” – ezért nehéz költségeiben kezelhető, hatékony megoldást találni.
Aztán itt van az újabb piacok keresésének a problémája is. Például az ERP-rendszerek fő moduljaival már telített a hazai piac, ezért a szállítók olyan, újabb és újabb modulokat találnak ki, amilyeneket egyébként olcsóbb, külső fejlesztőmunkával létre lehetne hozni, és integrálni lehetne a SOA-ba, ám a nagy szállítók biztos, ami biztos alapon a saját rendszerükön belül is kifejlesztik. Ez azt is jelenti, hogy az eddigi modulokat további részekre darabolják, és ez jelentős árnövekedéssel jár. Nem olcsó a hardverek és a szoftverek támogatása sem.
A SOA tehát az elképzelt formájában nem valósul meg Magyarországon, mivel a nagy gyártók mohósága miatt az erősen korlátozott anyagi forrásokkal rendelkező kisebb felhasználók reménytelen helyzetben vannak, így csak összeeszkábált megoldásokat engedhetnek meg maguknak, tovább szaporítva a szigetrendszerek erdejét – véli Gálfi Zoltán. Az integrációs projektekben a hardver- és szoftverproblémákhoz még egy további gond is járulhat, nevezetesen, hogy megváltozik a felhasználó – mutat rá Alföldi István, a Neumann János Számítógép-tudományi Társaság (NJSZT) ügyvezető igazgatója.
Ezt az utóbbi 10 évben számos eset is alátámasztja az államigazgatásban és az egészségügyben, ahol az állandó átszervezések miatt két évnél tovább nem maradt meg ugyanaz a környezet, elértéktelenítve az informatikai befektetéseket. És ezt nem lehet a SOA-ba beillesztett egy-két plugin-megoldással rendbe hozni. El kellene gondolkozni azon, hogy hány száz- vagy ezermillió forintot költöttünk el feleslegesen informatikai fejlesztésekre.
Az egy dolog, hogy a multinacionális cégek minél többek akarnak kisajtolni a megrendelőből; viszont a megrendelő dolga az lenne, hogy egy-két, netán öt év múlva is ugyanúgy használható rendszert kérjen a szállítótól. A felhasználókról sem szabad megfeledkezni, hiszen az információs társadalom szempontjából sokkal fontosabb tényezõnek számítanak, mint a hárombetûs bûvszavak.
Ne alkalmazást, megoldást!
Bár a SOA mögötti koncepció – az integráció – nem új keletû igény, azért van különbség az IT „történelmi koraiban” jelentkezõ szükségletei között – magyarázza Klotz Tamás. Húsz évvel ezelõtt például fel sem merült, hogy a beszállító rendszerével kapcsolatba kell kerülni, a fõ kapcsolattartási módszer a papír alapú kommunikáció volt, levélben vagy faxon, esetleg telefonon is kereshették egymást a partnerek. Tíz évvel ezelõtt az is elképzelhetetlen volt, hogy egy banki front-office ne papíron vegye fel az ügyfél adatait és igényét, s ezeket ne így adja át a back-office-nak feldolgozásra. Mindez rengeteg emberi munkát, képzést igényelt.
Mai elképzelések szerint, ha valaki SOA alapon kezd gondolkodni, akkor kevesebb problémája lesz az üzemeltetéssel, kevesebb embert kell kiképezni, rugalmasabb rendszert fog kapni, amelyet aztán jobban lehet a változó körülményekhez, illetve az üzleti modellhez alakítani. Ezért ma az üzletnek és az informatikának közel kell kerülnie egymáshoz, s ha ez nem történik meg, mert az üzleti oldalon esetleg nincs meg az elkötelezettség, akkor a projekt sikertelen lesz. Az üzletet ugyanis legfőképpen az érdekli, hogy az informatika milyen hozzáadott értéket tud neki adni.
Egyébként két dolog nyújthat hozzáadott értéket: a kész alkalmazásként megjelenõ, iparág-specifikus tranzakció-kezelõ rendszer és az üzleti intelligencia. Ezt a kettõt, persze, össze kell kötni, hiszen mindenki friss jelentéseket akar olvasni. Az összekötéshez viszont a SOA-ra van szükség. A kölcsönhatás tehát állandó, mindazonáltal az üzleti döntéshozó elõször alkalmazást fog választani.
Nem szabad szem elõl téveszteni, hogy a változó világ új üzleti modelleket, új folyamatokat kényszerít ki a cégekbõl. Akkor járunk jobban, ha ezeket a folyamatokat rugalmasan össze lehet állítani komponensekbõl. Így elkerülhetõ, hogy egy régi, monolitikus, integrált ERP ne legyen használható ugyanolyan hatékonysággal a változások után is. A SOA-koncepció kialakításakor a vállalatoknak vigyázniuk kell arra, hogy azokat a komponenseket erõsítsék, amelyek a különféle alkalmazások minél jobb összeillesztését szolgálják – beleértve a portálokat és a dokumentummenedzsmentet is.
Nem kár az energiáért
S ha a bevezetés szintjén nem is, de a tudás szintjén a legtöbb IT-vezetõnek ott van a fejében a SOA – fûzi tovább Rabe Ágnes, az Xapt Hungary kereskedelmi igazgatója. Arra ugyanis már a közepes cégek IT-felelõsei is rádöbbentek, hogy az alkalmazásokon kívül szükség van más megoldásokra is (a vason kívül), amelyek az alkalmazásokat együttmûködtetik, s
lehetõvé teszik a kommunikációt a partnerekkel is. Csakhogy az még ritkán tudatosul bennük, hogy ennek is megvan az ára. Amikor a cégek IT-költségvetésüket tervezik, elsõsorban az alkalmazásokat veszik számba, s ha marad még pénzük, akkor foglalkoznak az együttmûködést lehetõvé tevõ köztesszoftverrel is.
Abban nagy a felelõsségük az IT-cégeknek, hogy ne alkalmazásokat, hanem megoldásokat ajánljanak és szállítsanak ügyfeleiknek. Bár sokan ezt állítják magukról, mégis nagyon kevés az igazán hozzáértõ, széles látókörrel és tapasztalattal rendelkezõ, megoldásszállító szoftverház.
A szállítónak azonban nincs könnyû dolga, mert a döntéshozó általában nem közvetlenül, hanem csak végfelhasználóként van kapcsolatban a SOA-val és a köztesszoftverekkel, így elõnyét közvetlenül nem érzékeli, s nehéz eladni neki. Annak érdekében, hogy az alkalmazások közötti együttmûködés az evolúció egy következõ lépcsõjére léphessen, fel kell hívni a figyelmüket: a SOA használatával csökkenthetõk az üzemeltetési költségek. Nagy rendszerek esetében ugyanakkor komoly dilemma a stabilitás és a változás kettõsségének kezelése, azaz alkalmazásfejlesztés közben állandóan mérlegelni kell, melyek a rendszerkörnyezet meghatározó, változtathatatlan, s melyek a változást igénylõ elemei – beszél a nehézségekrõl Kertészné Gérecz Eszter, a Magyar Országgyûlés Hivatalának IT-vezetõje.
További gond, hogy amikor a felhasználó meghatároz egy alkalmazást, háttérbe szorul a stabil nyilvántartások precíz megtervezése, holott tulajdonképpen ezekre a stabil alapokra kellene rátelepíteni az alkalmazásokat. Ilyenkor válik hamar elavulttá a rendszer. A szállítók sokszor nincsenek felkészülve arra sem, hogy a meglévõ rendszerekhez miként tudnának újabb elemeket hozzáépíteni, mivel nem akarnak energiát fektetni a régi rendszer mélységeiben való megismerésébe.
Tézis, antitézis
A SOA és a TCO egymás antitézisei – állítja Szentiványi Gábor, az ULX Kft. ügyvezetõ igazgatója. A TCO igazat állít ugyan, de nem jó mérõszám. Egy vállalat forgalmának körülbelül 10 százalékát költi informatikára, a fennmaradó 90 százalék a reputáció, az üzleti, azaz hozzáadott érték. Az informatikai kiadásokból le lehet faragni, így a névleges TCO alacsonyabb lesz, ugyanakkor a szintén informatikai projektként elszámolt SOA éppen a maradék 90 százalékhoz ad hozzá értéket számos területen, például a projektmenedzsmentben.
A SOA segít a monopóliumok lebontásában is: amíg az elmúlt évtizedekben, korszakokban egy-egy hatalmas szállító otthagyta lábnyomát az informatika minden területén (például az IBM vagy a Microsoft), addig a 21. században, lassan ugyan, de lebomlanak az egyeduralmak. A szoftverek és hardverek komplexitása ugyanis elérte azt a fokot, hogy már egy gyártó nem tudja áttekinteni a skálát, s az állandó változások miatt nem tud megfelelõ minõséget nyújtani minden szegmensben. A szolgáltatások ráadásul a SOA jóvoltából csereszabatosakká válnak, és ezzel a köztesszoftver kap hangsúlyos szerepet – ennek megvalósító eszköze a vállalati szolgáltatási busz (enterprise service bus). A csereszabatosság miatt többen is hozzáférnek a „kondérhoz”, egyforma értéket szolgáltatva ugyanannak a vevõnek.
Mindazonáltal a SOA nem hardverkérdés, bár kezelni kell a kövületté váló „vasak” problémáját, hiszen ezek akadályozhatják a SOA további fejlõdését. Erre nyújthat jó megoldást a virtualizáció.
Azonban ha architektúráról és komplex rendszerekrõl beszélünk, szólni kell a teljesítõképességrõl, azaz a rendszer sebességérõl is. Ha túl komplexre építjük a rendszert, lehet, hogy lelassul, s nem tudja kellõképpen kiszolgálni az ügyfeleket, ezért a monolitikus, nagy teljesítményû alrendszerek még fenn fognak maradni egy ideig – aztán pedig lassan ezek is beolvadnak a nagy rendszerbe, mert a párhuzamosítás és a hardverek fejlõdése ezt lehetõvé teszi.
Persze, a SOA mint vízió létjogosultsága nem vitatható, a probléma inkább a hitelességével van – figyelmeztet Kiri Róbert, a Stratis Vezetõi és Informatikai Tanácsadó Kft. igazgatója. Minden szállító azt hirdeti, hogy a SOA milyen jó az ügyfeleknek, arról viszont nemigen hallani, hogy az adott szállító saját falain belül, a szoftvergyártásban hogyan használja ezt a platformot. Kézenfekvõ lenne, hogy õk elsõként vezetik be maguknál a SOA-t mint technológiát és mint mûködési modellt. Tehát ne csak hirdessék a hitet, hanem cselekedjenek is eszerint. Az üzemeltetésrõl is el kell gondolkodni. Az alapideológia szerint minél integráltabb egy rendszer, annál nehezebb üzemeltetni; ha valahol meghúzunk egy szálat, ki tudja, mi és hol fog felborulni.
Konklúzió
A szállítók nem szeretik, bár megértik még csak potenciálissá sem vált – elsõsorban önkormányzati – kuncsaftjaik elsõ reakcióját, amikor valami nagyszerût készülnek kínálni: a felkeresett szervezet elõtt ugyanis az a dilemma tornyosul, hogy informatikát fejlesszen, vagy utcát aszfaltozzon. Ilyenkor a szállító általában hangos elköszönéssel veszi a kalapját, mert érzi, beszélgetõpartnere az utóbbi felé hajlik. Pedig Klotz Tamás szerint hosszabb távon talán jobban járna, ha az informatikát választaná, s tisztában lenne vele, hogy nem (csak) technológiát vesz, hanem hosszú távú megoldást létező üzleti problémáira. Ez pedig szemléletváltást követel.
Mártonffy Attila
