Legacy järjestelmien uusimisessa huomioitavaa, joitakin hyviä käytäntöjä tiedoksi

1. LEGACY JÄRJESTELMIEN
UUSIMINEN
Vesa Keskinen, Senior consultant

2. Legacy System määritelmä
• Wikipedia:
• „A Legacy System is an old method, technology, computer system
or application program”
• ”a legacy system is any corporate computer system that isn't
Internet-dependent”
• Huom! Legacy system ei ole yhtäkuin host-järjestelmä, sillä
nykyinen mainframe-hw ajaa sujuvasti samaan aikaan 64 bit Linuxia
ja Javaa ja toisaalta 1960 luvun vintage-koodia
• “Legacy Modernization refers to the conversion, rewriting or porting
of a legacy system to a modern computer programming language,
software libraries, protocols, or hardware platform.”

3. Taustaksi
• On arvioitu, että vielä noin 70 % maailman
tietojärjestelmien datasta sijaitsee mainframejärjestelmissä
• Vakuutusyhtiöt, pankit, kaupat, lentoyhtiöt, terveydenhuo
lto ja monet muut toimialat ovat rakentaneet
ydintietojärjestelmänsä mm. COBOL-sovellusten ja
erilaisten host-tietokantojen varaan
• ICT kustannuksista legacy-järjestelmien ylläpito
”haukkaa” keskimäärin reippaasti yli 50 % ko. toimialoilla

4. Taustaksi
• Legacy Modernization ekosysteemi on jo varsin
monimuotoinen
• Isot toimijat, kuten IBM, Microsoft, Oracle ja moni muu
ovat luoneet laajan joukon migraatiotyökaluja
• Erilaisia konversio-ohjelmia kielestä toiseen löytyy myös
useilta pienemmiltä softataloilta
• Tietoa parhaista käytännöistä ja tutkimuksista löytyy
paljon
• Legacy modernisaatiota on harjoitettu suuressa
mittakaavassa jo reilusti yli 10 vuotta

5. Uusimisen perussyitä
• Korkeat käyttökustannukset
• COBOL-ohjelmoijat ja host-asiantuntijat poistuvat työelämästä koko
ajan; osaamiskato
• Järjestelmien/sovellusten huono integroitavuus (yleensä vain pointto-point järjestelmäintegraatioita)
• Joustavuuden ja ketteryyden puute sovelluskehityksessä  time-tomarket ei niin nopea kuin pitäisi, myös laki- tai viranomaismuutokset
hitaita ottaa käyttöön
• Järjestelmien monimutkaisuus eli nk. spagettikoodi on riskitekijä
sinällään  korkeat ylläpitokustannukset, vaativa testaus yms.
• Toimittajien tuki ja osaaminen vähenee

6. Legacy integraatio
lähde:practisingsafetech.com

7. Uusimisen perussyitä
• Kaksi keskeisintä syytä ovat kustannusten alentaminen ja
palveluiden integraation mahdollistaminen:
– Taustajärjestelmät on saatava liitettyä
•
•
•
•
Työpöytäsovelluksiin
Portaaliratkaisuihin
Kumppanijärjestelmiin
Liiketoimintaprosessien seurantaan ja hallintaan
– Back-end toiminnallisuus on tuotava kaikenlaisille päätelaitteille

8. Hyödyt, joita tavoitellaan
• Matalammat käyttö- ja ylläpitokustannukset (standardialustoilla,
standardisovelluspalvelimilla)
• Alustakapasiteetille vaihtoehtoja (pilvipalvelut, IaaS)
• Sovelluskehitys ketterillä menetelmillä SOA ja avoimet rajapinnat
hyödynnettynä  Service Integration mahdollistuu, moderni
sovellusrakenne
• Laaja toimittajatuki

9. Uusimisvaihtoehtoja
• Re-hosting (uudelle alustalle siirto)
• Re-engineering, integration and service enablement (uudelleen
suunnittelu)
• Refresh, (sovellusrakenteen muokkaus, modularisointi, webkelpoisuus)
• Valmisohjelmisto / uuskehitys

