JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 11. Teknologia-arkkitehtuurin suunnittelu

Transkriptio

1 JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 11. Teknologia-arkkitehtuurin suunnittelu Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto Termit ja määritelmät Teknologia-arkkitehtuurin suunnittelussa huomioitavia tekijöitä Virtualisoinnin eri vaihtoehtojen arviointi SaaS (Software-as-a-Service) IaaS (Infrastructure-as-a-Service) PaaS (Platform-as-a-Service) /10

2 1 Johdanto Tässä liitteessä käsitellään tarkemmin teknologia-arkkitehtuurin suunnittelussa huomioitavia tekijöitä ja teknologia-arkkitehtuurin virtualisointia (pilvipalvelut). Liite täydentää JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen -suositusta. 2 Termit ja määritelmät ADSL en Asymmetric Digital Subscriber Line verkkokytkintekniikka, jolla on mahdollista siirtää jopa 8 Mb/s tavallista puhelinlinjaa käyttäen CAPEX en Capital Expenditure käyttöomaisuusinvestoinnit on kulua, jonka hyöty jakautuu pitkälle ajanjaksolle. Tällaiset kulut ovat luonteeltaan kertaluonteisia ja johtuvat pysyvän omaisuuden hankinnasta. CEM en Composable Enterprise Model arkkitehtuurimalli, jossa liiketoiminnan palvelut ja toiminnot, prosessit, organisaatiot, toimittajariippuvuudet ja teknologiat nähdään rakennuspalikoina, jotka voidaan uudelleen konfiguroida vastaamaan muuttuviin vaatimuksiin uusissa käyttö-, muutos- tai kilpailutilanteissa CEIP en Cloud enabled integration platform pilvipohjainen integraatiopalvelu CI en Continuous Integration jatkuva prosessi ja kehitysmenetelmä, jossa koko ohjelmisto koostetaan ja integroidaan jatkuvasti liittyviin ympäristön järjestelmiin Kehitysmenetelmää käytetään esim. DevOps-tyyppisessä ohjelmistokehityksessä ja erityisesti kehitettäessä ohjelmistoja virtualisoituihin ympäristöihin. CMDB en Configuration Management Database konfiguraationhallintajärjestelmä, joka ylläpitää yhtä tai useampaa konfiguraatiotietokantaa Konfiguraationhallintajärjestelmissä säilytetään ICT-resurssien ja -komponenttien konfiguraatiotietueet koko niiden elinkaaren ajan ja kukin tietokanta säilyttää rakenneosien ominaisuudet ja suhteet toisiin rakenneosiin. DevOps fi DevOps 2/10

3 IT-organisaatioiden toimintatapa, jossa tehostetaan ohjelmistokehitystä hyvän sisäisen kommunikaation avulla Docker en Docker Container (kontti)-virtualisointitekniikkaa hyödyntävä sovellusten paketointi- ja suoritusympäristö, jota käytetään erityisesti kehitettäessä ohjelmistoja eri pilvimalleihin EDI en Electronic Data Interchange elektronisessa muodossa olevan tiedon automatisoitu siirto organisaatioiden tietojärjestelmien sovellukselta toiselle Liikennöinnissä käytetään kansainvälisiä ja kotimaisia määrämuotoisia sanomia, esim. EDIFACT (Electronic Data Interchange for Adminstration, Commerce and Transport) muodossa. Ethernet en Ethernet pakettipohjainen lähiverkkoratkaisu (LAN), joka on yleisin ja ensimmäisenä laajasti hyväksytty lähiverkkotekniikka Help Desk fi käyttäjätuki en Help Desk ICT-käyttäjätukea antava käyttötuki tai tukikeskus, joka palvelee organisaation asiakkaita tai omaa henkilökuntaa hybridipilvi fi hybridipilvi en Hybrid cloud erilaisten pilvityyppien käyttöä sekaisin IaaS-, PaaS- ja SaaS -virtualisointimallien käyttämä tietoverkko voi olla julkinen pilvi (public cloud), yksityinen pilvi (private cloud), luotettu pilvi (trusted cloud) tai hybridipilvi (hybrid cloud). IaaS en Infrastructure as a Service palvelimien ja palvelinsalien ulkoistettu kokonaisuus, johon sisältyvät yleensä verkkoyhteydet, tallennustila, palvelimet ja niiden ylläpito ipaas en Integration Platform as a Service hallittu pilvipohjainen integraatiopalvelu, jossa kokoelma eri pilvipalveluita mahdollistaa integraatioiden kehityksen, toteutuksen ja hallinnan Palvelu yhdistää integraatiovirroilla paikallisia ja pilvipohjaisia prosesseja, palveluita, sovelluksia ja dataa yksittäisissä tai useisissa erillisissä organisaatioissa. 3/10

4 MPLS en Multiprotocol Label Switching menetelmä, jolla kuljetetaan esimerkiksi IP-paketteja ennalta määriteltyjen yhteyksien ylitse nopean runkoverkon solmujen kautta ilman, että solmujen tarvitsee tehdä reititystä OpenShift en OpenShift Red Hat -yhtiön ylläpitämä PaaS-pilvialusta, jonka avulla ohjelmistokehittäjät pystyvät kehittämään ja ylläpitämään sovelluksia pilviympäristössä PaaS en Platform as a Service ulkoistettu palvelualusta PaaS-mallin kehitysalustat mahdollistavat ohjelmistokehityksen ja valitun pilvimallin mukaisen teknisen kehityksen antamalla kehittäjille välineet ladata sovelluksiaan osaksi kokonaisuutta. REJ en Rapid Economic Justification IT-aloitteen tai -palvelusuunnitelman arvon ja suorituskyvyn arviointi ROI en Return of Investment kannattavuustarkastelu, jossa investointia arvioidaan hyödyn, tuottavuuden ja vaikuttavuuden näkökulmasta SaaS en Software as a Service virtualisoitu ohjelmistopalvelu, jota käytetään perinteisen fyysisen ohjelmiston hallintatavan sijasta SAM en Software Asset Manager tuotteistettu lisenssisalkun hallintaohjelmisto, jonka avulla voidaan tehdä organisaation nykyisen ohjelmistoomaisuuden lisensoinnin hallintaa, kartoitusta ja optimointia ohjemistojen elinkaarien ja kustannussäästötavoitteiden mukaisesti Service Desk en Service Desk keskitetty yhteydenottopiste organisaation sisällä palveluntarjoajan ja käyttäjien välillä Tyypillisesti palvelukeskus hallinnoi virhetilanteita ja palvelupyyntöjä palvelutuottajan ja käyttäjien välillä sekä hoitaa viestinnän palvelujen käyttäjien ja muiden osapuolten kanssa. TCO en Total Cost of Ownership elinkaarilaskenta, joka sisältää ICT-kehityksen ja -ylläpidon kokonaiskustannukset 4/10

5 3 Teknologia-arkkitehtuurin suunnittelussa huomioitavia tekijöitä Arkkitehtuurivaatimukset ja arkkitehtuurin elinkaari Teknologia-arkkitehtuurin suunnittelun ja toteuttamisen yhteydessä joudutaan vastaamaan seuraaviin yleisiin teknologia-arkkitehtuurin vaatimuksiin: Järjestelmien tulee olla tarvittaessa skaalautuvia - Liiketoiminnnan kyvykkyys käyttää palveluita ja toimintoja tarpeen mukaan Tietotekniikka- ja teknologiapalveluiden ja komponenttien käyttö ja ylläpito tulee olla helppoa ja niiden saatavuus hyvä Automaatioasteen nostaminen tulee olla mahdollista - IT-järjestelmien manuaaliset prosessit ja/tai skriptaukset tulee eristää arkkitehtuurin kannalta, jotta toimintojen automaatioastetta voidaan nostaa. Organisaation tietoon tulee olla joustava pääsy - Teknologia-arkkitehtuurin on kyettävä tarjoamaan joustava ja helppo pääsy organisaation tietoon komponentoitujen palveluiden ja hallittujen rajapintojen kautta. Lisäksi teknologia-arkkitehtuurin suunnittelussa tulee huomioida arkkitehtuurin eri elinkaari- ja kehitysmallien erot sekä niiden asettamat vaatimukset. Erityisesti migraatioarkkitehtuurissa on usein käytössä rinnakkain vanha ja uusi arkkitehtuuri, jotka voivat poiketa huomattavasti toisistaan, mikä voi hankaloittaa yhteiskäyttöä ja lisätä kustannuksia. Usein arkkitehtuuri koostuu yhdistelmästä pilvipalveluita (erilaiset virtualisointiratkaisut) ja perinteisiä teknologioita, organisaation omia fyysisiä palvelimia ja infraalustoja ym. Edellisten vaatimusten täyttäminen teknologia-arkkitehtuurissa johtaa yleensä keskusteluun virtuaalisaatiosta uusien palveluiden kehityksen yhteydessä (virtualisointi, ks. luku 4). Strategiset tavoitteet ja toiminnan kehittämisen vaatimukset Organisaation strategiset tavoitteet, liiketoimintamallit, tiedonhallinta, rajaukset, reunaehdot ja kehittämisvaatimukset ja -tavoitteet asettavat selkeitä vaatimuksia teknologia-arkkitehtuurille ja ne ohjaavat joko eri virtualisointimalleihin tai niistä pois. Tiedonhallinnan kehittämisvaatimukset voivat auttaa arvoinnissa erilaisten vaihtoehtojen välillä (esim. virtualisointi). Analysoimalla nyky- ja tavoitetilan eroja ja toimintaympäristöanalyysien kautta saadaan tarkempaa tietoa, jonka perusteella voidaan luoda luotettavampia ja tarkennetumpia suunnitelmia muutosvaiheiden ajaksi. Siirtyminen komponenttipohjaiseen arkkitehtuuriin Perinteisesti teknologia-arkkitehtuurilla on kehitetty omaan fyysiseen hallintaan tulevia teknologisia ratkaisuja, joiden IT:n operatiivinen malli ja toimintaympäristöt ovat usein muodostuneet hyvinkin staattisiksi ja siilomaisiksi. Toisaalta uudempien teknologiapalveluiden eri virtualisaatiomallit ovat luoneet tarpeita, jossa liiketoiminnan palvelut ja toiminnot, prosessit, organisaatiot, toimittajariippuvuudet ja teknologiat nähdään eräänlaisina rakennuspalikoina (komponentteina), joiden avulla voidaan vastata helpommin ympäristöjen tuleviin muutoksiin. Tämä on usein johtanut komponenttipohjaisiin järjestelmäjäsennyksiin, jotka yleensä asettavat merkittäviä haasteita perinteisille tietojärjestelmille. Kustannusvaikutusten arviointi Usein teknologia-arkkitehtuurin suunnittelussa otetaan huomioon myös esillä olevien valintojen eri kustannusvaikutukset. Esimerkiksi ROI-, TCO- ja/tai REJ-laskelmilla huomioidaan nykytila, investointi- ja operatiiviset kulut, elinkaarilaskelmat sekä muut päätökseen vaikuttavat seikat, jotta päätöksenteon pohjalla olisi mahdollisimman paljon ja riittävän läpinäkyvää faktoihin perustavaa tietoa. Kustannusanalyysien kannalta olisi tärkeää huomioida eri teknologia- ja tietojärjestelmäarkkitehtuurin kokonaisbudjetin kustannuselementtien vaikutukset ja tehdä vertailuja esim. operatiivisen hallinta- ja 5/10

6 tukimallin, teknisten tilojen välillisten kustannuksien (sähkö-, ilmanvaihto- ja jäähdytyskustannukset) ja lisenssisalkun sisältämien kustannusten kautta, huomioiden esim. valitun virtuaalisaatioratkaisun vaikutus käytettyyn lisenssimalliin. 4 Virtualisoinnin eri vaihtoehtojen arviointi Virtualisoinnin eli pilvipalveluiden avulla voidaan saavuttaa huomattavia kustannussäästöjä, mutta pitää huomioida myös virtualisointiin liittyvät riskit, esim. verkon latenssi (viive) sekä virhetilanteista toipuminen. Toisaalta virtualisointi voi myös vähentää riskejä, koska esim. sovelluskerros on yleensä erotettu fyysisestä alustasta. Eri virtualisointimallien valinnoissa on tärkeää ymmärtää olemassa olevan teknologiaarkkitehtuurin nyky- ja tavoitetila sekä ratkaisun kyvykkyydet sekä haasteet siirryttäessä virtualisoituihin palvelumalleihin. Kuvassa 1 on esitetty millä teknologioilla teknologiapalvelut voidaan toteuttaa eli palveluiden tarvitsema alusta ja sen mahdollinen virtualisointimalli. Teknologiaresursseilla kuvataan, millä teknologioilla ko. alusta voidaan toteuttaa. Toteutus voidaan virtualisoida halutuin osin. Kuva 1. Teknologiakaavio. Virtualisoinnin eri vaihtoehdoista kuvataan tässä dokumentissa SaaS-, PaaS- ja IaaS-mallit (ks. kuva 2). Alla olevassa kuvassa Fyysinen tarkoittaa, ettei virtualisointi ole käytössä. 6/10

7 Kuva 2. Palveluiden virtualisointitavat ja palveluiden vastuunjako. Seuraava kaavio (kuva 3) esittää kuinka eri teknologia-arkkitehtuurin palvelut ja toiminnot jakaantuvat eri virtualisointikerroksiin periaatetasolla. SaaS-mallissa lähes koko teknologia-arkkitehtuuri on ulkoistettu palveluntarjoajalle. Usein kyseinen virtualisointimalli sopii uusille sovelluspalveluille, joiden kehittämisessä on huomioitu virtualisoinnin vaatimukset tai olemassa olevia sovelluksia joiden rajapinnat ja sovellusmalli sopivat SaaS-mallin mukaiseen virtualisointiin. IaaS-mallissa teknologia-arkkitehtuurin selkeät infrastruktuurin palvelut on virtualisoitu ja loput teknologiapalvelut ovat edelleen organisaation omassa fyysisessä hallinnassa. PaaS-malli on edellä mainittujen SaaS- ja IaaS-mallien välimuoto eli siihen kuuluvat palveluntarjoajan kanssa tehdyn sopimuksen mukaiset teknologiapalvelut. 7/10

8 Kuva 3. Virtualisointimallit ja teknologia-arkkitehtuurin kerrokset. 4.1 SaaS (Software-as-a-Service) Virtualisointimalli, jossa hankitaan käyttöön kolmannen osapuolen virtualisoima teknologiapalvelu koonaisuudessaan. SaaS-mallissa kaikki teknologiakerrokset ovat virtualisoituja ja niiden sovellukset kokonaisuudessaan hoidetaan palveluntarjoajan kautta. Usein SaaS-pohjaisella virtualisoinnilla tavoitellaan teknologiapalveluiden erittäin nopeaa käyttöönottoa. Samalla virtualisoitujen teknologiapalveluiden takia tarvittavat laiteinvestoinnit jäävät pieniksi ja ohjelmisto- ja virtualisointiratkaisun toimittaja huolehtii huolto-, päivystys- ja varmuuskopioista. Tällöin myös käyttökustannukset ovat ennustettavia. Tyypillistä tälle pilvimallille on, että käyttäjän kannalta palveluntarjoajan täytyy tarjota teknologiapalvelu käyttäjälle kokonaisuudessan. Esimerkkejä SaaS-palveluista ovat esim. Microsoft Office 365 ja Salesforce.com SaaS-mallissa täytyy kiinnittää erityisesti huomiota rajapintojen hallintaan ja niiden kyvykkyyteen palvella organisaation tarpeita. Kuvassa 4 on esimerkki SaaS-virtualisointimallista. 8/10

9 Kuva 4. SaaS-virtualisointimallin esimerkkikuva. Huom! Kuvassa 4 artefaktit Virtualisoidun sovelluspalvelimen käyttö ja Virtualisoidun tietokantapalvelimen käyttö kuvaavat pilvimallin virtualisointisopimusta, jossa määritetään tarkemmin pilvipalvelun käyttöön liittyvät tiedot. 4.2 IaaS (Infrastructure-as-a-Service) Virtualisointimalli, jossa vain infrastruktuuripalvelut (esim. palvelin-, tietokanta- ja näihin liittyvät tietoverkkoteknologiat) ovat virtualisoituja. Tässä pilvimallissa järjestelmä- ja sovelluspalvelut ovat organisaation itsensä hallinnoimia ja omistamia. Esimerkki IaaS-palvelusta on, että keskeiset sovellus- ja tietokantapalveluiden palvelimet ja niiden ohjelmistot ovat virtualisoituina kolmannella osapuolella. Toinen esimerkki IaaS-palvelusta on Amazon Web Services (AWS). 4.3 PaaS (Platform-as-a-Service) PaaS-virtualisointi mallissa ollaan IaaS- ja SaaS-mallien välimaastossa. Valinta tehdään riippuen organisaation strategiasta, vaatimuksista ja tarpeista sekä pilvipalveluiden tarjoajien kyvykkyyksistä ja näistä syntyvistä kustannuksista. 9/10

10 PaaS-mallissa palvelualustat ovat virtualisoituja eli palvelimien tilaaminen, komponenttien asennukset, versiohallinta jne. siirtyy pilvipalvelun tarjoajalle. PaaS-mallissa palvelualustan ulkoistamisen edut organisaatiolle ohjelmistokehityksen kannalta ovat: - joustava kehitys - testaus - sovellusten käyttöönotto tarvitsematta omistaa ja hallita virtualisoituna olevia laitteistoja ja varusohjelmistoja. Organisaation liiketoiminnnan kannalta PaaS-malli tarjoaa mahdollisuuden nopeaan ja ketterään sovelluskehitykseen ilman hidastavia laite- ja ohjelmistohankintoja. Esimerkkejä PaaS-palveluista ovat esim. Docker- ja OpenShift -teknologiat ja Composable Enterprise -tyyppiset komponenttipohjaiset teknologia-arkkitehtuurit. Edellä kuvattujen pilvimallien lisäksi on olemassa myös laaja joukko muita virtualisoinnin variaatioita, joissa esimerkiksi organisaatio voi itse hallinnoida osaa virtualisoiduista palveluista (On-Premise). Eri pilvimallien käyttämä tietoverkko voi olla julkinen pilvi, yksityinen pilvi tai luotettu pilvi sekä näiden eri tyyppien yhdistelmä. Viimeksimainittua kutsutaan hybridipilveksi. Huolimatta teknologia-arkkitehtuurien erilaisista virtualisointitavoista tai fyysisistä sijoitusmalleista, arkkitehtuuri tulisi kuvata suosituksessa annetuilla kerrosarkkitehtuurin ohjeilla. 10/10