Hajautettujen järjestelmien hajautettu kehittäminen

1 Hajautettujen järjestelmien hajautettu kehittäminen M. Lampi Tiivistelmä Tässä tutkimuksessa esitetään hajautetun kehittämisen toteutusteknologioille ja arkkitehtuuriratkaisuille asettamia haasteita, muodostetaan niiden avulla joukko arviointikriteerejä ja vertaillaan kahta yleisesti tunnettua hajautettujen järjestelmien toteutusteknologiaa, CORBA ja Web Services, näitä arviointikriteereitä vastaan. Arviointikriteerit muodostettiin hajautetun kehittämisen kirjallisuudesta löydettyjen yleisimpien ongelmakenttien avulla. Löydetyt ongelmakentät olivat: Kommunikaatio, Projektin koordinointi, Resurssien allokointi ja työn jakaminen ja Asiantuntemuksen hallinta. Tämän jälkeen etsittiin kirjallisuudesta niihin liittyviä arkkitehtuurisia haasteita, joiden pohjalta muodostettiin arviointikriteerit. Arviointikriteereitä muodostettiin neljä kappaletta: Arkkitehtuurimalli, Dokumentointi, Alustariippumattomuus, Suunnittelumenetelmät ja Design patternit. Valitut teknologiat arvioitiin näiden kriteerien suhteen. Arvioinnin tuloksena todettiin, että nämä teknologiat ovat tässä suhteessa hyvin samanlaisia, molemmilla on hyvä arkkitehtuurituki hajautettujen järjestelmien hajautettuun kehittämiseen ja molempia teknologioita voidaan käyttää useissa erilaisissa ympäristöissä. Tutkimuksessa löytyi kuitenkin joukko pienempiä eroavaisuuksia, jotka tietyissä olosuhteissa tulevat hyvinkin ratkaiseviksi, esimerkiksi asennukset ja dokumentointi. Avainsanat Hajautettu kehittäminen, hajautetut järjestelmät, CORBA, Web Services A. Tausta I. JOHDANTO Nykyaikaiset komponenttiteknologiat mahdollistavat järjestelmien tehokkaan hajauttamisen ja järjestelmien hajauttaminen on myös hyvin yleistä. Järjestelmien kehittäminen tapahtuu usein hajautetusti organisaation sisäisesti, yhteistyökumppaneiden tai tytäryhtiöiden kanssa. Alalla vallitseva tilanne, joka ajaa pieniä yhtiöitä yhteen ja ulkoistamaan kehittämisen, lisää hajautetun kehittämisen tarvetta entisestään. Tutkimuksen tarkoituksena on selvittää, miten erilaisten teknologioiden arkkitehtuurimallit ja näihin liittyvät tunnetut suunnittelumenetelmät vastaavat tähän kasvavaan tarpeeseen. B. Tutkimusongelma Tutkimusongelma voidaan ilmaista seuraavan kysymyksen muodossa: Miten hajautettujen järjestelmien toteutusteknologiat ja niiden arkkitehtuurit soveltuvat hajautettuun kehittämiseen? Tutkimusongelman ratkaisemiseksi työssä pyritään etsimään vastauksia myös seuraaviin kysymyksiin: Minkälaisia vaatimuksia hajautettu kehittäminen asettaa järjestelmäarkkitehtuureille? Minkälaisia ovat hajautettujen järjestelmien kehittämisessä käytettävien teknologioiden arkkitehtuuriratkaisut? C. Tavoitteet Tutkimuksen tavoitteena on selvittää, kuinka hyvin hajautetut järjestelmät soveltuvat hajautettuun kehittämiseen. Tutkimuksessa käsiteltävät toteutusteknologiat mahdollistavat järjestelmien tehokkaan hajauttamisen, mutta näiden samaisten arkkitehtuurien soveltuminen hajautettuun kehitykseen on asia, johon tämä tutkimus yrittää vastata. D. Rajaukset Tutkimuksessa käsitellään yleisimpiä hajautettujen järjestelmien kehittämiseen soveltuvia toteutusteknologioita. Muut toteutusteknologiat rajataan tämän tutkimuksen piiristä. Mielenkiintoisia näistä toteutusteknologioista tekee se, että ne ovat yleisesti melko tunnettuja, paljon käytettyjä, kilpailevat keskenään samoista markkinoista ja ovat usein mukana yritysten teknologiavalinnoissa. Tutkimuksessa keskitytään valittujen toteutusteknologioiden arkkitehtuurien ja niiden suunnittelumenetelmien kartoittamiseen ja analysointiin hajautetuissa järjestelmissä, muut toteutusteknologiat ja arkkitehtuurit ja niiden soveltuvuus hajautettuun kehittämiseen eivät kuulu tämän tutkimuksen piiriin. E. Käytettävät tutkimusmenetelmät Tutkimus suoritetaan kirjallisuuskatsauksena ja empiirisenä tutkimuksena. Aluksi tutkitaan hajautetun kehittämisen ongelmia ja niiden arkkitehtuureille asettamia vaatimuksia kirjallisuuskatsauksen avulla. Tämän jälkeen empiirisessä osassa muodostetaan katsauksen pohjalta arviointikriteerit, joiden avulla arvioidaan seuraavassa osiossa esitettävien toteutusteknologioiden ja suunnittelumenetelmien soveltuvuutta hajautettuun kehittämiseen. Näiden kahden osan perusteella analysoidaan teknologioiden sopivuutta hajautettuun kehittämiseen vertaamalla valittujen toteutusteknologioiden arkkitehtuuriratkaisuja ja suunnittelumenetelmiä muodostettuihin arviointikriteereihin. Lopuksi kerätään saadut tulokset yhteen.

2 II. HAJAUTETTU KEHITTÄMINEN JA ARKKITEHTUURI A. Hajautettu kehittäminen Puhuttaessa hajautetusta kehittämisestä tarkoitetaan usein varsin eri asioita, eikä termin yksiselitteinen määrittely ei ole helppo tehtävä. Hajautetulla kehittämisellä voidaan yksinkertaisimmillaan tarkoittaa sitä, että kehittämisorganisaatio on maantieteellisesti hajautettu (Herbsleb et al., 2001). Toinen, hieman kattavampi määrittely on, että kehittämisen ei tarvitse olla maantieteellisesti hajautettua, vaan myös saman talon eri kerroksissa tai jopa saman käytävän eri päissä tapahtuvaa kehittämistä voidaan ajatella tietyllä tavalla hajautetuksi kehittämiseksi(herbsleb et al., 2001). Yksi määrittely, ohjelmiston kehittämistavasta riippuva, käsittää hajautettuna kehittämisenä kehitystyön, jossa järjestelmä kehitetään hajautetussa ympäristössä. (Sugiyama, 2000). Tässä kirjallisuuskatsauksessa tarkoitetaan hajautetulla kehittämisellä kehittämistä, joka tapahtuu sellaisessa ympäristössä ja olosuhteissa, että kehittäjät eivät voi työskennellä samassa paikassa samaan aikaan. B. Hajautetun kehittämisen haasteet Hajautettua kehittämistä käsittelevästä kirjallisuudesta löytyy suuri joukko erilaisia haasteita. Tässä tutkimuksessa otettiin tarkasteltavaksi neljä yleistä ongelmakenttää ja niihin liittyvät haasteet. Kirjallisuudesta (Herbsleb et al., 2000; Mockus et al., 2001; Herbsleb et al., 2001; Battin et al., 2001) löydettyjen yleisten hajautetun kehittämisen ongelmien joukosta valittiin nämä neljä ongelmakenttää sillä perusteella, että näihin liittyviin haasteisiin voidaan oletettavasti vaikuttaa teknologiavalinnoilla, arkkitehtuuriratkaisuilla ja suunnittelumenetelmillä. Tarkasteltavaksi valitut ongelmakentät: 1. Kommunikaatio 2. Projektin koordinointi 3. Resurssien allokointi ja työn jakaminen 4. Asiantuntemuksen hallinta Seuraavissa kappaleissa käsitellään näitä ongelmakenttiä ja niistä löytyviä haasteita. 1) Kommunikaatio Useat lähteet kuvaavat kommunikaation yhdeksi suurimmaksi ja eniten vaikeuksia tuottavaksi haasteeksi hajautetussa kehittämisessä (Ebert, 2001; Herbsleb et al., 2001; Paasivaara, 2003). Paasivaara (2003) esittää neljä luokkaa, joihin kommunikaatio voidaan jakaa, 1) ongelmien ratkaisu, 2) tiedotus ja valvonta, 3) suhteiden luonti ja 4) päätösten tekeminen ja koordinointi. Näistä neljästä luokasta yritetään luokkiin 1, 2 ja 4 etsiä arkkitehtuurisia vaikutustapoja. Kommunikaatioon liittyvät haasteet aiheuttavat hajautetuissa projekteissa monia ongelmia, joista tässä esitetään näihin kolmeen valittuun luokkaan liittyvät yleisimmät ongelmat. Luokkaan 1, ongelmien ratkaisu, liittyy oikean henkilön löytäminen (Herbsleb et al., 2001; Paasivaara, 2003). Tämä on erityisen yleistä hajautetuissa projekteissa, koska hajautetuista projekteista puuttuu epävirallinen kommunikaatio, jonka avulla tieto projektiin osallistuvien henkilöiden erityisosaamisista leviää organisaatiossa (Herbsleb et al., 2001). Tämän kanavan puuttuminen aiheuttaa viivettä oikean henkilön löytämiseen ja ongelman ratkaisuun. Toinen ongelma on vastauksen saamiseen kuluva aika. Koska hajautetussa kehittämisessä oikea henkilö voi olla hyvinkin kaukana ja työskennellä eri vuorokauden aikaan, aiheutuu tästä vastauksen saamiseen merkittävä lisäviive (Herbsleb et al., 2000). Luokkaan 2, tiedotus ja valvonta, liittyy muutoksista ja projektin etenemisestä tiedottaminen ja etenemisen valvonta (Herbsleb et al., 2001). Varsinkin muutoksista tiedottamista pidetään erityisen ongelmallisena, koska niiden tiedottaminen formaalien dokumenttien kautta on vaikeaa (Mockus et al., 2001). Epävirallisen kommunikaation puute vaikuttaa vahvasti myös tähän ongelmaan, koska tiedot muutoksista yms. Projektiin liittyvistä asioista leviävät usein juuri tällaisten käytäväkeskustelujen kautta (Herbsleb et al., 2000). Myös projektin etenemisen seuranta ja projektin eri jäsenten tietous projektin tilasta vaikeutuu epävirallisen kommunikaation puuttuessa, koska suuri osa tällaisesta informaatiosta välittyy juuri tämän kanavan kautta lokaalisti tapahtuvissa projekteissa, varsinkin silloin kun on kyseessä nopeasti muuttuvat olosuhteet ja epästabiilit projektit (Kraut et al., 1995). Viimeiseen tässä käsiteltävään luokkaan, luokkaan 4, liittyy haasteina vastuiden jakaminen hajautettujen resurssien ja organisaatiotasojen kesken, oikeiden henkilöiden löytäminen päätöksiä tehtäessä ja näistä päätöksistä tiedottaminen (Herbsleb et al., 2000; Herbsleb et al., 2001b; Paasivaara, 2003). 2) Projektin koordinointi Koordinointiin liittyy kolme projektin tuotteeseen vahvasti liittyvää ongelmaa, arkkitehtuuri, integrointi ja konfiguraatioiden hallinta (Battin et al., 2001). Varsinkin silloin, kun tehdään monimutkaisia projekteja tai osa projektiin kuuluvista resursseista ei tunne projektin käsitteitä ennestään, arkkitehtuurin tekeminen ymmärrettäväksi ja tiedon jakaminen on suuri haaste (Battin et al., 2001). Projektin tuloksena tulevan ohjelmiston integrointiin liittyy ongelmia silloin, kun tuotteen kehittäminen tapahtuu hajautetusti. Kun tuotetta kehitetään samanaikaisesti useassa paikassa, kasvaa integrointityön suorittamiseen tarvittava työmäärä (Battin et al., 2001). Myös konfiguraatioiden hallinta muuttuu monimutkaisemmaksi silloin, kun projektin tuotteen osista on useita eri paikoissa olevien ihmisten tekemiä versioita (Battin et al., 2001). Projektiin liittyy myös joukko muita koordinointiin liittyviä ongelmia. Yksi näistä on eri kehityspaikkojen prosessien eroavaisuudet. Ongelmia syntyy, jos esimerkiksi eri yksiköt ovat määritelleet yksikkötestauksen eri tavalla (Mockus et al., 2001). Kun tuotetta kehitetään hajautetusti, tulee ongelmaksi

