Ugye te sem a római kort követő Nagy Népvándorlásra gondolsz, amikor azt hallod: migráció?

Sok embertől kikértem a véleményét, hogy mondjon véleményt az oldalról, hogy javíthassam a színvonalát. A pozitív visszajelzések mellett mindig megkaptam a kérdést:

Te, mi az az adatmigráció?

Nos, akkor oldjuk a feszültségeket, és fogalmazzuk meg pontosan, hogy mi az adatmigráció, és mikor használjuk. Egyáltalán, mi a migráció informatikai szempontból nézve.

Mit mond a wikipedia:

A migráció tárgyak, organizmusok vagy emberek csoportjának irányított, szabályos vagy szisztematikus mozgása.

Információtechnológiai szempontból a migráció szót három csoportba oszthatjuk:

• Adatmigráció – data migration
• Rendszermigráció – system migration
• Folyamatmigráció – process migration

Adatmigráció

Az általános megfogalmazás szerint az adatmigráció adatok automatizált mozgatásának folyamata tárolóeszközökön, formátumokon vagy számítógépes rendszereken.

Azonban ez csak egy egymondatos definíció, nemcsak adatok egyszerű mozgatásáról van szó, különben könnyen ebbe a hibába eshetsz. Az adatmigráció egyszeri folyamat, amely bár hosszú időintervallumon át történhet, de befejezettnek tekinthető, ha a folyamat véget ért. Ellentétben sok más adatintegrációs feladattal, amelyek törthénhetnek folyamatosan is.

Az adatmigráció magában foglalja az adatok újrastruktúrálását valamilyen módon. Ez jelentheti mezők összevonását, formátumok változását, vagy más úton történo transzformálását. Jegyezd meg, ha az adatok újrastruktúrálása nem történik meg, akkor nem migrációról van szó, hanem adatmozgatásról vagy relokációról. Ez utóbbi is lehet bonyolult feladat, gondolj csak tízmillió banki ügyfél adatainak átmozgatására, amikor egy új rendszert állítanak be, mert a régi már megtelt.

Az adatmigráció mindig tartalmazza az adatok használatának karbantartását. A használat szónál gondolj adatkezelési vagy analitikai szempontokra. Soha nem történik olyan eset, amikor az adatokat kivesszük a környezetéből és átrakjuk egy másikba, amelyen a az üzleti folyamatok különbözőek.

Az adatmigráció nem egy hagyományos ETL feladat

Az ETL (Extraction, Transform, Load) betűszó rövidítése az adatok kinyerését, áttranszformálását és újra betöltését jelenti. Ebben a folyamatban az adatok használata megváltozik, operációs környezetből átkerül analitikai környezetbe.

Tipikusan tehát az adatmigráció mindig egy nagyobb projekt része, amely lehet

• Alkalmazásintegráció – több heterogén alkalmazás helyett egy nagy alkalmazást vezetnek be, amelyek költséghatékonyabban lefedik az üzleti folyamatokat
• Alkalmazás upgrade – egy meglevő alkalmazás új verziójának bevezetése
• Vállalatok fúziója vagy különválása, stb.

Rendszermigráció

A rendszermigráció folyamán programok összességét mozgatjuk egy platformról a másikra. A platform szón itt nemcsak operációs rendszert értünk, hanem valamilyen hardverarchitektúrát vagy szoftver keretrendszert, amely megengedi, hogy különbözo szoftverek fussanak rajta.

Azonban itt még kiegészítem a wikipédia definícióját azzal, hogy a rendszer nemcsak hardver és szoftvereszközöket tartalmaz, hanem adatbázist ezzel együtt adatokat is. Vagyis a rendszermigrációba beletartozik az adatmigráció is.

Folyamatmigráció

Ez a legszebb az egészben. A kérdés itt az, hogy hogyan tudod felmérni egy vállalat üzleti folyamatait, esetleg hogyan lehet optimalizálni őket – bár ez utóbbi a BRP (Business Process Reengineering) feladata. Ha egy új rendszert vezetnek be, például egy komplex vállalatirányítási rendszert (ERP), akkor akaratlanul is megváltoznak az üzleti folyamatok. Szerencsés esetben a vállalat határozza meg az üzleti folyamatait és a vásárolt alkalmazás ehhez idomul.

Azonban már láthattál olyat, hogy a vállalat folyamatainak kell alkalmazkodnia a vállalatirányítási rendszer által megszabott folyamatokhoz.

Ez akkora és izgalmas téma, hogy máskor is külön fogok foglalkozni vele.

Bookmark It

Hide Sites

Ez a bejegyzés az “Adatminőség-pokol 9 köre” sorozat 3. része. Korábbi bejegyzések: itt és itt.

Cégtulajdonosok, adatkezelők figyelem!

Megérne egy kérdést, hogy mit tart a vállalkozásában vagy a saját területén a legnagyobb értéknek. Talán az emberi erőforrásokat? Gépeket, eszközöket? Kapcsolatokat? Esetleg az információt, amelyet adat formájában az adatbázisban tárol?

Ha az utóbbi, akkor érdemes elgondolkodni, hogy mit tesz meg azért, hogy ez a legnagyobb érték az is maradjon. Az első gondolat természetesen az, hogy rendszeresen biztonságba helyezi az adatokat (biztonsági mentések formájában), de ezzel most itt nem foglalkozunk. A következő lépés az, hogy ne szemétkupacban kelljen turkálnia, ha valamilyen információt elő szeretne bányászni az adatbázisaiból. Ha úgy gondolja, hogy ez is fontos, akkor nyomjon meg gombot a következő szavazásban:

Ha az első gombot nyomta meg, akkor mindenképpen olvasson tovább! Hacsak nem Ön agya az IBM Blue Gene szuperszámítógép klónozott változata. Ha más gombot nyomott meg, akkor is olvasson tovább, mivel megoldásokat találhat a HOGYAN-ról.

Ha idáig eljutott az olvasásban, akkor csak az tudom mondani, hogy “Gratulálok! Ön kezdi megérteni, hogy az adatminőség biztosítása fontos helyen szerepel az üzlet továbbfejlődésében. ”

Rendben, mit fog akkor csinálni, hogyan fogja megoldani a problémát?

Thomas Redman a Data Driven: Profiting from Your Most Important Business Asset (Adatvezérlés: profitálás a legfontosabb üzleti vagyonból) című könyvében egy analógiát használ, amit úgy hív, hogy adatminőség-tó.

“A tó reprezentálja az adatbázist és a víz a benne levő adatokat. Az áramlás, amely új vizeket hoz a tóba, olyan üzleti folyamatok, amelyek új adatot hoznak az adatbázisba. A víz szennyezett, mint ahogy az adatok is tartalmaznak szemetet. Hasonlóan a hiányosságok az üzleti folyamatban hibákat generálnak az adatbázisban.

Az egyik út a víz minőségének javítására a víz tisztítása. Vagyis szurok beépítése, a víz átfolyatása speciálisan tervezett tartályokon, kémiai anyagok használata a baktériumok megölésére és a PH-érték beállítására.

Az alternatíva a vízszennyeződés csökkentésére a gyárak szennyeződéskibocsátásának redukálása.

A kontraszt a két megközelítésben igen erős. Az első esetben maga a tó van a fókuszban, a második esetben a tóba ömlő áramlás. Hasonló a képlet az adatok esetében. A hibák megtalálása és kijavítása az adatbázisban olyan adatokon, amelyek már léteznek. A hibák megelőzése az üzleti folyamatokra és a jövőben keletkező adatokra koncentrál.”

Reaktív adatminőség

Abban az esetben, amikor a feladat a hibák megtalálása és korrigálása az operatív adattárban (operative data store – ODS) és a adattárházban (enterprise data warehouse – EDW) vagy más vállalati adattárban, akkor a vállalat reagál a felmerült problémára.  Más szóval a hibák javítása azután történik, miután az adatbázisba kerültek már az adatok.

Proaktív adatminőség

Ha a vállalat a megelőzésre fordít figyelmet, vagyis a hibák kijavítása már az adatforrásból jövő adatok adatbázisba kerülés előtt megtörténik, akkor a vállalat proaktívan áll a kérdéshez. Thomas Redman felállít egy tizes szabályt a proaktív adatminoség leírásakor, mely szerint:

“Tízszer többe kerül az a munkaegység, amely a hibás input adatok (pl. késői, hiányos, inkorrekt) kijavítására irányul, mint az a munka, ha input adatok tökéletesen kerülnek az adatbázisba“‘.

Nyilvánvalóan lehetetlen a hibák tökéletes megelőzése, azonban minél nagyobb a bejövő adatok kontrollja, annál nagyobb az adatok minősége a vállalatok információs rendszerben.

Hiperaktív adatminőség

Mivel a legtöbb komplex probléma nem oldható meg gyorsan és könnyen, a legjobb megoldás a kétfajta adatminőség-biztosítás kombinálása. Jim Harris ezt hiperaktív adatminőségnek hívja. A lényege, hogy az adatminőség biztosítása egy vállalat mindennapi feladata kell hogy legyen.

Bookmark It

Hide Sites

Az adatminőség-pokol 9 köre – a közönyösek köre

Kinek a feladata az adatminőség biztosítása?

Kik a legfobb közönyösek, akik megérdemlik az elso kört? Maguk a vállalatok, ahol esetleg már realizálódott, hogy órákat vesztegetnek el naponta azzal, hogy a megfelelo adatokat elobányásszák az adatbázisból, holott elvileg néhány másodpercen belül rendelkezésre kell állnia. Itt nem arra gondolok, hogy lassú az alkalmazás, vagy a hálózati kapcsolat a felhasználó számítógépe és az adatbázis között, hanem hogy rossz adatok jelennek meg. A rossz adatot nem lehet az ajánlatra vagy számlára írni, hanem előtte ki kell javítani, vagy esetleg más módon előállítani a kívánt dokumentumot.

De vajon költenek-e a vállalatok a mai gazdasági klímában egy új projektre, ahol amelynek az a feladata, hogy az adatminőséget biztosítsák, és az a célja, hogy rengeteg időt és pénzt spóroljanak meg azzal, hogy a helyes adatok rögtön rendelkezésre állnak. Azok költenek arra, amely cégeknek a gyenge adatminőség miatt elvesztegetett idő már fáj. És jobban fáj, mint az adatminőség biztosítására, adattisztításra fordított összeg.

Hogy milyen módozatok vannak arra, hogy egy vállalatnál elérjük a kívánt minőséget, arról egy későbbi bejegyzésben írok.

De, például a Drótkerítésgyártó Vállalat úgy döntött, hogy befektet, és optimalizálja a költségeit adatminőség szempontból is. De ki fogja elvégezni a munkát? Az IT részleg, vagy az üzleti részleg?

Az adatminőség biztosítása az IT feladata

Az első gondolat az, hogy az informatikai részleg, mert az információ az adatbázisban van tárolva, és az alkalmazások amelyek menedzselik az adatok elérését/módosítását. Ezért, ha probléma van az adatokkal, akkor az informatikusoknak kell megoldani a helyzetet.

Aki így gondolja, az töltse le az adatmigrációról szóló tanulmányomat, amely az adatminőség témának a testvérterülete.

Nyilván egy informatikus nem fogja tudni eldönteni, hogy az ügyfél Kovács József azért van kétszer az adatbázisban, mert véletlenül kétszer vették fel az adatait, vagy azért, mert két Kovács József nevű ügyfél van. Ha az informatikus dönti el, hogy mit lehet változtatni az adatbázisban, akkor könnyen lehet, hogy nagyobb károk keletkeznek, mintha hagyták volna az adatokat békén. Mert második Kovács József a vállalat legfőbb kliense, drótkerítés-nagykereskedő, és éppen őt törölték ki az adatbázisból…

Az adatminőség biztosítása az üzleti folyamatokhoz értők feladata

Vagyis az adatminőség biztosítása az üzleti részleg feladata, mert az adatok az üzleti folyamatok során képződnek, és a felhasználók azok, akik menedzselik a feladatokat, és ha problémák vannak az adatokkal, akkor az ő felelősségük az elrontott adatok tisztítása és helyretétele.

