Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1

Tietojärjestelmät eivät rakennu itsestään, vaan niiden kehitys vaatii monia askelia vaatimusmäärittelystä, suunnitteluun, toteutukseen, testaukseen ja toimittamiseen. Yksi tärkeä askel on järjestelmän arkkitehtuurin suunnittelu, joka luo perustan onnistuneelle ratkaisulle. Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturi on useamman vuoden ajan järjestänyt 3+3 -päiväistä “Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssia, jossa käsitellään tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja ja keinoja erinomaiseen ratkaisuun pääsemiseksi. Osallistuin kurssin ensimmäiselle kolmipäiväiselle teoria- ja alustuspainotteiselle osiolle alkuviikosta ja tietämystä kertyi suurilta osin avainteemoista ja 4+1 -mallin hyödyntämisestä. Kurssin toinen osa on edessä syksyllä.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1

Tietojärjestelmäarkkitehti on henkilö, jonka vastuulla on liiketoimintaa tukevan järjestelmän kokonaisvaltainen suunnittelu sekä soveltuvimpien teknologioiden valinta. Arkkitehtuurin suunnittelu vaatii haastavaa koordinointia, suunnittelua sekä kommunikointia ja arkkitehtuurin avainteemojen ymmärtäminen on tärkeää sekä asiakkaana että toimittajina toimiville organisaatioille. Tietojärjestelmän arkkitehtuuri luo perustan onnistuneelle ratkaisulle ja sen suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Yksi tällaisista on Tieturin 3+3 -päiväinen “Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssi, joka käsittelee tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja ja sen kurssisisältö on määritelty Open Groupin määrittelemää Information Technology Architect Certification Level 1 (ITAC) sertifikaatin vaatimusten mukaan.

“Valmennusohjelman suoritettuaan osallistuja osaa tietojärjestelmäarkkitehdin työn kannalta systemaattiset toimintatavat ja merkittävät välineet. Kurssilla arkkitehtuuria tarkastellaan kokonaisvaltaisesti kuitenkin valmentaen osallistujaa erityisesti sovellusarkkitehtuurin suunnittelun haasteisiin.” – Tieturi

Valmennusohjelman ensimmäinen kolmipäiväinen osio käsitteli aihepiiriä aika paljon teoreettisesti ja painottui aiheen alustukseen. Oikeastaan vasta viimeisenä päivänä käytiin läpi arkkitehtuurin suunnitteluun liittyviä vaiheita käytännössä 4+1 -mallin kautta, joka oli sellaista sisältöä, jota olin kurssilta odottanut. Paljon kurssilla tuli kuitenkin asiaa ja materiaalia, osa tuttua ja osa uutta, mutta päällimmäisenä mieleen jäi kommunikoinnin ja tiedon jakamisen tärkeys, joka on oleellista kaikissa muissakin sovelluskehityksen rooleissa. Lisäksi kurssin vetäjä, Juhani Lind, kertoi käytännön esimerkkejä ja omia kokemuksiaan sovelluskehitysprojekteista, joka täydensi aiheen käsittelyä. Kumma kyllä, enemmän tuntui olevan kerrottavaa epäonnistuneista projekteista, kuin onnistuneista, vaikka arkkitehtuuriratkaisu olisikin ollut erinomainen :)

Kurssi jatkuu toisella osalla syksyllä, jolloin luvassa on arkkitehtuuriin liittyen metodeja, testausta, SOAa, integraatiota, lisensointia, tietoturvaa, valvontaa, arviointia, dokumentointia ja hallintaa. Ainakin paperilla mielenkiintoisempia aiheita kuin alkuosassa.

Osa 1, päivä 1:

  • Tietojärjestelmäarkkitehdin toimenkuva
    • Arkkitehdin toimenkuva ja vastuut, kommunikoinnin haaste, arkkitehdin osaamisprofiili
  • Miten arkkitehtuuria hyödynnetään?
    • Kuinka arkkitehtuuri rakennetaan?, arkkitehtuurin sidosryhmät, kuinka arkkitehtuuria sovelletaan käytännössä?, metodeja arkkitehtuurin luomiseen
  • Hyvä kokonaisarkkitehtuuri
    • Yritysarkkitehtuurin rakentaminen, arkkitehtuurin käyttäminen, arkkitehtuurin merkitys, viitekehyksiä: TOGAF vs. Zachman Framework
  • Arkkitehtuurin laatukriteerit
    • Arkkitehtuurin suhde liiketoiminnan tavoitteisiin, millainen on hyvä arkkitehtuuri? suunnittelumalleja toteuttamiseen, Quality Attribute Workshop (QAW)

