Arkkitehtuurit – tekniikkaa ja taidetta, Sytyken risteilyseminaari 7.-9.9.05
Artikkelin on kirjoittanut Eija Kalliala. Seminaarin ohjelma ja kalvot ovat Sytyken verkkopalvelussa osoitteessa http://www.sytyke.org/.
Systeemityöyhdistys Sytyken seminaariin kokoontui yli kuusikymmentä systeemityön ammattilaista verkostoitumaan ja poimimaan asiantuntijoiden antia arkkitehtuureista. Seminaari oli perinteisen antelias ja runsas. Huomasin verkostojeni laajenevat automaattisesti, kun joka vuosi saan uuden hyttitoverin ja tapaan yhteisten iltojen ja aamujen myötä tutuiksi tulleita entisiä hyttitovereitani.
Jouko Poutanen IBM:ltä aloitti seminaarin mieleenjäävällä esityksellään tehoista arkkitehtuurimallinnuksesta. Hän puhui mallikeskeisestä kehittämisestä Sytyken seminaarissa jo pari vuotta sitten, mutta nyt ideaa on päivitetty. Tasojen ja palvelinten määrä kasvaa, samoin monimutkaisuus joka ulottuvuudella. Fuusiot ja vaihtoehtoiset työvälineet sotkevat vielä tilannetta. Mallinnus on yksi vaihtoehto monimutkaisuuden hallintaan.
Jouko Poutanen esitti loistavan kuvan koirankopista, talosta ja pilvenpiirtäjistä, jolla pysäytti miettimään, milloin mallinnetaan ja milloin ei.
Mallikeskeinen kehitys (MDD, Model-Driven Development) ulottuu perinteistä mallintamista laajemmalle. Ensin mallinnetaan liiketoiminta ja vaatimukset tietojärjestelmälle, sen jälkeen palveluelementit karkealla tasolla. Liiketoimintaprosesseista johdetaan arkkitehtuuri. Näin kehitetystä mallista nähdään, kuinka laajasta prosessista on kysymys ja paljonko tarvitaan resursseja. Mallissa voidaan kuvata myös fyysiset rakenteet ja niiden jakautuminen eri koneille.
UML (Unified Modeling Language) on vakiintunut yleisimmin käytettynä mallinnuskielenä. Perus-UML:stä puuttuu kuitenkin joissain vaiheissa tarvittavia elementteja, joten kieleen saattaa tulla muutoksia lähiaikoina. Profiilien avulla voidaan toki laajentaa UML:a omilla stereotyypeillä ja soveltaa sitä luovasti: kysehän on metakielestä.
Lopuksi Jouko Poutanen totesi, että mitä abstraktimpi mallin taso on, sitä tehokkaammin se palvelee sovelluksen kehittämistä.
Pekka Kähkipuro Sysopen Digialta kertoi mobiilien yritysjärjestelmien haasteista ja ratkaisuista liiketoiminnan, arkkitehtuurien ja osaamisen näkökulmista. Hän kertoi mobiilista integraatiosta: mobiileihin järjestelmiin voidaan liittää ei-mobiileja laitteita. Järjestelmille on tyypillistä, että tietoja käsitellään taustajärjestelmissä, ja mobiililaite vastaa käyttötilanteen hallinnasta. Päätelaitteessa voi olla myös jotain paikallista käsittelyä, mutta kokonaisuus koostuu lähes aina myös ei-mobiileista ratkaisuista ja palveluista.
Mobiileilla yritysjärjestelmillä tavoitellaan mahdollisimman tehokkaita ja nopeita prosesseja, joista käyttäjä saa välittömän palautteen.
Mobiliteetin avulla voidaan tehdä aivan uusia asioita: mobiilit järjestelmät luovat vanhojen rinnalla uusia käytänteitä, tulevaisuudessa mahdollisesti uutta liiketoimintaa. Nykyisin lähes jokaisessa tietojärjestelmäprojektissa rakennetaan internet-palveluita. Gartner on todennut kehityksestä, että enää asiakkaalle ei tule postitse papereita, joita hän ei halua, vaan hän kahlaa tietomeressä, josta onkii itselleen tarpeellista tietoa.
Pekka Kähkipuro totesi, että propelihattuinen innostus helposti unohtaa liiketoiminnan normaalit lainalaisuudet: luullaan, että asiakas ja myyjä löytävät toisensa verkosta automaattisesti.
Mobiilit palvelut toimitetaan käyttäjälle joko nopeimmalla tai edullisimmalla tavalla palvelun kriittisyydestä riippuen
Mobiilipalveluissa voidaan erottaa seuraavat näkökulmat liiketoiminnasta tekniikkaan:
* liiketoiminta
* sovellus
* integrointi
* infrastruktuuri
* hallinnointi
* turvallisuus.
Kysymys turvallisuudesta on yksi keskeinen mobiili-integraation este, koska sovellusten saaminen tietoturvallisiksi edellyttää huolellista toteutusta.
Eero Koskinen SAP Finlandilta kertoi integraatioarkkitehtuurin toteutuksesta SAP NetWeaverin avulla. Hän kuvasi, miten innovaatioista tulee standardoimalla tavanomaisia, kuten on käynyt kauppojen asiakaskorteille ja pankkien ottoautomaateille: ne eivät tarjoa enää kilpailuetua, mutta kaikilla pitää olla sellaiset.
SAP NetWeaver on avoimia arkkitehtuureja käyttävä sateenvarjotuote.
Eero Koskinen kehui RFID:iä, jota voidaan lukea myös radioaaltojen välityksellä. Portaalista hän totesi, että se yksinkertaisesti tarkoittaa käyttöliittymäpalveluita eri tuotteisiin, jotka voidaan toteuttaa ekstra-, intra- tai internetina.
TietoEnatorin Tomi Tuominen piti loistavan, osuvalla kriittisellä huumorilla höystetyn esityksen www-sovellusturvallisuudesta. Hänen mukaansa ensimmäinen tietokonebugi löytyi vuonna 1945, jolloin koi oli tarttunut releeseen. Tilanne raportoitiin huolellisesti eikä enää toistunut.
Www-sovellusturvallisuudessa kaikki lähtee tarvemäärittelystä, joten tietoturvaihmisen pitää olla mukana alusta asti. On liian myöhäistä pyytää häntä tarkistamaan järjestelmää enää käyttöönoton kynnyksellä.
Tässä on Tomi Tuomisen esityksestä poimittuja herkullisia paloja.
* Sovellusturvallisuuden kannalta on olennaista, että järjestelmä sisältää vain tarpeellisen toiminnallisuuden.
* Pidetään asiat yksinkertaisina.
* Jos jokin on todettu hyväksi, sitä kannattaa uudelleenkäyttää.
* Sanat ”safety” ja ”security” suomennetaan molemmat samalla tavalla, mutta niiden ero on hyvä ymmärtää. Safety tarkoittaa, että kun tulee sähkökatko, niin lukot aukeavat, security taas, että ne pysyvät kiinni.
* Turvallisuusratkaisuja pitää arvioida taloudellisesti: kolmen euron kohteen suojaamiseen ei kannata käyttää kymmentä euroa – paitsi ehkä puolustusvoimissa.
* Suhteellisuudentajua ei pidä unohtaa: Setelipaino ja Mellunmäen R-kioski tarvitsevat erilaista tietoturvaa.
* Toteutuksessa sovellusturvallisuuden kannalta on olennaista, että tarkastetaan syöte ja tulos.
* Useimmat pystyvät lukemaan html-koodia, harvat hexakoodia.
* Sovellusturvallisuudessa kannattaa hyödyntää sipulimallia: rakennetaan monta kerrosta niin, että niistä läpi yrittävää rupeaa itkettämään.
* On syytä luopua ”tätä ei kukaan keksi” -ajattelutavasta. Maailmassa on liikaa ihmisiä, joilla ei ole elämää ja jotka kokeilevat kaikkea.
* Kriisitilannetta varten pitää laatia selviytymissuunnitelma: jos kaikki menee totaalisesti pieleen, niin miten siitä selvitään.
* Jos autentikointi hoidetaan palvelimella, niin sovellus ei milloinkaan ole turvallinen.
* Http on tilaton protokolla: kun käyttäjä heittää kysymyksen, vastaus tulee heti, eikä vastaaja enää tiedä, mitä on kysytty.
* Saatavuus- ja turvavaatimukset asettavat reunaehdot rakennettavalle sovellukselle.
Tomi Tuominen esitti html-, java- ja php-koodiesimerkein, millaisia turvallisuusongelmia verkkopalveluissa käytännössä on esiintynyt. Hän näytti esim. virheilmoituksia, jotka eivät ole tavallisen käyttäjän kannalta kovin informatiivisia, mutta tunkeutujalle kultakaivoksia. Hän totesikin tietoturvan alkavan siitä, että tiedetään, mitä pitää suojata.
Lisää tietoa www-sovellusturvallisuudesta on OWASP:in verkkopalvelussa http://www.owasp.org/. Tomi Tuominen totesi, että mistään ei saa rahallakaan parempaa.
Sakari Olli Tieturilta pohti, onko SOA ajattelutapa vai teknologia. Hän johdatteli aiheeseen kuvaamalla, miten tavallisella käyttäjällä on työasemassaan useita sovelluksia auki yhtaikaa tai yrityksellä on useita järjestelmätoimittajia ja syntyneen sekamelskan hallinta on vaikeaa.
SOA (Service Oriented Architecture) on asioiden yhdistämistä liiketoimintaprosessien mukaisesti, missä ei sinänsä ole mitään uutta. Jo viisi vuotta sitten järjestelmiä voitiin yhdistää, mutta se oli kallista erilaisten toimittajien ja yhdistämistekniikoiden (esim. CORBA) vuoksi.
Nykyään on helppoja alustariippumattomia tekniikoita, kuten XML-pohjainen WebService, joilla järjestelmiä voidaan liimata toisiinsa. Avoimet ratkaisut ovat muuttuvassa maailmassa tärkeitä ja yksinkertaisimmat voittavat aina. Vaikka tänään tuntuisi siltä, että yrityksen sisällä kaikki toimii ongelmitta, niin tilanne voi olla toinen fuusion jälkeen huomenna.
SOA-ajattelun takana on järjestelmäintegraatio. Palvelut ovat tilattomia. SOA-protokolla standardoi tavan, miten palvelupyyntö kapseloidaan, kun se siirtyy sovellukselta toiselle. SOA on avointa ja Sakari Ollin mukaan todennäköisesti hyvin tuettua myös tulevaisuudessa, joten sen kanssa ollaan vahvalla pohjalla.
Sakari Olli korosti, että kaiken, mitä rakennamme, pitää tukea liiketoimintaa. SOA huolehtii integroinnista, korkeamman tason palveluiden tarjoamisesta käyttäjälle.
Jari Isokallio TietoEnatorilta pohti, ovatko yritysarkkitehtuurit hypeä vai asiaa. Tänä päivänä liiketoiminta ja tietotekniikka yhdistyvät ja kaikki perustuu liiketoimintastrategioihin. Mallit ovat kommunikointivälineitä, työkaluja, joilla yritysarkkitehtuuria eli EA:ta (Enterprise Architecture) kehitetään. Mallit kertovat, mitä pitää olla olemassa, mutta eivät ota kantaa siihen, miten se tehdään.
Yrityksen arkkitehtuurit, liiketoiminta-, informaatio-, järjestelmä- ja teknologia-arkkitehtuuri, kuvaavat eri asioita ja niiden vaikutusalueet pitää määritellä.
Eräs tapa kehittää yritysarkkitehtuuri on lähteä nykytila-analyysista, jossa analysoidaan nykyinen liiketoiminta ja tietojärjestelmät. Tämän jälkeen kuvataan tavoitearkkitehtuuri analysoimalla ja kehittämällä liiketoimintaprosesseja, ja johdetaan tietojärjestelmät. Lopuksi laaditaan kehittämissuunnitelma.
Maailmalla on olemassa raskaita malleja yritysarkkitehtuurin kehittämiseen, mutta niitä ei tarvitse käyttää sellaisinaan vaan soveltaa menetelmiä tarvittaviin osa-alueisiin. Kehitystyö voi edetä ylhäältä alas (top-down) tai alhaalta ylös (bottom-up). Edellisessä onnistumistodennäköisyys on suurempi. Jos rahaa olisi riittävästi, niin paras tapa olisi soveltaa molempia lähestymistapoja.
Jari Isokallio on joissain yrityksissä törmännyt siihen, että yritysarkkitehtuuri on kyllä olemassa, mutta sitä ei käytetä mihinkään. Silti se halutaan päivittää ajan tasalle. Niinpä yritysarkkitehtuurin hallintamalli pitäisi pitää mahdollisimman yksinkertaisena, kevyenä ja ketteränä. Tykillä ei kannata ampua hyttystä.
Jari Isokallio kertoi muutaman esimerkin yritysarkkitehtuurin kehittämisestä.
* Fuusion jälkeen tehdään esitutkimus, karsitaan kohdeorganisaation toimintojen päällekkäisyydet ja kuvataan tavoitetila.
* Järjestelmäsukupolven vaihdos tehdään liiketoiminnan ehdoilla ja otetaan huomioon kaikki tasot.
Lopuksi Jari Isokallio kertoi, että jokainen yritysarkkitehtuuri, jota hän on ollut kehittämässä, on ollut yksilöllinen. Yrityksillä on omat liiketoimintastrategiansa ja -tavoitteensa, eikä muiden arkkitehtuureita voida suoraan hyödyntää.
Aali Alikoski kertoi järjestelmien mallinnuksesta Microsoftin Software Factories -välineillä. Virtuaalitiimeissä viestintä eri roolien välillä on ongelmallista. Työvälineiden pitäisi vähentää sovellusten monimutkaisuutta, olla integroituja ja mahdollistaa tiimin yhteistoiminta, muokkaus ja laajentaminen. Aali Alikoski demosi mallinnusta Visual Studio 2005 Team System -ohjelmistolla.
Aija Palomäki käytti runsaasti fingelskaa esitellessään Nokian omaa yritysarkkitehtuuria. Projektinhallintamenetelmät kertovat, kuka raportoi kenelle ja missä on vastuu, kun eri yksiköt kehittävät yritysarkkitehtuuria.
Kaikki alkaa liiketoimintaprosessien ymmärtämisestä: millaisia prosesseja yrityksessä on ja mitä tietoja ne välittävät toisilleen. Lopuksi ulkopuolinen konsultti mittaa eri osa-alueiden tietohallinnon kypsyyttä. Arvioinnissa katsotaan, miten on onnistuttu ymmärtämään yrityksen nykyiset ja tulevat tietotarpeet. Aija Palomäen näyttämä esimerkki osoitti, että tieto liikkuu hyvin prosessin sisällä, mutta heikosti prosessien välillä.
Sivu päivitetty 28.9.05
Eija Kalliala, [email protected]
Eijan sivuston alkuun
Vastaa