1. April 25, 2013 www.ExigenServices.com
DATU MIGRĀCIJA PRAKSĒ:
PIEEJAS UN PROBLĒMAS
Valdis Prodnieks,
valdis.prodnieks@exigenservices.com

2. KĀPĒC JĀMIGRĒ? GALVENIE IEMESLI
Šajā lekcijā runājam tikai par biznesa IT sistēmām
Biznesa motivētas pārmaiņas:
 Uzņēmuma daļu standartizācija / uzņēmumu pārpirkšana
 Standartproduktu ieviešana / atteikšanās no standartproduktiem
 Biznesa procesu izmaiņas
Tehniski motivētas pārmaiņas:
 Izmaiņas piegādātāja dēļ
– Vecās versijas vairs netiek uzturētas vai kļūst nepieņemama cenu politika
– piegādātājs var bankrotēt vai tikt nopirkts
 Tehniskās infrastruktūras optimizācija

3. 3 www.ExigenServices.com
REASONS FOR MODERNIZATION
Motivating factors:
 Reductions in IT budget
 Requirements to reduce licensing costs
 Requirements to reduce the high maintenance costs of legacy systems
 Changes in regulatory environments
 Discontinuation of vendor support
 Shrinking IT labor pool
 Mergers and acquisitions
 Requirements for quick time-to-market when implementing new features
 Improve productivity
 Launch of new products and services
 IT infrastructure expansion
 Growth in workloads, data volumes, and document processing
requirements

4. 4 www.ExigenServices.com
MODERNIZATION PROCESS
ASSESS TRANSFORM MANAGE
Assessment of the Existing IT
Infrastructure
Analysis of the Total Cost of
Ownership and ROI
Risk analysis
Transformation Planning
Infrastructure and
Application Design
Migration Services
System monitoring,
management, and
support, including
performance tuning and
security audits

5. DATU MIGRĀCIJA IR TIKAI DAĻA ...
Citas migrējamās daļas var būt, piemēram:
 Biznesa aplikācijas un pieejas
 Biznesa procesi
 Operētājsistēma
 Programmēšanas valodas
 Datu bāzes vadības sistēmas (ne visas bija / ir / būs relāciju DB)
 Arhitektūras modelis (piem. Servisorientēta arhitektūra)
 Aparatūra (sava, īrēta vai mākonī)
 Dažādu veidu «middleware», piemēram,
– Biznesa procesu vadības sistēmas (BPMS)
– Back office automatizācija (job scheduler, JCL)
– Ziņapmaiņas sistēmas (piemēram Apache MQ)
– . . .

6. SITUĀCIJAS NOVĒRTĒŠANA PIRMS PROJEKTA
Saprast veco un jauno biznesa procesu, to atbilstību
Jaunā / vecā datu vārdnīca
 Vai tādu vispār iespējams iegūt?
 Vai eksistē ‘cross-references’?
 Vai ir zināmas nepieciešamās datu validācijas?
 Ko darīt, ja viss ir konfigurējams?
Vai biznesa loģika vecajā aplikācijā ir saprotama?

7. MIGRĒJAMIE DATI
 Datu bāzes
– Ne visas datu bāzes bija / ir / būs relāciju DB
 Datnes
– Ne visas datnes ir tik vienkāršas kā teksta faili
 Citi dati
Par maz ir tikai nomigrēt tabulas / datnes. Pēc migrācijas biznesa
procesam, kas sākts vecajā aplikācijā, jāvar korekti nobeigties
jaunajā aplikācijā.

8. IZAICINĀJUMI
Bieži datu migrācijai tiek patērēts vairāk resursu, nekā plānots
sākumā. Galvenās problēmas visos gadījumos ir līdzīgas, bet
projekta sākumā datu īpašnieks parasti nepiekrīt, ka tās ir nozīmīgas.
Datu migrācijas projekti var būt ar ļoti dažādu riska pakāpi.
Smagākajos gadījumos datu migrācijas projekts var būt līdzīgs
duelim – otra mēģinājuma var arī nebūt. Dažreiz ar radošām
tehniskām innovācijām var darīt brīnumus. Reizēm ir vērts jau
projekta sākumā pierunāt klientu uz kompromisiem (atteikties no
daļas datu migrācijas vai labot tos jau pēc migrācijas).

