ݺߣ

ݺߣShare a Scribd company logo

Kokonaisarkkitehtuurityön menneisyys, nykyisyys ja tulevaisuus

•Download as PPTX, PDF•
•
Gofore Oy
Gofore Oy

Kokonaisarkkitehtuurityon menneisyys, nykyisyys ja tulevaisuus - Retrospektiivi julkisen hallinnon kokonaisarkkitehtuuriin

1 of 40
Download to read offline
Kokonaisarkkitehtuurityon menneisyys, nykyisyys ja tulevaisuus Retrospektiivi julkisen hallinnon kokonaisarkkitehtuuriin
Agenda • Kokonaisarkkitehtuuri • Menneisyys – 10 vuotta kokonaisarkkitehtuuria • Nykyisyys 2017 • Tulevaisuus?
Gofore Oy • Perustettu 2001 • Liikevaihto 18,5M€  35M€ tavoite 2017 • 15% kannattavuus • 350 asiantuntijaa • 5 Toimipaikkaa: Suomi, Saksa, UK • Suomen paras työpaikka • Euroopan 2. paras työpaikka • Modernien ja ketterien suunnittelu- ja kehitysmenetelmien vahvat onnistumiskokemukset ja kokonaisymmärrys: palvelumuotoilu, kokonaisarkkitehtuuri, Lean, Kanban, Scrum, SAFe • Laaja kokonaisarkkitehtuurityön osaaminen ja kokemus julkishallinnossa sekä teollisuus- ja palveluliiketoiminnan asiakkuuksissa
Kokonaisarkkitehtuuri
Kokonaisarkkitehtuuri • Enterprise Architecture = Yritysarkkitehtuuri = Kokonaisarkkitehtuuri • Organisaation toiminnan rakennekokonaisuus, joka muodostaa toimintakyvykkyyden asiakasarvon tuottamiseksi • Ihmiset ja osaamiset • Prosessit ja toimintamallit • Tiedot ja tietojärjestelmät Toiminta Tieto Järjestelmät Teknologia
Arkkitehtuurisuunnittelu • Arkkitehtuurisuunnittelu on systeemiajatteluun perustuva kokonaisvaltainen ja systemaattinen tapa jäsentää ja kehittää toiminnan rakenteita • Kysymys on organisaation kehittämisestä ja kehittämistoiminnassa käytettävistä menetelmistä ja johtamismalleista • Organisaation kehitystoiminnan sisällöllinen suunnittelumenetelmä • Arkkitehtuurisuunnittelun ja kehittämisen tavoitteena on tuottaa mahdollisimman tehokas ja tarkoituksenmukainen organisaation rakennekokonaisuus ja tuotantosysteemi • Arkkitehtuurisuunnittelun prosessi käsittää toiminnan rakenteita kuvaavien mallien tuottamista ja niihin liittyvää vuorovaikutusta ja päätöksentekoa • Työkalupakki kommunikaatioon ja yhteisymmärryksen luomiseen
Millainen oli tietojärjestelmäkehittämisen ja arkkitehtuurin maailma vuonna 2007?
2007 – järjestelmät ja arkkitehtuuri • Tuotepohjaiset ratkaisut korostuivat hankinnoissa • Räätälöinnin sijaan ”konfigurointia” • Offshoring – tekeminen mm. Baltiassa. Suomenkieliset määrittelyprojektit ja määrittelyjen käännöstyöt. • Joustamattomat integraatioratkaisut • Hyväksymistestausten korostutuminen (sopimuksellinen hyväksyntä) • Thin client & fat backend • Raskaita ja rajapinnoiltaan huonosti toteutettuja ratkaisuja. • Sekalaisia käyttöliittymiä ja kehnoa käytettävyyttä • Järjestelmäkeskeisyys • Isoja kokonaisuuksia ja fokus toiminnallisuuden nippeleissä (käyttötapaukset ja vaatimusluettelot). • Keskitetyt integraatioratkaisut • Integraatiospaghetti hallintaan ja orkesterointi-malliin (EAI, ESB) • SOA puheissa, mutta ei käytännössä. Integraatiot tuotteiden ehdoilla. • ERP-hankkeet vielä suosiossa • Suurien toiminnanohjauksen kokonaisjärjestelmien hankinta suosiossa • Palveluhankintojen ensimmäisiä kokemuksia • Palveluhankinnan soveltamista räätälöityihin ratkaisuihin
2007 - kehitysmallit • Kehitystoiminta monin paikoin hajautunutta • Jokainen kehittää ja tekee asioita itsenäisesti. Yhteisenä elementtinä ehkä yhteinen projektimalli. • Vesiputoustyyppinen kehittäminen ja laajat määrittelyt • Raskaita projekteja, paljon määrittelyjä ja isoja vaatimuslistoja • Jatkuvat muutoskierteet projektien aikana ja niiden jälkeen • IT-palvelunhallinnan korostuminen • ITIL-prosessit, SLA:t ja niiden hallinta • Tapahtumien ja muutostenhallinnan ”tiukka kurittaminen” • Lopputulos- ja sopimuskeskeiset hankinnat: • Hankittiin pääosin lopputuloksia (laajasti määritelty järjestelmä) • Paljon huomiota sopimuksiin (riskien siirto, omistajuus, hyväksyntäkriteerit) ja sopimusriitelyihin • Asenne: toimittajat huijaavat ja sopimusten pitää olla tiukkoja • Kokonaisarkkitehtuuri mallina ja menetelmänä vasta ensimmäisissä kokeiluissa • Prosesseja, tietoja ja tietovirtoja kuvattiin, mutta ilman systemaattista taustaviitekehystä ja yhdenmukaisia malleja. Kuvaustyön fokus yleensä järjestelmän laajuudessa (hankearkkitehtuuri/vaatimusmäärittely). • Ensimmäisiä kohdearkkitehtuureja KA-menetelmää hyödyntäen
Kaikki oli olemassa jo 2007?
Havaintoja kokonaisarkkitehtuurityön kehittymisestä 2007-2017
Onnistumisia • Kokonaisarkkitehtuurin ja sen menetelmien tunnettuus on kasvanut kaiken aikaa ja uusia aloittelijoita lähtee yhä edelleen liikkeelle • Tietohallintolaki on ollut merkittävä alulle panija KA-toimintaan monessa organisaatiossa • Kokonaisarkkitehtuurityö on pääsääntöisesti roolitettu ja vastuutettu selkeästi • Organisaation tilannekuva on saatu monessa organisaatiossa kohtuulliselle tasolle • Tiedot, tietojärjestelmät ja teknologiat hallinnassa – tiedetään mihin ympäristöön kehitetään • Uutta kokonaisuutta palvelevaa arkkitehtuuria on saatu rakennettua etenkin silloin, kun fokus on ollut erilaisissa toiminnallisissa kohdearkkitehtuureissa • On haukattu sopivia ja aidosti toimintaa kiinnostavia paloja suunnittelutyön kohteeksi ja lähtökohtana on ollut todellinen kehitystarve. • On päästy yli ICT-keskeisyydestä ja järjestelmäfokuksesta
Julkisen hallinnon kokonaisarkkitehtuurityön generaatiot FEAR ValtIT Kartturi KuntaIT JHS 179 v1 JHS 179 v2 TOGAF Zachman Framework JHKA Kuntasektorin KA 2006 2017
Julkisen hallinnon kokonaisarkkitehtuurityön generaatiot FEAR ValtIT Kartturi KuntaIT JHS 179 v1 JHS 179 v2 TOGAF Zachman Framework JHKA Kuntasektorin KA Ymmärrys kasvaa: oikea tekemisen tapa ja taso löytyy Odotusten huippu Tietohallintolaki: innostus ja ”pakote” Edelläkävijät: pienen piirin hiljaista kehitystä Tympääntyminen ja pettymys: onko tästä mihinkään? 2006 2017
Mitä on tapahtunut kymmenessä vuodessa? • Menetelmiä ja hallintamalleja on kehitetty monta kierrosta • Paljon paukkuja hallintaan ja menetelmiin – sisällöt ovat olleet toissijaisia. On kuviteltu, että yhteentoimivuuden haasteet ratkeavat hallintamallin, menetelmän ja kuvauspohjien avulla. • Yleisistä malleista on luotu vielä erikseen organisaatio- tai kohdealuekohtaisia sovituksia, jossa menetelmää ja mallipohjia on räätälöity kohteeseen sopivaksi. Toisinaan sovitusta on tehty radikaalillakin tavalla. • Kokonaisarkkitehtuuria on leimannut vahva mallinnus- ja mallikeskeisyys • Menetelmiä on kehitetty, jotta saataisiin ”paremmat ja helpommin hyödynnettävät mallipohjat”. Kartturi-menetelmä on ollut suosiossa nimenomaan JHS:ää kehittyneempien kuvauspohjien vuoksi. • On tuotettu erilaisia malleja muiden ”hyödynnettäväksi”  varsinainen arkkitehtuurinen ajattelu- ja ratkaisukyvykkyys on ollut toissijaista. • Julkishallinnon tason sisältöohjausta on nähty pilkahdellen. Ideat ja suunnitelmat hyviä, toteutukset ontuvia ja hitaita. • VIP ja Valtori • JHKA-yhteiset palvelut • KaPA • VM:n uusi ”ekosysteemisuuntaus”
Mitä on tapahtunut kymmenessä vuodessa? • Tavoiteltua organisaatioiden yhteentoimivuutta ei ole saavutettu kuin erityisalueilla (esim. Kanta, KaPA) • Poikkihallinnolliset arkkitehtuurityöt ovat olleet hedelmällisiä keskustelun avauksia, mutta niistä ei ole syntynyt konkreettisia kehittämistoimenpiteitä – tai niitä ei ole toteutettu. • Sisäistä yhteentoimivuutta on saavutettu jonkin verran, mutta ehkä teknisiin tukipalveluihin painottuen • Vastuun karttamisen dilemma – ”tehkää näin, käyttäkää tätä” • Arkkitehtuurityötä on työnnetty jatkuvasti jonkun muun tehtäväksi keskittymällä toimintamallien, ohjeiden ja pohjien kehittämiseen. • Viime kädessä suunnittelu on jäänyt tekemättä tai se on pudonnut konsultin tehtäväksi • Tavallaan tämä on ollut luonnollinen seuraus siitä, että tekemistä (kehittämistä) on liikaa suhteessa käytettäviin arkkitehtiresursseihin. • Onko määrä ongelma vai tekemisen tapa?
ValtIT/JHKA-kypsyystasomalli (CMM) 2007 2007 oltiin täällä: joko mitään ei oltu aloitettu tai oli juuri herätty 2017 ollaan täällä: standardeja on määritelty vaikka kuinka, mutta niitä ei noudateta (koska ne eivät toimi)
Miksi kypsyystaso ei ole kasvanut? • On jääty loputtomaan menetelmäkehittämisen luuppiin • On tavoiteltu yhtä yhtenäistä menetelmää, kuvausmalleja ja työkaluja. Niitä on kehitetty, jotta ”muut voisivat tehdä työn”. Arkkitehtuuriresurssit ovat olleet kaiken aikaa niukat. • Työkaluista on odotettu hopealuotia, mutta sitä ne eivät ole tarjonneet • Resursseja kroonisesti liian vähän – keskitytään jatkuvasti tulipaloihin ja täytetään kalenterit kokouskeskeisillä kehittämiskäytännöillä • KA-suunnittelu on ollut irrallista käytännön kehittämistyöstä (kehitetään muuta) • Synteesityö jää helposti tekemättä tai ainakin formalisoimatta ja jalkauttamatta • Suunnittelu voi tuottaa hyviä ideoita, mutta niitä ei syystä tai toisesta kyetä toteuttamaan. Arkkitehtuuri ei jalkaudu vaatimuksiksi työjonoilla. • Yksittäisistä suunnitelmista ja selvityksistä ei ole kyetty luomaan kokonaiskuvaa – arkkitehtuuri ja kuvaukset ovat pirstaleisia • On sinällään hyvä, että suunnittelun tapa ja taso vaihtelee kehityskohteen tarpeen mukaisesti, mutta kokonaisuudesta pitäisi kyetä muodostamaan synteesiä. Sitä eivät menetelmät ja välineet tuota.
Liityntä toiminnan johtamiseen ja kehittämiseen • Alkuun (ja valitettavasti toisinaan edelleenkin) on luotu kehittämisprosesseista ja malleista erillistä arkkitehtuurinhallintaa • Arkkitehtuurin hallinnassa on kuvattu liittymä kehittämiseen, mutta kehittämismalleissa ei välttämättä arkkitehtuuriin. Arkkitehtuurisuunnittelua on tehty ikään kuin kehittämistyöstä irrallisena tai vain löyhästi siihen kytkeytyen. • On organisoitu arkkitehtuurifunktioita, jotka tuottavat kuvauksia muiden hyödynnettäväksi • Arkkitehtuurin kytkös organisaatioiden kehittämismalleihin on parantunut kaiken aikaa • Arkkitehtuurin rooli on ollut liian paljon perään katsova ja tarkistuspisteisiin sidottu. Osaamisen ja resurssien puutteessa on arkkitehtuurisuunnittelu ”ulkoistettu” kehityshankkeissa tehtäväksi ja tätä sitten kommentoidaan ja katsellaan. • Etupainoisen ja aidosti ohjaavan arkkitehtuurisuunnittelun aikaansaamisessa edelleen haasteita. Hankkeet lähtevät käyntiin muusta kuin arkkitehtuurisuunnittelusta ja tekevät ratkaisunsa melko itsenäisesti.
KA-hallinnan organisointi • Tekijöitä ja osaajia on vähän. Käytännössä suurin osa käytännön arkkitehtuurityöstä on yleensä ulkoistettu konsulteille. • Suunnittelua tehdään osana hankkeiden suunnittelu- ja määrittelytyötä. Skoopit suppeita ja jatkuvuus epävarmaa. • Toisinaan on hankittu ja tehty laajoja arkkitehtuuripalvelusopimuksia, jolloin on voitu jatkaa suunnittelutyötä pitkäjänteisesti yhden kumppanin kanssa. • Arkkitehtuurityön epäjatkuvuutta on tuottanut myös runsas henkilöstön vaihtuvuus arkkitehtuuritehtävissä • Vastuut on kirjattu ja niitä sovelletaan • Arkkitehdit tukossa kehityshankkeiden tulipaloissa. Kokouskeskeinen kehittämistyö syö valtavasti työaikaa. • Arkkitehdit ovat usein irti toiminnasta ja sen kehittämisestä, jäädään helposti teknisten ratkaisujen tasolle • Välillä on tehty yksityiskohtaisia RACI-matriiseja arkkitehtuurityön vastuista.
KA-toiminnan mittarit ja jatkuva kehittäminen • KA-toimintaa tai kehittämistoimintaa laajempana kokonaisuutena ei juurikaan mitata. • Kehittämistä seurataan lähinnä budjetin ja projektien aikataulujen kautta. • Arkkitehtuurityötä, sen vaikuttavuutta tai työn kehittymistä ei mitata • Ministeriöltä hallinnon alalle kohdentuvaa kehittämis- ja arkkitehtuurityön tulosohjausta on näkynyt hieman • JHKA-kypsyystasomittauksia on toteutettu jonkin verran ja niiden avulla on pyritty löytämään kehityskohteita. • Arviointi on ollut kertaluonteista – ehkä siksi, että on huomattu, ettei edistymistä ole tapahtunut
Suunnittelun kohteet • Vuosina 2007-2017 on tehty paljon eri tyyppisiä arkkitehtuurisuunnitelmia • Valtionhallinto-, kuntasektori ja julkishallintotasoiset arkkitehtuurit • Poikkihallinnolliset kohdearkkitehtuurit eri toimijoiden kesken • Organisaatiotasoiset arkkitehtuurit: järjestelmäkartat ja salkut, tietoarkkitehtuurikuvaukset • Toiminnalliset kohdearkkitehtuurit prosesseittain tai toiminnoittain: onnistuneimmat arkkitehtuurityöt ovat liittyneet erilaisten toiminnallisten kokonaisuuksien tavoitetilan suunnitteluun ja siitä johdettuihin kehitystoimenpiteisiin. • Haasteena on ollut toisaalta rajautuminen välillä vähän liiankin pieniin kokonaisuuksiin. • Kovassa suosiossa ovat olleet teknisluonteiset ”alusta-arkkitehtuurit”, kuten sähköisen asioinnin arkkitehtuurit, asianhallinnan arkkitehtuurit, käyttövaltuushallinnan arkkitehtuurit, integraatioarkkitehtuurit jne. • Haasteena on ollut se, ettei itse ydintoimintaan ja sen suunnitteluun ole uskallettu tai voitu koskea. Myöskään sitoutumista yhteiseen leikkaavaan ”tukitoimintoarkkitehtuuriin” ei ole saatu aikaan, joten tuloksetkin ovat jääneet syntymättä.
KA-välinegeneraatiot ja kehitys • Vuosien varrella on nähty iso joukko erilaisia mallinnustyökaluja mm. • Rational • Visio • ARIS • QPR • Sparx • Archi • Jne. • Notaatioiden osalta on tapahtunut iso harppaus. Erillisistä ja eri lähtökohdista tulleista kuvaustavoista on siirrytty melko paljon koko arkkitehtuurin kattavaan kieleen – ArchiMateen • Tosin, tällä hetkellä trendi näyttää kääntyvän taas siitä pois… • Massiivisten kuvausrepositorioiden ja teknisluonteisen kuvaustavan myötä arkkitehtuuri on etääntynyt johdosta ja päätöksenteosta. On synnytetty liian monimutkaisia ja hankalasti avautuvia kuvauksia väärässä vaiheessa kehittämisprosessia. • Operointimielessä yksityiskohtainen kuvaus voi olla tarpeen, mutta kehittämisen suunnittelun ja päätöksenteon kannalta toimivampaa on käsitteellinen ja konseptoiva mallinnustapa. • Ketteryys on kasvanut myös suunnittelussa, minkä myötä suosiotaan on lisännyt perinteinen Powerpoint- arkkitehtuuri ja erilaiset canvas-pohjat. Olennainen tiivistyy A4:ään. Tarkempi suunnittelu tehdään vasta lähempänä toteutusta.
Kuvaustyön ja arkkitehtuurin hallinnan ”harhapolkuja” • Toiminta-arkkitehtuurin suunnittelun yhteydessä on päädytty usein keskustelemaan olemassa olevan laatu-/toimintajärjestelmän liittämisestä kokonaisuuteen. • Kuvatut prosessit ovat toiminta-arkkitehtuuria, mutta ne kuvaavat nykytilaa toimintaohjetasolla. Kehittämisessä on taas kyse toimintamallien muuttamisesta. Suunnittelun ja suorittamisen abstraktiotasot ovat eri. • Käytännössä toimintajärjestelmätyökalusta on haluttu tehdä arkkitehtuurityökalu tai toisinpäin. • Suunniteltu toimintamallimuutos jalkautuu toteutuessaan toimintajärjestelmän nykytilakuvaukseksi. • Tietoteknisiä rakenteita kuvattaessa mennään helposti liian syvälle ylläpidollisiin fyysisiin elementteihin ja lähdetään pohdintaan CMDB-järjestelmän liittämiseksi arkkitehtuurirepositorioon. • Toimintajärjestelmän tavoin CMDB on fyysinen suorittavan tason kuvaus, kun kehittämistyötä suunnitellaan korkeammalla abstraktiotasolla. • Suunnittelun oikean abstraktiotason löytäminen on avainasia • Mennään liian helposti yksityiskohtiin ja käytännön toteutuksiin
Toimintaympäristön haasteita • Systeeminen ongelma: tekemisen pitää olla virallista, ohjeistettua ja päätettyä • Asiat pitää vastuuttaa sekä toimintamallit määrittää ja ohjeistaa, mutta kuitenkaan ei toimita niin… • Kulttuuri ja maaperä ei ole kovin otollisia kokeilemiselle ja iteratiiviselle etenemiselle • Päätöksentekokoneisto ei siedä epävarmuutta ja toimii reaktiivisesti päätösesityksiin perustuen • Julkisten hankintojen ”tuska” • Pitkät sopimukset ja kasvavat hankintojen koot. Kilpailutuksen tuska on kovaa, joten sitä minimoidaan tekemällä entistä suurempia ja harvempia hankintoja. • Suunnittelua tehdään hankintakeskeisesti ei lopputuloskeskeisesti. Hyvän arkkitehtuurin saa helposti pilattua vääränlaisella kilpailutustavalla. Hankintamalli tulisi miettiä osana arkkitehtuuriratkaisun toteuttamista.
Arkkitehtuurin kypsyys? Arkkitehtuurin kypsyys? On pyöritty kymmenen vuotta jatkuvassa konsolidointikierteessä (mm. hallinnon muutosten seurauksena) Täällä pitäisi olla Arkkitehtuurin ydinrakenteet (tiedot) kunnossa ja tehokkaasti rajapinnoin käytettävissä
Kokonaisarkkitehtuurin nykyisyys
Tämän päivän arkkitehtuuri • Teknologiat (erityisesti frontti) vanhenevat vauhdilla. Uusia sovelluksia syntyy ja kuolee jatkuvasti. • Tiedon, bisneslogiikan ja rajapintojen merkitys tehokkaan ja toimivan arkkitehtuurin ytimenä kasvaa koko ajan • Arkkitehtuuri on entistä hajautuneempaa • Paljon erillisiä palveluita (mikropalvelut) • Laskenta ja logiikka on palannut osin päätelaitteisiin ja toisaalta hajautunut suurten datamäärien myötä laitteisiin (IoT). • Pilvipalvelut itsestään selviä • Teknologia-arkkitehtuurin rooli suunnittelussa on väistynyt taka-alalle. Kukaan ei halua rakentaa sitä enää itse. • Ohjelmistokehityksen automaatioaste noussut valtavasti • Integroidut ja automatisoidut testaus- ja julkaisumenettelyt. Julkaisusyklit ovat tiheytyneet paljon. • Kaikki kehittäminen on enemmän tai vähemmän ketterää, mutta sitä johdetaan vesiputousmaisessa projektirakenteessa. • Aikataulut ja tehtävät ajavat sisällön ja tulosten edelle • Tuoteomistajatyössä parantamisen varaa
KA-työn tilanne • Arkkitehtuurityötä on tehty laajasti julkishallinnossa sen eri tasoilla • KA on asiana melko hyvin juurtunut tietohallintojen piirissä, toiminnan puolella vaihteleva ymmärrys • Tekeminen on hyvin hankevetoista – luodaan arkkitehtuuria yksittäisten jo käynnistettyjen kehityshankkeiden sisällä. • Hyvä arkkitehtuurisuunnitelma on nähty hyväksi lähtökohdaksi hankkeen ja siinä kehitettävien ratkaisujen toteuttamista • Kohdearkkitehtuureista johdetaan suoraan vaatimuksia sovelluskehityksen työjonoihin • Arkkitehtuurisuunnittelua ei välttämättä tilata tai pyydetä, vaan KA on osa suunnittelun työkalupakkia. • Palvelut (SaaS ja PaaS) ovat lisääntyneet merkittävästi. Valmiiden ratkaisuiden etsiminen on keventänyt suunnittelua.
Kokonaisarkkitehtuurin tulevaisuus?
Muutos on jatkuvaa ja kiihtyvää • Tarve toimintaympäristön ja asiakastarpeiden analysoinnille kasvaa • Suunnittelun asiakas- ja käyttäjälähtöisyys korostuvat kaiken aikaa ja siinä on menty syvemmälle tasolle: ratkaistaanko edes oikeita ongelmia? • Maailma on täynnä erilaisia kehittämisongelmia ja ratkaistavia asioita, mutta mihin niistä kannattaa tarttua? • Tarve nopeaan ongelman validointiin, ratkaisumallien etsintään ja kehityspanosten allokointiin • Ketteröityminen jatkuu ja valtaa alaa. Leanin virtaustehokkuus tulee vähitellen koko kehittämisprosessiin. • Konsultit juoksevat ketterästi, mutta tilaajan toimintamallien muutos on vaikeaa. Funktionaaliset organisaatiorakenteet ja johtamisjärjestelmä esteenä monessa.
Tulevaisuus? • Tietoarkkitehtuuri ja rajapinnat korostuvat – core kuntoon • Tiedot on saatava kuntoon ja rajapintojen kautta liikkumaan • Ymmärrys toiminnan luonteesta ja aidosta yhteisten ratkaisujen tarpeesta • Miltä osin on järkevää tavoitella ja tuottaa yhteisiä ratkaisuja? • Resurssitehokkuuden pyrkimystä ei ole järkevää viedä äärilaitaan, vaan rakentaa toiminnasta ratkaisuineen modulaarista. • Julkishallinnon tasolla VM:n rooli ja pyrkimykset arkkitehtuurityössä ovat muuttumassa? • Organisaatioidenvälisen suoran yhteentoimivuuden sijaan laajoja ekosysteemejä • Arkkitehtuurimenetelmien ja suunnittelun merkitys organisaatioiden oman kehittämisen kannalta korostuu (ei tehdä vain VM:ää varten)
Kehittämisen menetelmäpakki laajenee ja menetelmät integroituvat Lean Palvelu- muotoilu Palvelupolku Asiakas Kokonais- arkkitehtuuri Palveluprosessi Toiminnan kyvykkyydet
Case Vantaa
Kehittämisen kokonaisuus VALMISTELU Tavoitetilan suunnittelu ja kehittämistarpeiden valmistelu ja analysointi TILANNEKUVA Landscapen hallinta ja arkkitehtuurikyvykkyyden kehittäminen TOTEUTUS Arkkitehtuurisuunnittelu ja vaatimustenhallinta kehityshankkeissa Portfolion hallinta ja investointi- päätösten ohjaus IDEA KONSEPTI DESIGN STRATEGINEN KEHITTÄMISEN SUUNNITTELU Tavoitetilan arkkitehtuurinen jäsennys Jatkuva virtaus, nopeat syklit Jatkuva taustaprosessi Jatkuva taustaprosessi
Suunnittelu ja suunnitelmat muuttuvat • Perinteisen raskaan viipaloinnin ja mallinnuksen sijaan tarvitaan kevyempiä nopeasti yhteisymmärrystä luovia ja maksimaalisia oppimiskokemuksia tuottavia arkkitehtuurimalleja • Lean-filosofian mukaisesti suunnittelun fokus kiinnittyy asiakkaaseen ja asiakkaan arvon tuottoon. • Suunnittelu on • Kehitysongelman tunnistusta ja validointia • Ratkaisukonseptien suunnittelua • Business case:ien luomista • Toteutettavuuden arvioimista ja investointien ohjausta • Toteutusvaiheessa designin suunnittelua ja arkkitehtuurisen kiitotien rakentamista • Suunnittelu on iteratiivista ja oppivaa. Synnytetään suunnitellaan, testataan ja opitaan.
Opit
Mitä opimme? • Ollaan oikealla tiellä • Kaikkiaan koko julkisen hallinnon kokonaisarkkitehtuurityö on nostanut esiin kehittämistoiminnan kipupisteitä ja saanut niihin liittyviä asioita etenemään • On ymmärretty, että on kysymys kehittämistoiminnasta ja siihen liittyvästä suunnittelusta • Lähtötilanne ja sen tilannetieto on jatkuvasti paremmin hanskassa • Esim. hallinnon muutostilanteissa on päästy nopeasti keskustelemaan erilaisista tilanteista ja yhteisistä ratkaisuista • Menetelmät eivät ratkaise, vaan ihmiset ja osaaminen ratkaisevat • Standardimenetelmät eivät ratkaise itsessään kehittämisongelmia – tarvitaan osaamista, älyä ja ajattelua • Tarvitaan yhteistyötä, yhdessä tekemistä ja kommunikointia • Tarvitaan aikaa ja kapasiteettia tehdä järkevää suunnittelutyötä
Mitä opimme? • Kehitys kehittyy ja vauhti kasvaa koko ajan. Lean ja ketteryys valtaa alaa – myös arkkitehtuurisuunnittelun tulee mukautua. Tarvitaan oikea-aikaista ongelmien validoinnin, konseptoinnin ja ratkaisusuunnittelun adaptiivisia malleja ja käytäntöjä. • Ongelmat eivät välttämättä liity siihen, että tekemistä on liikaa, vaan siihen, että sitä tehdään liian suurissa paloissa ja aikaa vievin kokouskeskeisin käytännöin.
Kiitos Juha Siltanen, juha.siltanen@gofore.com