3 eri tuotosten riippuvuuksien hallinta. Kun yksi yksikkö on myöhässä, saattaa se vaikuttaa muiden yksiköiden työn etenemiseen tai tuotteen integrointiin haitallisesti (Mockus et al., 2001). 3) Resurssien allokointi ja työn jakaminen Vaikka resurssien ja työn jakamisen voi sisällyttää myös osaksi koordinointia, käsitellään sitä tässä erillisenä ongelmana sen vakavuuden vuoksi ja siksi, että oletettavasti projektin tuotteen arkkitehtuuri vaikuttaa tähän asiaan mielenkiintoisella tavalla. Suurimpia haasteita tässä kohdassa on projektin tuotteen jakaminen itsenäisiin osajärjestelmiin, työtehtävien allokointi tiimeille, tiimien välisten riippuvuuksien hallinta ja projektin tuotteen laadun ja yhtenäisyyden varmistaminen (Ebert et al., 2001; Battin et al., 2001; Mockus et al., 2001b). Projektin tuotteen järkevää jakamista itsenäisiin osajärjestelmiin pidetään haastavana ja keskeisenä asiana (Repenning et al., 2001; Mockus et al., 2001b) hajautetussa kehittämisessä. Jos tätä ei onnistuta tekemään, johtaa se ylimääräiseen kommunikaation ja koordinoinnin tarpeeseen (Repenning et al., 2001). Työtehtävien allokoinnissa tiimeille haasteena on saada työtehtävät jaettuna tiimeille siten, että ne vastaavat kyseisen tiimin taitotasoa (Battin et al., 2001) ja että niillä on mahdollisimman vähän riippuvuuksia muiden tiimien työn etenemisestä. Onnistunut työtehtävien allokointi tiimien kesken vähentää tiimien välisen kommunikaation tarvetta ja siitä projektiin aiheutuvia viiveitä (Herbsleb et al., 2001b). Hajautetussa kehittämisessä tiimien väliset riippuvuudet tulisi pyrkiä minimoimaan turhan tiimien välisen kommunikaation ja siitä aiheutuvan viiveen takia (Herbsleb et al., 2001b). Riippuvuuksia tiimien välille aiheuttavat edellisten kohtien lisäksi vastuiden ja tietotaidon jakautuminen (Herbsleb et al., 2001). Myös tuotteen laadun ja yhtenäisyyden hallinta on eräs hajautetun kehityksen haasteista. Koska kehitys tapahtuu hajautetusti, tulee projektin tuotteen eri osajärjestelmien arkkitehtuureista helposti erilaisia. Tämä vaikuttaa tuotteen arkkitehtuurin yhtenäisyyteen, laatuun ja uudelleenkäytettävyyteen (Battin, 2001). 4) Asiantuntemuksen hallinta Myös asiantuntemuksen hallintaan liittyy paljon haasteita, kun kehitys hajautetaan. Aikaisemmat tutkimukset osoittavat yleisimmiksi ongelmiksi tiimien välisen luottamuksen rakentaminen ja säilyttämisen (Kiel, 2003), riittävän suunnitteludokumentaation tuottamisen ja sen jakamisen, integrointiin liittyvät kysymykset ja tiimien välisen asiantuntemuksen välittämisen ja asiantuntemuksen löytämisen (Nakamura, 1997; Battin, 2001; Herbsleb et al., 2001b). Asiantuntemuksen hallintaan liittyy myös strateginen puoli, eli asiantuntemuksen hallintaan vaikuttavat vahvasti myös yrityksen strategiset tekijät varsinkin silloin, kun projekti toteutusvaihe ulkoistetaan kokonaan tai osittain toiselle yritykselle (Muller et al., 2000). Tiimien välisen luottamuksen rakentaminen ja säilyttäminen on tärkeää kaikenlaisissa projekteissa, ja hajautetuissa projekteissa tämän luottamuksen muodostaminen ja säilyttäminen on erityisen vaikeaa aikaerojen, kielierojen, kulttuuristen eroavaisuuksien ja eriarvoisuuden johdosta (Kiel, 2003). Luottamuksen puute vaikuttaa erittäin haitallisesti tiimeissä tehtyjen päätösten ja suunnitelmien siirtämiseen toisiin tiimeihin, koska ilman luottamusta toisen tiimin jäsenten tietotaitoon on erittäin vaikea hyväksyä sieltä tulevia päätöksiä ilman kattavaa taustatietoa (Kiel, 2003). Tuote- ja suunnitteludokumentaation tuottaminen ja sen saavutettavuus hajautetussa kehittämisessä voidaan jakaa kolmeen päähaasteeseen(nakamura, 1997): 1. suunnittelutiedon jakaminen kehittämisyksiköiden ja kehittäjien kesken 2. suunnittelutiedon uudelleenkäyttö seuraavissa projekteissa 3. tuotteen laadun varmistaminen suunnittelutiedon avulla Tärkeää näissä kaikissa kohdissa on erityisesti se, että saatavilla oleva tieto on ajan tasalla. Suunnittelu- ja tuotedokumentaation jakaminen eri paikoissa sijaitsevien tiimien kesken on usein vaikeaa ja aikaa vievää toimintaa. Aikaa käytetään paljon pelkästään siihen, että yritetään päättää keskustellaanko tiimien kesken edes samasta asiasta (Mockus et al., 2001). Tuotteen laadun varmistamiseen suunnittelutiedon avulla taas vaikuttaa eri tiimien tuottaman dokumentaation yhteneväisyys ja tarkkuus. Integrointiin liittyvät kysymykset ovat hajautetussa kehittämisessä haastavia, koska tuotteen osien integrointi vaatii usein eri tiimien kehittäjien erityisosaamista. Tämä erityisosaaminen on jakautunut ja siitä aiheutuu ylimääräistä kommunikaatiotarvetta ja viiveitä integrointia tehtäessä (Herbsleb et al., 2001b). Erityisen epämiellyttäväksi tämän tilanteen tekee se, että aikaisemman tutkimuksen mukaan hajautetuissa projekteissa integrointiin tarvittava työmäärä on selkeästi suurempi kuin lokaalisti tapahtuvissa projekteissa (Battin et al., 2001). Asiantuntemuksen välittäminen ja oikeanlaisen asiantuntemuksen löytäminen vaikeutuu hajautuksen mukana varsinkin epävirallisen kommunikaation puutteen vuoksi. Kun ei tiedetä, keneen täytyy missäkin asiassa ottaa yhteyttä, syntyy projektiin turhia viiveitä ja tehdään vääriä olettamuksia (Herbsleb et al., 2001; Herbsleb et al., 2001b). Lokaalisti tapahtuvissa projekteissa tiimien jäsenet voivat oppia tarvittavaa asiantuntemusta suoraan kyseisen asiantuntemuksen omaavalta henkilöltä, mutta hajautetuissa projekteissa asiantuntemus on myös hajaantunut ja kommunikaation vähyydestä ja viiveistä johtuen asiantuntemuksen tehokas siirtäminen on vaikeaa (Battin, 2001). C. Yhteenveto haasteista Kuten edelliset kappaleet osoittavat, kirjallisuudesta löytyy

4 suuri joukko erilaisia hajautetun kehittämisen ongelmakohtia ja niihin liittyviä haasteita. Tässä tutkimuksessa ei yritetty kerätä kattavaa joukkoa erilaisista haasteista, vaan tarkoituksena oli kerätä joukko yleisimpiä ongelmia ja haasteita, joihin oletettavasti pystytään vaikuttamaan ainakin jonkin verran projektin tuotteeseen liittyvillä teknologia- ja arkkitehtuurivalinnoilla sekä kirjallisuudesta löytyvillä suunnittelumenetelmillä. Taulukko 1 esitetään yhteenveto edellisissä kappaleissa kuvatuista ongelmakohdista johdettu yhteenveto niihin liittyvistä haasteista. Tätä joukkoa käytetään jatkossa pohjana etsittäessä teknologian, arkkitehtuuriratkaisujen sekä suunnittelumenetelmien mahdollisuuksia tukea hajautettua kehittämistä. Taulukko 1 Hajautetun kehittämisen ongelmia ja niihin liittyviä haasteita Ongelmakenttä Ongelmakenttään liittyvät haasteet Kommunikaatio Ongelmien ratkaisu, oikean henkilön löytäminen ja kommunikaation viive Tiedotus ja valvonta, erityisesti muutoksista tiedottaminen Päätösten tekeminen ja koordinointi, vastuiden jakaminen ja päätöksistä tiedottaminen Projektin Arkkitehtuuri, arkkitehtuurin koordinointi saaminen yleisesti ymmärrettäväksi Integrointi, integrointiin kuluvan ajan ja resurssitarpeen minimointi Konfiguraatioiden hallinta, varsinkin useiden itsenäisten komponenttien versioiden, muutosten ja yhteensopivuusasioiden hallinta Prosessien eroavaisuudet Tiimien tuotosten riippuvuudet, työn suunnittelu siten, että eri tiimien tuotokset ja niiden Resurssien ja työn jakaminen aikataulumuutokset vaikuttavat mahdollisimman vähän muiden tiimien työn etenemiseen Tuotteen jakaminen itsenäisiin osajärjestelmiin Työtehtävien allokointi tiimeille, taitotason ja työtehtävien riippuvuuksien hallinta Tiimien väliset riippuvuudet Tuotteen laatu ja yhteneväisyys, arkkitehtuurin tekninen yhteneväisyys, uudelleenkäytettävyys Asiantuntemuksen hallinta Tiimien välisen luottamuksen kehittäminen ja ylläpito, tiimien välinen päätösten ja muiden tuotosten siirto Tuote- ja suunnitteludokumentaation tuottaminen ja saatavuus, ajantasaisuus ja yhteneväisyys Tuotteen integrointi, varsinkin integroinnin työmäärä ja kommunikaatio Asiantuntemuksen välittäminen ja tiimien välillä ja oikeanlaisen asiantuntemuksen löytäminen D. Hajautetun kehittämisen tukeminen teknologiavalinnoilla, arkkitehtuuriratkaisuilla ja suunnittelumenetelmillä Kun aloitetaan projektin suunnittelu, jossa käytetään hajautettua kehittämistä, on projektin johdolla edessään paljon avoimia asioita. Näitä ovat esimerkiksi (Muller, 2000): Hajautusstrategiasta päättäminen Projektin seurantamenetelmistä päättäminen Kommunikaatiotavoista päättäminen Vastuiden ja vastuuhenkilöiden päättäminen Toteutusteknologian valinta Tässä tutkimuksessa keskitytään valitun toteutusteknologian, arkkitehtuuriratkaisujen ja suunnittelumenetelmien mahdollisuuksiin vaikuttaa edellä esitettyihin hajautetun projektin ongelmakohtiin. Nämä kolme asiaa liittyvät toisiinsa kiinteästi, koska valittu teknologia rajoittaa mahdollisia arkkitehtuuriratkaisuja ja suositeltuja suunnittelumenetelmiä. Tästä syystä tutkimuksessa pyritään ensin määrittelemään hajautettua kehittämistä tukevan arkkitehtuurin ominaisuudet, jonka jälkeen voidaan tutkia valittujen teknologioiden soveltuvuutta hajautettuun kehittämiseen. Seuraavissa kappaleissa käsitellään Taulukko 1 Hajautetun kehittämisen ongelmia ja niihin liittyviä haasteita esitettyjä ongelmakenttiä ja etsitään arkkitehtuuriin ja suunnittelumenetelmiin liittyviä tapoja vaikuttaa näihin ongelmiin. Yksi asia, johon tulevissa kappaleissa kiinnitetään huomiota, on eri teknologioille ja arkkitehtuurimalleille löytyvät design patternit, eli yleisesti tunnetut, dokumentoidut ja todistettavasti toimivat arkkitehtuuriratkaisut (Gamma et al., 1997). 1) Kommunikaatio Kommunikaatio on ongelmakenttä, johon löytyy useita erilaisia tapoja vaikuttaa teknologian, arkkitehtuuriratkaisujen ja suunnittelumenetelmien avulla. Tehokkaimmin kommunikaatiosta hajautetussa kehittämisessä aiheutuvia ongelmia voidaan estää minimoimalla tiimien välinen

