Kanat ja kalkkunat muuttavat, mutta eivät välttämättä
IT-maailmassa

Ben Wilson: Uudistamisen uudet haasteet.

Edinburghin yliopiston ja Heriott-Wattin yliopiston tutkijat ovat määritelleet perinteiset järjestelmät ja perinteisten järjestelmien uudistamisen tärkeyden selvästi. "Perinteisten järjestelmien – eli niiden, jotka huomattavasti vastustavat muutosta ja kehittymistä liiketoiminnan muuttuvien vaatimusten mukaisiksi – uudistaminen on tunnustetusti yksi ohjelmistoinsinöörien suurimmista haasteita."

Niitä lähteitä, jotka eivät pidä perinteisten järjestelmien uudistamista tärkeänä, on vaikea löytää. Samalla on kuitenkin mahdotonta löytää näiden lähteiden keskuudesta yhteistä kantaa sille, mikä olisi paras lähestymistapa uudistamiseen. Ajan mittaan on esitetty monia malleja, jotka eroavat paitsi lähestymistavassa, myös tavassa, jolla ne määrittelevät uudistamismallien avulla saavutettavat tulokset.

Asiantuntijoiden keskustelu oikeasta lähestymistavasta "järjestelmien uudistamiseen" näyttää päätyneen pattitilanteeseen, jossa kaksi vastakkaista ideologiaa sotii keskenään. Nämä ideologiat kiistelevät siitä, onko organisaation parhaiden etujen mukaista "migroida" suuri tehtäväkriittinen tietojärjestelmä kerralla kokonaisuudessaan vai pala palalta. Koska tämä tieto on ratkaiseva uudistamissuunnittelussa, kunkin mallin antama vastaus on yksi sen määritteleviä ominaisuuksia.

Ajan myötä akateemikot ja teollisuuden asiantuntijat ovat kuvanneet näitä kahta lähestymistapaa useilla nimillä. Kaksi suosituimmista, joita nykyään käytetään mallien suuntausten kuvaamiseen ovat "Chicken Little" (Pikku Kananen) ja "Cold Turkey" (”kylmä kalkkuna”, kerrasta poikki).

Chicken Little –termin esiintulo

Ensimmäiset viitteet näihin kahteen termiin ovat löydettävissä vuodelta 1991, Berkeleyssä sijaitsevan University of Californian uraauurtavasta DARWIN-projektista. Projektin tulokset esittelivät "Chicken Littlen" lähestymistapana, jossa perinteiset järjestelmät muutetaan iteratiivisesti (myöhemmin käytettiin sanaa "inkrementaalisesti"). Kun DARWIN-malli viimeisteltiin, lähestymistavan inkrementaalista luonnetta painotettiin. Malli jaettiin yhteentoista helposti muistettavaan vaiheeseen, joista jokainen alkoi sanalla "inkrementaalisesti". Tämä lähestymistapa vastaa selkeästi "ei" kaikki kerralla -kysymykseen. Chicken Little -mallissa perinteisen järjestelmän ja kohdejärjestelmän välille kehitetään "yhdyskäytäviä", jotta tiedot säilyisivät eheinä projektin kuluessa.

Projekti esitteli myös "Cold Turkeyn" vaihtoehtoisena lähestymistapana. Tutkimuksessa todetaan, että "Cold Turkey –lähestymistavassa perinteinen tietojärjestelmä kirjoitetaan uudelleen alusta asti ja kohdejärjestelmä tuotetaan käyttämällä nykyaikaisia ohjelmistotekniikoita ja laitteistoja.". Cold Turkeyn pääasiallinen määrittelevä ominaisuus on sen "suuri pamaus" -lähestymistapa järjestelmävaihdokseen.