9. PROBLĒMAS UN RECEPTES
 Datu nepietiek vai tie ir sliktā kvalitātē
– Plānojiet datu validāciju / tīrīšanu / papildināšanu
 Dati jāielādē un jāpārbauda ļoti ātri (piemēram, nedēļas nogalē)
– Plānojiet veikt migrāciju pirms laika, tad regulāri migrēt tikai «deltas»
 Grūti droši notestēt migrētos datus, bet kļūdas var būt
uzņēmumam kritiskas
– Paralēls abu sistēmu darbs pārejas laikā.
 Mērķa dati ir strukturēti savādāk. Jaunā platforma neatbalsta
vecās datu piekļuves metodes
– Gatavas receptes visiem gadījumiem var arī nebūt. Esiet radoši.

10. 10 www.ExigenServices.com
DATA MIGRATION: MAINFRAME SPECIFIC
Issues Ways to reduce risk
EBCDIC->ASCII, big/small Endian:
•special arithmetic data types
•sorting problems
Use specialized data conversion tools.
Consider these problems by application
design
Mainframe data access methods not available
on new platform
Be creative, 1:1 redesign might not be
optimal
Data cleansing often underestimated Start data cleansing very early. Separate
technical cleansing. Involve SMEs early.
You can not completely isolate data migration
form overall design issues
Use iterative (or even agile) process
Centralized versus distributed Use proven design patterns for new
design, use old design as checklist
Normalized versus flat, performance issues Do not over-normalize. Use smart
mapping techniques for migration.
SYSTEM REENGINEERING

11. DATU VALIDĀCIJA
 Datus var lādēt vai nu tieši tabulās / datnēs (ETL Pieeja)
 Vai caur aplikācija API (imitējot ievadi caur aplikāciju)
– Šis ceļš ir ilgāks, bet nodrošina drošāku validāciju.
Migrējot jānodrošina, ka jaunā aplikācija varēs pastrādāt ar
iemigrētajiem datiem. Tāpēc visi migrējamie dati jāpakļauj iespējami
pilnai validācijai.
 Ne vienmēr mēs zinām visus validācijas likumus. Tie var būt jāpēta.
 Tas var prasīt lielāku vai mazāku programmēšanu. Eksistē arī gatavi rīki šādam
nolūkam.
 Kad datu kļūdas ir atrastas, tās ir jālabo – automātiski vai ar roku. Process
jāturpina tik ilgi, kamēr validācijas kritēriji ir apmierināti.

12. DATU TĪRĪŠANA / PAPILDINĀŠANA
 Izdaliet atsevišķi tehnisko tīrīšanu
– Tehnisko tīrīšanu var veikt IT personāls
– Pārējo var tikai biznesa cilvēki (SME)
 Tīriet datus cik agri vien var
– Vislabāk aplikācijā, no kuras jāmigrē
– Var būt speciālas «tīrītavas» starp jauno un veco aplikāciju
– Nekritiskas kļūdas var vienoties atstāt tīrīšanai jaunajā aplikācijā.
 Rēķinieties ar to, ka uz daudziem jautājumiem neviens nevarēs
atbildēt, ja vecajai aplikācijai ir 10 gadi vai vairāk
– Dati satur daudzas pēdas – par bijušajiem biznesa procesiem, kādreizējām
kļūdām, aizmirstiem programmētāju trikiem u.t.t.
Datu problēmas pēc migrācijas nedrīkst radīt uzņēmumam pārāk
lielus zaudējumus. Tās nedrīkst paralizēt jauno aplikāciju.

13. DATU TRANSFORMĒŠANA
Reizēm tas ir dabiski un viegli, reizēm ne visai.
Piemērs 1:
 Vecajā aplikācijā produktu definīcijas ir hardkodētas
 Jaunā aplikācija izmanto standarta no trešās partijas nopirktu rīku produktu
definēšanai.
Piemērs 2:
 Vecajā aplikācijā datu validācijas ir hardkodētas
 Jaunā aplikācija validācijām izmanto BRE (business rule engine)
Plānojot projektu, jāplāno datu pārveidojumi (data mapping). Ar to
parasti nodarbojas biznesa analītiķi, pārsvarā klienta cilvēki (SME), ar
IT cilvēku atblastu.

