Kokonaisarkkitehtuurin hyödyt Sytyke ry:n ja Tietoturva ry:n Kevätseminaari Eetu Niemi, FT Coala Oy
Eetu Niemi Koulutus FT, tiedonhallinta ja logistiikka (TTY) 2016 KTM, tietojärjestelmätiede (JY) 2006 Työkokemus Senior Consultant (Coala) 03/2013-> Kokonaisarkkitehtuuri ja ratkaisuarkkitehtuuri Käyttäjä- ja pääsynhallinta (IAM) Consultant (Accenture) 05/2008-02/2013 Tutkija ja projektipäällikkö (JY) 2006-2008 Pro Gradu -työ (TeliaSonera) 2005 Sertifikaatit ja välineet TOGAF9 Certified, ArchiMate 2 Certified BiZZdesign, Sparx, MEGA Suite, ARIS, QPR, Rational, iserver 2
Väitöstutkimus kokonaisarkkitehtuurin hyötyjen syntymisestä Tapaustutkimus Haastattelut suuressa julkishallinnon organisaatiossa (syksy 2011-alkuvuosi 2012) Päätutkimuskysymys Miten kokonaisarkkitehtuurin hyödyt syntyvät? Näkökulmat Hyötyjen syntyprosessi Kokonaisarkkitehtuurin sidosryhmät Kokonaisarkkitehtuurin tuotteiden ja palveluiden käyttö Kokonaisarkkitehtuurin hyötyjen syntymisen mittaaminen Artikkeliväitöskirja, kuusi journal- ja konferenssiartikkelia 3
Esityksen sisältö 1. Kokonaisarkkitehtuuri ja sen hyödyt 2. Hyötyjen syntymiseen vaikuttavat tekijät ja saadut hyödyt 3. Kokonaisarkkitehtuurin sidosryhmät 4. Kokonaisarkkitehtuurin hyötyjen mittaaminen 5. Kokonaisarkkitehtuurin käyttö IT-palvelukehityksessä 4
Kokonaisarkkitehtuuri ja sen hyödyt 5
Mitä kokonaisarkkitehtuuri on? Enterprise architecture is a coherent whole of principles, methods and models that are used in the design and realization of an enterprise s organizational structure, business processes, information systems, and infrastructure (Lankhorst 2005) Tuotenäkökulma Mallit, kaaviot, periaatteet, roadmapit, julkaisut, muu dokumentaatio An enterprise architecture (EA) identifies the main components of the organization, its information systems, the ways in which these components work together in order to achieve defined business objectives, and the way in which the information systems support the business processes of the organization Enterprise architecting is the set of processes, tools, and structures necessary to implement an enterprise-wide coherent and consistent IT architecture for supporting the enterprise s business operations. It takes a holistic view of the enterprise s IT resources rather than an application-by-application view. (Kaisler et al. 2011) Palvelunäkökulma Arkkitehtuurituki, arkkitehtuurikatselmoinnit, arkkitehtuurianalyysit päätöksentekijöille [EA] is the definition and representation of a high-level view of an enterprise s business processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise Two key components of EA are the planning process (definition), and the direct and tangible outputs of that planning process (representation), i.e., EA documentation (e.g., architecture diagrams, roadmaps, and other artefacts) (Tamm et al. 2011) Prosessinäkökulma Suunnittelu, päätöksenteko, mallintaminen, ylläpito ja hallinta organisaation tai muun kohteena olevan kokonaisuuden rakenteen kuvaus, jota käytetään toiminnan kehittämisessä (JHS 179) the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company s operational model (Ross et al. 2006) 6
Miksi kokonaisarkkitehtuurin hyötyjen syntymistä kannattaa tutkia? Kokonaisarkkitehtuurityön perustelu vaatii hyötyjen osoittamista Organisaation toimintojen on pystyttävä osoittamaan hyödyllisyytensä Vähän empiirisiä tutkimuksia, joissa ylipäätään on todennettu että hyötyjä syntyy On melko hyvin tiedossa, mitä hyötyjä voi parhaassa tapauksessa syntyä Hyötyjen mittaamista on pidetty vaikeana ja sitä ei tehdä käytännössä juuri koskaan Aiemmat tutkimustulokset hyötyjen syntyprosessiin liittyen ovat ristiriitaisia Ei ole yhteisymmärrystä siitä, mitä kautta hyödyt syntyvät Yleisesti hyväksytty teoria kokonaisarkkitehtuurista yleensä puuttuu 7
Kokonaisarkkitehtuurilla on monia potentiaalisia hyötyjä Muutoksen ohjaaminen ja tukeminen Päätöksenteon parantuminen Viestinnän ja yhteistyön kehittäminen Alentuneet (IT) kustannukset Liiketoiminnan ja IT:n yhteentoimivuus Liiketoimintaprosessien kehittäminen Tietojärjestelmien kehittäminen Uudelleenkäyttö Riskien vähentäminen jne. Ks. esim. Tamm et al. 2011 8
Aiemmat kokonaisarkkitehtuurin hyötyjen syntymistä kuvaavat mallit Aier 2014 Boh and Yellin 2007 Foorthuis et al. 2010 Org. Char. EA Process EA Principles Management Governance Mechanisms for EA Standards Management EA Results EA Principles Grounding EA Principles Guidance EA Standards Definition Compliance assessments of projects EA Social Environment Hierarchical Culture Rational Culture Group Culture Developmental Culture EA Results Use First EA Principles Application Use and Conformance to EA Standards Management propagation of EA EA Standards Conformance and Use Project conformance to EA EA Consistency Outcomes Second and Third EAM Utility EA benefits for the organization as a w hole Assistance for projects EA benefits for projects Foorthuis et al. 2015 EA Approach Project Compliance w ith EA Architectural insight EA-Induced Capabilities Project Performance Organizational Performance System Information Intention to Use Use Net Lange 2012 Lux et al. 2010 Other IS Resources EAM Infra. IS Resources EAM Product EAM Service Delivery EAM-related Resources EAM Cultural Aspects Use IS Capabilities EAM Capability Other IS Capabilities (IT Resource Exploitation in) Business Processes EAM Business Process Performance Organizational Performance Service User Satisfaction (DeLone & McLean 2013) Schmidt & Buxmann 2011 Interaction Variables EA Planning Stakeholder Participation EA Documentation EA Communication & Support EAM Approach EA Governance EA Programming EA Implementation IT Flexibility IT Connectivity IT Compatability Duration of EA Implementation IT Efficiency IT Modularity Tamm et al. 2011 EA Benefit Enablers Organizational van Steenbergen & Brinkkemper 2008 EA Practice Architectural Results Organizational Performance Business Goals 9 DeLone & McLean 2003 System Information Service Intention to Use Use User Satisfaction Net
Hyötyjen syntymiseen vaikuttavat tekijät ja saadut hyödyt 10
Hyödyt syntyvät monimutkaisen prosessin kautta EA First EA Process EA Product EA Service Second Third EA Results Use EA Social Environment 11
EA Prosessien laatu (EA Process ) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Kokonaisarkkitehtuuriprosessit kattavat Arkkitehtuurituotteiden (kuvausten ja mallien) tuottamisen Arkkitehtuuripalveluiden (esim. projektien arkkitehtuurituki) tuottamisen Arkkitehtuurituotteiden muutosten hallinnan ja ylläpidon Arkkitehtuurin käytön hallinnan Prosessien laatua kuvaavia tekijöitä ovat mm. Selkeät tavoitteet Kokonaisarkkitehtuurin viitekehyksen (esim. TOGAF, JHS 179) laatu Kokonaisarkkitehtuurin mallinnuskäytännöt Kokonaisarkkitehtuurivälineen (esim. BiZZdesign, QPR, Sparx) laatu Sidosryhmien osallistuminen kokonaisarkkitehtuurityöhön Työnjako muiden kehittämisen toimintojen (esim. hankesalkku, IT-kehittäminen, prosessikehittäminen) kanssa Kokonaisarkkitehtuurin tuottamisen ajoitus Lähdemateriaalin laatu Resurssien (mm. raha, osaava työvoima) saatavuus 12
EA Tuotteiden laatu (EA Product ) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Kokonaisarkkitehtuurituotteet kuvaavat kokonaisarkkitehtuurin sisällön Kokonaisarkkitehtuurituotteita ovat mm. Arkkitehtuuriperiaatteet Nykytilan ja tavoitetilan arkkitehtuurimallit Arkkitehtuurimalleja selittävät tekstit Arkkitehtuurin tiekartat (roadmapit) Tuotteiden laatua kuvaavia tekijöitä ovat mm. Tuotteiden saatavuus (oikea tuote oikealla hetkellä) Sisällön selkeys Sisällön yhtenäisyys Kuvaustavan yhtenäisyys (kuvattu samoilla periaatteilla) Sisällöllinen yhtenäisyys (esim. alatason arkkitehtuuri noudattaa ylempää) Kuvauskannan sisällön laatu (esim. duplikaattielementit) Sisällön oikea tarkkuustaso (yksityiskohtaisuus) Tuotteen hyödyllisuus käyttäjälle Tuotteiden laatu tarkoittaa eri asioita eri sidosryhmille Esim. johto vs. projektiarkkitehti vs. IT-kehittäjä 13
EA Palveluiden laatu (EA Service ) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Kokonaisarkkitehtuuripalvelut tukevat kokonaisarkkitehtuurituotteiden käyttöä (ts. kokonaisarkkitehtuurin jalkauttamista) Kokonaisarkkitehtuuripalveluita ovat mm. Hankkeiden ja projektien arkkitehtuurituki Hankkeiden ja projektien arkkitehtuurikatselmoinnit Päätöksenteon tukipalvelut Palveluiden laatua kuvaavia tekijöitä ovat mm. Palveluiden saatavuus (oikea palvelu oikealla hetkellä) Aktiivisuus palveluiden tarjoamisessa Palvelun tarjoajan osaaminen (tiedot ja taidot) Palvelun hyödyllisyys käyttäjälle 14
EA Tuotteiden ja palveluiden käyttö (EA Results Use) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Hyötyjen syntyminen vaatii kokonaisarkkitehtuurituotteiden ja -palveluiden käyttöä Kokonaisarkkitehtuurin käyttötarkoituksia ovat mm. Uusien kokonaisarkkitehtuurituotteiden tuottaminen Projektin laajuuden asettaminen ja riippuvuuksien tunnistaminen Tietojärjestelmä- ja ratkaisuhankinnat (kilpailutukset) Tietojärjestelmäsalkun hallinta Projektisalkun hallinta (esim. kriittisten hankkeiden tunnistaminen ja riippuvuuksien hallinta) Liiketoiminnan päätöksenteon tukeminen (esim. yleiskuvilla ja riippuvuuksien tunnistamisella) Kokonaisarkkitehtuurin käyttäjiä ovat mm. Kokonaisarkkitehtuuritiimi tai -toiminto Kehityshankkeet ja -projektit Tietohallinto IT-kehitys ja ylläpito Projektitoimisto (PMO) Liiketoimintajohto Käyttöä kuvaavia tekijöitä ovat Käytön määrä Mitä tuotteita ja palveluita käytetään Käyttötarkoitus ja tavoitteet Mukana olevat sidosryhmät Käytön ajoitus Käyttäjätyytyväisyys 15
EA Sosiaaliset ja kulttuuriset tekijät (EA Social Environment) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Kuvaa osaltaan kokonaisarkkitehtuurin jalkauttamisen onnistuneisuutta Kattaa ne sosiaaliset ja kulttuuriset tekijät, jotka vaikuttavat kokonaisarkkitehtuurin hyötyjen syntymiseen Näitä tekijöitä ovat mm. Kokonaisarkkitehtuurin yleinen hyväksyntä Ylimmän johdon tuki Muiden organisaatioiden kokonaisarkkitehtuurityön tuntemus Sosiaaliset ja kulttuuriset tekijät vaikuttavat hyötyjen syntyprosessin kaikkiin osiin 16
EA Syntyneet hyödyt (1/2) (EA ) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Hyödyt syntyvät kokonaisarkkitehtuurin käytön kautta toissijaisesti suoraan kokonaisarkkitehtuuriprosesseista Hyödyissä on eri tasoja ja hyödyillä on keskinäisiä riippuvuussuhteita eli hyöty voi vaikuttaa toisen hyödyn syntymiseen Osa hyödystä syntyy siinä vaiheessa, kun kokonaisarkkitehtuurikuvausten hyödyntämisen kohde (esim. prosessi, tietojärjestelmä) on käytössä 1. tason hyöty on tietyn sidosryhmän suoraan saama Yleensä parempi ymmärrys jostain asiasta 2. tason hyöty on yleensä tästä paremmasta ymmärryksestä tai sen tuloksena toteutetusta asiasta nouseva hyöty, esim. Projekti pääsee nopeammin käyntiin Tehdään päätöksiä paremmin informoituna Point-to-point -integraatioiden määrä vähenee IT:n standardisointi ja IT-komponenttien uudelleenkäyttö lisääntyy 3. tason hyödyt ovat edellisistä hyödyistä nousevia organisaatiotason hyötyjä, esim. Kustannussäästöt 17
EA Syntyneet hyödyt (2/2) (EA ) EA Process EA Product EA Service EA Results Use First Second Third EA Social Environment Tässä tutkimuksessa tuli esiin useita kokonaisarkkitehtuurin hyötyjä, mm. Yleiskuvan luominen jostain kokonaisuudesta Riippuvuuksien tunnistaminen Standardien, valmiiden ratkaisumallien (patterns) ja esimerkkien tuominen Yhteisen sanaston luominen Projektin käynnistymisen nopeuttaminen Päätöksenteon parantuminen Käyttöön otettujen ratkaisujen laadun parantuminen Toisteisuuden (duplikoinnin) vähentyminen (esim. IT-komponentit) Tietojärjestelmien yhteentoimivuuden parantuminen IT-ratkaisujen standardoinnin lisääntyminen IT-kustannusten vähentyminen 18
Kokonaisarkkitehtuurin sidosryhmät 19
Yleistä kokonaisarkkitehtuurin sidosryhmistä Sidosryhmiä ovat kaikki yksilöt, ryhmät ja organisaatiot, jotka liittyvät jotenkin kokonaisarkkitehtuuriin Sidosryhmillä on odotuksia ja tarpeita kokonaisarkkitehtuuria kohtaan. Tarpeet ja odotukset luonnollisesti vaihtelevat sidosryhmän mukaan Sidosryhmät voidaan jakaa seuraaviin kategorioihin Tuottajat (Producers) Käyttäjät (Users) Tukijat (Facilitators) Sama sidosryhmä voi toimia useassa roolissa (ts. kuulua useaan kategoriaan) Sidosryhmiä on melko paljon (tutkimuksessa tunnistettiin 29 eri sidosryhmää) Sidosryhmät, tarpeet ja odotukset vaihtelevat organisaation mukaan 20
Kokonaisarkkitehtuurilla on monia sidosryhmiä Evaluator Project Manager Development Project Group Program Management Office User Context Business User Research & Design Project Steering Group Management Enterprise Sponsor Legislator Investment Board Board of Directors Internal Communications Producer Context System Development Applications Development Enterprise Architect Architect Architecture Board Architecture Group ICT Organization ICT Maintenance Security ICT Operations Facilitator Context Partner Customer Owner Public Competitor 21 Figure Symbols: Role Team or Group Organization
Kokonaisarkkitehtuurin hyötyjen mittaaminen 22
Kokonaisarkkitehtuuri on syvällä organisaation kokonaisuudessa Liiketoiminta Tukitoiminnot HR Talous IT Kehittämistoiminnot Prosessikehitys Projektinhallinta Hankesalkku IT-kehitys Kokonaisarkkitehtuuri Menetelmäkehitys Kehittämisen tukitoiminnot 23 Hyödyt ketjuttuvat - yhden toiminnon vaikutuksen arviointi on vaikeaa.
Kokonaisarkkitehtuurin mittaamisessa huomioitavia asioita Miten syntyneet hyödyt voi linkittää juuri kokonaisarkkitehtuuriin (korrelaatio tai jopa kausaatio)? Mitä mittaamisella halutaan saavuttaa? Kehitetään omaa toimintaa? Osoitetaan kokonaisarkkitehtuurin hyödyllisyys maksajille? Mitä pitäisi mitata? Hyötyjä itseään vs. hyötyjen syntymiseen vaikuttavia tekijöitä? Hyötyjen syntymiseen vaikuttavia tekijöitä on monia Mitataanko prosessia vai sen tuotoksia? Mitataanko käytön jälkeisiä kokonaisarkkitehtuurin hyötyjä? Mitä mittareita käytetään? Laadulliset vs. määrälliset mittarit Määrällisistä tutkimuksista ja muilta osa-alueilta (esim. palveluiden ja dokumenttien laadun mittaaminen) on kyllä saatavissa valmiita mittareita mutta vaihtoehtoja on todella paljon Missä vaiheessa ja kuinka usein kannattaa mitata? Historiallisen mittaustiedon kerääminen Mistä ja miten mittausdata kerätään? 24
Hyötyjen syntymisketjun mittaaminen määrällisillä mittareilla (esimerkki) EA Process 25 Prosessien laatu Kokonaisarkkitehtuuritoiminnan kustannukset Tuotteiden ja palveluiden laatu Viimeisteltyjen ja hyväksyttyjen kokonaisarkkitehtuurituotteiden määrä Projektit (määrä ja % kaikista), joille on tarjottu arkkitehtuuritukea EA Social Environment Kohderyhmä: projektit EA Product EA Service Tuotteiden ja palveluiden käyttö Projektit (määrä ja % kaikista), joissa on nähty jokin kokonaisarkkitehtuurituote Projektit (määrä ja % kaikista), joissa on hyödynnetty jotain kokonaisarkkitehtuurituotetta Projektit (määrä ja % kaikista), joille on annettu arkkitehtuuritukea? EA Results Use EA Syntyneet hyödyt Projektin esiselvitys-/ First määrittelyvaiheen kesto/kustannus Budjetissa Second valmistuneet projektit (määrä ja % kaikista) Aikataulussa Third valmistuneet projektit (määrä ja % kaikista) Laatutavoitteet täyttäneet projektit (määrä ja % kaikista) Bonus Yhden kokonaisarkkitehtuuri -tuotteen kustannus Yhden projektin arkkitehtuurituen kustannus
Kokonaisarkkitehtuurin käyttö ITpalvelukehityksessä 26
IT-palvelukehityksen ohjaamisen haasteita IT-kehittämisen tarpeita nousee esille monista lähteistä Liiketoiminnan tarpeet, loppukäyttäjien haasteet, vanheneva teknologia, riskit Tarpeita ei välttämättä kerätä ja käsitellä suunnitelmallisesti Priorisointi on vaikeaa, sitoutuminen siihen vielä vaikeampaa Projektit huolehtivat yleensä lähinnä omasta tontistaan Kokonaisuus, riippuvuudet ja yhteentoimivuus voivat unohtua Perinteiset projektien ohjaustoiminnot ja -menetelmät (esim. hankesalkunhallinta ja projektinhallinta) keskittyvät ohjaamaan vain omalla vastuullaan olevia asioita (esim. resurssit, aikataulu, lopputuotosten laatu, budjetti, riskit) 27
IT-palvelukehityksellä on liittymäpintoja moniin muihin toimintoihin Kokonaisarkkitehtuuri Toimintojen päällekkäisyydet ja ristiriidat tulee minimoida. IT-infran ja teknologioiden hallinta Hankesalkku ja projektin hallinta ITpalvelukehitys IT-palvelunhallinta Liiketoiminnan tavoitteet 28
Kehittämisen ohjaaminen on kokonaisarkkitehtuurin tärkeimpiä tavoitteita Kokonaisarkkitehtuuri auttaa tunnistamaan tarpeita projektien käynnistämiseksi Kokonaisarkkitehtuuri tukee toteutettavan IT-palvelun asemoinnissa kokonaisuuteen (erityisesti riippuvuuksien tunnistaminen) Kokonaisarkkitehtuuri auttaa toteutettavan IT-palvelun määrittelyssä Kokonaisarkkitehtuuriohjauksella voidaan varmistaa, että projekti tunnistaa merkittävä arkkitehtuurituotteet ja noudattaa arkkitehtuurin linjauksia Projektin työaikaa säästyy, koska samoja asioita ei tarvitse selvittää erikseen joka projektissa 29
IT-kehittämisen tarpeita voidaan tunnistaa arkkitehtuurista useilla tavoilla Nykytilan järjestelmäarkkitehtuurin analyysi Käydään läpi järjestelmien toiminnallinen ja tekninen laatu sekä tunnistetaan puutteet IT-ratkaisutarpeiden tunnistaminen prosessikehityksen yhteydessä Tietty tavoitetilan prosessi tai sen vaihe tarvitsee järjestelmätukea, jota tällä hetkellä ei ole saatavissa Tietty nykytilan prosessin vaihe hoidetaan manuaalisesti, koska järjestelmätukea ei ole saatavissa Nyky- vs. tavoitetilan järjestelmäarkkitehtuurin puutteiden (gap) analyysi Tunnistetaan, mitä nykytilasta puuttuu tavoitetilaan verrattuna 30
Kokonaisarkkitehtuuri auttaa IT-kehittämisen asemoinnissa kokonaisuuteen Prosessit IT-palvelut Järjestelmät Tieto Uusi IT-ratkaisu Infrastruktuuri Voidaan hahmottaa, miten uusi ratkaisu tulee sijoittumaan osaksi organisaation prosesseja, tietomallia sekä järjestelmä- ja teknologiakokonaisuutta Kokonaisarkkitehtuuri myös voi valmiiksi linjata IT-ratkaisuissa käytettäviä tuotteita, teknologioita ja standardeja 31
Kokonaisarkkitehtuuri tukee uuden IT-palvelun määrittelyssä Ymmärtämällä kokonaisuus ja erilaiset riippuvuudet pystytään paremmin kuvaamaan haluttu ratkaisu ja sen vaatimukset Mahdollistaa toiminnan kehittämisen ja järjestelmien välisten vastuiden uudelleen suunnittelun ei ainoastaan suoraviivaisesti korvata vanhaa järjestelmää Vältetään kustannuksiin ja aikatauluun vaikuttavat yllätykset, kuten vasta toteutusvaiheessa esille tulevat välttämättömät integraatiotarpeet Kehitysprojektin laajuus pysyy paremmin hallittuna Kokonaisarkkitehtuurin tulee vaatia tai olla mukana suunnittelemassa uutta toimintamallia ja vastuunjakoa Esim. tietokantatuotteena käytetään x:ää; toimittajan y tuotteita ei käytetä Pilvipalveluiden osalta palvelun sisäisen IT-arkkitehtuurin merkitys vähenee, mutta kokonaisarkkitehtuurin merkitys suhteellisesti kasvaa (esim. integroituminen prosesseihin ja järjestelmiin) 32
Kokonaisarkkitehtuurin vaikuttamiskeinot projektissa Arkkitehtuurituki Yhdessä suunnittelu ja mallintaminen Esimerkiksi neuvonta, työpajat, vierituen antaminen, projektin kannalta relevanttien arkkitehtuurituotteiden tunnistaminen Arkkitehtuurikatselmoinnit Tarkastetaan projektin arkkitehtuurituotteet tiettyjä kriteereitä vasten Voidaan toteuttaa enemmän tai vähemmän formaalisti Arkkitehtuurituotteiden (omaehtoinen) hyödyntäminen projektissa Tuotteiden pitää olla helposti löydettävissä (esim. navigointirakenteet ja nimeäminen vaikuttavat) Tuotteiden saatavuus esimerkiksi julkaisujen kautta on kriittistä Arkkitehtuuristen laatukriteerien asettaminen muissa ohjaustoiminnoissa Esim. projektimetodologia vaatii tietynlaisten arkkitehtuurituotteiden tuottamista Arkkitehtiresurssin tarjoaminen projektille Dedikoitu osa- tai täysipäiväinen arkkitehti projektille 33
Miten kehittää kokonaisarkkitehtuurin ohjausvaikutusta? Varmista resursointi Arkkitehdin tuki on tärkeää Sidosryhmät eivät välttämättä itse osaa tai heillä ei ole aikaa tutustua kuvauksiin Vaikuta ajoissa Suunnitelmien tai päätösten jo valmistuttua muutosten tekeminen on vaikeaa, vaikka niihin olisi syytäkin Painotus ennemmin tuessa ja ohjauksessa kuin lähes valmiiden suunnitelmien katselmoinnissa Löydä tasapaino tuen antamisen ja määräämisen välillä Kokonaisarkkitehtuurin tulisi olla projekteille hyödyllinen palvelu Asemoi kokonaisarkkitehtuuriohjaus muiden tuki- ja ohjaustoimintojen kanssa Minimoi päällekkäisyydet ja ristiriitaisuudet Varmista, että arkkitehtuurituotteet ovat viimeisteltyjä ja helposti saatavilla Kuvaa kokonaisarkkitehtuuriohjaus osana kokonaisarkkitehtuurin hallintamallia ja jalkauta suunnitelmallisesti 34
Yhteenveto 35
Hyötyjen syntymiseen liittyen kannattaa muistaa nämä Kokonaisarkkitehtuuri tuottaa hyötyjä Yksittäiset sidosryhmät voivat saada hyötyjä melko välittömästi Organisaatiotason hyötyjen syntyminen voi kestää kauan Kokonaisarkkitehtuuria ei voi tehdä siilossa ota sidosryhmät mukaan! Tunnista sidosryhmät ja tarpeet Arkkitehtuurituotteita tuotetaan sidosryhmille Kokonaisarkkitehtuuria tulee käyttää (ja käyttää oikein), jotta hyötyjä ylipäätään voisi syntyä Helpoin ja luonnollisin paikka kokonaisarkkitehtuurin käyttöön on ITpalvelukehityksen ohjaaminen Kokonaisarkkitehtuuripalvelut ovat kriittisiä arkkitehtuurituotteiden käytön tukemisessa Arkkitehtuurituotteiden laatu on tärkeää, mutta ylilaatua kannattaa välttää Hyötyjen mittaamisessa voi lähteä liikkeelle kevyesti 36
Lisätietoa Väitöskirja http://urn.fi/urn:isbn:978-952-15-3850-6 Väitöstilaisuuden lectio (teksti) Väitöstilaisuuden lectio (podcast) https://www.linkedin.com/pulse/v%c3%a4it%c3%b6stilaisuudenlectio-enterprise-architecture-eetu-niemi-phd https://soundcloud.com/coalaoy/kokonaisarkkitehtuurin-hyotyjensyntyminen-lectio-vaitostilaisuudesta 37