Kahden ideologian kilpajuoksussa on sanottava, että ”kalkkuna” sai huonon lähdön: DARWIN-alkututkimus alkaa arvostella Cold Turkey lähestymistapaa 56-sivuisen raportin toisella sivulla. Kun Morgan Kaufmann Publishers –kustantamo julkaisi tutkimuksen kirjana vuonna 1995, teoksen luojat Brodie ja Stonebraker hyökkäsivät entistä voimakkaammin Cold Turkey –lähestymistapaa vastaan aloittaen menetelmään kohdistuvan kritiikkinsä esipuheessaan "Ironista kyllä, nykypäivän monimutkainen ympäristö tekee Cold Turkeysta mahdottoman, mutta se kannustaa ihmisiä myös harkitsemaan sitä. Koska on niin hankalaa pohtia, miten perinteinen tietojärjestelmä muutetaan inkrementaalisesti, suunnittelijat usein välttävät koko haastetta. He uskovat naiivisti, että Cold Turkey on ratkaisu ongelmaan.".

Cold Turkeyn vastainen kritiikki ei niinkään näytä keskittyneen tekniseen lähestymistapaan, vaan arvostelijoiden huolena on pikemmin laajoihin ohjelmistokehitysprojekteihin liittyvä suuri epäonnistumisen riski. Kirjassa esitetyt Cold Turkeyn "esteet", kuten "Liiketoiminnan olosuhteet eivät koskaan säily ennallaan", "Tarkkoja määritelmiä on harvoin", "Dokumentoimattomia riippuvuuksia on usein olemassa", "Suurten projektien hallinta on vaikeaa" ja "Suuret projektit usein paisuvat" eivät ole pelkästään perinteisten järjestelmien uudistamiseen liittyviä erikoispiirteitä. Yksi Chicken Littlen pääasiallisista valopuolista on mallin kyky jakaa laaja projekti pienempiin osiin, joista jokainen tuottaa valmistuttuaan selvän ja näkyvän tuloksen: jälleen uusi osa perinteistä järjestelmää toimii kohdejärjestelmässä. Mallin suurimmat edut ovat siinä, että organisaatio pystyy keskittymään tiettyihin tarkistuspisteisiin pitkän projektin aikana ja että johto voi nähdä pitkäaikaisessa sijoituksessa silloin tällöin joitakin etuja.

Cold Turkey -mallin epäilyä on helpompi ymmärtää, kun DARWIN-tutkimusta katsotaan sen historiallisessa yhteydessä. DARWIN-projektin aikakaudelta puuttuivat tietenkin kehittyneet ohjelmistotyökalut, joilla migraatiot olisi voitu tehdä automaattisesti ja turvallisesti. Vuonna 1991 automatisoitu järjestelmämigraatioteollisuus ei ollut niin pitkälle kehittynyt kuin nykyään, ja epäonnistumisia sattui paljon organisaatioiden yrittäessä migroida laajoja tehtäväkriittisiä tietojärjestelmiä. Varhaisimmat migraatiotyökalujen kehittäjät, kuten Anubex vuonna 1995, aloittivat vasta muutamaa vuotta myöhemmin. Näin ollen suuri osa tietojärjestelmien migraatioista DARWIN-projektiin johtavalla ajanjaksolla tapahtui tavalla, jota alalla nykyään kutsutaan "käsityöksi."

Cold Turkey saa tukea

Chicken Little–lähestymistapaan kohdistui ankaraa kritiikkiä kaksi vuotta Brodien ja Stonebrakerin kirjan julkaisemisen jälkeen, kun irlantilaiset tutkijat esittelivät MILESTONE-nimisen itsenäisen projektin tuloksia. Tutkimustulokset esitettiin vuonna 1997 Asia Pacific Software Engineering–konferenssissa ja International Computer Science –konferenssissa Hong Kongissa. Tutkimus torjuu Chicken Little-metodologian, ei sen kiistattomien projektinhallintaetujen vuoksi, vaan teknisistä syistä. Raportissa todetaan: "Brodien ja Stonebrakerin Chicken Little –metodologia tarjoaa kaikkein kypsimmän lähestymistavan. Migraation aikana perinteisen järjestelmän ja kohdejärjestelmän on kuitenkin oltava yhdyskäytävien kautta vuorovaikutuksessa keskenään, mikä lisää jo sinällään monimutkaisen prosessin monimutkaisuutta entisestään ja on myös huomattava tekninen haaste. Tarvitaan siis turvallinen, kaikenkattava, yhdyskäytävät tarpeettomiksi tekevä lähestymistapa perinteisten järjestelmien migraatioon.". .

