Tekninen track, muistio (draft)

Alustava työjärjestys:

Terveiset:

tavoitteena yhteinen näkemus arkkitehtuurista
(entä jos aloitettaisiin puhtaalta pöydältä, mikä olisi välineistö?)
Teknisten osion tulisi keskittyä löytämään ratkaisuja ongelmien sijaan

Työjärjestys (tekninen track)

• 9.00 - 9.15 Avaus, johtoryhmien tahtotila ja päivän tavoitteet
• 9.15 - 10.15 Projektien teknisten valintojen ja niiden perusteiden esittely (á 20 min)
  
  • Peppi/Perusrekisteri
  • OTM
  • ROTI
• 10.15 - 11.30 Edellisen työvaiheen esityksiin pohjautuen
  
  • yhtäläisyyksien ja erojen identifiointi ja dokumentointi
  • valintaperusteiden dokumentointi
  • arkkitehtuuriperiaatteiden kirjaaminen ja mahdollisten niistä poikkeamisedellytysten kirjaaminen
• 11.30 - 12.15 Lounas
• 12.15 - 14.00 Havaittujen erojen arviointi ja dokumentointi
  
  • projektikolmion näkökulmasta
  • yhteistyön aikajänteen näkökulmasta
• 14.00 - 15.00 Tulevien valintatilanteiden hallinnointi prosessina
  
  • Prosessin suunnittelu: vaihtoehtoiset toimintatavat

Asioita:

• Jos yhteinen arkkitehtuuri, mitkä ovat valintakriteerit... puhutaanko koko arkkitehtuurista vai integraatioarkkitehtuurista
• Extreme-taso: yksi yhteinen järjestelmä ja projekti (tulevaisuuden tavoitetaso)
  
  • Teknisestä näkökulmasta: SOA periaatteissa ei tarvi olla yhtä yhteinen järjestelmä, ennemmin yksi yhteinen projekti
    
    • tavoitteena kuitenkin järjestelmäkokonaisuus?
  • Tarvitaanko yhteinen integraatioalusta / integraatioarkkitehtuuri?
  • Jos tehdään yhdessä projektissa, onko näin isosta kehitystiimissä / tiimeissä järkeä?
  • "jos aloitettaisiin puhtaalta pöydältä, mikä olisi välineistö?"
    
    
• Mitä tarkoittaa palvelu?
  
  • puhutaan SOA palvelusta
  • autonomisia ajettavia kokonaisuuksia, tarjoaa rajapinnat sen käyttämiseksi
  • ei puhuta käyttöliittymästä

• Mahdollinen arkkitehtuurilinajaus: palveluiden toteuttamisessa ei väliä (SOA) järjestelmäkokonaisuuksien kannalta
  
  • onko väliä?
  • mitä tarkoittaa ylläpidettävyyden ja jatkokehityksen kannalta
    
    • Onko perusrekisterin kaltaisessa järjestelmässä järkeä, että kokonaisuus koostuu palveluista, jotka tehty tekniikalla X
    • Extreme-mallissa ongelma ei ole tekninen vaan hallinnollinen
      
      • Mahdollista ehkä "ekosysteemi", jossa projektit tuottaa tiettyjä kokonaisuuksia, joista kokonaisuus syntyy
      • Mitä yhteisymmärystä teknologiasta tarvitaan
        
        • tietomalli....
        • deploy käytäntö...

Extreme

• Voiko extreme vaihtoehdossa tehdä omilla teknologiavalinnoilla, onko mahdollista ja millä edellytyksillä?
  
  • saadaanko tästä ylläpidettävä ja jatkokehitettävä kokonaisuus
• Ennen Extreme vaihetta tulee kuitenkin kaikilla osapuolilla jo paljon tuloksilla (omilla teknologioilla), Saadaanko tästä SOA kokonaisuus
• Yhteinen näkemys teknologiapaletista, jolla Extreme vaiheeseen siirtyminen myöhemmin mahdollista
• "Helpoin" tapa siirtyä Extreme malliin on jatkaa vain yhtä projektia ja yhdistää siihen muiden projektien nykyiset tulokset
  
  • Kaikkien projektien yhdistäminen tuottaa liian ison projektin?
• Tutkitaan
  
  • 1) Palvelut omille kehitystiimeille, jotka palvelun toteuttaa ja vastaa siitä (ja tälle hallinnollinen malli)
    
    • mitkä riskit (osaaminen, ylläpito jne)
  • 2) Spekuloidaan voidaanko tekniikat lyödä lukkoon (entä jos aloitettaisiin puhtaalta pöydältä, mikä olisi välineistö?)

2)

Yleinen järjestelmäarkkitehtuuri: SOA

Matriisi:

https://docs.google.com/a/eduix.it/spreadsheets/d/15wifOI6T4Wsyj0SWBq5WpdMueHjW8rvbUU4mkUpEFuY/edit#gid=0