Ero sivun ”Palvelulle” versioiden välillä
Rivi 217: | Rivi 217: | ||
== Sopimukset == | == Sopimukset == | ||
+ | Palvelun toteutusta tilattaessa kannattaa miettiä sen eri elinkaaren vaiheita ja palvelun osien ja siihen syötetyn sisällön oikeuksia. Automaattisesti tulee ajateltua, että ainakin sisältö on palvelun omistajan omaisuutta. Miten toimia tilanteessa jos järjestelmä lakkaa toimimasta tai se tulee rakentaa uudelleen - joko saman palveluntarjoajan tai nykyisen kilpailijan avustamana? Onko se mahdollista ja mielekästä? Mitä se kaikki maksaa ja kauanko se kestää? Onko halvempaa ja nopeampaa aloittaa tietojen syöttö alusta? | ||
+ | |||
+ | Monet palvelut sisältävät tietokannan joka yleensä on SQL-tyyppinen relaatiotietokanta. Tietokanta koostuu tauluista, sen sarakkeista, taulujen välisistä sidoksista ja monesta muusta yksityiskohtaisesta määrittelystä jonka tekeminen on vaativaa ja aikaa vievää. Tietokannan rakenteen kuvaus on siis itsessään jo arvokas ja voi täyttää immateriaalisen teoksen tunnusmerkit. | ||
+ | |||
+ | Palvelun omistaja yleensä haluaa palvelustaan säännölliset varmuuskopiot (''eng database dump'') kaiken varalle. Tietokannasta - tai vastaavasta tehtynä se paljastaa tekotavan ja mahdollistaa ratkaisun monistamisen rajatta. Immateriaalinen teos siis siirtyy toimittajalta asiakkaalle. Mitkä ovat sen käyttö- ja levitysoikeudet? Saako sillä tai sitä hyödyntäen rakentaa palvelun uudelleen? Toisen palveluntarjoajan, kolmannen osapuolen avustamana? Käyttäen samoja - tai kilpailevan toimittajan komponentteja? | ||
+ | |||
+ | Mitä jos palvelun omistaja ei saa, tai ei ole saanut vuosikausiin kopiota tiedoistaan? Niistä on otettu varmuuskopiot, mutta ne ovat palvelun toteuttajan hallussa. Mitä jos osapuolet riitaantuvat, esimerkiksi nousseista hinnoista - tai syötetyn sisällön omistajuudesta keskustellessa - ja palvelusopimus lakkaa, pahimmassa tapauksessa palvelu sammuu verkosta samalla? | ||
+ | |||
+ | Palvelun omistajan syöttämien tietojen hallitseminen - olivat ne sitten palveluntarjoajan tai omissa tiloissa, on mahdollista jos niiden normaalia käyttöä laajempi hyödyntäminen on estetty teknisellä muodolla (ei esimerkiksi luovuteta tekstimuotoista tms luettavaa tietokannan varmuuskopiota) tai pääsynestolla. Hallinnan menetys nostaa lähtökynnystä (''barrier to exit'') ja saattaa laskea kynnystä kovempaan hinnoitteluun tai muihin sopimusehtoihin kun tiedetään, että toteutuksen kilpailuttaminen on vaikeaa. | ||
+ | |||
+ | Kummankin osapuolen näkemys on ymmärrettävä: | ||
+ | * Tietokantasuunnittelu on kallista ja helposti monistettavaa/väärinkäytettävää arvoa, sitä halutaan suojella. Toisaalta alan kilpailu on kovaa ja kokonaisuuden oikeuksista, riitapykälistä ja yhteistyön lopettamisen yksityiskohtia ei haluta tuoda esille hankinta/tarjousvaiheessa. | ||
+ | * Voisi olettaa, että tiedon tuottaja ja lähde omistaa - sekä hallitsee tietonsa täysin. Näin ei kuitenkaan aina ole, koska asia ei ole tullut mieleen hankinta/kilpailutusvaiheesa. Jälkikäteen asiaa on enää vaikea sopia jos oma tieto on jo ulkopuolisen kontrollissa ja tyydyttävään sopimukseen ei olisi päässyt hankintavaiheessakaan. | ||
+ | |||
+ | Tärkeintä olisi, että molemmille osapuolille on selvää alusta asti: | ||
+ | * kenen omaisuutta sisältö on | ||
+ | * kenen omaisuutta sen tekninen kuvaus on (esim tietokannan rakenne) | ||
+ | * missä muodossa tiedot on tallennettu (jokin tunnettu relaatiotietokanta ja/tai yhdistelmä tms) | ||
+ | * missä sisällön tallennus sijaitsee fyysisesti (palvelun omistajan, toteuttajan vai kolmannen osapuolen tiloissa) | ||
+ | * kenellä on rajoittamattomat pääsyoikeudet palvelun osiin ja sisältöön | ||
+ | * kuka ottaa eri osista varmuuskopiot, missä muodossa ja mihin | ||
+ | * saako palvelun omistajalla säännöllisen varmuuskopion jota voi itse - tai palkattu kolmas osapuoli tulkita | ||
+ | * jos varmuuskopio ohjelmakoodeista ja sisällöstä luovutetaan, onko niiden toimivuutta / pystyttämistä kokeiltu säännöllisesti | ||
+ | |||
+ | Kaikka ylläolevaa olisi hyvä miettiä jo ennen hankintapäätöstä. Kannattaa miettiä mitä tapahtuu jos osapuolet riitaantuvat ja keskeyttääkö riitaantuminen / sopimuksen tulkinta esim oikeudessa toiminnan tai sen kehittämisen / siirtämisen uuteen palvelimeen, ohjelmointikieleen, tietokantaan jne. Onko yllämainittuja kohtia mainittu sopimuksessa ja mitä niiden rikkomisesta seuraa? | ||
+ | |||
+ | Aiheesta muualla: | ||
* [http://it2010.fi/ it2010.fi] | * [http://it2010.fi/ it2010.fi] | ||
* [http://it2010.fi/ IT2015 uudistetut sopimusehdot] | * [http://it2010.fi/ IT2015 uudistetut sopimusehdot] |
Versio 2. lokakuuta 2016 kello 09.24
Palvelun omistajalle digitalisaatio asettaa isoja haasteita teknologian kehitysnopeuden ja käyttöönottotahdin ollessa muita teollisuudenaloja nopeampi. Monen yhteisön päättäjälle tietotekniikka vain sivuaa itse yhteisön ydintoimintaa - mutta silti sähköisten palveluiden tarjoamiselle kasvaa paineita ja niiden suunnittelu ja rakentaminen vaatii paljon perehtymistä ja asiantuntijaresursseja joita ei välttämättä ole käytettävissä. Vääriä valintoja tehdessä investointi saattaa vaatia uudelleen rakentamista ennen aikojaan ja väärälle valitulle teknologialle sopivan toimittajan löytäminen myöhemmin saattaa olla vaikeaa ja kallista.
Yhteisön johdolle toimiva, joskin työläs vaihtoehto tehdä oikeita valintoja vähillä resursseilla on itse perehtyä verkkopalveluiden ratkaisuihin ja analysoida paras vaihtoehto eri arkkitehtuureista, tekniikoista ja kehityksen trendeistä.
Sivulle on koottu yhteenveto eri osa-alueista auttamaan päätöksenteossa ja herättämään ajatuksia.
Sisällysluettelo
Kohderyhmät
Kohderyhmä ja sen suhde palveluun yleensä määrittelee palvelun toteutustavan ja arkkitehtuurin. Arkkitehtuurivalintoja on viime aikoina muokannut mobiililaitteiden suosion kasvu ja toisaalta web-käyttöliittymien ulkoasun ja vasteellisuuden kehittyminen, jonka myötä sen kehitysmalleja on kopioitu henkilökohtaisten tietokoneiden käyttöliittymien kehityksestä.
Komponenttien ja arkkitehtuurin valinta perustuu usein kohderyhmän käyttöprofiilista ja siihen investoitujen kehitys- ja ylläpitokustannusten kompromissista. Jos palvelua/palvelu:
- käyetään satunnaisesti
- käytetään toistuvasti
- käytetään eri päätelaitteilta kuten tietokoneelta ja mobiililaitteesta
- käytetään päätelaitteeseen asennetulla sovelluksella
- käsittelee tekstiä monimutkaisempia aineistoja kuten karttoja, videota tai ääntä
käytetään satunnaisesti
Jos käyttö on satunnaista, enimmäkseen tekstin ja kuvien käsittelyä ja tapahtuu tietokoneelta - yleinen tapa on toteuttaa se web-selaimessa ja valittavana on useita eri frameworkkeja ja arkkitehtuureita.
Tyypillinen esimerkki on henkilön rekisteröinti palveluun, jossa syötetään henkilö- ja yhteystiedot.
käytetään toistuvasti
MVC mielekäs
käytetään eri päätelaitteilta
MVC raskas, applikaatioserveri kevyempi, eri alustojen jaettu koodi kustannustehokkaampi
käytetään päätelaitteeseen asennetulla sovelluksella
käsitellään tekstiä monimutkaisempia aineistoja
kartat, multimedia -> app
Arkkitehtuurit
Templaattipohjaiset
Esimmäisen sukupolven palveluita kehitettiin enimmäkseen templaatti-järjestelmien avulla. Yksinkertaisimmillaan kaikki tietokantakyselyt tehtiin käsin suoraan käyttöliittymän templaateista ja niiden kehittäminen ja ylläpito oli hidasta ja kallista.
Asiakas-palvelin frameworkit
Toisen sukupolven arkkiehtuuriksi voidaan kutsua asiakas-palvelin arkkiehtuuria jossa itse sovellus muodostuu palvelimessa jatkuvasti pyörivästä sovelluksesta tietokantoineen ja käyttäjän päässä oli pelkistetty käyttöliittymä ja sen yhteydet, metodit sovellukseen.
Malli-Näkymä-Käsittelijä (MVC)
Kolmannen sukupolven palvelut noudattavat usein MVC (Model view controller, malli-näkymä-käsittelijä) arkkiehtuuria jota on jo pitkään käytetty henkilökohtaisen tietokoneiden graafisissa ohjelmistoissa.
Java ja applikaatioserverit, Frameworkit, RESTful, rikkaat asiakaat
Teknologiat
html5
Frameworkit
Drupal on selainpohjainen sisällönhallintajärjestelmä (CMS), jonka avulla luot, hallitset ja julkaiset sisältöä verkkosivuille ilman teknistä osaamista verkkosivujen toteuttamisesta. Drupal soveltuu pienten verkkosivujen toteutuksesta aina laajoihin ja haastaviin verkkototeutuksiin.
Wordpress
Joomla
Django
Javascript
Arkkitehtuureita:
jQuery (jquery.com) selainriippumaton, modulaarinen (core, UI, mobile, 3. osapuolen pluginit) abstraktiokirjasto joka helpottaa javascript-toteutuksen toteuttamista (dom-model, ajax jne).
AngularJS angularjs.org.
React reactjs.com.
MEAN (mean.io)
Visuaalisia kirjastoja: datatables (datatables.net) on suosittu taulukirjasto. fancytree (github.com - fancytree) ja jstree (jstree.com) esittävät hierarkian. d3js (d3js.org) soveltuu laajojen tietomassojen visualisointiin.
Mobiiliapplikaatiot
Tietokannat
MariaDB
PostgreSQL
Elastic
Verkkotunnus ja varmenne
Suomalaisen .fi-päätason verkkotunnuksen (TLD, top-level domain) alta jaettavia tunnuksia hallinnoi Viestintävirasto. Hallinnointi tapahtuu domain.fi -verkkopalvelussa. Tunnuksen anominen ja hallinta on maksullista ja siihen liittyvän asioinnin voi tehdä myös palveluntarjoajan kautta.
Tunnuksella voi olla eri haltija ja siihen liittyvän tekniikan hoitamiseen erikoistunut taho. Anottaessa tunnusta, loppukäyttäjän tulee varmistua, että rekisteriin merkitään oikea haltija eikä palveluntarjoajaa koska tällöin täysi omistus- ja määräysvalta ei ole tunnuksen käyttäjällä.
Varmenne
Palvelu tarvitsee varmenteen, jotta kävijä tietää varmasti asioivansa oikeassa palvelussa eikä petosta yrittävällä näköiskopiolla. Varmennetta käytetään aloittamaan suojattu (salattua) SSL-yhteys joka näkyy WWW-selaimessa https linkin yhteystapana. Varmentajia on sekä kaupallisia ja valtioita. Niiden myöntämät varmenteet ovat sidottu verkkotunnuksen nimeen, maksullisia ja määräaikaisia.
Lait, selosteet ja sertifikaatit
Mediakortti
Rekisteriseloste
Henkilötietolain 10 §:n mukaan Rekisterinpitäjän on laadittava henkilörekisteristä rekisteriseloste, josta ilmenee:
1) rekisterinpitäjän ja tarvittaessa tämän edustajan nimi ja yhteystiedot;
2) henkilötietojen käsittelyn tarkoitus;
3) kuvaus rekisteröityjen ryhmästä tai ryhmistä ja näihin liittyvistä tiedoista tai tietoryhmistä;
4) mihin tietoja säännönmukaisesti luovutetaan ja siirretäänkö tietoja Euroopan unionin tai Euroopan talousalueen ulkopuolelle; sekä
5) kuvaus rekisterin suojauksen periaatteista.
Rekisterinpitäjän on pidettävä rekisteriseloste jokaisen saatavilla. Tästä velvollisuudesta voidaan poiketa, jos se on välttämätöntä valtion turvallisuuden, puolustuksen tai yleisen järjestyksen ja turvallisuuden vuoksi, rikosten ehkäisemiseksi tai selvittämiseksi taikka verotukseen tai julkiseen talouteen liittyvän valvontatehtävän vuoksi[1].
Tietoturvaseloste
Henkilötietolaki
Sähköisen viestinnän tietosuojalaki
- käyttöä kuvaavien tietojen tallentaminen käyttäjän päätelaitteelle ja niiden käyttö (evästeet / keksit / cookiet)
EU direktiivit
Viranomaisvaatimukset
Asioijan tunnistaminen, roolit ja valtuudet
Palvelun luonteesta riippuu riittääkö pelkkä henkilön tunnistaminen koko asiointiin vai tarvitseeko tapahtuma tietoa myös tunnistetun henkilön oikeuksista eri rooleihin ja valtuuksiin. Suurin osa tunnistusmenetelmistä ei sisällä roolitietoa ja palvelun toteuttaminen vaatii tällöin yhteydet taustajärjestelmiin joiden tiedot on tyypilisesti suojattu lailla ja siten yhteys vaatii sopimuksen rekisterinpitäjään ja sen käyttö on maksullista.
Asioinnin osapuoliin ja asiointikohteeseen liittyviä tietoja:
- nimi
- yksilöivät tunnukset HETU, SATU, Y-Tunnus ja niiden väliset sidokset
- kansalaisuus
- asuinpaikka
- asioijan elossa olo / kuolema
- ikä ja täysi-ikäisyys
tarkempia tietoja
- oikeudellinen toimikelpoisuuden rajoitukset
- alaikäisen tai edunvalvonnan alaisen edustajan valtuutus
- avioliitto- tai rekisteröity parisuhde
- yhteisöt: yhdistykset, säätiöt, kunnat, seurakunnat, valtio - ja nämä ulkomaalaisina
- edustetun yhteisön nimenkirjoitusoikeus - toimivalta, kelpoisuus (Kaupparekisteri)
- edustetun yhteisön päätösvaltaisuus - riittävä määrä allekirjoittajia
- käsitellyn asian omistusoikeudet, panttaukset, tms ja valtakirjat
Osa näistä tiedoista saadaan nykyään Väestörekisterikeskuksen västötietojärjestelmästä (VTJ), verohallinnon rekisteriin tallennetuista KATSO-tunnusten välisisistä valtuutuksista ja Patentti- ja rekisterihallituksen Kaupparekisteristä. Jatkossa Palveluväylän rooli- ja valtuutuspalvelu RoVa yhdistää ja korvaa kaikki edellämainitut julkis- ja yksityissektorin yhteisöjen osalta.
Pankkitunnukset
Julkisen Avaimen Infrastruktuuri (PKI)
Palveluväylä / XROAD
Kolmannen osapuolen sisällöt / Avoin data
Jos palvelu käyttää hyväkseen esimerkiksi karttoja verkkosivuillaan, mistä niitä saa ja millä ehdoilla?
Seuranta
Google Analytics
Maksaminen
NETS on tanskalainen korttimaksamiseen erikoistunut yritys joka vuonna 2012 osti suomalaisen Luottokunta Oy:n. Yrityksen tärkeimmät tuotteet ovat Visa- ja MasterCard kortit ja kauppiaiden korttimaksupäätteet ja -automaatit.
Klarna on vuonna 2005 perustettu ruotsalainen verkkomaksamiseen erikoistunut yritys joka toimii EU-maiden lisäksi Yhdysvalloissa.
Sveawebpay
Paytrail on vuonna 2007 perustettu Suomen Verkkomaksut nimellä ja erikoistunut verkkomaksamiseen.
Poplatek
ApplePay
iZettle on Applen kassapalvelu.
Pivo Kassa on Osuuspankin kuukausimaksullinen kassalaite, kuittitulostin, käteislipas, viivakoodinlukija ja korttipääte. Varastonhallinta ja raportointi. Kassatapahtumista ja verkkokaupan ostoksista veloitetaan tapahtumapohjaisesti.
MobilePay on Danske Pankin älypuhelimen maksujärjestelmä.
Sopimukset
Palvelun toteutusta tilattaessa kannattaa miettiä sen eri elinkaaren vaiheita ja palvelun osien ja siihen syötetyn sisällön oikeuksia. Automaattisesti tulee ajateltua, että ainakin sisältö on palvelun omistajan omaisuutta. Miten toimia tilanteessa jos järjestelmä lakkaa toimimasta tai se tulee rakentaa uudelleen - joko saman palveluntarjoajan tai nykyisen kilpailijan avustamana? Onko se mahdollista ja mielekästä? Mitä se kaikki maksaa ja kauanko se kestää? Onko halvempaa ja nopeampaa aloittaa tietojen syöttö alusta?
Monet palvelut sisältävät tietokannan joka yleensä on SQL-tyyppinen relaatiotietokanta. Tietokanta koostuu tauluista, sen sarakkeista, taulujen välisistä sidoksista ja monesta muusta yksityiskohtaisesta määrittelystä jonka tekeminen on vaativaa ja aikaa vievää. Tietokannan rakenteen kuvaus on siis itsessään jo arvokas ja voi täyttää immateriaalisen teoksen tunnusmerkit.
Palvelun omistaja yleensä haluaa palvelustaan säännölliset varmuuskopiot (eng database dump) kaiken varalle. Tietokannasta - tai vastaavasta tehtynä se paljastaa tekotavan ja mahdollistaa ratkaisun monistamisen rajatta. Immateriaalinen teos siis siirtyy toimittajalta asiakkaalle. Mitkä ovat sen käyttö- ja levitysoikeudet? Saako sillä tai sitä hyödyntäen rakentaa palvelun uudelleen? Toisen palveluntarjoajan, kolmannen osapuolen avustamana? Käyttäen samoja - tai kilpailevan toimittajan komponentteja?
Mitä jos palvelun omistaja ei saa, tai ei ole saanut vuosikausiin kopiota tiedoistaan? Niistä on otettu varmuuskopiot, mutta ne ovat palvelun toteuttajan hallussa. Mitä jos osapuolet riitaantuvat, esimerkiksi nousseista hinnoista - tai syötetyn sisällön omistajuudesta keskustellessa - ja palvelusopimus lakkaa, pahimmassa tapauksessa palvelu sammuu verkosta samalla?
Palvelun omistajan syöttämien tietojen hallitseminen - olivat ne sitten palveluntarjoajan tai omissa tiloissa, on mahdollista jos niiden normaalia käyttöä laajempi hyödyntäminen on estetty teknisellä muodolla (ei esimerkiksi luovuteta tekstimuotoista tms luettavaa tietokannan varmuuskopiota) tai pääsynestolla. Hallinnan menetys nostaa lähtökynnystä (barrier to exit) ja saattaa laskea kynnystä kovempaan hinnoitteluun tai muihin sopimusehtoihin kun tiedetään, että toteutuksen kilpailuttaminen on vaikeaa.
Kummankin osapuolen näkemys on ymmärrettävä:
- Tietokantasuunnittelu on kallista ja helposti monistettavaa/väärinkäytettävää arvoa, sitä halutaan suojella. Toisaalta alan kilpailu on kovaa ja kokonaisuuden oikeuksista, riitapykälistä ja yhteistyön lopettamisen yksityiskohtia ei haluta tuoda esille hankinta/tarjousvaiheessa.
- Voisi olettaa, että tiedon tuottaja ja lähde omistaa - sekä hallitsee tietonsa täysin. Näin ei kuitenkaan aina ole, koska asia ei ole tullut mieleen hankinta/kilpailutusvaiheesa. Jälkikäteen asiaa on enää vaikea sopia jos oma tieto on jo ulkopuolisen kontrollissa ja tyydyttävään sopimukseen ei olisi päässyt hankintavaiheessakaan.
Tärkeintä olisi, että molemmille osapuolille on selvää alusta asti:
- kenen omaisuutta sisältö on
- kenen omaisuutta sen tekninen kuvaus on (esim tietokannan rakenne)
- missä muodossa tiedot on tallennettu (jokin tunnettu relaatiotietokanta ja/tai yhdistelmä tms)
- missä sisällön tallennus sijaitsee fyysisesti (palvelun omistajan, toteuttajan vai kolmannen osapuolen tiloissa)
- kenellä on rajoittamattomat pääsyoikeudet palvelun osiin ja sisältöön
- kuka ottaa eri osista varmuuskopiot, missä muodossa ja mihin
- saako palvelun omistajalla säännöllisen varmuuskopion jota voi itse - tai palkattu kolmas osapuoli tulkita
- jos varmuuskopio ohjelmakoodeista ja sisällöstä luovutetaan, onko niiden toimivuutta / pystyttämistä kokeiltu säännöllisesti
Kaikka ylläolevaa olisi hyvä miettiä jo ennen hankintapäätöstä. Kannattaa miettiä mitä tapahtuu jos osapuolet riitaantuvat ja keskeyttääkö riitaantuminen / sopimuksen tulkinta esim oikeudessa toiminnan tai sen kehittämisen / siirtämisen uuteen palvelimeen, ohjelmointikieleen, tietokantaan jne. Onko yllämainittuja kohtia mainittu sopimuksessa ja mitä niiden rikkomisesta seuraa?
Aiheesta muualla:
- it2010.fi
- IT2015 uudistetut sopimusehdot
- jhs-suositukset.fi - HS 166 Julkisen hallinnon IT-hankintojen yleiset sopimusehdot (JIT 2015)
Katso myös
Lähteet
- ↑ finlex.fi - Henkilötietolaki 523/1999 Viitattu: 2016-03-07