10. Re-hosting
• Re-hosting tarkoittaa, että sovelluskokonaisuus (sovellukset,
tietokannat, parametristot, eräajokomponentit ym.) siirretään
ajettavaksi uudella alustalla ns. migraatiotyökalujen avulla
sovelluslogiikkaan puuttumatta

11. Re-hosting
• Re-hosting plussat:
+ Ajoalustan käyttökustannukset pienenevät
• Re-hosting miinukset:
- Koodi säilyy ennallaan ja samoin aiemmin esitellyt ongelmat
• Business-case logiikka: käyttökustannukset vs.
migraatiokustannukset (ROI)
• Eniten käytetty uudistamistapa tällä hetkellä (Gartner)

12. Re-engineering
• Pyritään kaivamaan olemassa oleva business-logiikka esiin ja
suunnitellaan ja toteutetaan uusi sovellus osin migratoiden
moderniin palvelukeskeiseen ympäristöön ja nykyaikaiselle alustalle
• Plussat:
+Business-logiikka saadaan ”talteen”
+ käyttökulut pienenevät
+ Service Integration mahdollistuu aidosti
• Miinukset:
- business-tietoa jää huomioimatta yleensä huonon
dokumentaation takia
• Business-case logiikka: Migraatio- ja kehityskustannukset vs.
modernin sovelluskehitysympäristön myötä parantunut tuottavuus
plus integraatiohyödyt ja pienentyneet käyttökulut

13. Refresh
• Käydään olemassa oleva sovellusrakenne läpi, pyritään
modularisoimaan se, eli löytämään uudelleenkäytettävät osat,
poistamaan turhat osat, tekemään modulit web service kelpoisiksi
• Migratoidaan kaikki, mikä pystytään uudemmalle tasolle
• Huom! Tämä harjoitus kannattaa tehdä myös Re-engineering
projektien ensi vaiheena ja tehdään usein re-hostingin jälkivaiheena
• Plussat:
+ parempi legacy-koodin rakenne, parempi integroitavuus
+ business-logiikka saadaan talteen
• Miinukset:
- järjestelmä on edelleen face liftin kokenut legacy-järjestelmä
• Business-case logiikka: integroitavuuden hyödyt plus alentuneet
ylläpitokustannukset vs. käyttökustannukset

14. Valmisohjelmisto / uuskehitys
• Suuren legacy-järjestelmän korvaavaa valmisohjelmistoa ei ole;
kaikki vaativat paljon sovitustyötä, samoin ison
sovelluskokonaisuuden uudelleen ohjelmointi
• Plussat:
+ käyttökustannukset alenevat
+ modernit ympäristöt, standardit integraatiorajapinnat
• Miinukset:
- liiketoimintasääntöjen hyödyntäminen heikkoa tai vaatii suuren
työn
- datamigraatio usein vaikeaa
• Business-case logiikka: tehdyn työn hinta ja/tai valmisohjelmiston
lisenssi vs. legacyn käyttö- ja ylläpitokustannukset

15. Toimintavaihtoehtoja
• Lopulta legacyt on kuitenkin uusittava, mutta lyhyellä tähtäimellä on
vaihtoehtoja:
– Älä tee mitään – aika hoitaa lopulta
• Sopii tilanteeseen, jossa joku tietty sovellus on
korvautumassa lähitulevaisuudessa; älä kuitenkaan ajaudu
ajolähtötilanteeseen
– Päivitä ympäristösi
• Legacy-maailmakin kaikesta huolimatta elää; joskus
uusimpien versioiden käyttöönotto tuo hyötyjä, jotka
kannattaa ulosmitata
• Ulkoista
– Anna sovellusylläpito ja käyttöalustan ylläpito siihen
erikoistuneelle toimittajalle
• Tee modernisointi-strategia osana pitkän aikavälin ICT-strategiaa

16. Strategiset ajurit
•
•
•
•
•
Pyrkimys palveluintegraatiossa standardiratkaisuihin
Alemmat käyttökulut mielellään käytetyn kapasiteetin mukaan
Alustaratkaisut esimerkiksi pilvipalveluina
Laaja päätelaitetuki (loppukäyttäjän tarpeet huomioitava)
Datan (melko Big) parempi hyödyntäminen (vähintään perinteinen
data mining ja raportointi, mielellään data-analytiikka jo
hyötykäyttöön)

17. Modernisointi-strategia
• ”Normaalin” strategiaprosessin mukaan:
– Nykytilan kuvaaminen [Planning Base]
– Tavoite (visio) [Results required]
– Suunnitelmat tavoitteiden saavuttamiseksi [How, Road Map]
– Toteutus [Implementation]
– Onnistumisen arviointi [Review]
• CSI (Continual Service Improvement)

18. Strategiassa huomioitavaa
• Kiinnitä tavoitearkkitehtuuri
• Huomioi paitsi ohjelmistoarkkitehtuuri, rajapinnat ja
kehitysvälineistö myös seuraavat näkökulmat:
– Skaalautuvuus, jatkuvakäyttöisyys
– SaaS, IaaS, virtualisointi
– Tietoturva
• Huom! Tavoitearkkitehtuurin liittyvät teknologiavalinnat
tulevat osin annettuna jo muun sovellusmassan takia
(sovelluspalvelimet, ohjelmointikielet…)

19. Strategiassa huomioitavaa
• Kiinnitä integraatioarkkitehtuuri, huomioi mm. seuraavat
integraatiotarpeet:
– Kanavapalvelut (portaali, web services, erilaiset
päätelaitteet jne.)
– Prosessipalvelut
– Liiketoimintapalvelut ( Sovellukset, BPM, BI, work
flow, viestintäratkaisut…)
– Tietokantapalvelut

20. Yksinkertaistettu vaiheistus
• ARVIOINTIVAIHE
– Nykyarkkitehtuuri, koodin laatu, infran rajoitteet, sovellusten riippuvuudet,
dokumentoinnin laatu…
• KIINNITYSVAIHE
– Strategiset valinnat, tavoitearkkitehtuuri(t), Road Map, taloudelliset analyysit,
hallintomalli…
• TOTEUTUSVAIHE
– Migraatiot, uuskehitys, integraatiorajapinnat…
• TRANSITIOVAIHE
– Käyttöönotto, tuki- ja ylläpito…
• HUOM! Ennen toteutusvaihetta on oleellisen tärkeää kokeilla
POC:eilla ja valmiilla Framework:eilla eri vaihtoehtojen ja välineiden
toteutuskelpoisuutta

21. Uusimisen Road Map
•
Road Map pitää sisällään mm. seuraavia aktiviteetteja:
– Kiinnitetään liiketoimintatavoitteet, muut strategiset tavoitteet, KPI:t, aikataulut ja
tavoitearkkitehtuuri
– Piirretään riippuvuuskartta liittyen eri sovelluksiin, infraan ja ulkoisiin liittymiin
– Tunnistetaan sisäiset ja ulkoiset integrointitarpeet
– Tunnistetaan ja arvioidaan vaikutukset käyttäjiin ja asiakkaisiin
– Tunnistetaan vaikutukset henkilöstöön ja muihin sidosryhmiin
– Arvioidaan erilaiset rajoitteet (infra, vanhat softat…)
– Arvioidaan muutoskustannukset
– Laaditaan toteutuksen riski/hyöty-analyysi sisältäen ainakin:
• Valitun migraatiotekniikan vaatiman työmäärän
• Migraatioon kuluvan ajan (vaatimusmäärittelystä käyttöönottoon)
• Järjestelmäkokonaisuuden dokumentoinnin
• Oletettujen käyttökustannusten vähenemisen migraation jälkeen (käyttö-, ylläpitosekä lisenssikustannukset)
• Integroitavuushyötyjen arvioinnin
• Koulutus- ym. kustannukset

22. Uusimisen viitekehys
• Usein monitoimittajahanke, jossa korostuu hyvät ohjelmajohtamisen
käytännöt
• Legacy järjestelmän uusimisohjelma voidaan jakaa kolmeen
päävaiheeseen: uusinnan valmisteluvaihe, uusinnan toteutusvaihe
ja käyttöönottovaihe
• Eri vaiheiden hallintaan tulee erityisesti panostaa
• Valmisteluvaiheessa korostuu SCOPEN HALLINTA
• Toteutusvaiheessa on tärkeää LAADUN-, KONFIGURAATION- JA
MUUTOSTEN HALLINTA
• Käyttöönottovaiheessa erityishuomio MUUTOSHALLINTAAN

