Sovelluksen modernisoinnin haasteita

Modernisoinnin haasteita

FinPUG-seminaarin teemana on tänä vuonna 2018 "Modernisointi".  Jotenkin tuntuu tutulta - aihe ei nimittäin ole esillä ensimmäistä kertaa.

Lyhyesti: Kysymys on olemassa olevan liiketoimintasovelluksen kehittämisestä niin, että se kykenee vastaamaan "uusiin haasteisiin". 

Loppuasiakkaat haluavat jatkuvuutta ja lisäkehitystä toiminnallisiin järjestelmiinsä.  Toimivan järjestelmän korvaaminen nähdään järkeväksi vain, jos sovellus on "elinkaarensa lopussa".  Elinkaari loppuu, kun sitä ei kyetä kehittämään eikä modernisoimaan.

Sovelluksen toimittajat katsovat samaa asiaa omasta näkökulmastaan: Sovellus voi toiminnallisesti olla nykyasiakkaille tyydyttävä, mutta uusien asioiden hankinta on hankalaa vanhanaikaisuuden takia.

Heti alkuun on sanottava, että modernisoimiseksi harvoin riittää sovelluksen ulkoasun face-lift eli kasvojen kohotus.  Termi tulee autoteollisuudesta, jossa uusi vuosimalli saadaan aikaiseksi kosmeettisin muutoksin.

Ulkoasu eli käyttöliityntä (UI) tai modernimmin ilmaistuna käyttökokemus (UX) on tärkeä asia, mutta sovelluksen arkkitehtuuri ja muu "konepellin alapuoli" on sitäkin tärkeämpi.  Sitäpaitsi käyttöliitynnän ulkonäkö ei välttämättä vastaa käyttöliitynnän tärkeämpää ominaisuutta - käyttötoiminnallisuutta.

Sovelluksen toiminnallisuus

Tärkein ominaisuus liiketoimintasovelluksessa joka tapauksessa lienee sovelluksen toiminnallisuus eli järjestelmä kykenee siihen tehtävään, mihin se on hankittu, toimii luotettavasti, varmasti ja helposti.  Usein tämä toiminnallisuus on syntynyt monien vuosien vähittäisessä kehitystyössä, sitä ei ollut versiossa 1. 

Juuri tämän toiminnallisuuden säilyttäminen ja kehittäminen on modernisointiprojektien taustalla.

Modernisoinnin haasteet

Viime kesällä Progress järjesti Road Shown "ProgressWorldTour2017", jossa käsitetiin myös modernisoinnin haasteita.  10. kohdan luettelo oli seuraavanlainen:

• Existing Monolithic design
• Thousands of programs, and lines of code
• Inconsistent standards
• Complex dependencies
• Functional fragmentation
• Elusive system semantics
• Redundancy, little reuse
• Brittle to enhancement or change
• Lack of documentation
• Lack of transformation tools

Yritetään suomentaa:

• Monoliittinen rakenne: Sovellus on tehty käytettäväksi yhdellä tavalla.Käyttöliityntä ja sovelluslogiikka on samoissa ohjelmissa.
• Sovellus koostuu tuhansista ohjelmista ja moninkertaisista määristä koodirivejä.Vaikka OpenEdge kääntäjä osaa kääntää ohjelmat virheettömästi toimivaksi kokonaisuudeksi, tällaisen koodin hallinta ja varsinkin muuttaminen on erittäin hankalaa.
• Standardit ovat epäyhtenäisiä: Sovellus on kehitetty vuosien varrella käyttäen aina kulloinkin soveliasta tekniikkaa: include-tiedostoja, funktioita, persistenttejä ohjelmia jne.
• Monimutkaiset riippuvuudet periytyvät epäyhtenäisistä standardeista ja lähdekoodin heikosta hallinnasta.
• Vaikeasti ymmärrettävät merkitykset
• Jos uudeleenkäyttöä ei ole suunniteltu, samaa kopioitua koodia on sadoissa rinnakkaisissa ohjelmissa.
• Laajennukset tai muutokset on vaikeita toteuttaa, kun sovellus on hauras kuin jouluhimmeli.
• Ohjelman alkuperäinen kirjoittaja on ajatellut, että Progress 4GL on niin yksinkertaista, että siihen riittää peruskoulun englannin kurssi.
• Kokonaisuuden tarvitsemaan muutokseen ei löydy sopivia välineitä.