5 kommunikointi suunnittelemalla tuotteen arkkitehtuuri siten, että se koostuu mahdollisimman itsenäisistä alijärjestelmistä ja että näiden väliset rajapinnat ovat mahdollisimman tarkasti, yksiselitteisesti ja yhtenäisesti kuvattu ja dokumentoitu (Repenning, 2001; Herbsleb, 2001b) Näistä ominaisuuksista voidaan johtaa teknologialta ja arkkitehtuurilta kaivattuja ominaisuuksia/vaatimuksia: Teknologian tarjoamat arkkitehtuurimallit mahdollistavat tuotteen koostamisen useista erillisistä komponenteista, jotka voivat sijaita eri paikoissa. Teknologia ja taustalla olevat arkkitehtuurimallit mahdollistavat tehokkaita tapoja luoda rajapintoja komponenttien välille. On olemassa sellaisia design patterneita, joiden avulla voidaan toteuttaa komponenttien välisten riippuvuuksien vähentämistä ja rajapintoja tehokkaasti. Teknologia tarjoaa suunnitelmien ja toteutuksen dokumentointiin valmiit ratkaisut, joita on helppo käyttää ja jotka mahdollistavat yhtenäisen dokumentaation tuottamisen ja nopean jakamisen tiimien välillä. Dokumentoinnin yhteydessä on erityisen tärkeää, että toteutuksen aikana tuotettava dokumentaatio, esim. ohjelmakoodin kommentit, voidaan mahdollisimman helposti koostaa yhtenäiseksi, luettavaksi dokumentiksi. Toinen tärkeä tekijä on se, että toteutusvaiheessa tulevat muutokset voidaan mahdollisimman helposti päivittää suunnitelmadokumentaatioon. 2) Projektin koordinointi Projektin koordinoinnin ongelmiin löytyy myös teknologiaan ja arkkitehtuuriin liittyviä ratkaisuita, varsinkin aikaisemmin kuvattuihin projektin tuotteeseen liittyviin ongelmiin: arkkitehtuuri, integrointi ja konfiguraatioiden hallinta (Battin et al., 2001). Arkkitehtuurin ymmärrettävyysongelmiin voidaan vaikuttaa kommunikoimalla arkkitehtuurista yleisten design patterien ja yleisesti tunnettujen kuvauskielien avulla (Gamma et al., 1997). Integroinnin ongelmiin voidaan vaikuttaa rakentamalla tuote keskittymällä komponenttien riippumattomuuteen ja hajautuksen helppouteen, eli eri paikoissa tehtyjen moduulien helppoon integrointiin toimivaksi kokonaisuudeksi. Suunnittelemalla järjestelmä siten, että se koostuu mahdollisimman itsenäisistä komponenteista, voidaan vähentää myös tiimien aikataulujen riippuvuuksia toisistaan ja niistä johtuvia viiveitä (Mockus et al., 2001). Konfiguraatioiden hallinnan kannalta on tärkeää se, miten hyvin arkkitehtuurin/teknologian avulla voidaan määritellä tietyssä installaatiossa käytettävä versio ja voiko komponentin versioita olla samanaikaisesti useampia asennettuna. Näistä asioista voidaan johtaa seuraavat toteutusteknologialta ja arkkitehtuurilta kaivatut ominaisuudet/vaatimukset, jotka vaikuttavat projektin koordinointiin: On olemassa joukko yleisiä design patterneita ja jokin yleisesti tunnettu kuvauskieli. Eri paikoissa toteutettujen komponenttien asentaminen ja yhdistäminen toisiinsa on oltava helppoa, ja on mahdollista hallita useita versioita samoista komponenteista yhtä aikaa. Teknologia tarjoaa suunnitelmien ja toteutuksen dokumentointiin valmiit ratkaisut, joita on helppo käyttää ja jotka mahdollistavat yhtenäisen dokumentaation tuottamisen ja nopean jakamisen tiimien välillä. Teknologia ei ole alustariippuvainen, ts. Eri tiimit voivat käyttää eri työkaluja ja toteutusympäristöjä. 3) Resurssien ja työn jakaminen Tästäkin ongelmakentästä löytyy paljon aikaisempaa tutkimustietoa. Aikaisemmin esitettyihin resurssien ja työn jakamiseen liittyviin haasteisiin, eli projektin tuotteen jakamiseen itsenäisiin osajärjestelmiin, työtehtävien allokointiin tiimeille, tiimien välisten riippuvuuksien hallintaan ja projektin tuotteen laadun ja yhtenäisyyden varmistamiseen löytyy myös muutama teknologiaan ja arkkitehtuuriin liittyvä vaikutusmahdollisuus. Projektin tuotteen osajärjestelmiin jakamiseen ja tiimien välisten riippuvuuksien hallintaan liittyvät asiat käsiteltiin jo edellisissä kappaleissa, joten niihin ei tässä oteta enää kantaa. Tietylle tiimille annettujen työtehtävien tulisi olla mahdollisimman itsenäisiä muiden tiimien työtehtävistä, joten tässäkin kohdassa vaatimuksena on mahdollisuus luoda itsenäisiä komponentteja tehokkaasti. Toinen, tässä kohdassa mielenkiintoisempi asia on tuotosten siirtäminen tiimien välillä. Tällä siirtämisellä tarkoitetaan: (Mockus et al., 2001) Toiminnallisuuden siirtämistä tiimiltä toiselle, eli siirretään jonkin tietyn komponentin tai osajärjestelmän vastuu toiselle tiimille Siirtäminen lokalisaation vuoksi, eli siirretään tuotos lokalisoitavaksi tietylle alueelle Siirtäminen tuotteen kehitysvaiheen mukaan, eli tuotteen kehittämisen eri vaiheet tapahtuvat eri paikoissa. Siirtäminen ylläpitovaiheeseen, eli siirretään esim. tuotteen vanhemmat versiot toiseen paikkaan ylläpidettäväksi. Näissä tapauksissa tulee erityisen tärkeäksi tuotteen dokumentointiin ja työkaluihin liittyvät asiat. Itse tuotteen siirtämiseen liittyy erityisesti alusta- ja työkaluriippumattomuus. Tästä ongelmakentästä voidaan siis johtaa seuraavia ominaisuuksia/vaatimuksia, jotka toteutusteknologian ja arkkitehtuurin tulisi täyttää: Dokumentoinnin tekeminen, työkalut ja menetelmät löytyvät valmiina. Tietotaidon jakaminen tehokkaan dokumentaation avulla ja yleisten ja yleisesti tunnettujen kuvaus ja dokumentointimenetelmien avulla on mahdollista.