23. Scopen hallinta – hyvät käytännöt
• Uusimishankkeelle johtoryhmätasoinen omistaja (tämä ei ole
yleensä CIO:n homma)
• Suuri syy isojen projektien epäonnistumiseen on usein siinä, että
scope ymmärretään eri lailla osapuolien (liiketoiminta, asiakkaat,
projekti-tiimi…) kesken  haettava yhteinen ymmärrys ja tahtotila
sidosryhmien kesken, tarvittaessa allekirjoituksin
• Kun tavoitteet ja vaatimukset kiinnitetään, niin minimoitava
kurinalaisesti jälkimuutokset
• Scopekin määritellään, suunnitellaan, todennetaan ja muutokset
hallinnoidaan systemaattisesti ja tarkasti dokumentoiden

24. Laadun hallinta – hyvät käytännöt
• Erillinen laatuvastaava ei ole huono idea massiiviselle
uusimisprojektille
• Laadun ”tarkkailu” organisoitava
• Kun käytettävissä on yrityksen sovelluskehityksen parhaat
käytännöt, valmistuotteet, standardit, ohjeistukset yms. tuotosten
arviointiin, niin niitä on syytä myös valvotusti KÄYTTÄÄ
• Katselmoinnit riittävän usein paitsi tuotosten laatuun myös
tuottamisen laatuun (prosessit, menetelmät, työkalut…) liittyen
• Projektipäälliköille mahdollisimman vähän, mieluiten ei ollenkaan
oto-rooleja

25. Konfiguraation hallinta – hyvät
käytännöt
• Windows-hakemisto ei ole versiohallintatyökalu!
• CI:t kirjoihin ja kansiin
• Pidettävä kaikista muutoksista kirjaa, hyväksytettävä tarvittaessa
Change management boardilla (CMB)
• Testaushavainnot pitää pystyä jäljittämään tehtyihin muutoksiin
(järjestelmätuki)

26. Muutoshallinta – hyvät käytännöt
• Ottaen huomioon, kuinka paljon muutoksia jo tyypillisessä,
”normaalissa” softaprojektissa esiintyy, kannattaa muutoshallinta
organisoida huolella:
– Roolit
– Prosessit
– Työkalut
– Raportointi
– Isojen muutosten erilliskäsittely (CMB)
• Ylipäätään tiettyjen ITIL-käytäntöjen soveltamisesta on jo
toteutusvaiheessa hyötyä kehitys- ja projektihallinnan menettelyjen
lisänä, mutta käyttöönotossa ja ylläpidossa ne ovat MUST

27. Case-esimerkkejä
• Toimittajien sivuilta niitä löytyy paljonkin
– Kannattaa kuitenkin suhtautua varauksellisesti, koska päätavoite
on omien tuotteiden markkinointi; silti tutustumisen arvoista
• Gartner, Forrester, IDC, Aberdeen Group jne. tarjoavat case
tietoa, analyysejä, trendejä ja teknologia/työkalu-arviointeja

28. Vinkkejä
• Menetelmiä/malleja tutustuttavaksi, jos Legacy uusinta on
ajankohtainen:
– ADM (Architecture Driven Modernization), OMG:n malli
– SDAM (Service Driven Application Modernization), intialaisen
HCL:n kehittämä SOA-pohjainen malli
– GQM (Goal, Question, Metric), softamigraation laadun
varmistamiseen
– SRRT (Software Rewriting and Replacement Times),
taloudellinen arviointimalli
– RMM (Risk-Managed Modernization), perinteistä riskianalyysiä
monipuolisempi menetelmä

29. Vinkkejä
• Kirjallisuutta:
– Ulrich, Newcomp: Information Systems Transformation;
Architecture-Driven Modernization Case Studies, MK 2010
– Fairbanks: Just Enough Software Architecture; A Risk-Driven
Approach, Marshall & Brainerd 2010
– Seacord, Plakosh, Lewis: Modernising Legacy Systems,
Addison-Wesley Professional, 2003