MILESTONE-projektin "Cold Turkey" –metodi ei kuitenkaan suuresti eroa DARWIN-projektin "Chicken Little" -metodista. Pääasiallinen ero on siinä, että DARWIN-projektissa uusia alijärjestelmiä kehitetään ja otetaan tuotantoon saman tien, kun taas MILESTONEssa alijärjestelmät otetaan tuotantoon vasta, kun koko järjestelmä on saatu valmiiksi. MILESTONE-metodologian viimeinen vaihe on täydellinen tiedonsiirto perinteisestä ympäristöstä kohteeseen. Raportti painottaa, että heidän lähestymistavassaan yhdyskäytävien tarve poistuu, koska käytössä olevan tiedon migraatio on prosessin viimeinen vaihe.

Hämmennys

Keskustelu siitä, milloin käytössä oleva tieto siirretään perinteisestä järjestelmästä kohdejärjestelmään ja kuinka monessa vaiheessa se tapahtuu, saattaa kummastuttaa. Mitä tekemistä käytössä olevan tiedon sijainnilla on "perinteisten järjestelmien migraation” kanssa? Brodien ja Stonebrakerin mukaan perinteinen tietojärjestelmä on sellainen, joka "perinteiseen tapaan" vastustaa muutosta. Muutoksen vastustamisen syitä ovat järjestelmää kuvaavan prosessin huono dokumentointi, järjestelmän toiminnan ymmärtämättömyys määritelmien puutteen vuoksi ja se, että vuosien ylläpidon aikana ohjelmakoodin rakenteellisuus on heikentynyt. Jos tietojärjestelmällä on tällaiset ominaisuudet, mitä hyödyttää siirtää tietoja toiseen ympäristöön? MILESTONE-tutkimus väittää myös, että "Perinteisen järjestelmän migraatiossa kehitetään kohdejärjestelmä, joka säilyttää alkuperäisen järjestelmän toiminnallisuuden ja tiedot mutta jota on helppo ylläpitää ja sovittaa tuleviin liiketoiminnan vaatimuksiin." . Jos tiedon säilyttäminen on tärkeää, miksi se täytyy siirtää muualle?

Näyttää siltä, että termistä "perinteinen järjestelmä" on tullut synonyymi kolmelle eri käsitteelle:

  • heikkolaatuinen järjestelmä, joka vastustaa muutosta riippumatta, millä alustalla se toimii;
  • laadusta riippumatta mikä tahansa järjestelmä, joka toimii suljetulla tai vanhentuneella alustalla; or
  • heikkolaatuinen järjestelmä, joka vastustaa muutosta ja toimii suljetulla tai vanhentuneella alustalla.

USAF:stä saadut kokemukset näyttäisivät viittaavan samaan havaintoon. M. Olsem lausui paneelissa (ICSM97): "Ohjelmien uudistamisprojektien tavoitteena on muuttaa perinteiset järjestelmät asiakaspalvelinjärjestelmiksi, jotka perustuvat diskreettien objektien käyttöön.".

Jos "migraatio" ja "uudistaminen" ovat sekaantuneet samaksi käsitteeksi, tämä hämmentää organisaatioita, jotka tarvitsevat jompaakumpaa. Se johtaa myös ”migraatio-uudistusprojektien” laadun heikkenemiseen, koska hankkeilta puuttuu aina selkeä painopiste. Sen enempää uudistamisen kuin migraationkaan kannalta ei ole tarkoituksenmukaista sekoittaa näitä käsitteitä keskenään.

Jos organisaatio kohdistaa mittavia varoja suureen kehitysprojektiin, jossa käytetään uusimpia kehitystyökaluja, mutta ei dokumentoi kehitystuloksia, toimi määritelmien mukaan tai käytä kunnollista arkkitehtuuria, eikö heillä ole silloin käsissään "perinteinen järjestelmä" joka vastustaa muutosta, vaikka se olisikin vain kaksi vuotta vanha? On vaikea kuvitella, että järjestelmän siirtäminen uusimpaan asiakaspalvelintekniikkaan toisi mitään etuja. Tarvitaan selkeää uudistamista.