6 Dokumentaation ajan tasalla pitäminen on helppoa. Projektin tuotetta voidaan käyttää ja kehittää erilaisissa ympäristöissä eikä sen osien siirtäminen ympäristöstä toiseen ole vaikeaa. 4) Asiantuntemuksen hallinta Asiantuntemuksen hallintaan ei kirjallisuudesta löytynyt juurikaan toteutusteknologiaan ja arkkitehtuuriin liittyviä tapoja vaikuttaa. Yleisimpiin edellä esitettyihin ongelmiin, kuten tiimien välisen luottamuksen rakentaminen ja säilyttäminen, riittävän suunnitteludokumentaation tuottaminen ja sen jakaminen ja tiimien välisen asiantuntemuksen välittäminen ja asiantuntemuksen löytäminen löytyi kuitenkin muutamia vaikutusmahdollisuuksia. Suunnitteludokumentaation jakamiseen liittyvät asiat johtavat edelleen dokumentaation tuottamisen ja päivittämisen työkaluihin ja menetelmiin, joka käsiteltiin jo tuotteen siirtämistä tiimien välillä tarkasteltaessa. Dokumentaatioon liittyvä asia on myös tuotteen laadun varmistaminen suunnittelutiedon avulla. Tämä on koko ajan enemmän käytetty tekniikka tuotteen laadun varmistamiseen ja vaatii tuotteen dokumentaatiolta yhtenäisen muodon, dokumentaatiota useista kehitysvaiheista ja yhteensopivuuden standardien kanssa (Nakamura et al., 1997). Asiantuntemuksen välittämiseen ja oikeanlaisen asiantuntemuksen löytämiseen ei teknologia/arkkitehtuuri juurikaan tarjoa apuvälineitä. Aikaisempien tutkimusten mukaan keino vaikuttaa tähän liittyy osajärjestelmien jakamiseen toiminnallisuuden perusteella itsenäisiin kokonaisuuksiin ja näiden osajärjestelmien vastuiden antaminen tiimeille/henkilöille(mockus et al., 2001; Ebert et al., 2001). Tällöin tiedetään ainakin, millä tiimillä pitäisi olla tietyn osajärjestelmän tietotaito hallussa ja osataan ottaa yhteyttä oikeaan tiimiin ongelman ilmetessä. Tiimien välisen luottamuksen rakentamiseen ei kirjallisuudesta löytynyt teknologiaan ja arkkitehtuuriin liittyviä vaikutustapoja. Toteutusteknologian/arkkitehtuurin vaikutusmahdollisuudet asiantuntemuksen hallintaan ovat varsin rajalliset. Tähän ongelmakenttään liittyy edellä esitettyjen asioiden perusteella seuraavat toteutusteknologian ja arkkitehtuurin ominaisuudet/vaatimukset: Dokumentaation tuottamiseen, ylläpitoon ja esittämiseen liittyvät vaatimukset, kuten kuvattu edellä kohdassa 3) Resurssien ja työn jakaminen. III. ARVIOINTIKRITEERIT Edellisen kappaleen perusteella voidaan huomata, että toteutusteknologialla on mahdollista vaikuttaa moniin yleisimpiin hajautetun kehittämisen ongelmiin. Vielä yllättävämpää on kuitenkin huomata, että tietty toteutusteknologian ja arkkitehtuurin ominaisuus voi vaikuttaa useisiin ongelmakenttiin samanaikaisesti, kuten esimerkiksi tuotteen jakaminen itsenäisiin osajärjestelmiin tai tuotteen dokumentointi. Nämä ominaisuudet toistuivatkin lähes jokaisen ongelmakentän tarkastelun yhteydessä. Taulukko 2 Arviointikriteerit on esitetty tässä tutkimuksessa käytettävät arviointikriteerit ja niiden yhteydessä huomioitavat ominaisuudet, jotka on kerätty edellä esitetyistä ongelmakenttäanalyyseista. Taulukko 2 Arviointikriteerit Arviointikriteeri Arkkitehtuurimalli Dokumentointi Painoarvo 4 Alustariippumattomuus Suunnittelumenetelmät, Design patternit Arvioinnissa huomioitavat ominaisuudet Komponenttien hajauttaminen Komponenttien väliset riippuvuudet, niiden minimointi, rajapintojen toteutusmahdollisuudet Komponenttien asentaminen ja yhdistäminen toisiinsa Komponenttien versioiden hallinta Komponenttien siirtäminen Dokumentaation tuottamisen menetelmät yhtenäisen dokumentaation tuottamiseen Dokumentaation jakamisen menetelmät Kuvauskielten soveltuvuus Dokumentaation päivittäminen Erilaiset kehittämistyökalut ja ympäristöt Tuotteen tai osien käyttäminen erilaisia ympäristöissä Yleisten suunnittelumenetelmien määrä Riippuvuuksien poistaminen Rajapintojen toteutus Seuraavissa kappaleissa arvioidaan valittuja teknologioiden ja niiden sovellusarkkitehtuurien soveltuvuutta hajautettuun kehittämiseen näiden arviointikriteerien avulla. Taulukko 2 Arviointikriteerit painoarvo sarake kuvaa kunkin ominaisuuden tärkeyttä arviointia tehtäessä. Tämä painoarvo on muodostettu sen perusteella, miten moneen ongelmakenttään kyseinen ominaisuus liittyy. 4 2 3

7 IV. ARVIOITAVAT TEKNOLOGIAT A. Hajautettu järjestelmä Hajautetulle järjestelmälle on olemassa useita määrittelyjä, tässä muutama (Hitchens, 2003): Hajautettu järjestelmä on joukko itsenäisiä tietokoneita, jotka näkyvät järjestelmän käyttäjälle yhtenä tietokoneena Hajautetussa järjestelmässä verkossa olevilla tietokoneilla sijaitsevat komponentit kommunikoivat ja koordinoivat toimiaan lähettämällä toisilleen viestejä Järjestelmä, joka koostuu useista tietokoneista Tämä voi siis tarkoittaa tilannetta, että järjestelmä on jakaantunut eri palvelimille ympäri maailman, tai sitten tilannetta, jossa järjestelmän osat sijaitsevat samalla palvelimella, mutta toimivat itsenäisinä sovelluksina. Myös tällöin on kyse hajautetusta järjestelmästä, koska komponentit ovat itsenäisiä kokonaisuuksia ja keskustelevat ja koordinoivat toimiaan välittämällä viestejä. Tässä tutkimuksessa keskitytään nimenomaan hajautettuihin järjestelmiin, joissa verkossa olevilla tietokoneilla sijaitsevat komponentit kommunikoivat ja koordinoivat toimiaan viestien avulla. B. Teknologioiden esittely Tarkasteltavat teknologiat jakautuvat kahteen pääjoukkoon: hajautettuihin olioihin perustuvat ja palvelulähtöiset teknologiat. Hajautettuihin olioihin perustuvat teknologioiden, kuten CORBA (Common Object Request Broker Architecture), perusideana on: (Plasil et al., 1999) Asiakas-olio(Client), joka haluaa saada jonkin asian tehtyä, kutsuu kauko-oliota (remote object, server object), joka tarjoaa tämän palvelun rajapintansa kautta. Palvelun käyttäminen tapahtuu luomalla palvelua tarjoavasta oliosta viite (remote reference) ORB-palvelun (Object Request Broker) avulla, jonka kautta asiakasolio voi kutsua tämän metodeja. Kutsuttavasta oliosta muodostetaan rajapinnat, jonka kautta tähän olioon viitataan, asiakkaan päässä se on stub ja palvelua tarjoavan objektin päässä skeleton. Kuva 1 CORBAn arkkitehtuuri Toinen pääjoukko, palvelulähtöiset (service oriented) teknologiat, Web Servicet, toimivat siten, että: (Booth et al., 2003) Palvelun tarjoava ja palvelua käyttävä sovellus sopivat keskenään palvelun kuvauksesta ja semantiikasta. Tämä tapahtuu käyttämällä Discovery agency palvelua. Kuvauksella tässä tarkoitetaan koneellisesti tuotettavaa kuvausta palvelun rajapinnasta ja semantiikalla sopimusta siitä, mitä mahdollisen interaktion tarkoitus. Eli palvelulähtöisen arkkitehtuurin pääosat ovat järjestelmässä kulkevat viestit, palveluja pyytävät ja niitä tarjoavat agentit ja yhteinen viestien kuljetukseen tarkoitettu kuljetusmekanismi. Tässä kappaleessa esitellään kolme hajautettuihin olioihin keskittyvää teknologiaa ja yksi palvelulähtöinen teknologia. 1) Hajautettujen olioiden teknologiat a) CORBA CORBA, eli Common Object Request Broker Architecture, on OMG:n (Object Management Group) kehittämä standardi hajautettujen järjestelmien tekemiseen. CORBAn perusideana on, että se on alustariippumaton ja että sen avulla voivat eri teknologioilla tehdyt järjestelmät toimia yhdessä. Tämä on erityisen tärkeää vanhojen ja uusin järjestelmien integroinnissa. (Plasil et al., 1999; Saiedian et al., 2002) b) DCOM DCOM (Eli Distributed Component Object Model) on Microsoftin kehittämä teknologia. Tämän teknologian perusideana on, että eri tietokoneilla olevat oliot voivat keskustella keskenään. Tämä teknologia kehitettiin Microsoftin COM (Component Object Model) pohjalta, jonka avulla välitettiin viestejä Windows ohjelmien välillä. (Plasil et al., 1999; Saiedian et al., 2002) c) Java RMI Java RMI, eli Remote Method Invocation, on Sun Microsystemsin kehittämä hajautettujen olioiden malli. Sen perusideana on mahdollistaa hajautettujen Java-olioiden kommunikointi keskenään. RMI käyttää tällöin hyväksi Javan ominaisuuksia. Verkossa olevat koneet, joissa on JVM (Java Virtual Machine), voivat kommunikoida keskenään hajautettujen olioiden kautta. JVM tarkoittaa Sun kehittämää virtuaalikonetta, joka osaa ajaa Javalla tehtyjä sovelluksia. (Plasil et al., 1999; Saiedian et al., 2002) 2) Palvelulähtöiset teknologiat Palvelulähtöisistä teknologioista tässä siis tarkastellaan Web Services teknologiaa. Tämä toimii hyvin pitkälle kuten teknologioiden esittelyssä kuvattiin. Perusajatus on, että palvelua tarvitseva agentti pyytää palvelukuvauksen erityisesti tätä tarkoitusta varten olevalta agentilta (discovery agency). Agentti saa vastauksena palvelun rajapintakuvauksen, jonka palvelua tarjoava agentti on discovery agencylle julkaissut.