Epäonnistuneet modernisointiprojektit

Samassa esityksessä oli luettelo modernisointiprojektien epäonnistumisien syistä (jälleen 10 kohtaa):

• Flawed or incomplete transformation strategy
• Relying on technical expertise alone
• Inadequately trained people tied to old technologies
• “We know our application inside-out!”
• Little time spent gathering or validating requirements
• Architecture is not the primary consideration
• No recognition of a distinctive transformation process
• Inadequate planning and weak resolve to follow plans
• Lack of long-term commitment from management
• Management predetermines technical decisions

Nämä on helppo suomentaa:

• Virheellinen tai epätäydellinen muutosstrategia, esimerkiksi muutetaan vain käyttöliitynnän ulkoasua.
• Nojaudutaan vain tekniseen asiantuntemukseen.
• Heikosti koulutettuja ihmisiä, jotka ovat sidoksissa vanhaan teknologiaan.
• "Me tiedämme sovelluksemme perinpohjaisesti!"
• Vähän aikaa kerätä tai läpikäydä loppukäyttäjien vaatimuksia.
• Arkkitehtuuria ei nähdä ensisijaisena asiana.
• Ei osata tunnistaa muutosprosessin erityisominaisuuksia.
• Riittämätön suunnittelu ja heikko kyky suunnitelmien seuraamiseen.
• Johdon pitkän aikavälin sitoutuminen puuttuu.
• Johto määrittää teknisiä päätöksiä - usein puheliampien ja antelaimpien myyntitykkien vaikutuksesta.

Entä ohjeistus?

Näistä epäonnistumisen arvioista on helppo tehdä - jälleen 10-kohtainen - luettelo onnistuneen modernisointiprojektin ohjeitukseksi:

• Formulate a complete and coherent strategy
• Technical expertise and disciplined management
• Invest in training people on new technology
• Invest in learning what you don’t know
• Gather and validate requirements with customers
• Architecture is the foundation
• Establish an appropriate transformation process
• Invest in planning and discipline to execute plans
• Commit to transformation as a long-term investment
• Technical decisions based on proper analysis

eli

• Laadi täydellinen ja johdonmukainen strategia.
• Tekninen asiantuntemus ja kurinalainen hallinnointi
• Sijoita ihmisten uuden teknologian koulutukseen.
• Sijoittaa sen oppimiseen, mitä et tiedä.
• Kerää ja läpikäy huolella asiakkaiden vaatimukset ja ehdotukset.
• Arkkitehtuuri on projektin perusta.
• Perusta asianmukainen muutosprosessi.
• Investoi projektin suunnitelmiin ja johdonmukaiseen seurantaan suunnitelmien toteuttamiseksi.
• Sitoudu muutokseen pitkäaikaisena investointina.
• Perusta tekniset päätökset asianmukaiseen analyysiin myyntipuheiden sijasta.

Tulevaisuusturvattu (Future-Proof) sovellusarkkitehtuuri

Modernisointiprojekteja tulee varmasti tulevaisuudessakin, kun liiketoiminnan digitalisointi etenee.  Nämä sovelluksen muutokset ja laajennukset ovat sitä helpompia toteuttaa, mitä tulevaisuusturvatumpi sovelluksen rakenne ja arkkitehtuuri ovat.

Lähtökohtana on tietenkin oikeaoppisesti suunniteltu ja toteutettu tietokanta: normalisoitu skeema, yksilöivät tunnistekentät, triggereilllä automatisoidut vaina- ja viite-eheydet ja järkevästi tehty indeksointi.

Sovelluksen business-logiikka pitää erottaa omaksi tasokseen: palveluiksi, joita voidaan kutsua eri rajapinnoista, käyttöliitynnöistä ja integraatiosta.

Vakiotoiminnot pitää toteuttaa vakioluokilla koodin kopioimisen sijasta.

Progress suosittelema arkkitehtuuri "OERA" (OpenEdge Reference Architecture) perustuu näihin periaatteisiin ja tuotekehitys tuottaa ratkaisuja sen eri osa-alueille.

Teppo Määttänen