Kokonaisarkkitehtuurin hyötyjen syntyminen

Transkriptio

1 Kokonaisarkkitehtuurin hyötyjen syntyminen JHKA-työryhmän kokous Eetu Niemi, FT Senior Consultant (Coala)

2 Eetu Niemi Koulutus FT, tiedonhallinta ja logistiikka (Tampereen teknillinen yliopisto) 2016 KTM, tietojärjestelmätiede (Jyväskylän yliopisto) 2006 Työkokemus Senior Consultant (Coala) 03/2013-> Kokonaisarkkitehtuuri ja ratkaisuarkkitehtuuri Käyttäjä- ja pääsynhallinta (IAM) Consultant (Accenture) 05/ /2013 Tutkija ja projektipäällikkö (Jyväskylän yliopisto) Pro Gradu -työ (TeliaSonera) 2005 Sertifikaatit ja välineet TOGAF9 Certified, ArchiMate 3 Practitioner BiZZdesign, Sparx, MEGA Suite, ARIS, QPR, Rational, iserver 2

3 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

4 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. Käytännön huomioita kokonaisarkkitehtuurin johtamiseen 4

5 Kokonaisarkkitehtuuri ja sen hyödyt 5

6 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) 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) [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) 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

7 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) 7

8 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 8

9 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

10 Aiemmat kokonaisarkkitehtuurin hyötyjen syntymistä kuvaavat mallit Aier 2014 Boh and Yellin 2007 Foorthuis et al 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 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 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 EA Benefit Enablers Organizational van Steenbergen & Brinkkemper 2008 EA Practice Architectural Results Organizational Performance Business Goals 10 DeLone & McLean 2003 System Information Service Intention to Use Use User Satisfaction Net

11 Hyötyjen syntymiseen vaikuttavat tekijät ja saadut hyödyt 11

12 Hyödyt syntyvät monimutkaisen prosessin kautta EA First EA Process EA Product EA Service Second Third EA Results Use EA Social Environment 12

13 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 13

14 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ä 14

15 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 15

16 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 16

17 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 17

18 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 18

19 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 19

20 Kokonaisarkkitehtuurin sidosryhmät 20

21 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 21

22 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 22 Figure Symbols: Role Team or Group Organization

23 Kokonaisarkkitehtuurin hyötyjen mittaaminen 23

24 Kokonaisarkkitehtuuri on syvällä organisaation kokonaisuudessa Liiketoiminta Tukitoiminnot HR Talous IT Kehittämistoiminnot Prosessikehitys Projektinhallinta Hankesalkku IT-kehitys Menetelmäkehitys Kokonaisarkkitehtuuri 24 Hyödyt ketjuttuvat - yhden toiminnon vaikutuksen arviointi on vaikeaa.

25 Kokonaisarkkitehtuurin mittaamisessa huomioitavia asioita Miten syntyneet hyödyt voi linkittää juuri kokonaisarkkitehtuuriin (korrelaatio tai jopa kausaatio)? Koko ketjun mittaaminen ja korrelaatioiden tunnistaminen Vertailu aikaisempaan tilanteeseen 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? 25

26 Hyötyjen syntymisketjun mittaaminen määrällisillä mittareilla (esimerkki) EA Process 26 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

27 Käytännön huomioita kokonaisarkkitehtuurin johtamiseen 27

28 Varmista hyötyjen syntyminen mahdollisimman aikaisessa vaiheessa Jos hyötyjä joutuu odottamaan liian kauan, kokonaisarkkitehtuuritoiminta ajetaan alas (tai ainakin sen uskottavuus menetetään) Hyötyjä ei ala syntyä automaattisesti sen myötä, että kuvausvälineeseen alkaa kertymään kuvausmassaa Suunnittele kokonaisarkkitehtuurille riittävän lyhyet kehityssyklit ja näiden tuloksille konkreettiset käyttökohteet Tällöin saadaan nopeita voittoja, tulokset innostavat ja jaksetaan pitempijaksoista kehittämistäkin Osa merkittävimmistä (organisaatiotason) hyödyistä syntyy vasta pidemmällä aikavälillä 28

29 Hyötyjen syntyminen vaatii kokonaisarkkitehtuurin käyttöä Suurin osa hyödyistä syntyy kokonaisarkkitehtuurituotteiden ja - palveluiden käytöstä Kokonaisarkkitehtuurin käyttö on tärkein kokonaisarkkitehtuuriohjauksen mekanismi Tunnista sidosryhmät ja arkkitehtuurin käyttökohteet Tue järjestelmällisesti kokonaisarkkitehtuurin käyttöä Arkkitehtuuripalvelut ovat tärkeitä: esim. viestintä, työpajat ja vierituki Kaikki sidosryhmät eivät välttämättä itse osaa tai heillä ei ole aikaa tutustua kuvauksiin Löydä tasapaino tuen antamisen ja määräämisen välillä Kokonaisarkkitehtuurin tulisi olla sidosryhmille hyödyllinen palvelu Varmista, että arkkitehtuurituotteet ovat viimeisteltyjä ja helposti saatavilla Sidosryhmille hyödyllisten raporttien ja analyysien (esim. liikennevalot, riippuvuusanalyysit ja nelikentät) tuottaminen arkkitehtuuritiedosta on myös tärkeää Huolehdi siitä, että kokonaisarkkitehtuurin hallintamalli on käyttöä tukeva 29