A megoldás tehát, hogy A Drótkerítésgyártó Vállalat vezetése kijelöl egy titkárnot és egy értékesítésen dolgozó szakembert, együtt összeülnek és 2 hét alatt kiszedik az összes szemetet az adatbázisból. Ebben az esetben lehetséges, hogy az értékesíto kivonása miatt akkora bevételtől esett el a Drótkerítésgyártó Vállalat, hogy jobb lett volna inkább az adatokat békén hagyni. Mert elvesztették a német Joseph Schmidt drótkerítés-nagykereskedőt, aki 30%-kal több megrendelést biztosított volna a vállalatnak.

Vagyis?

Az adatminőség biztosítása mindenki feladata

A sikertelen adatminőség-projektekre az a jellemző, hogy az üzleti részleg függetlenül definiálja a követelményeket és az IT részleg függetlenül írja meg a specifikációt. Ezután hipp-hopp elvégzi a “kódolás, tesztelés, leadás és a “kész van!” győzelmi felkiáltás lépéseit, ezáltal az üzleti részleget meghagyva a “megoldás” frusztrációjában.

A sikeres adatminőség-projektet az jellemzi, hogy egy központilag menedzsment megbízott összeforrasztja az IT és üzleti részleget egy iteratív sikeres projektté. Ebben az üzleti részleg birtokolja az adatokat, és érti, hogy milyen jelentősége van a mindennapi üzleti folyamatokban, az IT részleg pedig definiálja a szükséges adatminőségi normákat és folyamatokat.

Bookmark It

Hide Sites

Ki itt belépsz, hagyj fel minden reménnyel

Ez a felirat fogadta Dante Poklának bejáratát. A vétkek súlya szerint helyezkednek el a Pokol egyre mélyebb köreiben a bűnösök aszerint, hogy milyen mértékben sértették meg isteni és a természeti törvényeket.

Ne félj, nem fogunk egyből a pokolba leszállni, ma még csak a Földön fogjuk elkövetni a bűnöket az adatminőség földi világában, hogy aztán megbűnhődjünk a pokol egyre mélyebb bugyraiban.

Az ok, hogy a pokolban kötünk ki: csak az Egyesült Államokban évente több, mint 600 millárd dollárba kerül a gyenge adatminoség.

Vegyünk csak egy példát. Aki feliratkozik a migration.hu oldalon, hogy letöltse a tanulmányt, az beírhat egy családi nevet és keresztnevet. Mondjuk beírja így, mert siet:

Családi név: Kiss

Keresztnév: Gáza

A levelezőrendszer ilyen kezdetű levelet fog küldeni első alkalommal, ha nem javítom ki kézzel:

Kedves Gáza!

…

Gáz, nem? Hibás a felhasználó, mert o írta be így a nevét, hibás vagyok én is, mert nem nézek meg minden egyes nevet, aki megadja az email címet. Mondjuk nekem még nincs százezres nagyságrendű adatbázisom az érdeklődőkbol, de mit csináljak akkor, ha naponta jön 2000 látogató az oldalra, és ebből 400 megadja a nevét és email címét?

Manapság egyre inkább internacionalizálódunk. Ennek többek között olyan hátránya is van, hogy a vállalatok többnyelvű szoftvert használnak – mert esetleg nem minden Gizike tud angolul – és vannak szavak, esetleg földrajzi nevek, amelyek máshogy tárolódnak az adatbázisban. Például a holland Hága városa 52-féleképpen írható le: Den Haag, Den Haague, stb. El tudod képzelni, hogy mi történik akkor, ha például a vállalat piackutatást szeretne folytatni ebben a városban, és címeket gyűjt az adatbázisból?

Így láthatod, hogy milyen könnyen keletkeznek a bűnök, amelyeket az adatminőség poklába vezetnek. A következő bejegyzésekben végigmegyünk a pokol mind a kilenc körén.

Bookmark It

Hide Sites

Az elozo bejegyzés a számai alapján láthattad, hogy az integrációs és adatmigrációs projektek nagyon nagy százaléka nem sikeres. Felmerül a kérdés, hogy mi ennek az oka?

Ha elviszed a 15 éves autódat a szerelohöz rutinellenorzésre, elso pillantásra a tapasztalt autószerelo azt fogja mondani, hogy két nap múlva készen lesz, és kapásból felsorolja, hogy mit fog átnézni és cserélni. Ha a harmadik napon felhívod a szerelot, vajon mit fog mondani?

“Kedves Uram, ennek az autónak sokkal több baja van, mint amit elozoleg sejteni lehetett. Ez az autó egyáltalán nem volt karbantartva, a szervízkönyvben is látszik, hogy néhány kötelezo szervíz hiányzik. Ezen kívül van néhány olyan hibája, amelyhez nincs megfelelo muszerem, és el kell vinnem a Hiper Diagnosztikai Garázsba, hogy a pontos okot megállapítsuk és kijavítsuk.”

Ha nem látod egybol az analógiát, akkor segítek

1. A tapasztalt autószerelonk rosszul becsülte fel a munka nagyságát az elején, és hiányosan határolta körül a feladatokat számodra.
2. Az autószerelo muhelynek nem volt mindenhez megfelelo eszköze
3. Bizony, te is hibás voltál, mert nem tartottad eléggé karban az autót.

Az adatmigrációs projektekben szinte elenyészo annak az oka, hogy a migrációt végrehajtó csapat tapasztalatlan, ill. elso projektes. Legkritikusabb probléma a feladat körülhatárolása ill. becslése az adatmigrációs projekt elején. A megfelelo szoftverek használata és azok megértése is fo hiányosság. Emellett a forrásadatok minosége a legtöbb esetben kivánnivalót hagy maga után, és ez még bonyolultabbá teheti a migrációt.

Ezen kívül van nehány kisebb súlyú, javításra szoruló körülmény, amelyek felsorolását meghagyom neked. A kisebb súly nem azt jelenti, hogy ezek hiánya miatt a projekt még sikeres lehet, hanem azt, hogy kevesebb százalékban fordult elo, mint sikertelenségi tényezo. Tehát ezek is fontosak, és meg kell oket is említeni ebben a blogban. Megoldás közzététele 1 hét múlva (vagyis nem a következo bejegyzésnél).

Bookmark It

Hide Sites

Miért lövöm tele a magyar internetet, videomegosztókat azzal a ténnyel, hogy az adatmigráció egy olyan terület, amelyet az ipari elemzok konzekvensen figyelmen kívül hagynak? Nézzük a száraz számokat: A projektek adatmigrációs része csak 16%-a sikeres, vagyis amelyeket idoben és költségkereten belül szállitanak.

Álljunk meg egy pillanatra, mennyi is ez a szám. Képzeld el, hogy a fonököd 10 hónapon belül 10 feladatot oszt ki neked. A 10 hónap alatt egyszer, maximum kétszer végzed el a feladatot úgy, hogy nem csúszol ki az idobol, és nem használsz el a tervezetnél több pénzt. Te ezek után biztosítva érzed, hogy megmarad a munkahelyed? OK, gondolhatod, miért olyan izgalmas ez, a legtöbb informatikus nem is találkozik közvetlenül ilyen feladattal. Sajnos nem tudlak megnyugtatni, három okból:

1. Az én piackutatásom szerint az informatikai projektek legalább 50%-ában szükséges adatmigráció.
2. Az adatmigráció mindig egy nagyobb projekt része, és a fenti szám szerint pedig szuk keresztmetszet. Tehát, ha a migráció részfeladat nem sikeres, akkor magával rántja a projektet.
3. 2007-es adat szerint abban az évben az adatmigrációs projektek világszinten átütötték az 5 milliárd dolláros küszöböt. A piac pedig növekedik, elorejelzések szerint 2012-ig meghaladják a 8 milliárd dolláros részesedést.Ez évi átlag 10-12%-os növekedés.

A célom ebben a blogban az, hogy téged, a számítástechnika és informatika iránt érdeklodonek megmutassam, hogy a fenti borzaszó számot hogyan lehet csökkenteni úgy, hogy a legjobb megoldásokat (best practices)  Te is alkalmazod az ügyfeleidnél és projektjeidben. Ezenkívül milyen elonyt tudsz még kovácsolni ebbol? Végeredményben a legfontosabb, hogy a cégednek elégedett ügyfeleid legyenek, és a sikeres projekt egyik elofeltétele annak, hogy az ügyfeled elégedett lesz és hosszú távú kapcsolatot tudsz kiépíteni vele.

Ez  a bejegyzés a Bloor Research 2007-es kutatása alapján készült.
Szerzoje Philip Howard, a Bloor kutatási igazgatója.

Bookmark It

Hide Sites

Kendőzetlen reklám a migration.hu oldalnak.
Ha tetszik a video, akkor küldd tovább, ez a linkje:

http://www.youtube.com/watch?v=BjssWtwG8aY

Bookmark It

Hide Sites

Az elozo bejegyzés végén feltett kérdést fogom feloldani most: egy adatmigrációs projekt hány százaléka technikai ill. menedzsment kérdés. Hogy pontosítsam, van egy nagy szelet közös metszet, vagyis technikai kérdésbe burkolt menedzsment feladat (például kérdések tisztázása, adatok beszerzése), ezeket most nem a technikai feladatok közé sorolom.

Szóval kedves barátom (a többesszámot szerencsére kihagytam, mert annak negatív zöngéje van), én megfordítom az arányt, amelyet a két hozzászóló tippelt: az a tapasztalatom, hogy kb. 70% menedzsment feladat és 30% technikai feladat.

Ott szokott bukta lenni a projektben, ha adatmigrációs projektmenedzseri feladatokat technikai hozzáállással próbálod megoldani.

Bookmark It

Hide Sites

Meg kell elégedned egy ideig azzal a ténnyel, hogy a blog külön indult a honlaptól (migration.hu), de így gyorsabb volt elindítani. Több célja van ennek a blognak, hogy miért kapkodtam vele ennyire:
1. a Te oldaladról: információt fogsz itt is kapni tolem, mint a hírlevélben, de itt egy kicsit másként.
2. nyilvánvalóan szeretném látni az aktivitásodat, ezért ha mondanivalód van, oszd meg azonnal, nehogy benned maradjon.

Egyébként: üdvözlet Párizsból!

Két hetet vagyok itt a francia SFR mobilszolgáltató IN rendszerének migrációján. A projekt majdnem két éve tart, és most az UAT (user acceptence test) elott vagyunk ( az UAT magyar megfelelojét nem tudod véletlenül?).
A migráció alapját egy több, mint 450 oldalas folyamatleírás képezi, amelyet lépésrol lépésre le kell tesztelni. Most az ügyfél visszautasította az utolsó lépések egyikét. Technikailag ez azt jelenti, hogy 1 db paramétert át kell állítani, hogy a migrációs folyamatba betegyünk egy lépést. Mit okoz ez az 1 lépés?
1. Plusz éjszakát a migráció folyamán (ez a negyedik)
2. Az UAT eltolását 2 héttel, mivel emiatt az egy lépés miatt újra kell tesztelni a központban az egész folyamatot, ami min. 1 hét (az állások és az alkudozások miatt 2 hét lesz a késés)
3. 1 héttel korábban hazamegyek – de utána meg vissza kell jönni.

Miért jó az ügyfélnek?
1. Ezzel az egy plusz lépéssel az adathalmaz kb. 5%-án meg tudja nézni, hogy helyesen muködik-e minden, vagyis biztosítva van a migráció többi része, és kevesebb valószínuséggel lesz hiba.
2. Ha mégis hiba van, a fall-back nem 6-8 óráig tart, hanem 1-2 óráig, mert a napközbeni csúcsidoben nem mindegy, hogy a kiszolgáló gépek eroforrásai milyen akciókra mennek el.
3. hamarabb le lehet zárni a clusteren a két node között feloldott lemeztükrözést, így kisebb a valószínusége, hogy ha elromlik a lemez, ahol az éles adatok vannak, akkor elveszik 1 nap adatai.

A költségeket most nem említem, de végig lehet gondolni, hogy repülojegy, szálloda, szakértoi óradíj, várakozás miatti termelékenységkiesés miatt hány millió lehet. És nyilván inkább megéri az ügyfélnek, mint a kockázat vállalása.

Amint láthatod, az adatmigrációnak a technikai részét alig említettem, mert már nem releváns ebben a fázisban.

A kérdésem, hogy véleményed szerint egy migrációs projektben hány százalék a technikai kérdés (migrációs tool fejlesztés, adatokkal való bíbelodés, stb).
(a másik pedig ha van egy jó magyar kifejezés az UAT-re a tarsolyodban, akkor oszd meg velem)

Bookmark It

Hide Sites