8 Nyt palvelua tarvitseva agentti voi alkaa käyttämään palvelun tarjoajan palveluja tämä rajapinnan avulla (Booth et al., 2003; Patil et al., 2003). Kuva 2 Web Services arkkitehtuuri C. Vertailu Jokaista neljästä valitusta arviointikriteeristä arvioidaan erikseen. Arvioinnissa painotetaan ongelmakenttien valinnan yhteydessä määritettyjä ominaisuuksia.(taulukko 2 Arviointikriteerit). Arvioinnin yhteydessä teknologioille ei anneta absoluuttisia arvoja eikä teknologioita laiteta millään tavalla paremmuusjärjestykseen, vaan esitetään hyvät ja huonot ratkaisut tai ratkaisujen puuttuminen. Lopuksi esitetään yhteenveto arvioinnin tuloksista. Tähän tarkasteluun otetaan mukaan CORBA ja Web Services. DCOM ja Java RMI jätetään pois tämän tarkastelun piiristä, koska ne ovat toiminnaltaan hyvin samankaltaiset CORBAn kanssa. Kuitenkin, jos jonkin arviointikriteerin kohdalla huomataan näiden ja CORBAn välillä jotain oleellista eroa, tuodaan se esille. 1) Arkkitehtuurimalli 2) Dokumentointi a) Hajautettujen olioiden teknologia: CORBA a) CORBA CORBA ei rajoita komponenttien sijaintia mitenkään, komponentti voi sijaita samassa osoiteavaruudessa, eri osoiteavaruudessa samalla serverillä, tai sitten kokonaan eri serverillä omassa osoiteavaruudessaan. Täten komponenttien hajauttaminen on mahdollista monella eri tavalla. Komponenttien väliset rajapinnat toteutetaan IDL-kielen (Interface Description Language) avulla, joka on CORBAn standardoitu kuvauskieli. Tästä IDL-kuvauksesta generoidaan viittauksiin tarvittava koodi. Kutsut ja vastaukset välitetään IIOP protokollan avulla, joka on standardoitu, joten komponenttinen yhdistäminen onnistuu helposti myös eri organisaatioiden välillä (Plasil et al., 1999). Komponenttien siirto tapahtuu siirtämällä komponentti paikasta toiseen ja rekisteröimällä uudessa paikassa oleva komponentti uudestaan Object Adapteriin, joka esittää komponentin tarjoamaa palvelua. Siirrossa on kuitenkin huomioitava, että komponentin tulee olla toteutettu sellaisessa ympäristössä, joka on yhteensopiva kohdeympäristön kanssa. Komponentit löytävät toisensa niiden rekisteröinnin jälkeen käyttämällä nimipalvelua (Plasil et al., 1999). Yhteenvetona CORBAn arkkitehtuurimallin sopivuudesta hajautettuun kehittämiseen voisi sanoa, että se sopii siihen hyvin. Komponenttien hajauttaminen ja rajapintojen luonti on helppoa, yhdistäminen toimii suoraviivaisesti ja siirtäminenkin on mahdollista tietyin varauksin. Erityisesti hyvää CORBAssa on se, että sen oleellisimmat osat nojaavat standardeihin. Huono puoli CORBAssa on se, että sen asentaminen on työlästä. ORB-ydin, joka yhdistää kutsujan ja kutsuttavan pitää asentaa jokaiseen koneeseen, myös asiakaskoneeseen. Tämä lisää asennukseen tarvittavaa työtä (Saiedian et al., 2002). DCOM eroaa CORBAsta siinä, että sillä ei ole olemassa yleistä palvelun hakua eikä se nojaa yleisiin standardeihin yhtä vahvasti kuin CORBA. DCOM-komponenttien Siirrettävyys toimii vain Windows alustoilla ja asennuksen yhteydessä ei tarvita erillisen ajoympäristön asennusta, koska se on mukana windows-alustoissa (Saiedian et al., 2002). Java RMI eroaa siinä, että se tarvitsee JVM:n toimiakseen ja se on ohjelmointikieliriippuvainen (pääasiassa Java). b) Palvelulähtöinen teknologia: Web Services Web Servicet tukevat hajauttamista yhtä hyvin kuin CORBA. Komponenttien väliset riippuvuudet ja niiden yhdistäminen toisiinsa tapahtuu WSDL-kielellä määritettyjen rajapintojen kautta. Tähän yhdistämiseen tarvittava koodi saadaan generoitua automaattisesti. Palvelujen linkittäminen tapahtuu pyytämällä discovery agencyltä (palvelujen tiedot sisältävä palvelu) tietyn palvelun kuvausta tai sitten kutsumalla suoraan ennalta tiedettyä osoitetta. Siirtäminen on helppoa, mutta ympäristöjen tulee olla yhteensopivia. Myös Web Services nojaa vahvasti standardeihin ja sopii hyvin vanhojen ja uusien järjestelmien yhdistämiseen. CORBA ei tarjoa valmista tapaa dokumentoida suunnitelmia ja tuotetta, mutta kuvauskielistä ainakin UML sopii hyvin tähän. Automaattinen dokumentaation tuottaminen, jakaminen, päivittäminen ja dokumentaation formaatti jää kehitysympäristöjen huoleksi. Java RMI tarjoaa hyvän tavan automaattisen dokumentaation tuottamiseen, JavaDoc. Tämän työkalun avulla voidaan tuottaa yhtenäistä dokumentaatiota toteutetusta tuotteesta. JavaDocin avulla generoidaan dokumentaatio ohjelmakoodin sekaan laitetuista kommenteista, joilla kuvataan luokkien ja niiden metodien toimintaa, parametrejä, paluuarvoja yms.(sun Microsystems, 2003) b) Web Services Web Services ei itsessään määrittele mitään yhtenäistä kattavaa dokumentointitapaa, se on jäänyt Web Servicejä hyödyntävien kehitysympäristöjen huoleksi. Täten kovin heterogeenisessa ympäristössä on vaikeata saada aikaiseksi yhtenäinen dokumentointiprosessi. Web Servicet tarjoavat yhtenäisen tavan tehdä palvelun kuvaus (Patil et al., 2003),

9 jonka avulla voidaan välittää tietoa palvelun käyttötarkoituksesta ja käyttötavoista yms. Sekin auttaa hajautetussa kehittämisessä rajapintaongelmien ratkaisussa, koska tämä kuvaus on tietynlainen rajapintakuvaus palvelusta. Tämän kanavan kautta myös dokumentaation jakaminen tapahtuu automaattisesti ja tämä dokumentaatio pysy ajan tasalla. Kuten CORBA, myös Web Servicesien kuvaaminen onnistuu hyvin UML:n avulla. 3) Alustariippumattomuus a) CORBA CORBAn käyttäminen erilaisissa ympäristöistä riippuu näiden ympäristöjen tuesta CORBAlle. CORBA on kuitenkin laajasti tuettu ja näin ollen sillä tehtyjä tuotteita tai tuotteen osia on mahdollista toteuttaa useilla ohjelmointikielillä ja useissa ympäristöissä (Saiedian et al., 2002). Java RMI käyttäminen onnistuu missä tahansa ympäristössä, jossa on JVM. Eri ympäristöjen JVM:ien toiminnassa on kuitenkin havaittu eroavaisuuksia, mikä saattaa lisätä kustannuksia (Plasil et al., 1999). b) Web Services Myös Web Services on riippuvainen eri ympäristöjen tuesta sille. Web Services tuki löytyy jo useimmista kehitysympäristöistä ja Web Services Architecture Working Groupissa, joka vastaa Web Services standardien eteenpäin viennistä, on mukana lähes kaikki merkittävät ohjelmistoyritykset.(w3c, 2003). Tietyssä ympäristössä tehdyn tuotteen siirtäminen toiseen ympäristöön ei onnistu suoraan, kuten Java RMI:llä, vaan ympäristöjen pitää olla yhteensopivat tai sitten pitää toteutusta muuttaa. 4) Suunnittelumenetelmät, Design patternit a) CORBA Koska CORBA on oliopohjainen teknologia, voidaan toteutuksessa käyttää hyväksi yleisiä olio-ohjelmoinnin design patterneita. Näitä design patterneita ja niihin liittyvää tietoa on paljon (Gamma et al., 1997). Rajapintojen toteutus tapahtuu standardoidun IDL-kielen avulla ja riippuvuuksien poistamiseen löytyy olio-ohjelmoinnin design patterneista paljon vaihtoehtoja. b) Web Services Web Services design patterneista ei kirjallisuudesta löytynyt juurikaan tietoa. Design patterneista kertovat kirjallisuuslähteet liittyivät aina tiettyyn kehitysympäristöön, yleisiä design patterneita ei löytynyt. Koska design patternien käyttömahdollisuudet riippuvat kehitysympäristöstä, voi yleisten design patternien määrittäminen hajautettuun projektiin olla mahdotonta tai ainakin hankalaa. 5) Yhteenveto Taulukko 3 on esitetty CORBA ja Web Services vertailun tulokset. Taulukko 3 Vertailun tulokset Arviointikriteeri CORBA Web Services Arkkitehtuurimalli, painoarvo 4 Dokumentointi, painoarvo 4 Alustariippumattomuus, painoarvo 3 Suunnittelumenetelmät, design patternit, painoarvo 2 Standardoidut ratkaisut, komponenttien yhdistäminen helppoa. Asennus työlästä. Sopii hyvin uusien ja vanhojen järjestelmien yhdistämiseen Ei omaa dokumentointikäytäntöä, UML sopii kuvauskieleksi Eri ympäristöjen tuki tarpeen, löytyy kuitenkin useimmista ympäristöistä Suuri joukko valmiina, Olioohjelmoinnin design patternit sopivat, rajapintojen kuvauksessa standardoitu IDLkieli Standardoidut ratkaisut, siirtäminen helppoa tietyin varauksin, sopii hyvin uusien ja vanhojen järjestelmien yhdistämiseen, asennus helppoa Palvelujen kuvauskieli löytyy, muuta yleistä dokumentointikäytäntöä ei ole, kuvauskieli esim. UML Eri ympäristöjen tuki tarpeen, löytyy kuitenkin useimmista ympäristöistä Ei juurikaan kirjallisuutta, liittyvät aina johonkin kehitysympäristöön. Kuten Taulukko 3 Vertailun tulokset huomataan, ovat vertailtavat teknologiat valittujen arviointikriteerien suhteen varsin samanlaiset. Eroja syntyy lähinnä pienissä asioissa, kuten asennukset, tietyt dokumentoinnin osat yms. Suurempia eroja näiden teknologioiden käyttöön kehittämisessä saataisiin, jos otettaisiin kehitysympäristöt mukaan vertailuun. Näin ei kuitenkaan tässä tapauksessa voida tehdä, koska hajautetussa kehittämisessä täytyy varautua heterogeenisiin ympäristöihin. Tehtäessä päätöksiä valinnoista näiden teknologioiden välillä, täytyy ottaa huomioon pikkuasiat. Esimerkiksi, jos järjestelmä koostuu suuresta määrästä erillisiä komponentteja, voi CORBAn asennustyöstä tulla merkitsevä tekijä. Web Services teknologian ongelmana taas on yleisten design patternien puute. Yksi suuri tekijä teknologiaa valittaessa on myös se, että mikä on kyseisen teknologian tila sen elämänkaaressa. CORBA on stabiloitunut teknologia, kun taas Web Servicet ovat vielä melko uusi teknologia. Toisaalta taas Web Serviceitä kuvataan seuraavaksi hajautettujen järjestelmien läpimurtoteknologiaksi (Martin et al., 2003). Yhteenvetona tästä tutkimuksesta voidaan sanoa, että tarkistellut teknologiat soveltuvat hyvin hajautettujen

10 järjestelmien hajautettuun kehittämiseen ja valinta niiden välillä on tehtävä tapauskohtaisesti. Parantamisen varaa kuitenkin löytyy, varsinkin dokumentointikäytäntöjen puolelta. V. JOHTOPÄÄTÖKSET Tässä tutkimuksessa esitettiin hajautetun kehittämisen toteutusteknologialle ja arkkitehtuuriratkaisulle asettamia haasteita, muodostettiin niiden avulla arviointikriteerit ja vertailtiin kahta yleisesti tunnettua hajautettujen järjestelmien toteutusteknologiaa, CORBA ja Web Services, näitä arviointikriteerejä vastaan. Arviointikriteerit muodostettiin hajautetun kehittämisen kirjallisuudesta löydettyjen yleisimpien ongelmakenttien avulla. Löydetyt ongelmakentät olivat: 1. Kommunikaatio 2. Projektin koordinointi 3. Resurssien allokointi ja työn jakaminen 4. Asiantuntemuksen hallinta. Tämän jälkeen etsittiin kirjallisuudesta niihin liittyviä arkkitehtuurisia haasteita, joiden pohjalta muodostettiin arviointikriteerit. Arviointikriteerejä muodostettiin neljä kappaletta: 1. Arkkitehtuurimalli 2. Dokumentointi 3. Alustariippumattomuus 4. Suunnittelumenetelmät ja Design patternit Valittuja teknologioita vertailtiin näiden kriteerien suhteen. Arvioinnin tuloksena todettiin, että nämä teknologiat ovat tässä suhteessa hyvin samanlaisia, molemmilla on hyvä arkkitehtuurituki hajautettujen järjestelmien hajautettuun kehittämiseen ja molempia teknologioita voidaan käyttää useissa erilaisissa ympäristöissä. Tutkimuksessa löytyi kuitenkin joukko pienempiä eroavaisuuksia, jotka tietyissä olosuhteissa tulevat hyvinkin ratkaiseviksi, esimerkiksi asennukset ja dokumentointi. Tutkimuksessa ei käsitelty ollenkaan valittujen teknologioiden kehitysympäristöjä ja niihin liittyviä työkaluja. Tämä rajaus tehtiin työn laajuuden vuoksi. Eri kehitysympäristöjen ja työkalujen tuki hajautetulle kehittämiselle on kuitenkin erittäin mielenkiintoinen tutkimusalue ja on oletettavaa, että suuri osa tutkimuksessa löydetyistä esimerkiksi dokumentointiin liittyvistä puutteista voidaan korvata oikeanlaisilla kehitysympäristöillä ja työkaluilla.

11 VIITTEET Battin, R.D., Crocker, R., Kreidler, J., Subramanian, K., 2001, Leveraging resources in global software development, IEEE Booth, D., Haas, H., McCabe, F., Newcomer, E., Web Services Architecture, 15.11.2003, available at http://www.w3.org/tr/2003/wd-ws-arch- 20030808/#whatis Ebert, C., De Neve, P., 2001, Surviving global software development, IEEE SOFTWARE Gamma, R., Helm, R., Johnsson, R. Vlissides, J., 1997, Design patterns Elements of reusable object-oriented software, Addison Wesley professional computing series Herbsleb, J. D., Mockus, A., Finholt, T. A., Grinter, R. E., 2000, Distance, Dependencies, and Delay in a Global Collaboration, ACM Press Herbsleb, J.D., Moitra, D, 2001, Global software development, IEEE Herbsleb, J. D., Mockus, A., Finholt, T., Grinter, R. E., 2001b, An Empirical Study of Global : distance and speed, IEEE, pp. 481-494 Herbsleb, J. D., Mockus, A., 2003, An Empirical Study of Speed and Communication in Globally Distributed, IEEE, pp. 481-494 Hitchens, M., 2003, itec801, Introduction to distributed systems, Macquarie University, Sydney Australia Kiel, L., 2003, Experiences in distributed development: a case study, University of Alberta, Canada Kraut, R.E., Streeter, L. A., 1995, Coordination in software development, ACM Martin, J., Arsanjani, A., Tarr, P., Hailpern, B., 2003, Web Services: Promises and Compromises, ACM Press, pp 48-58 Mockus, A., Herbsleb, J. D., 2001, Challenges of global software development, IEEE, pp 182-184 Mockus, A., Weiss, D. M., 2001b, Globalization by chunking a quantitative approach, IEEE, pp 30-37 Muller, R., Ruland, D., Hoch, D. Klosterkemper, B., 2000, Offshore software development in emerging countries, McKinsey & Company, Articles volume one IT management Nakamura, K., Fujii, Y., Kiyokane, Y., Nakamura, M., Hinenoya, K., Peck, Y. H., Choon-Lian, S., 1997, Distributed and concurrent development environment via sharing design information, IEEE OMG, Object Management Group, 15.11.2003, available at http://www.omg.org/ Paasivaara, M., 2003, Communication needs, practices and supporting structures in global inter-organizational software development projects, Helsinki University of Technology Patil, S., Newcomer, E., 2003, ebxml and Web Services, IEEE Plasil, F., Stal, M., 1999, An Architectural view of distributed objects and components in CORBA, Java RMI, and COM/DCOM, Repenning, A.,Loannidou, A., Payton, M., Wenning, Y., Roschelle. J., 2001, Using components for rapid distributed software development, IEEE Saiedian, H., Ghanem, N., Natarajan, J., 2002, A framework for evaluating distributed object models and its application to web engineering, Kluwer academic publishers Sugiyama,Y., 2000, Distributed development of complex software systems with Object Make, IEEE Sun Microsystems, JavaDoc tool, 15.11.2003, available at http://java.sun.com/j2se/1.4.2/docs/tooldocs/javadoc/ W3C, Web Services Architecture working group, 15.11.2003, available at http://www.w3.org/2002/ws/arch/