14. PARALĒLS ABU SISTĒMU DARBS
 Par katru aspektu vienai no sistēmām jābūt noteicējai (master)
– Otrā sistēmā šo datu izmaiņas vēlams aizbloķēt
– Jārada sinhronizācijas mehānisms
– Jāizstrādā «rezerves izpletnis»
 Var būt grūti savilkt kopā datus no abām sistēmām
– Varbūt tam jātaisa trešā sistēma.
 Lietotājiem jāstrādā ar 2 aplikācijām vienlaicīgi
– Pieaug treniņu un atbalsta izmaksas,
– Pārejas laikā zema darba efektivitāte
Paralēla 2 sistēmu ekspluatācija rada papildus drošību bet arī
ievērojamas papildus izmaksas.

15. LIELS DATU APJOMS
Var gadīties, ka vajadzīgu datu apjomu nemaz nevar ielādēt
vajadzīgajā laika intervālā. Tad migrācija jāuzsāk ātrāk, kombinējot
‘big bang’ un pakāpeniskās migrācijas metodi.
 Nofiksē kādu vecās sistēmas stāvokli un pakāpeniski to ielādē, lai
cik tas laika arī prasītu.
 Nākošās izmaiņas migrē kā ‘tikai izmaiņas’
– Vecai aplikācijai jābūt spējīgai šīs izmaiņas iedot
– Jaunajai aplikācijai jābūt spējīigai šīs izmaiņas paņemt
Šī pieeja atrisina ātruma problēmu bet rada papildus izmaksas.
Vēl grūtāk ir tad, ja veco aplikāciju vispār nedrīkst apturēt.

16. DATU MIGRĀCIJAS TESTĒŠANA
 Vislabāk testēt ar reāliem datiem, bet, iespējams, ka dati būs
jāanonimizē
– Neatkarīgi, vai to programmē paši vai izmanto rīkus, tas nozīmē papildus
laiku un izmaksas
 Ar migrētajiem datiem jātestē būtiskie biznesa scenāriji.
 Jātestē arī veiktspēja gan migrācijas procesam, gan arī mērķa
aplikācijai ar pietiekoši daudz nomigrētiem datiem.

17. MĪTI
 Mani dati ir kārtībā, tie nav jālabo
 Atrastās datu kļūdas var viegli izlabot
 Es zinu, kā jāvalidē dati
 Dati viegli, dabiski transformējas no vienas sistēmas otrā
 Funkcionalitāte, kas strādā ar dabīgi ievadītiem datiem, gan jau
strādās arī ar migrētiem datiem

18. DATU MIGRĀCIJA KĀ BIZNESS
Šis nav viegls bizness IT kompānijai, jo parasti nevar iztikt bez klienta
biznesa zinātājiem (SME).
Parastai kompānijai, kam nepieciešama migrācija, arī tas tipiski nav
viegls pasākums, jo trūkst zināšanu par tipiskām problēmām, kas
sagaida.
Dažas IT kompānijas pārdod rīkus, kas var būt noderīgi datu
migrācijai.
 Izvēloties šādus rīkus, kritiski jāizsver, vai ieguldījums tiešām atmaksāsies
 Dažas «datu specifiskas»rīku funkcijas:
– Datu maskēšana
– Datu vārdnīcas
– Datu transformācija (mapping)

19. SĀKOT PROJEKTU
Ieteikums – samazināt datu migrācijas apjomu, cik iespējams
(nelaidiet džinu ārā no pudeles!). Dažas idejas:
 Tikai jaunam biznesam izmantot jauno aplikāciju, lai ‘vecais bizness’ dabīgi
izbeidzas vecajā aplikācijā.
 Nelabot datu kļūdas, kurām nav pietiekoši sliktas ietekmes
Izvairieties no ‘big bang’ scenārijiem, cik iespējams. Ja tas nav
iespējams, paredziet pietiekošu laiku / apjomu. Strādājiet ar klientu,
lai atrunātu viņu no ‘pašnāvnieciskiem scenārijiem’.
Bieži kompānijas ir izsviedušas simtiem tūkstošu analīzei un pēc tam
atteikušās no jaunu aplikāciju ieviešanas, jo migrācija ir par riskantu.