LEGACY JÄRJESTELMIEN

UUSIMINEN

Vesa Keskinen, Senior consultant

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.”

Taustaksi

• On arvioitu, että vielä noin 70 % maailman

tietojärjestelmien datasta sijaitsee mainframe-

jä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

Taustaksi

• Legacy Modernization ekosysteemi on jo varsinmonimuotoinen

• 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

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 point-

to-point järjestelmäintegraatioita)

• Joustavuuden ja ketteryyden puute sovelluskehityksessä time-to-

market 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

Legacy integraatio lähde:practisingsafetech.com

Uusimisen perussyitä

• Kaksi keskeisintä syytä ovat kustannusten alentaminen japalveluiden 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

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

Uusimisvaihtoehtoja

• Re-hosting (uudelle alustalle siirto)

• Re-engineering, integration and service enablement (uudelleen

suunnittelu)

• Refresh, (sovellusrakenteen muokkaus, modularisointi, web-

kelpoisuus)

• Valmisohjelmisto / uuskehitys

Re-hosting

• Re-hosting tarkoittaa, että sovelluskokonaisuus (sovellukset,

tietokannat, parametristot, eräajokomponentit ym.) siirretään

ajettavaksi uudella alustalla ns. migraatiotyökalujen avulla

sovelluslogiikkaan puuttumatta

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)

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

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

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

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

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)

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)

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…)

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

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

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äpito-

sekä lisenssikustannukset)

• Integroitavuushyötyjen arvioinnin

• Koulutus- ym. kustannukset

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

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

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

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)

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

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

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ä

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