30 Kokonaisarkkitehtuurituotteiden tulee olla tarpeeksi (mutta ei liian) laadukkaita Kokonaisarkkitehtuurituotteiden tulee olla ennen muuta sidosryhmiä palvelevia Eri sidosryhmien tarpeet ovat erilaisia Ylilaatu (esim. liian suuri tarkkuus tai laajuus) voi olla käyttöä haittaava asia! Pidä käyttönäkökulma mukana kokonaisarkkitehtuurituotteita tuotettaessa mihin käyttötarkoitukseen, mille sidosryhmille, jne. Se, mitä asioita arkkitehtuurissa tulee kuvata, riippuu organisaation toimintamallista (ja arkkitehtuurin käyttötarkoituksista) Tuota arkkitehtuuria vain se määrä mitä tarvitaan määrä ei takaa laatua! Arkkitehtuurituotteiden laatuun vaikuttavat myös 1) arkkitehtien osaaminen ja 2) arkkitehtuurivälineen laatu 30

31 Kokonaisarkkitehtuuriprosessit vaativat riittävän tukidokumentaation ja välineet Käytä toimintaa tukevaa notaatiota ja viitekehystä Resursseihin ja arkkitehtuurin käyttötarkoituksiin sopiva (ei liian raskas) Viitekehys tulee aina sovittaa organisaatioon (ts. mitä tämä tarkoittaa juuri meillä) Käytä laadukasta arkkitehtuurivälinettä (ja käytä sitä oikein) Kuvauskanta (repository) -pohjaisuus on ehdoton vaatimus Arkkitehtuurin yhdenmukaisuuden varmistaminen on kriittistä (esim. duplikaattien välttäminen, notaation noudattamisen valvonta) Kuvauskannan rakenne ja järjestelytoiminnallisuudet helpottavat mm. tiedon löytämistä Raportointi-, julkaisu- ja analyysitoiminnallisuudet ovat tärkeitä arkkitehtuurin käytön kannalta (myös muille kuin arkkitehdeille) Varmista tukidokumentaation saanti Ei geneeristä ohjeistusta vaan ohjeet siitä, miten juuri meidän organisaatiossa sovelletaan notaatiota ja viitekehystä Myös referenssimateriaalien kuten sidos- ja viitearkkitehtuurien hyödyntäminen arkkitehtuurityössä kannattaa ohjeistaa Ota sidosryhmät (myös liiketoiminta) mukaan arkkitehtuurityön tekemiseen Varmista resursointi, osaaminen ja koulutus 31

32 Hallintamallin tulee olla arkkitehtuurin käyttötarkoitusta tukeva Huomioi arkkitehtuurin käyttö kokonaisarkkitehtuurin hallintamallissa Vaikuttaa siihen, mitä tuotoksia tulisi vaatia esim. kokonaisarkkitehdeilta ja projekteilta Ei kannata vaatia mitään, mitä ei käytetä Varmista arkkitehtuuriohjauksen mukaantulo 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 Minimoi kokonaisarkkitehtuurin ja muiden toimintojen (esim. ITpalvelukehitys, hankesalkun hallinta) päällekkäisyydet ja ristiriidat Ohjattavalta (esim. projekti) ei tule vaatia samaa tietoa eri muodoissa eri ohjaustoimintojen tarpeisiin Muut toiminnot voivat hyödyntää kokonaisarkkitehtuuria, mutta se vaatii toiminnolta riittävän kypsyystason Kuvaa kokonaisarkkitehtuuriohjaus osana kokonaisarkkitehtuurin hallintamallia ja jalkauta suunnitelmallisesti Mittaa, vertaa muihin organisaatioihin ja kehitä toimintaa havaintojen perusteella 32

33 Kokonaisarkkitehtuurilla on liittymäpintoja moniin muihin toimintoihin Kokonaisarkkitehtuuri ITpalvelukehitys Toimintojen päällekkäisyydet ja ristiriidat tulee minimoida. IT-infran ja teknologioiden hallinta Hankesalkku ja projektin hallinta IT-palvelunhallinta Liiketoiminnan tavoitteet 33

34 Yhteenveto 34

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 35

36 Lisätietoa Väitöskirja Väitöstilaisuuden lectio (teksti) Väitöstilaisuuden lectio (podcast)