ÜZLETI ÉS INFORMATIKAI ARCHITEKTÚRA KAPCSOLATÁNAK MODELLEZÉSE1 Dr. Fehér Péter 1
BEVEZETÉS
A nagy szervezetek esetében megfigyelhető, hogy igen komplex, külső szemlélő számára indokolatlan nagyságú, és logikátlan megoldásokat tartalmazó infokommunikációs (IKT) architektúrával rendelkeznek. Ez az architektúra részben az üzleti igényeknek való gyors megfelelés miatt alakul ki, amikor a gyors változtatási kényszer miatt nem jut sem idő, sem energia az új megoldások meglévő architektúrába való tudatos beillesztésébe (Weill és Ross, 2009). Ez az architektúra ugyan megfelelően kiszolgálja az üzleti architektúrát, de megléte mind fejlesztési és üzemeltetési szempontból kockázatossá és költségessé teszik a működést és korlátozza a változtatási lehetőségeket. Jelen tanulmányban azt vizsgáljuk, hogy ilyen komplex infokommunikációs architektúrák esetében milyen lehetőségek állnak rendelkezésre az egyszerűsítésre. Ezúton is köszönjük a kutatáshoz adatot, hozzáférést biztosító szervezetek számára a támogatást! 2
SZERVEZETI ARCHITEKTÚRÁK
2.1
Szervezeti architektúra modellezés
Egy vállalat felépítését és működését az szervezeti/vállalati architektúra (enterprise architecture) fogalom keretei között írhatjuk le. Nem véletlen az építészeti fogalommal való kapcsolat, hiszen szinte tervrajz szerűen modellezhető ez a felépítés, különböző módszertanok felhasználásával. Az architektúra definíciója alatt – melyet jelen tanulmány keretei között is használunk, egy rendszer, jelen esetben egy szervezet alapvető szervezési módját értjük, amely megtestesül (a) az alkotórészeiben, (b) a köztük és a környezettel fennálló kapcsolataiban, továbbá (c) a tervezését és továbbfejlesztését irányító elvekben. Az ISO 15704 szabvány ezt a megközelítést alkalmazza, mely szerint az architektúra leírja egy rendszer elemeinek alapvető elrendezését, definiálva a köztük lévő kapcsolatokat (legyen az fizikai vagy koncepcionális objektum vagy entitás). A vállalati architektúra kontextustól függően jelenthet: •
egy formális rendszer leírást komponens szinten, mely segíti az implementációt;
•
komponensek struktúráját, kapcsolataikkal, elvekkel és útmutatókkal a fejlődésük kezelésére;
• rendszer vagy komponens-‐szintű szervezeti struktúrát. 1 Megjelent: Átalakulás és koszolidáció a Magyar gazdaságban és gazdaságirányításban, Válogatás a 50.
Közgazdász-‐vándorgyűlés előadásaiból, Eger, 2012. Szeptember 27-‐29. 13 oldal. Megjelenés ideje: 2013.
1
Az angol „enterprise architecture” fogalom vállalati architektúrának fordítható, ugyanakkor ezen fordítás (mint az angol eredeti is) azt a benyomást teszi, hogy csupán piaci szervezetek számára lehet érdekes ezen megközelítés alkalmazása. A valóságban bármilyen iparágban működő szervezet – így beleértve a kormányzati szervezetek, intézményeket is – leírható ezen elvek alkalmazásával, ezért jelen tanulmány keretei között a megengedőbb „szervezeti architektúra” fogalmat használjuk. Ebben a fogalomrendszerben is megkülönböztethetőek ugyanakkor eltérő irányzatok. Kang és társainak (2010) megközelítése az gyakorlatban széles körben elfogadott megközelítést alkalmazzák, melyben a szervezeti architektúrán belül megkülönböztetik az üzleti, emberi erőforrás és információtechnológiai területeket. Az üzleti architektúra tartalmazza az üzleti stratégiát, teljesítmény mutatókat, és az üzleti folyamatokat, kapcsolataikkal együtt. A stratégiával összhangban az üzleti folyamatokat végrehajtják, és a vonatkozó teljesítmény mutatók alapján értékelik őket. Az erőforrás architektúrák – IT és emberi erőforrás architektúra – szintén tartalmaznak stratégiákat, teljesítmény mutatókat, erőforrásokat és kapcsolatokat. A vállalati erőforrásokra azért van szükség, hogy rugalmasan szolgálják ki az üzleti folyamatokat, amint az üzleti folyamat megváltozik. Ha az erőforrások túl szorosan kapcsolódnak az üzleti folyamatokhoz, rugalmasságot nehéz elérni. Az üzleti folyamatokat és a vállalati erőforrásokat külön kell meghatározni és kezelni, és csak lazán szabad egymáshoz kötni őket. Az üzleti vállalati architektúrában fontos szerep jut az üzleti stratégiának. Ahogy a fenti ábra is mutatja, minden részarchitektúra rendelkezik saját stratégiával. Mivel a vállalati erőforrások (IT erőforrások, emberi erőforrások) célja az üzleti folyamatok kiszolgálása, az erőforrás stratégiák (IT stratégia, emberi erőforrás stratégia) olyan stratégiák, melyek az üzleti folyamatokat kiszolgáló erőforrásokkal foglalkoznak. Más szóval az erőforrás stratégiák azzal foglalkoznak, hogy mennyire jól szolgálják ki az erőforrások az üzleti folyamatokat. Az IT terület egyre fokozódó hangsúlyosságával, az IT stratégiák és az üzleti stratégiák egymásba mosódtak, összekeveredtek. A fenti kutatás az üzleti stratégiát egy irányvonalnak vagy egy elérni kívánt helyzetnek tekinti, amerre a vállalatnak fejlődnie kellene, és az üzleti folyamat azon tevékenységek összességét fedi le, melyekkel az üzleti stratégiát végrehajtják. Ezzel párhuzamosan, az erőforrás stratégiákat úgy határozza meg, mint vállalati erőforrás politikák az üzleti folyamatok precíz kiszolgálásához, és a vállalati erőforrások (IT erőforrások, emberi erőforrások) olyan erőforrások, melyek segítenek az üzleti folyamatok szisztematikus végrehajtásában.
Ezen megközelítés létjogosultsága mellett egy architektúra fejlesztési és modellezési módszertanok (pl. TOGAF) szívesen alkalmazzák az üzleti és információtechnológiai architektúrák összekapcsolására a szolgáltatási architektúra megjelenítést, miközben az emberi erőforrás architektúra felépítést az üzleti architektúra részének tekintik. Ezen megközelítés szerint a szolgáltatási architektúra feladata olyan absztrakt informatikai funkciók definiálása, melyek üzleti értéket teremtenek. Ez az összekapcsolás biztosítja, az üzleti és informatikai területek közötti fogalmi eltérések leküzdését is. Az informatikai (illetve a konvergencia miatt az infokommunikációs) architektúrán belül megkülönböztethetőek az alkalmazási, technológiai és adat elemek (Fehér-‐Szabó, 2011; Leblanc, 2008). Az architektúra modellezés, és módszertanok alkalmazásának céljai között a következő főbb megközelítések azonosíthatóak:
2
• •
Statikus architektúra modellezés: a modellezés célja alapvetően a új architektúrák tervezése, illetve a meglévő architektúrák dokumentálása. Dinamikus architektúra modellezés: dinamikus modellezés esetében az architektúra leírást folyamatosan változónak tekintik, és lehetőség van akár operatív, akár stratégiai szinten a meglévő és célállapotok közötti átmenet értelmezésére.
A gyakorlatban jellemzően a statikus architektúrák alkalmazása a jellemző, míg a dinamikus modellek alkalmazása egyelőre kiforratlan. 2.2
Infokommunikációs architektúra komplexitás
A komplex infokommunikációs architektúrák kialakulását önmagában nem, vagy csak részben indokolja egy szervezet nagysága és komplex tevékenysége. A gyakorlati megfigyelések szerint (Weill és Ross, 2009) az indokok között említhetjük a következőket: •
•
•
Decentralizált döntések a beszerzésekről és fejlesztésekről: jellemzően ugyanarra a feladatra így több, egymás nem együttműködő megoldás jön létre (alkalmazási és adat architektúra), illetve heterogén eszközbeszerzés történik (technológiai architektúra, pl heterogén számítógéppark, heterogén telefonkészülék park, stb.). A jogos – és kevésbé jogos – üzleti igények gyors megvalósítása érdekében inkább gyors, mintsem átgondolt megoldások kerülnek kialakításra, melyek megfelelő architekturális tervezése elmarad. Komplex, redundáns üzleti architektúra (termék, szolgáltatások, folyamatok) hasonló bonyolultságú inforkommunikációs architektúra megoldásokkal biztosíthatóak csak.
A komplex infokommunikációs architektúrák mind további fejlesztési, mind üzemeltetési szempontból jelentős kihívásokat hordoznak magukban. Fejlesztési területen komplex meglévő architektúrába kell – akár már tudatos tervezéssel is – beilleszteni az új megoldásokat, mely adottságainak meg kell felelni. Ebből adódóan az új fejlesztések lehetőségei nem csak kockázatosak (mi fog működni? milyen komponensben kell még fejleszteni?), hanem az adottságok miatt korlátozottak is. Üzemeltetési oldalról a komplex környezet nehezen átlátható, és így nehezen is kezelhető, mely nem csak erőforrás-‐felhasználás területén jelent kihívást, hanem magát az üzemeltetési kockázatokat is növeli. 2.3
Komplex architektúrák egyszerűsítése
A korábbiakban bemutatott kihívások miatt az infokommunikációs architektúrák üzemeltetési és fejlesztési költségei olyan jelentőssé válhatnak, hogy akadályozzák az üzleti célok teljesülését. Az architektúrák egyszerűsítésére vonatkozóan felső szintű szállítói ajánlásokkal találkozhatunk, ugyanakkor az egyes részterületeken történő tényleges megvalósításra viszonylag kevés tapasztalat áll rendelkezésre. Ennek legfőbb oka a részterületek egyedisége mellett az egyes szervezeti környezetek kiszámíthatatlansága. Mindezek miatt minden esetben szükséges az egyedi feltételrendszer feltárása, és ezen peremfeltételek alapján a lehetséges – a korábban ismertetett elveknek megfelelő – megoldások keresése és megvalósítása.
3
Az infokommunikációs architektúrák átalakítása során a kívánt egyszerűbb célállapot megvalósítása történthez viszonylag rövid időn belüli átalakítással (big-‐bang), illetve inkrementális fejlesztéssel is. A radikális átalakítás gyors eredményeket biztosít, ugyanakkor nagy kockázata miatt az átalakítás időszakában jelentősen megnehezíti az szervezet működését, vagy az időszakosan duplikált struktúrák fenntartása jelentős erőforrások lekötését igényli. Az inkrementális változatás lépésenként alacsony kockázattal jár, de hosszú időn keresztül fenntartja a komplex architektúrák (ezáltal az ehhez kapcsolódó kockázatok és költségek) állapotát. Egy pillanatnyi infokommunikációs architektúra állapotból a szervezeteknek megvan a lehetősége, hogy több stratégiát követve végezzenek el változtatásokat (1. ábra): IKT hatékonyság javítása az üzleti funkcionalitás megtartása mellett: az infokommunikációs architektúra konszolidálása, miközben az üzleti igények nem kapnak prioritást. A túlzott IKT fókusz ugyanakkor az üzleti szolgáltatások minőségének romlásához vezethet. Üzleti hatékonyság javítása, miközben az IKT architektúra állapota nem változik, vagy éppen romlik az üzleti igények kiemelt kezelése miatt. Kiegyensúlyozott fejlődés: az informatikai és üzleti architektúra együttes fejlesztése, rész architektúrák konszolidációja melletti fejlesztés.
ICT hatékonyság javítása
Cél ICT architektúra
jlő
dé s
ICT hatékonyság javítása, az üzleti komplexitás csökkentésével
Kie gy en
súl
Informatikai hatékonyság
•
fe
•
yo zo tt
•
Kiindulási ICT architektúra
Üzleti hatékonyság javítása
…
Üzleti hatékonyság javítása, az ICT komplexitás növelésével
…
Üzleti funkcionalitás
1. ábra: IKT architektúra fejlesztési lehetőségek (Anderson és Betz 2008 alapján) 3
KUTATÁSI TERÜLETEK ÁTTEKINTÉSE
A még fennálló válság évei alatt a szervezeteknek kevés lehetősége, és kevés erőforrása áll rendelkezésre ahhoz, hogy ezen komplex infokommunikációs architektúrákat
4
egyszerűsítsék, konszolidálják, illetve összehangolják a szervezeti stratégiai célokkal. Még nagyobb kihívást jelent, ha a architektúra konszolidációja fejlesztési feladatokkal (interfészek, protokollok) jár együtt, hiszen ennek nem csak erőforrás, hanem időbeli átfutási ideje is jelentős lehet. A továbbiakban két olyan kutatási esetet vizsgálunk meg, melyben az infokommunikációs architektúra konszolidációja szükségszerű, indokolt, ugyanakkor annak megvalósítása számtalan kérdést vet fel. Mindkét fejlesztési terület (információtechnológiai architektúra, és kommunikációs architektúra) jelentős komplexitással, és heterogenitással rendelkezik, és mindkét esetben inkrementális változtatásokkal történik az architektúra javítása (azaz részarchitektúrákon keresztül) Ezen esetekben azt vizsgáljuk, milyen megoldásokkal sikerült az architektúra komplexitást csökkenteni, avagy ezen úton elindulni. Üzleti architektúra igények IKT architektúrában való megjelenítése
Eset
IKT architektúra integráció
Architektúra környezet Komplex, heterogén architektúra
Komplex, heterogén architektúra
Kutatási téma
Üzleti architektúra igények IKT architektúrában való kontrollált megjelenítése
IKT architektúra integráció, integrációs protokoll fejlesztés
Kihívások
-‐ Nagy számú architektúra gateway -‐ Átfedések, le ne fedett területek -‐ Változtatási kontroll hiánya
-‐Nagy számú IKT eszköz -‐ Eltérő szállítók, eltérő kommunikációs protokollok -‐ Integrációs kihívások, silószerű működés, korlátozott interoperabilitás
Eredmények
Architektúra kapuk és strukturális elemek számának csökkentése Kontroll folyamatok kialakítása
IKT architektúra integrálási megoldások Cél integrációs protokollok kialakítása
3.1
Üzleti architektúra igények IKT architektúrában való megjelenítése
Kutatásunkban egy magyarországi pénzintézet komplex informatikai architektúrája indokolja a változtatást, melynek belépési pontját magát az architektúrát érintő architektúra kapuk (gateways) jelentik, mely önmagában is komplex belépési feltételt jelent (2. ábra: az architektúra változtatását biztosító architektúra komplexitása) A komplex informatikai architektúrával rendelkező vállalatokra jellemző, hogy magának a informatikai infrastruktúrát és architektúrát érintő változásokra is eszközt rendszert használnak, melyek egymástól függetlenül működnek, ugyanakkor feladatukat, és a kapcsolódó üzleti és informatikai architektúra elemeket tekintve átfedéseket tartalmaznak. További jellemző, hogy az organikus architektúra fejlődés következtében a meglévő eszközök sem biztosítanak teljes lefedést a változások által érintett architektúra elemek összességére. Ennek következtében a változtatások feletti kontroll esetleges változtatások együttes elemzése nem megvalósítható, a változtatások hatásbecslése hiányos vagy éppen lehetetlen. A vizsgált esetben a szervezet 6 olyan teljesen vagy részben formalizált megoldással rendelkezett hasonló feladatokra, mely a változtatásokat volt hivatott kezelni, összességében a változtatásokat közel 500 kategóriába lehetett sorolni. Az átfedések
5
mellett voltak olyan változtatások, melyeket egyik eszköz sem támogatta, illetve lehetőség volt a használt eszközök megkerülésére is.
Üzleti architektúra elem
Támogató architektúra kapu 1
Támogató architektúra elemcsoport 1
Üzleti architektúra elem
Támogató architektúra kapu 2
Támogató architektúra elemcsoport 2
Üzleti architektúra elem
Üzleti architektúra elem
Támogató architektúra kapu …
Támogató architektúra kapu (n)
Támogató architektúra elemcsoport …
Támogató architektúra elemcsoport (m)
2. ábra: Komplexitás az architektúra elemek változtatását biztosító architektúrában A kutatás során vizsgálatra kerültek az informatikai szolgáltatásmenedzsment (Cannon és Wheeldon, 2007) a kiegészítő területek megoldásai is (így az incidenskezelés, melyre 1 fő, és további kiegészítő eszközök álltak rendelkezésre), illetve az üzleti igénykezelés (melyre informális, és átalakítás alatt lévő eszközök által rendelkezésre, 3.ábra). Mivel mindegyik forrás eredményezheti az architektúra változtatását, ezért végső soron a változtatáskezelési eszköznek minden forrás kezelésére alkalmasnak kell lennie. A meglévő architektúra kapuk esetében strukturális és tartalmi elemzés került végrehajtásra, azaz vizsgálatra került milyen meglévő eszközök, milyen változtatási kategóriái kerülnek felhasználásra, illetve ezek tartalma mennyire felel meg a strukturális felosztásnak. A struktúra elemzés feltárta, hogy az egyes kategóriák 70-‐ 80%-‐a kihasználatlan (így vagy szükségtelen, vagy új struktúrában szükséges megjeleníteni).
6
CMDB 1+
~
Incidens
Probléma
6+
Változtatás menedzsment
Változáskérelem
✗ Üzleti igény
Üzleti igény
3. ábra: Architektúra változtatás a szolgáltatásmenedzsment folyamatok mentén Szintén feltárásra kerültek az egymással átfedést mutató területek. A tartalmi elemzés során szövegbányászati eszközökkel (Black, 2006; Yang el al, 2008; Ur-‐Rahman and Harding, 2012) került feltárásra az egyes változtatási esetekhez kapcsolódó tényleges tartalom, mely biztosította a kiegészítő kategóriák megjelenítését, illetve a meglévő kategóriák finomhangolását. A strukturális elemzés kevésbé, míg a tartalmi elemzés jobban feltárta, hogy az architektúra kapuk alkalmazásával a teljes szervezeti architektúra irányába szükséges kitágítani az elemzést, hiszen mind üzleti folyamat, mind szervezeti környezet elemek is megjelentek a tartalomban. Az architektúra egyszerűsítés céljával összhangban ez a szélesebb körű integrálás indokoltnak tekinthető (4. ábra).
4. ábra: A tartalmi elemzés (bal oldal) és a kialakított új kérési struktúra
Az integráció során alkalmazkodni kellett a létező informatikai architektúra elemeihez, ugyanakkor szélesebb körű integrációs modell sikerült kialakítani azáltal, hogy az incidenskezelésre szolgáló gateway és változtatások kérésére vonatkozó gateway is összevonásra került, és melyeket kezelhetővé válik az egyes bejelentések állapotkövetése (5. ábra).
7
5.. ábra: Integrált változtatási és incidenskezelési architektúra és kapcsolatai Végeredményben az eszközök száma 1 integrált platformra, valamint 1 ideiglenesen megtartott eszközre, míg a kategóriák száma 56+27 darabra csökkent, melyek teljes lefedést biztosítanak. Az elemzés egyediségét jelenti, hogy ebben az esetben nem csak architektúra fejlesztés (és annak módjának vizsgálata) történt meg, hanem egyben az ezt karban tartó folyamat és megvalósítási architektúra modell is kialakításra került. Logging • • • •
Planning
Categorization • Impact and Risk Analysis Priorization • Step by step Clarification planning Business • Recovery Approval planning • Technical Approval
Executing • Change Scheduling • Change Executing
Review
Closure
• Progress reporting • Goal investigation
6. ábra: Kérések változtatási munkafolyamata A kialakítandó integrációs platform egységes formában fogadja be és kezeli az architektúra változtatására irányuló kéréseket, mi több, a kapcsolódó (és szintén változtatást igénylő) incidenseket, problémákat is. A struktúra kialakítása kapcsán tapasztalat, hogy bár a részletes kérésstruktúrák bár teljes lefedést biztosíthatnak, felhasználásuk csak részleges, ezért javasolt a kevésbé részletes struktúrák alkalmazása, melyek darabszámában (<100), struktúrájában (<10) és mélységében (<3) is
8
korlátozottnak kell lennie az áttekinthetőség megtartása érdekében. Ugyancsak tapasztalat, miszerint a a kérésstruktúrához kapcsolódó folyamatok számát alacsonyan szükséges tartani (<10 db) 3.2
IKT architektúra integráció
Nagy szervezetek esetében nem csak az üzleti igényeket kiszolgáló informatikai, hanem a kommunikációt biztosító kommunikációs architektúra esetében is megfigyelhető a komplexitás. Kutatásunkban az IKT architektúra kommunikációs megoldásaira koncentrálunk, ugyanakkor az IT és kommunikációs architektúrák konvergenciája miatt ezek teljes elválasztása nem megoldható (Herrel, 2012; Kincannon, 2011; Shen et al, 2007). Az általunk vizsgált szervezet esetében több egymást kiegészítő, illetve kiváltó kommunikációs megoldással rendelkezik, és akár ugyanazon területen belül is megfigyelhető a szállítói sokszínűség, és a platformok interoperabilitási korlátai. A kutatásunk során vizsgált szervezet célja a kommunikációs architektúrájának olyan módon történő fejlesztése, mely során azonosításra kerülnek a tényleges felhasználáshoz kapcsolódó szállítófüggetlen fejlesztési lehetőségek és meghatározhatóak az integrációs követelmények, akár a szükséges integrációs protokollok.
Szerver oldali komponensek
Kliens oldali készülékek
Vállalati címtár
IP telefon
Csoportmunka szerver Kommunikációs szerver
Videokonferencia végpont Információtechnológiai, architektúra
Jelenlét szerver Fax szerver
Integrációs architektúra
Hangposta szerver Videokonferencia szerver
Kommunikációs, architektúra
Okostelefon Tablet Hordozható számítógép Személyi számítógép
Alkalmazás szerverek FAX
Hangrögzítő szerver
Egyéb eszközök
Levelezési szerver
7. ábra: Kommunikáció orientált architektúra elemei A kommunikációs architektúrák szerepe elsősorban a személyes kommunikáció biztosítására került hagyományosan kialakítva, így a vezetékes megoldások esetében az e-‐mail, e-‐messaging, VOIP technológiák, valamint a vezetékes és vezeték nélküli telefonos megoldások. Annak ellenére, hogy a kommunikációs architektúrák során történtek fejlesztések az egyes technológiák összekapcsolására, az információtechnológiai integráció korlátozott, ad-‐hoc megoldásokkal rendelkezik, melyek elsősorban alkalmazásvezért megoldások váltanak ki. A fejlesztés korlátja, hogy
9
nem állnak rendelkezésre szállítófüggetlen kutatási adatok (benchmark-‐ok) sem a felhasználói szokásokra, sem az alkalmazott technológiákra vonatkozóan. A kommunikációs architektúra fejlesztésére vonatkozóan 2 hónapra vonatkozóan, összesen több, mint 2 millió hívásrekord került elemzésre. Már a hívási adatok elemzése is rámutatott arra, hogy a heterogén struktúrák akadályt jelentenek a kontroll és kezelhetőség tekintetében, ugyanis az elvárt adatok egységes kezelése ellenére is eltérő adatstruktúrákkal, jelölésekkel találkozhattunk. Ez az elemzés területén adattisztítási, illetve migrációs feladatokat jelent, és így vizsgálni kellett, a különböző kommunikációs platformokra vonatkozó mérések és adatok hogyan hozhatóak egységesen értelmező formátumra. Mi több, az értelmezéshez hozzátartozott a felhasználók (nem feltétlenül név szerinti, de egymástól elválasztott) azonosítása is, azaz a vállalati címtárral (telefonkönyvvel) való összekapcsolás.
A hívási szokások elemzése, és a más kommunikációs eszközök elemzése rámutatott arra, hogy az egyes területek – akár technológiailag fejlett – megoldásai silószerűen működnek, köztük az átjárhatóság alacsony, valamint a mobil kommunikációs megoldások esetében alacsony támogatási szint, kihasználatlan kapacitások figyelhetőek meg. Ilyen jelenség, hogy egyetlen embert többször is kell keresni, míg elérhető, akár 2-‐4-‐ kommunikációs csatorna felhasználásával (asztali telefon, mobil, instant message, e-‐ mail), mely nem csak az időfüggő elérésnek korlátja, de az információszerzésnek is jelentős hátrányára válik. Ebben a tekintetben előnyös az állapotjelző megoldások integrálása az eszközökkel (automatikus, de akár manuális beállítással is). Az egyes platformok között alacsony átjárást, átjárhatóság tapasztalható: vonalas mellékről melléket, mobilról mobilt hívnak az emberek, ami rámutat arra, hogy a szokások nehezen változnak. Még a mobil és vonalas kommunikációs eszközzel rendelkezők között is csupán 3,4% a keresztplatformos kommunikáció aránya.
Hívás kezdeményezés platformja a mobiltelefonnal rendelkezők körében
Hívás célplatformja a mobiltelefonnal rendelkezők körében
100%
100%
90%
90%
80%
80%
70% 60% 50%
70%
Mellék 79%
60%
40%
30%
30%
10% 0%
Mellék ! Mellék 76.9%
50%
40% 20%
Mellék ! Mobil 2,2%
20%
Mobil 21%
10%
Mobil ! Mobil 19,6%
Mobil ! Mellék 1,2%
0%
8. ábra: Hívások platform szerinti átjárhatósága
10
A 9. ábra mutatja be, hogy a kommunikációs architektúra integrálása során mely főbb területek kerültek azonosításra, ahol a protokoll alapú integráció megvalósítása szükséges.
Címtár integráció (központi vs. lokális szinkronizált) • Levelező rendszer • Beépített telefonkönyv • Asztali telefon • Mobil • Instant Messaging • Videokonferencia • Soft clients (telefon, videókonferencia)
Hang integráció • Telefon alközpontok átjárhatósága • Vonalas – mobil átjárhatóság • Soft client átjárhatóság • Egyetlen hívószám integráció • Hívástovábbítás integráció (asztali -> mobil automatikus átadás)
Mobilitás integráció • Címtár • E-mail • Instant messaging • Videókonferencia (tablet, PC)
9. ábra: Kiemelt kommunikációs architektúra integrálási területek Az egyik legnagyobb kihívást a címtárak integrálása jelenti, hiszen az átjárhatóság érdekében nem csak az adatok szinkronizálása szükséges, hanem a folyamatos karbantartás érdekében az egyes eszközök és alkalmazások kereszthitelesítését is meg kell oldani. Ez utóbbi elvárás akár azonos technológiák, és azonos rendszerek esetében is kihívást jelenthet, ha eltérő környezetben kerülnek kialakításra (pl. Lotus Notes kereszthitelesítés). Hasonló problémákkal a hang integráció területén is találkozunk, ahol az eltérő technológiai megoldások annak ellenére már alközponti átjárhatósági szinten is korlátot jelentenek, hogy az alkalmazott technológiák nem különböznek egymástól (pl. VOIP-‐ VOIP). Az integráció kihívásai között említhető a különböző csatornák összekapcsolása (vonalas – mobil – soft-‐phone), illetve a helyzetfüggő szabályok leképezésének kérdésköre. Mivel egyetlen emberhez több elérési csatorna tartozhat, ezért többféle megoldás szerint kezelhető az, hogyan biztosítjuk az elérést: • •
Eszközök integrálatlanok: minden eszközön (csatornán) egymástól függetlenül kereshetőek a személyek, gyakorlatilag ez a kiindulási állapot. Együttcsörgés: Amennyiben egy személyt keresnek valamilyen eszközön (csatornán), úgy a hívás minden csatornára befut. Ebben az esetben a hívónak – ha tudatásban van a megoldásnak – nem kell minden csatornát külön próbálnia. Az integráció során meg kell oldani a hívások párhuzamosítását (együttcsörgés), majd válasz esetén a hívás megfelelő csatornára irányítását. Annak érdekében, hogy egyetlen személyt nem keressen többször ilyen megoldás esetén az alkalmazott technológiáról mit sem tudó hívó, célszerű egyetlen hívószám megoldás alkalmazása az együttcsörgéssel együtt. Ebben az esetben az egyetlen
11
•
•
hívószám egy intelligens telefonközpontot feltételez, ahol a személyi eszközökre vonatkozó információk alapján történik meg a hívás továbbítása. Szabály alapú hívástovábbítás: Hívás esetén az eszközök előre beállított szabály szerint kapcsolódnak, pl: először a vonalas melléken csörög a telefon, majd 5 csengetés után átvált a mobiltelefonra, majd további 5 csengetés után a hangpostafiókra. Ebben az esetben is indokolt az egyetlen hívószámot támogató architektúra kiépítése az ismétlődő hívások elkerülése érdekében. Helyfüggő, intelligens hívástovábbítás: Szinten egyetlen hívószám szolgáltatás esetében működik tökéletesen, ha akár manuális beállítási (jelenlét információ), akár geolokációs megoldás alkalmazásával automatikusan kerül detektálása a fogadó fél helyzeti információja. Így például egy számítógépén, de nem a saját helyén dolgozó ember esetében a hívásokat a számítógépre telepített soft-‐phone alkalmazáson keresztül kapja, míg ha elhagyta a vállalatot, akkor a mobiljára kapcsolódik majd a hívás. Amennyiben munkaidőn kívül keresnek valakit, úgy automatikusan mobil platformra terelődik a beszélgetés, illetve beállítható lehet a hívók szűrése (csak meghatározott emberek esetében csörög a telefon).
A harmadik jelentős kihívást magában hordozó terület a mobilitás kérdésköre. Miközben minden kommunikációs csatorna mobilizálását meg lehet jeleníteni igényként, ennek megvalósítása részeiben szükségesek további fejlesztések: címtár integráció (magán és szervezeti címtér különválasztás), mobil e-‐mail kezelés, automatikus agy manuális jelenlét információ kezelése, üzenetküldés (instant messaging), illetve soft-‐videokonferencia kliensek felhasználása. A felsorolásból is látható, hogy nem csak alkalmazások területén, hanem az egyes protokollok egymáshoz kapcsolásában is megjelenik a fejlesztési igény (pl. videókonferencia összekapcsolása a mobil hálózatok, számítógépes kliensek, és videokonferencia berendezések között). Szintén kiemelt kérdésnek tekinthető a mobilitás megvalósítása során (mobiltelefonok, táblagépek és laptopok esetében) a biztonság, illetve a személyes és szervezeti adatok elválasztásának kérdése. Mobil eszközök esetében az eszköz elhagyhatja a vizsgált szervezet területét, ahol az eszköz védelmét központi megoldások biztosítják. Az eszköz elvesztésével megnő az azon tárol adatok illetéktelen hozzáférésének és felhasználásának veszélye. Szintén kockázat a felhasználói gondatlanságból adódó veszélyek megjelenése (pl. vírus, kémprogram), mely belépési pontot jelenthet a szervezet többi eszköze irányába is a nem jószándékű támadók részére. Mindezen kihívások miatt szükséges – az azóta gyártói megoldások között is teret kapó megoldás – mely elválasztja a magán és szervezeti adatokat, a szervezeti adatok tekintetében szigorúbb előírásokat alkalmaz (titkosítás, azonosítás), illetve lehetőséget biztosít az eszközök szervezeti, központi vezérlésére (adott esetben adattörlésre, vagy az eszköz leállítására). Mindezen megoldások a komplex kommunikációs architektúra tekintetében biztosítják, hogy az egyes kommunikációs csatornák silószerű működése megszűnjön, a technológiai heterogenitás ellenére is. A jövő útja ugyanakkor az architektúra ezzel párhuzamos egyszerűsítését is jelenti, az elemzésben megfogalmazott alapelvek figyelembevételével. Amennyiben az egyes részterületek esetében minden esetben a legjobb megoldást választjuk, jelentős integrációs feladatokkal, illetve a frissítésekkel ezek további fejlesztésével kapcsolatos teendőkkel kell számolni, addig az egységes szállítói architektúra – ha lenne is ilyen – nem tudja biztosítani azt a funkcionalitást, mely az igényeknek megfelelő megoldásokat biztosítja. Emiatt a javasolt megoldások a két véglet
12
között húzódnak, figyelembe véve a technológiai heterogenitás korlátozását, ás a standard és egyedi protokollok alkalmazhatóságát. 4
KUTATÁSI TAPASZTALATOK ÖSSZEFOGLALÁSA
A bemutatott esetek jól illusztrálják, milyen kihívásokat jelentenek a komplex infokommunikációs architektúrák, ugyanakkor a két példán keresztül is látható, hogy a komplex architektúrák kezelésére csak nehezen vállalkoznak a szervezetek. A szervezeti architektúrába való bármilyen beavatkozás esetében a szervezeteknek egyedi kihívásokkal kell szembenézniük, melyek kezelésére egyedi megoldásokat alkalmaznak. A tanulmányban bemutatott két eset mellett továbbiakat is figyelembe véve a következő főbb szempontok szükségesek ahhoz, hogy a változtatások sikeresek legyenek: •
•
•
5
Tudatosan átgondolt stratégia: Az architektúra változtatásai a szervezetek életére jelentős kihatással vannak, és jelentős erőforrásokat kötnek le. Emiatt érdemes elkerülni az ad-‐hoc megoldásokat, és változtatásokat részletes elemzésekkel, igényfelméréssel, a felhasználói szokások elemzésével kell támogatni. Kiegyensúlyozott haladás: A radikális változtatások és a lassú lépések közötti egyensúlyt megtalálva tudatosan kell megszabni a jövőbeli kíván architektúra állapotába vezető utat (roadmap). A változásokhoz szükséges idő és erőforrások biztosítása: A jó elemzés, és a megvalósítás tudatos tervezése is elbukhat a megvalósításhoz szükséges erőforrások és idő hiányában. A megvalósítás vezetői elkötelezettséget – és ezáltal dedikált erőforrásokat igényel. HIVATKOZÁSOK
Anderson, M., Betz, M. (2008) Business-‐based IT architecture: The business leader’s role in enabling public-‐sector change, in: Transforming Government, March 2008, pp. 33-‐42. Black, W. (2006) Text Mining, in: Encyclopedia of Language & Linguistics (Second Edition), pp. 621-‐624 Cannon, D., & Wheeldon, D. (2007). Service Operation (United Kingdom.). TSO (The Stationery Office) Fehér, P., Szabó, Z.(2011) Designing Measurement Model Using Architecture Modeling Frameworks, in: Proceedings of IEEE International Conference on Software, Knowledge Information, Industrial Management and Applications (SKIMA 2011, edited by Savino, M. M., Chackpitak, N-‐), September 8-‐11 2011, Benevento, Italy, IEEE Catalog Number: CFP1182R-‐PRT, ISBN: 978-‐1-‐4673-‐0247-‐0 Herrell, E. (2010) Enterprise Communications: The Next Decade, Forrester Kang, D., Lee, J., Kim, K. (2010): Alignment of Business Enterprise Architectures using fact-‐based ontologies, Expert Systems with Applications, Vol. 37, No 4, pp. 3274-‐3283. Kincannon, T. (2011) Unified Communications Conference Reveals Coming IT Transformations, http://bestinuc.com/unified-‐communications-‐conference-‐reveals-‐coming-‐it-‐transformation, (2011. April 19.) LeBlanc, Andrew (2008) Map Your IT Architecture to Your Business Processes, in: SAP Insider, 2008 Apr/May/Jun Issue Shen,G. -‐ Tucker, R.S. – Chae C-‐J. (2007) Fixed Mobile Convergence Architectures for Broad-‐band Access: Integration of EPON and WiMAX [Topics in Optical Communications], in: Communications Magazine, IEEE, Volume: 45 Issue:8, pp. 44 – 50. ISSN: 0163-‐6804, DOI: 10.1109/MCOM.2007.4290313 Ur-‐Rahman, N., Harding, J.A. (2012) Textual data mining for industrial knowledge management and text classification: A business oriented approach, in: Expert Systems with Applications, Volume 39, Issue 5, April 2012, Pages 4729-‐4739 Weill, P., Ross, J.W. (2009) IT Savvy: What Top Executives Must Know to Go from Pain to GainHarvard Business Press, 2009, Boston, MA Yang, Y.Y., Aker, L., Klose, T. Yang, C.B. (2008) Text mining and visualization tools – Impressions of emerging capabilities, in: World Patent Information, Volume 30, Issue 4, December 2008, Pages 280-‐293
13
