Tiptop – kokonaisarkkitehtuurin kuvaaminen projektissa

Esitys aiheesta: "Tiptop – kokonaisarkkitehtuurin kuvaaminen projektissa"— Esityksen transkriptio:

1 Tiptop – kokonaisarkkitehtuurin kuvaaminen projektissa
Draft Mikko Arasmaa

2 Sisällys Kartturi-mallin kuvaukset TIPTOP-projektissa Taustaa:
Eri tasojen kuvaukset: Periaatteellinen taso Käsitteellinen taso Looginen taso Fyysinen taso Kuvausten tuottamisen malli Lähdeaineisto (projektin aikana aiemmin tuotettu materiaali) Aikataulut, vastuut, kohdeyleisö kullekin kuvaukselle Taustaa: Tarve kokonaisarkkitehtuurille TIPTOP-projektissa Miksi ja miksi ei Kartturi-malli?

3 Kartturi-mallin soveltaminen: mitä kuvauksia tuotetaan

4 Periaatteellisen tason kuvaukset
Arkkitehtuuriperiaatteet: Tiptop-projektissa nojaudutaan OPI-osahankkeessa määriteltyihin arkkitehtuuriperiaatteisiin Korkeakoulut, OKM ja viranomaiset tuottavat yhteismitallisen tietomallin ja yhteentoimivuuden edellytykset (ml. tietovaranto viranomaistiedosta) Korkeakoulut päättävät mitä sovelluksia tuottavat Tietovarannot muodostavat yhteisen ytimen Integraatiotason kontrolli ”in house” Siirtymä tavoitetilaan asteittain, ”modulaarisesti” Yhteiset toimintaa tukevat palvelut keskeisille tiedoille Tietoturva- ja tietosuojaperiaatteet: Tietoturvallisuuden osa-alueista tärkeimpiä ovat ohjelmistoturvallisuus ja tietoaineistoturvallisuus

5 Käsitteellisen tason kuvaukset
Käsitteistö: TIPTOP-sanaston luominen Roolit: Käyttäjäryhmät ja prosesseihin osallistuvat toimijat Roolit-tietovarannon määrittely Tietojärjestelmäpalvelut: Käytännössä määritelty jo Kartturin mukaisella tasolla, ”laatikkoleikki” –> ylimmän tason kuvaus TIPTOPista Teknologiavaatimukset: Kokoaa yhteen teknologiaan liittyvät tarpeet Teknologiavalinnat on jo suurelta osin tehty, mutta tärkeää on että niiden perusteet muistetaan tulevaisuudessakin (miksi on tehty jokin ratkaisu)

6 Loogisen tason kuvaukset
Prosessilista/kartta ja prosessikuvaukset: Laurin tekemä työ Tietomallit: Kuvataan vain XDW-muutostarpeet Loogiset tietovarannot: Vedetään yhteen tietovarantojen määrittelyt Tietovirrat: Mitä tietoa siirtyy palveluiden välillä, mistä tietovarannosta jne. Järjestelmät/tietovarannot -matriisi: Tarvitaanko jos tietovirtakuvaukset tehdään kunnolla? Looginen tietojärjestelmäpalveluiden jäsennys: Käytännössä TIPTOPin ”yleiskuva” ja SOA-kuvat Integraatiomalli: Palveluiden integrointitavat, millä vaatimuksilla Palveluväylän käyttötavat Suorituskyky- ja volyymivaatimukset Teknologiakomponentit: Loogisen tason teknologiakuva

7 Fyysisen tason kuvaukset
Rajapinnat ja liittymät: Kaikkien fyysisten rajapintojen kuvaukset Koodistot: Tietomallin tietojen kooditus, arvolistat jne. Teknologiavalinnat Käytettävät teknologiat nimi- ja versiotasolla

8 Kuvausten tuottamisen malli
Projektissa ei ole eikä siihen muodosteta erillistä arkkitehtuurifunktiota, vaan tieto syntyy sprinteissä suunnittelun ja toteuttamisen yhteydessä. Ei käynnistetä erikseen massiivista arkkitehtuurin kuvaustyötä Tästä tiedosta voidaan projektin tasolla jalostaa Kartturin mukaiset kuvaukset Projektissa on jo tuotettu materiaalia jotka käyvät KA-kuvauksista sellaisenaan tai muokkaamalla: ”Master-kuvat”, laatikkoleikit + yleiskuva Prosessit eri tasoilla SOA-kuva Kehitysympäristö Tietovarantojen määrittelyä Metamalli-ehdotus …

9 Kuvausten tuottaminen: aikataulu, vastuut, kohdeyleisö
Vastuutaho Kohdeyleisö Arkkitehtuuriperiaatteet Jo olemassa CSC, TY Ulkoiset sidosryhmät Tietoturva- ja tietosuojaperiaatteet 12/2012 Kaikki Käsitteistö Roolit Tietovarannon toteuttajat Projektiin osallistuvat Tietojärjestelmäpalvelut Teknologiavaatimukset Jo olemassa, kerättävä yhteen  12/2012

10 Kuvausten tuottaminen: aikataulu, vastuut, kohdeyleisö
Vastuutaho Kohdeyleisö Prosessikartta Jo olemassa Lauri Stigell Kaikki Prosessikuvaukset 12/2012 Tietomallit Jatkuva koko projektin ajan Totti Tuhkanen Loogiset tietovarannot Sitä mukaa kuin tietovarantojen määrittely etenee Tietovarannoista vastaavat Projektiin osallistuvat (myös projektin jälkeinen aika) Tietovirrat Järjestelmät/tietovarannot Looginen tietojärjestelmäpalveluiden jäsennys CSC, TY Integraatiomalli 2/2013 Teknologiakomponentit

11 Kuvausten tuottaminen: aikataulu, vastuut, kohdeyleisö
Vastuutaho Kohdeyleisö Rajapinnat ja liittymät Sitä mukaa kuin määrittely etenee Rajapintojen suunnittelijat ja toteuttajat Projektiin osallistuvat (myös projektin jälkeinen aika) Koodistot Teknologiavalinnat Pääosin jo olemassa CSC, TY

12 Tarve kokonaisarkkitehtuurille TIPTOP-projektissa
RAKETTI-OPI:n linjauksen mukaisesti opiskelun ja opetuksen tukipalveluiden viitearkkitehtuuria tarkennetaan kehitysprojekteissa ja muutokset viedään hyväksyttäväksi hankekauden aikana OPI:n Synergia-ryhmälle  velvoite projektille TIPTOP-projektin keskeisimmät haasteet joihin voitaisiin osittain vastata KA-työllä: Kts. Riskilista wikissä Monta tiimiä, monta tapaa, monta kieltä  hajautettu toimintamalli Ensimmäinen (tai ensimmäisiä) kansallinen SOA-mallin mukainen projekti Ei selvää kokonaiskuvaa tavoitellusta lopputuloksesta projektin sisällä eikä ulkopuolella Kaksi tasoa: Projektin ”itseymmärrys”, mitä olemme tuottamassa Kommunikointi ulkopuolisille

13 Kartturi-mallin soveltaminen: Miksi ja miksi ei?
Oikein ja hyvin tehtynä kokoaa erilaiset palaset yhteen ja osoittaa myös niiden väliset suhteet. Tarjoaa yhden kommunikaatiomenetelmän sidosryhmille sekä peruspaketin TIPTOP-kokonaisuudesta projektin jälkeiselle ajalle Miksi ei: KA ja agile-menetelmät ovat osittain vastakkaisia näkökulmia. Ei voida olettaa, että tällaisessa projektissa on ensin KA ja sitten vasta toteutetaan, vaan mennään iteratiivisesti eteenpäin jolloin KA:lla ei ole sellaista suunnannäyttäjäroolia kuin oppikirjoissa. Kokonaisarkkitehtuuri ei auta kovinkaan paljoa päivittäisissä projektin toteuttamiseen liittyvissä haasteissa. Tämän vuoksi se voidaan helposti nähdä ylätason pilvien piirtämisenä jota projektissa on jo ollut riittävästi aiemminkin. Tämän vuoksi projektissa tulisi edelleen kiinnittää erityistä huomiota riittävän sovellusarkkitehtuurillisen osaamisen saamisen projektin käyttöön. Kartturi-malli ei ole ensisijaisesti suunniteltu yksittäisen kehitysprojektin tarpeisiin, vaan ennemminkin koko organisaation laajuiseen tarkasteluun. Tämän vuoksi sitä joudutaan venyttämään melko paljon, jotta siitä olisi jotakin hyötyä myös projektin aikana.