Toisaalta jos 25-vuotias, vanhentuneella alustalla toimiva COBOL-järjestelmä on kehitetty täydellisesti dokumentoituna ja määritysten mukaan eikä sitä ole koskaan muutettu, uudistaminen ei tuo suurta lisäarvoa. Silloin tarvitaan selkeää migraatiota.

Mitä migraatio siis tarkoittaa?

Migraatiossa (Anubexin migraatiokonseptin mukaan) organisaatio siirtyy turvallisesti, riskittömästi ja ennen kaikkea nopeasti avoimelle alustalle niin, että organisaation resursseja pyritään sääästämään. Organisaation tekninen riski poistetaan lopettamalla riippuvuus suljetusta tai vanhentuneesta tekniikasta. Migraatiot ovat nopeita, koska työkaluilla automatisoidaan prosessi ja varmistetaan koodin eheys. Uudistamisessa on kyse koodin laadun ja rakenteiden parantamisesta niin, että järjestelmä voidaan helposti sovittaa liiketoiminnan muuttuviin vaatimuksiin. Näin organisaatio pysyy kilpailukykyisenä.

Migraatio puhtaimmassa mielessä tekee tarpeettomaksi kysymyksen, milloin käytössä oleva tieto siirretään perinteisestä järjestelmästä kohdejärjestelmään. Migraatiometodologian ja -työkalujen avulla laajatkin järjestelmät muutetaan nopeasti ja täydellisesti kohdeympäristöön. Uudistamisen määrä ja laatu ennen prosessia, ennen ja jälkeen tai jälkeen prosessin tai sen antama lisäarvo ovat kysymyksiä, joita on pohdittava tarkempien migraatiometodologioiden yhteydessä. Uudistamisprosessi onnistuu vastaamaan sekä Chicken Little –haasteeseen (koodin laadun parantaminen askel kerrallaan maratonprojektien välttämiseksi) että Cold Turkey –haasteeseen (yhdyskäytävien välttäminen) vain vahvan migraatiokumppanin kanssa.

Tämä on saavutettavissa vain, kuin vahvat migraatiometodologiat ja uudistamismetodologiat yhdistetään peräkkäin perinteisen järjestelmän ajanmukaistamisprojektissa. Helpoin lähestymistapa perinteisiin järjestelmiin (joille on ominaista koodin heikko laatu ja toiminta vanhentuneilla tai suljetuilla alustoilla) on se, että järjestelmä, sen koodi ja tiedot, muutetaan nopeasti kohdealustalle puhtaan migraation avulla. Kun vanhentuneen tekniikan tuottama riski on poistettu, painopiste voidaan siirtää järjestelmän laadun parantamiseen. Yhdyskäytäviä ei koskaan tarvita, ja toisaalta uudistetut moduulit voidaan ottaa käyttöön viivytyksettä.

Sitä mukaa kun migraatiotyökalut ja -tekniikat (kuten Anubexin migraatiokonsepti ja -työkalut ) muuttuvat entistä automatisoidummiksi ja kehittyneemmiksi, uudistamisen lisäarvon määrittämiseen kohdistuu migraatioprojekteissa entistä enemmän paineita. Sen sijaan että yrittäisi tehdä kaksi asiaa kerralla (siirtää järjestelmä nykyaikaiselle alustalle ja parantaa ohjelmakoodien laatua), uudistamistyössä voidaan keskittyä enemmän koodin laadun ja arkkitehtuurin parantamiseen.

Huomatus: Jos sinun on vaikea uskoa, että kanat todellakin muuttavat, Northern Prairie Wildlife Research Centerin äskettäin tekemä tutkimus saattaa kiinnostaa sinua. Radiolähettimellä seurattujen preeriakanojen havaittiin muuttavan jopa 30 mailia talven aikana.