More Related Content

Kokonaisarkkitehtuurityön menneisyys, nykyisyys ja tulevaisuus

  • 1. Kokonaisarkkitehtuurityon menneisyys, nykyisyys ja tulevaisuus Retrospektiivi julkisen hallinnon kokonaisarkkitehtuuriin
  • 2. Agenda • Kokonaisarkkitehtuuri • Menneisyys – 10 vuotta kokonaisarkkitehtuuria • Nykyisyys 2017 • Tulevaisuus?
  • 3. Gofore Oy • Perustettu 2001 • Liikevaihto 18,5M€  35M€ tavoite 2017 • 15% kannattavuus • 350 asiantuntijaa • 5 Toimipaikkaa: Suomi, Saksa, UK • Suomen paras työpaikka • Euroopan 2. paras työpaikka • Modernien ja ketterien suunnittelu- ja kehitysmenetelmien vahvat onnistumiskokemukset ja kokonaisymmärrys: palvelumuotoilu, kokonaisarkkitehtuuri, Lean, Kanban, Scrum, SAFe • Laaja kokonaisarkkitehtuurityön osaaminen ja kokemus julkishallinnossa sekä teollisuus- ja palveluliiketoiminnan asiakkuuksissa
  • 5. Kokonaisarkkitehtuuri • Enterprise Architecture = Yritysarkkitehtuuri = Kokonaisarkkitehtuuri • Organisaation toiminnan rakennekokonaisuus, joka muodostaa toimintakyvykkyyden asiakasarvon tuottamiseksi • Ihmiset ja osaamiset • Prosessit ja toimintamallit • Tiedot ja tietojärjestelmät Toiminta Tieto Järjestelmät Teknologia
  • 6. Arkkitehtuurisuunnittelu • Arkkitehtuurisuunnittelu on systeemiajatteluun perustuva kokonaisvaltainen ja systemaattinen tapa jäsentää ja kehittää toiminnan rakenteita • Kysymys on organisaation kehittämisestä ja kehittämistoiminnassa käytettävistä menetelmistä ja johtamismalleista • Organisaation kehitystoiminnan sisällöllinen suunnittelumenetelmä • Arkkitehtuurisuunnittelun ja kehittämisen tavoitteena on tuottaa mahdollisimman tehokas ja tarkoituksenmukainen organisaation rakennekokonaisuus ja tuotantosysteemi • Arkkitehtuurisuunnittelun prosessi käsittää toiminnan rakenteita kuvaavien mallien tuottamista ja niihin liittyvää vuorovaikutusta ja päätöksentekoa • Työkalupakki kommunikaatioon ja yhteisymmärryksen luomiseen
  • 7. Millainen oli tietojärjestelmäkehittämisen ja arkkitehtuurin maailma vuonna 2007?
  • 8. 2007 – järjestelmät ja arkkitehtuuri • Tuotepohjaiset ratkaisut korostuivat hankinnoissa • Räätälöinnin sijaan ”konfigurointia” • Offshoring – tekeminen mm. Baltiassa. Suomenkieliset määrittelyprojektit ja määrittelyjen käännöstyöt. • Joustamattomat integraatioratkaisut • Hyväksymistestausten korostutuminen (sopimuksellinen hyväksyntä) • Thin client & fat backend • Raskaita ja rajapinnoiltaan huonosti toteutettuja ratkaisuja. • Sekalaisia käyttöliittymiä ja kehnoa käytettävyyttä • Järjestelmäkeskeisyys • Isoja kokonaisuuksia ja fokus toiminnallisuuden nippeleissä (käyttötapaukset ja vaatimusluettelot). • Keskitetyt integraatioratkaisut • Integraatiospaghetti hallintaan ja orkesterointi-malliin (EAI, ESB) • SOA puheissa, mutta ei käytännössä. Integraatiot tuotteiden ehdoilla. • ERP-hankkeet vielä suosiossa • Suurien toiminnanohjauksen kokonaisjärjestelmien hankinta suosiossa • Palveluhankintojen ensimmäisiä kokemuksia • Palveluhankinnan soveltamista räätälöityihin ratkaisuihin
  • 9. 2007 - kehitysmallit • Kehitystoiminta monin paikoin hajautunutta • Jokainen kehittää ja tekee asioita itsenäisesti. Yhteisenä elementtinä ehkä yhteinen projektimalli. • Vesiputoustyyppinen kehittäminen ja laajat määrittelyt • Raskaita projekteja, paljon määrittelyjä ja isoja vaatimuslistoja • Jatkuvat muutoskierteet projektien aikana ja niiden jälkeen • IT-palvelunhallinnan korostuminen • ITIL-prosessit, SLA:t ja niiden hallinta • Tapahtumien ja muutostenhallinnan ”tiukka kurittaminen” • Lopputulos- ja sopimuskeskeiset hankinnat: • Hankittiin pääosin lopputuloksia (laajasti määritelty järjestelmä) • Paljon huomiota sopimuksiin (riskien siirto, omistajuus, hyväksyntäkriteerit) ja sopimusriitelyihin • Asenne: toimittajat huijaavat ja sopimusten pitää olla tiukkoja • Kokonaisarkkitehtuuri mallina ja menetelmänä vasta ensimmäisissä kokeiluissa • Prosesseja, tietoja ja tietovirtoja kuvattiin, mutta ilman systemaattista taustaviitekehystä ja yhdenmukaisia malleja. Kuvaustyön fokus yleensä järjestelmän laajuudessa (hankearkkitehtuuri/vaatimusmäärittely). • Ensimmäisiä kohdearkkitehtuureja KA-menetelmää hyödyntäen
  • 12. Onnistumisia • Kokonaisarkkitehtuurin ja sen menetelmien tunnettuus on kasvanut kaiken aikaa ja uusia aloittelijoita lähtee yhä edelleen liikkeelle • Tietohallintolaki on ollut merkittävä alulle panija KA-toimintaan monessa organisaatiossa • Kokonaisarkkitehtuurityö on pääsääntöisesti roolitettu ja vastuutettu selkeästi • Organisaation tilannekuva on saatu monessa organisaatiossa kohtuulliselle tasolle • Tiedot, tietojärjestelmät ja teknologiat hallinnassa – tiedetään mihin ympäristöön kehitetään • Uutta kokonaisuutta palvelevaa arkkitehtuuria on saatu rakennettua etenkin silloin, kun fokus on ollut erilaisissa toiminnallisissa kohdearkkitehtuureissa • On haukattu sopivia ja aidosti toimintaa kiinnostavia paloja suunnittelutyön kohteeksi ja lähtökohtana on ollut todellinen kehitystarve. • On päästy yli ICT-keskeisyydestä ja järjestelmäfokuksesta
  • 13. Julkisen hallinnon kokonaisarkkitehtuurityön generaatiot FEAR ValtIT Kartturi KuntaIT JHS 179 v1 JHS 179 v2 TOGAF Zachman Framework JHKA Kuntasektorin KA 2006 2017
  • 14. Julkisen hallinnon kokonaisarkkitehtuurityön generaatiot FEAR ValtIT Kartturi KuntaIT JHS 179 v1 JHS 179 v2 TOGAF Zachman Framework JHKA Kuntasektorin KA Ymmärrys kasvaa: oikea tekemisen tapa ja taso löytyy Odotusten huippu Tietohallintolaki: innostus ja ”pakote” Edelläkävijät: pienen piirin hiljaista kehitystä Tympääntyminen ja pettymys: onko tästä mihinkään? 2006 2017
  • 15. Mitä on tapahtunut kymmenessä vuodessa? • Menetelmiä ja hallintamalleja on kehitetty monta kierrosta • Paljon paukkuja hallintaan ja menetelmiin – sisällöt ovat olleet toissijaisia. On kuviteltu, että yhteentoimivuuden haasteet ratkeavat hallintamallin, menetelmän ja kuvauspohjien avulla. • Yleisistä malleista on luotu vielä erikseen organisaatio- tai kohdealuekohtaisia sovituksia, jossa menetelmää ja mallipohjia on räätälöity kohteeseen sopivaksi. Toisinaan sovitusta on tehty radikaalillakin tavalla. • Kokonaisarkkitehtuuria on leimannut vahva mallinnus- ja mallikeskeisyys • Menetelmiä on kehitetty, jotta saataisiin ”paremmat ja helpommin hyödynnettävät mallipohjat”. Kartturi-menetelmä on ollut suosiossa nimenomaan JHS:ää kehittyneempien kuvauspohjien vuoksi. • On tuotettu erilaisia malleja muiden ”hyödynnettäväksi”  varsinainen arkkitehtuurinen ajattelu- ja ratkaisukyvykkyys on ollut toissijaista. • Julkishallinnon tason sisältöohjausta on nähty pilkahdellen. Ideat ja suunnitelmat hyviä, toteutukset ontuvia ja hitaita. • VIP ja Valtori • JHKA-yhteiset palvelut • KaPA • VM:n uusi ”ekosysteemisuuntaus”
  • 16. Mitä on tapahtunut kymmenessä vuodessa? • Tavoiteltua organisaatioiden yhteentoimivuutta ei ole saavutettu kuin erityisalueilla (esim. Kanta, KaPA) • Poikkihallinnolliset arkkitehtuurityöt ovat olleet hedelmällisiä keskustelun avauksia, mutta niistä ei ole syntynyt konkreettisia kehittämistoimenpiteitä – tai niitä ei ole toteutettu. • Sisäistä yhteentoimivuutta on saavutettu jonkin verran, mutta ehkä teknisiin tukipalveluihin painottuen • Vastuun karttamisen dilemma – ”tehkää näin, käyttäkää tätä” • Arkkitehtuurityötä on työnnetty jatkuvasti jonkun muun tehtäväksi keskittymällä toimintamallien, ohjeiden ja pohjien kehittämiseen. • Viime kädessä suunnittelu on jäänyt tekemättä tai se on pudonnut konsultin tehtäväksi • Tavallaan tämä on ollut luonnollinen seuraus siitä, että tekemistä (kehittämistä) on liikaa suhteessa käytettäviin arkkitehtiresursseihin. • Onko määrä ongelma vai tekemisen tapa?
  • 17. ValtIT/JHKA-kypsyystasomalli (CMM) 2007 2007 oltiin täällä: joko mitään ei oltu aloitettu tai oli juuri herätty 2017 ollaan täällä: standardeja on määritelty vaikka kuinka, mutta niitä ei noudateta (koska ne eivät toimi)
  • 18. Miksi kypsyystaso ei ole kasvanut? • On jääty loputtomaan menetelmäkehittämisen luuppiin • On tavoiteltu yhtä yhtenäistä menetelmää, kuvausmalleja ja työkaluja. Niitä on kehitetty, jotta ”muut voisivat tehdä työn”. Arkkitehtuuriresurssit ovat olleet kaiken aikaa niukat. • Työkaluista on odotettu hopealuotia, mutta sitä ne eivät ole tarjonneet • Resursseja kroonisesti liian vähän – keskitytään jatkuvasti tulipaloihin ja täytetään kalenterit kokouskeskeisillä kehittämiskäytännöillä • KA-suunnittelu on ollut irrallista käytännön kehittämistyöstä (kehitetään muuta) • Synteesityö jää helposti tekemättä tai ainakin formalisoimatta ja jalkauttamatta • Suunnittelu voi tuottaa hyviä ideoita, mutta niitä ei syystä tai toisesta kyetä toteuttamaan. Arkkitehtuuri ei jalkaudu vaatimuksiksi työjonoilla. • Yksittäisistä suunnitelmista ja selvityksistä ei ole kyetty luomaan kokonaiskuvaa – arkkitehtuuri ja kuvaukset ovat pirstaleisia • On sinällään hyvä, että suunnittelun tapa ja taso vaihtelee kehityskohteen tarpeen mukaisesti, mutta kokonaisuudesta pitäisi kyetä muodostamaan synteesiä. Sitä eivät menetelmät ja välineet tuota.
  • 19. Liityntä toiminnan johtamiseen ja kehittämiseen • Alkuun (ja valitettavasti toisinaan edelleenkin) on luotu kehittämisprosesseista ja malleista erillistä arkkitehtuurinhallintaa • Arkkitehtuurin hallinnassa on kuvattu liittymä kehittämiseen, mutta kehittämismalleissa ei välttämättä arkkitehtuuriin. Arkkitehtuurisuunnittelua on tehty ikään kuin kehittämistyöstä irrallisena tai vain löyhästi siihen kytkeytyen. • On organisoitu arkkitehtuurifunktioita, jotka tuottavat kuvauksia muiden hyödynnettäväksi • Arkkitehtuurin kytkös organisaatioiden kehittämismalleihin on parantunut kaiken aikaa • Arkkitehtuurin rooli on ollut liian paljon perään katsova ja tarkistuspisteisiin sidottu. Osaamisen ja resurssien puutteessa on arkkitehtuurisuunnittelu ”ulkoistettu” kehityshankkeissa tehtäväksi ja tätä sitten kommentoidaan ja katsellaan. • Etupainoisen ja aidosti ohjaavan arkkitehtuurisuunnittelun aikaansaamisessa edelleen haasteita. Hankkeet lähtevät käyntiin muusta kuin arkkitehtuurisuunnittelusta ja tekevät ratkaisunsa melko itsenäisesti.
  • 20. KA-hallinnan organisointi • Tekijöitä ja osaajia on vähän. Käytännössä suurin osa käytännön arkkitehtuurityöstä on yleensä ulkoistettu konsulteille. • Suunnittelua tehdään osana hankkeiden suunnittelu- ja määrittelytyötä. Skoopit suppeita ja jatkuvuus epävarmaa. • Toisinaan on hankittu ja tehty laajoja arkkitehtuuripalvelusopimuksia, jolloin on voitu jatkaa suunnittelutyötä pitkäjänteisesti yhden kumppanin kanssa. • Arkkitehtuurityön epäjatkuvuutta on tuottanut myös runsas henkilöstön vaihtuvuus arkkitehtuuritehtävissä • Vastuut on kirjattu ja niitä sovelletaan • Arkkitehdit tukossa kehityshankkeiden tulipaloissa. Kokouskeskeinen kehittämistyö syö valtavasti työaikaa. • Arkkitehdit ovat usein irti toiminnasta ja sen kehittämisestä, jäädään helposti teknisten ratkaisujen tasolle • Välillä on tehty yksityiskohtaisia RACI-matriiseja arkkitehtuurityön vastuista.
  • 21. KA-toiminnan mittarit ja jatkuva kehittäminen • KA-toimintaa tai kehittämistoimintaa laajempana kokonaisuutena ei juurikaan mitata. • Kehittämistä seurataan lähinnä budjetin ja projektien aikataulujen kautta. • Arkkitehtuurityötä, sen vaikuttavuutta tai työn kehittymistä ei mitata • Ministeriöltä hallinnon alalle kohdentuvaa kehittämis- ja arkkitehtuurityön tulosohjausta on näkynyt hieman • JHKA-kypsyystasomittauksia on toteutettu jonkin verran ja niiden avulla on pyritty löytämään kehityskohteita. • Arviointi on ollut kertaluonteista – ehkä siksi, että on huomattu, ettei edistymistä ole tapahtunut
  • 22. Suunnittelun kohteet • Vuosina 2007-2017 on tehty paljon eri tyyppisiä arkkitehtuurisuunnitelmia • Valtionhallinto-, kuntasektori ja julkishallintotasoiset arkkitehtuurit • Poikkihallinnolliset kohdearkkitehtuurit eri toimijoiden kesken • Organisaatiotasoiset arkkitehtuurit: järjestelmäkartat ja salkut, tietoarkkitehtuurikuvaukset • Toiminnalliset kohdearkkitehtuurit prosesseittain tai toiminnoittain: onnistuneimmat arkkitehtuurityöt ovat liittyneet erilaisten toiminnallisten kokonaisuuksien tavoitetilan suunnitteluun ja siitä johdettuihin kehitystoimenpiteisiin. • Haasteena on ollut toisaalta rajautuminen välillä vähän liiankin pieniin kokonaisuuksiin. • Kovassa suosiossa ovat olleet teknisluonteiset ”alusta-arkkitehtuurit”, kuten sähköisen asioinnin arkkitehtuurit, asianhallinnan arkkitehtuurit, käyttövaltuushallinnan arkkitehtuurit, integraatioarkkitehtuurit jne. • Haasteena on ollut se, ettei itse ydintoimintaan ja sen suunnitteluun ole uskallettu tai voitu koskea. Myöskään sitoutumista yhteiseen leikkaavaan ”tukitoimintoarkkitehtuuriin” ei ole saatu aikaan, joten tuloksetkin ovat jääneet syntymättä.
  • 23. KA-välinegeneraatiot ja kehitys • Vuosien varrella on nähty iso joukko erilaisia mallinnustyökaluja mm. • Rational • Visio • ARIS • QPR • Sparx • Archi • Jne. • Notaatioiden osalta on tapahtunut iso harppaus. Erillisistä ja eri lähtökohdista tulleista kuvaustavoista on siirrytty melko paljon koko arkkitehtuurin kattavaan kieleen – ArchiMateen • Tosin, tällä hetkellä trendi näyttää kääntyvän taas siitä pois… • Massiivisten kuvausrepositorioiden ja teknisluonteisen kuvaustavan myötä arkkitehtuuri on etääntynyt johdosta ja päätöksenteosta. On synnytetty liian monimutkaisia ja hankalasti avautuvia kuvauksia väärässä vaiheessa kehittämisprosessia. • Operointimielessä yksityiskohtainen kuvaus voi olla tarpeen, mutta kehittämisen suunnittelun ja päätöksenteon kannalta toimivampaa on käsitteellinen ja konseptoiva mallinnustapa. • Ketteryys on kasvanut myös suunnittelussa, minkä myötä suosiotaan on lisännyt perinteinen Powerpoint- arkkitehtuuri ja erilaiset canvas-pohjat. Olennainen tiivistyy A4:ään. Tarkempi suunnittelu tehdään vasta lähempänä toteutusta.
  • 24. Kuvaustyön ja arkkitehtuurin hallinnan ”harhapolkuja” • Toiminta-arkkitehtuurin suunnittelun yhteydessä on päädytty usein keskustelemaan olemassa olevan laatu-/toimintajärjestelmän liittämisestä kokonaisuuteen. • Kuvatut prosessit ovat toiminta-arkkitehtuuria, mutta ne kuvaavat nykytilaa toimintaohjetasolla. Kehittämisessä on taas kyse toimintamallien muuttamisesta. Suunnittelun ja suorittamisen abstraktiotasot ovat eri. • Käytännössä toimintajärjestelmätyökalusta on haluttu tehdä arkkitehtuurityökalu tai toisinpäin. • Suunniteltu toimintamallimuutos jalkautuu toteutuessaan toimintajärjestelmän nykytilakuvaukseksi. • Tietoteknisiä rakenteita kuvattaessa mennään helposti liian syvälle ylläpidollisiin fyysisiin elementteihin ja lähdetään pohdintaan CMDB-järjestelmän liittämiseksi arkkitehtuurirepositorioon. • Toimintajärjestelmän tavoin CMDB on fyysinen suorittavan tason kuvaus, kun kehittämistyötä suunnitellaan korkeammalla abstraktiotasolla. • Suunnittelun oikean abstraktiotason löytäminen on avainasia • Mennään liian helposti yksityiskohtiin ja käytännön toteutuksiin
  • 25. Toimintaympäristön haasteita • Systeeminen ongelma: tekemisen pitää olla virallista, ohjeistettua ja päätettyä • Asiat pitää vastuuttaa sekä toimintamallit määrittää ja ohjeistaa, mutta kuitenkaan ei toimita niin… • Kulttuuri ja maaperä ei ole kovin otollisia kokeilemiselle ja iteratiiviselle etenemiselle • Päätöksentekokoneisto ei siedä epävarmuutta ja toimii reaktiivisesti päätösesityksiin perustuen • Julkisten hankintojen ”tuska” • Pitkät sopimukset ja kasvavat hankintojen koot. Kilpailutuksen tuska on kovaa, joten sitä minimoidaan tekemällä entistä suurempia ja harvempia hankintoja. • Suunnittelua tehdään hankintakeskeisesti ei lopputuloskeskeisesti. Hyvän arkkitehtuurin saa helposti pilattua vääränlaisella kilpailutustavalla. Hankintamalli tulisi miettiä osana arkkitehtuuriratkaisun toteuttamista.
  • 26. Arkkitehtuurin kypsyys? Arkkitehtuurin kypsyys? On pyöritty kymmenen vuotta jatkuvassa konsolidointikierteessä (mm. hallinnon muutosten seurauksena) Täällä pitäisi olla Arkkitehtuurin ydinrakenteet (tiedot) kunnossa ja tehokkaasti rajapinnoin käytettävissä
  • 28. Tämän päivän arkkitehtuuri • Teknologiat (erityisesti frontti) vanhenevat vauhdilla. Uusia sovelluksia syntyy ja kuolee jatkuvasti. • Tiedon, bisneslogiikan ja rajapintojen merkitys tehokkaan ja toimivan arkkitehtuurin ytimenä kasvaa koko ajan • Arkkitehtuuri on entistä hajautuneempaa • Paljon erillisiä palveluita (mikropalvelut) • Laskenta ja logiikka on palannut osin päätelaitteisiin ja toisaalta hajautunut suurten datamäärien myötä laitteisiin (IoT). • Pilvipalvelut itsestään selviä • Teknologia-arkkitehtuurin rooli suunnittelussa on väistynyt taka-alalle. Kukaan ei halua rakentaa sitä enää itse. • Ohjelmistokehityksen automaatioaste noussut valtavasti • Integroidut ja automatisoidut testaus- ja julkaisumenettelyt. Julkaisusyklit ovat tiheytyneet paljon. • Kaikki kehittäminen on enemmän tai vähemmän ketterää, mutta sitä johdetaan vesiputousmaisessa projektirakenteessa. • Aikataulut ja tehtävät ajavat sisällön ja tulosten edelle • Tuoteomistajatyössä parantamisen varaa
  • 29. KA-työn tilanne • Arkkitehtuurityötä on tehty laajasti julkishallinnossa sen eri tasoilla • KA on asiana melko hyvin juurtunut tietohallintojen piirissä, toiminnan puolella vaihteleva ymmärrys • Tekeminen on hyvin hankevetoista – luodaan arkkitehtuuria yksittäisten jo käynnistettyjen kehityshankkeiden sisällä. • Hyvä arkkitehtuurisuunnitelma on nähty hyväksi lähtökohdaksi hankkeen ja siinä kehitettävien ratkaisujen toteuttamista • Kohdearkkitehtuureista johdetaan suoraan vaatimuksia sovelluskehityksen työjonoihin • Arkkitehtuurisuunnittelua ei välttämättä tilata tai pyydetä, vaan KA on osa suunnittelun työkalupakkia. • Palvelut (SaaS ja PaaS) ovat lisääntyneet merkittävästi. Valmiiden ratkaisuiden etsiminen on keventänyt suunnittelua.
  • 31. Muutos on jatkuvaa ja kiihtyvää • Tarve toimintaympäristön ja asiakastarpeiden analysoinnille kasvaa • Suunnittelun asiakas- ja käyttäjälähtöisyys korostuvat kaiken aikaa ja siinä on menty syvemmälle tasolle: ratkaistaanko edes oikeita ongelmia? • Maailma on täynnä erilaisia kehittämisongelmia ja ratkaistavia asioita, mutta mihin niistä kannattaa tarttua? • Tarve nopeaan ongelman validointiin, ratkaisumallien etsintään ja kehityspanosten allokointiin • Ketteröityminen jatkuu ja valtaa alaa. Leanin virtaustehokkuus tulee vähitellen koko kehittämisprosessiin. • Konsultit juoksevat ketterästi, mutta tilaajan toimintamallien muutos on vaikeaa. Funktionaaliset organisaatiorakenteet ja johtamisjärjestelmä esteenä monessa.
  • 32. Tulevaisuus? • Tietoarkkitehtuuri ja rajapinnat korostuvat – core kuntoon • Tiedot on saatava kuntoon ja rajapintojen kautta liikkumaan • Ymmärrys toiminnan luonteesta ja aidosta yhteisten ratkaisujen tarpeesta • Miltä osin on järkevää tavoitella ja tuottaa yhteisiä ratkaisuja? • Resurssitehokkuuden pyrkimystä ei ole järkevää viedä äärilaitaan, vaan rakentaa toiminnasta ratkaisuineen modulaarista. • Julkishallinnon tasolla VM:n rooli ja pyrkimykset arkkitehtuurityössä ovat muuttumassa? • Organisaatioidenvälisen suoran yhteentoimivuuden sijaan laajoja ekosysteemejä • Arkkitehtuurimenetelmien ja suunnittelun merkitys organisaatioiden oman kehittämisen kannalta korostuu (ei tehdä vain VM:ää varten)
  • 33. Kehittämisen menetelmäpakki laajenee ja menetelmät integroituvat Lean Palvelu- muotoilu Palvelupolku Asiakas Kokonais- arkkitehtuuri Palveluprosessi Toiminnan kyvykkyydet
  • 35. Kehittämisen kokonaisuus VALMISTELU Tavoitetilan suunnittelu ja kehittämistarpeiden valmistelu ja analysointi TILANNEKUVA Landscapen hallinta ja arkkitehtuurikyvykkyyden kehittäminen TOTEUTUS Arkkitehtuurisuunnittelu ja vaatimustenhallinta kehityshankkeissa Portfolion hallinta ja investointi- päätösten ohjaus IDEA KONSEPTI DESIGN STRATEGINEN KEHITTÄMISEN SUUNNITTELU Tavoitetilan arkkitehtuurinen jäsennys Jatkuva virtaus, nopeat syklit Jatkuva taustaprosessi Jatkuva taustaprosessi
  • 36. Suunnittelu ja suunnitelmat muuttuvat • Perinteisen raskaan viipaloinnin ja mallinnuksen sijaan tarvitaan kevyempiä nopeasti yhteisymmärrystä luovia ja maksimaalisia oppimiskokemuksia tuottavia arkkitehtuurimalleja • Lean-filosofian mukaisesti suunnittelun fokus kiinnittyy asiakkaaseen ja asiakkaan arvon tuottoon. • Suunnittelu on • Kehitysongelman tunnistusta ja validointia • Ratkaisukonseptien suunnittelua • Business case:ien luomista • Toteutettavuuden arvioimista ja investointien ohjausta • Toteutusvaiheessa designin suunnittelua ja arkkitehtuurisen kiitotien rakentamista • Suunnittelu on iteratiivista ja oppivaa. Synnytetään suunnitellaan, testataan ja opitaan.
  • 37. Opit
  • 38. Mitä opimme? • Ollaan oikealla tiellä • Kaikkiaan koko julkisen hallinnon kokonaisarkkitehtuurityö on nostanut esiin kehittämistoiminnan kipupisteitä ja saanut niihin liittyviä asioita etenemään • On ymmärretty, että on kysymys kehittämistoiminnasta ja siihen liittyvästä suunnittelusta • Lähtötilanne ja sen tilannetieto on jatkuvasti paremmin hanskassa • Esim. hallinnon muutostilanteissa on päästy nopeasti keskustelemaan erilaisista tilanteista ja yhteisistä ratkaisuista • Menetelmät eivät ratkaise, vaan ihmiset ja osaaminen ratkaisevat • Standardimenetelmät eivät ratkaise itsessään kehittämisongelmia – tarvitaan osaamista, älyä ja ajattelua • Tarvitaan yhteistyötä, yhdessä tekemistä ja kommunikointia • Tarvitaan aikaa ja kapasiteettia tehdä järkevää suunnittelutyötä
  • 39. Mitä opimme? • Kehitys kehittyy ja vauhti kasvaa koko ajan. Lean ja ketteryys valtaa alaa – myös arkkitehtuurisuunnittelun tulee mukautua. Tarvitaan oikea-aikaista ongelmien validoinnin, konseptoinnin ja ratkaisusuunnittelun adaptiivisia malleja ja käytäntöjä. • Ongelmat eivät välttämättä liity siihen, että tekemistä on liikaa, vaan siihen, että sitä tehdään liian suurissa paloissa ja aikaa vievin kokouskeskeisin käytännöin.