Ensimmäinen päivä ei juurikaan käsitellyt arkkitehtuurin suunnittelun käytännön asioita, vaan painottui mielestäni liikaakin tietojärjestelmäarkkitehdin toimenkuvaan ja yritysarkkitehtuurin suunnittelun teoriapohjaiseen läpikäymiseen. Lyhyesti tiivistettynä IT-arkkitehti tarvitsee liiketoiminnan tarpeita tyydyttävien ratkaisujen tekemiseen laaja-alaista osaamista, projektiin mielellään kokonaisvaltaisesti osallistumista ja kommunikointia. IT-arkkitehti on teknologisen valon tuoja. Päivän viimeinen aihe, arkkitehtuurin laatukriteerit, oli mielenkiintoinen etenkin pohdittaessa mittaamista ja asteikkoa. Toisaalta päivän jälkeen mieleen ei oikein jäänyt mitään koherenttia kuvaa asiasta, mutta paljon löyhiä ohjenuoria, mitä kokonaisarkkitehtuuri pitää sisällään ja miten sen suunnittelua voidaan lähestyä eri näkökulmista. Kommunikoinnin tärkeys tuli hyvin esille, mutta se on tärkeää jokaisessa projektin vaiheessa. Harjoituksena piirrettiin kuvitteellisen leffateatteriketjun teatterin kontekstuaalinen diagrammi.

Osa 1, päivä 2:

  • Arkkitehtuurin lähtökohtana liiketoiminta
    • Liiketoiminnan strategian ymmärtäminen, BPM (Business Process Management), prosessiorganisaatio, liiketoiminnan ymmärtäminen ja vaikutus arkkitehtuuripäätöksiin, hinta vs. elinkaari
  • Informaatioarkkitehtuuri
    • Liiketoimintalähtöinen informaatioarkkitehtuuri, käsitemallista kannan rakenteeseen, informaatioarkkitehtuurin hyödyntäminen, informaatioarkkitehtuurin suunnittelumalleja
  • Ohjelmistoarkkitehtuurin parhaat käytännöt
    • Sovellusarkkitehtuurin suunnittelumalleja, taktiikat ja patternit, Anti Patterns

Kurssin toinen päivä jatkoi aihepiirin käsittelyä arkkitehtuurin suunnittelun taktiikoista ja malleista, kehottaen näkemään kokonaisuus ja viemään kehitys läpi inkrementaalisesti osittain. Eli siis ketterästi. Tiedon jakamisesta keskusteltiin edelleen ja esitettiin muutaman kerran vuodessa kokoontuvaa virtuaalista arkkitehtuuritiimiä hyvien ja huonojen kokemusten jakamiseen. Harjoituksissa pohdittiin reaalimaailman vastineita erilaisille malleille kuten hajautettu tai tapahtumapohjainen järjestelmä, piirrettiin teatterin bisneksen prosessikaavio BPMN:llä. Päivän päätteeksi käsiteltiin 1. päivänä ohitettu TOGAF. Paljon asiaa, vähän konkretiaa, lukuun ottamatta TOGAFin nopeahkoa läpikäyntiä.

Osa 1, päivä 3:

  • Sovellusarkkitehtuurin suunnittelu
    • Arkkitehtuurin kerrokset, arkkitehtuurin valintaan vaikuttavat seikat
  • Sovellusarkkitehtuuri ja 4+1 malli
    • Käyttötapaukset lähtökohtana, looginen arkkitehtuuri, komponentti arkkitehtuuri, prosessi arkkitehtuuri, hajautus arkkitehtuuri
  • Rajapintojen suunnittelu
    • Rajapintojen määrittely ja suunnittelu, rajapintojen dokumentointi

Ensimmäisen osan viimeinen päivä lupasi aihepiireiltään enemmän konkretiaa ja sitä se myös tarjosi. Järjestelmän arkkitehtuurin suunnittelua käsiteltiin nyt käymällä läpi Philippe Kruchtenin kehittämän 4+1 -mallin eri näkymiä: Skenaario (käyttötapaus), looginen, prosessi, toteutus ja käyttöönotto. Jos alkuviikosta päivät olivat teoriaa, kuuntelua (ja nuokkumista), nyt päästiin tekemään asioita käytännössä. Kynät ja aivot sauhusivat, kun osallistujat piirsivät leffateatterin toiminnasta käyttötapauksia ja erilaisia kaavioita kuten järjestelmän tasot ja alijärjestelmät -kaavio, komponenttikaavio, rajapinnat ja rautapalikoita sisältävä käyttöönottokaavio. Kolmannen päivän jälkeen kotitehtäväksi jäi vielä 4+1-mallin soveltaminen johonkin oikeaan tai kuvitteelliseen järjestelmään tai sen osaan kurssin toiseen osaan mennessä.

Yhteenveto

“Architecting is making decisions. The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.” Philippe Kruchten, “The Architects – The Software Architecture Team”

Toista osaa odotellessa.

Aiheeseen liittyvät kirjoitukset

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *