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)
- 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ö?"
- Teknisestä näkökulmasta: SOA periaatteissa ei tarvi olla yhtä yhteinen järjestelmä, ennemmin yksi yhteinen projekti
- 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 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ö?)
- 1) Palvelut omille kehitystiimeille, jotka palvelun toteuttaa (ja tälle hallinnollinen malli)
2)
Yleinen järjestelmäarkkitehtuuri: SOA
Matriisi: