Telecommunications Software and Multimedia Laboratory
Mika Rajanen
Yhteentoimivuutta ja toiminnan tehostamista tietotek niikan arkkitehtuureilla
Master’s Thesis
Helsinki, January 24, 2008
Supervisor: Professor Antti Ylä-Jääski Instructor: Tuomo Karakorpi, M.Soc.Sc.
r ^
TEKNTt .1 JjvfEN KOP "T" A K O',n U TIETOIt-.k .UK.A.N IA1.UN k..UA.,srU KONUMir.HLNTlR '
U21.M) ESPOO
TEKNILLINEN KORKEAKOULU Tietotekniikan osasto
DIPLOMITYÖN TIIVISTELMÄ
Tekijä
Mika Rajanen
Päiväys
24.1.2008
Sivumäärä
10 + 91
Työn nimi
Yhteentoimivuutta ja toiminnan tehostamista tietotekniikan arkkitehtuureilla
Professuuri
Tietoliikenneohjelmistot
Koodi
T-110
Työn valvoja
Professori Antti Ylä-Jääski
Työn ohjaaja
Tuomo Karakoroi. VTK
Julkishallinnossa edellytetään yhä tehokkaampaa palvelutuotantoa. Tietotekniikka on apuväline tehokkaampaan toimintaan, mutta tietotekniikka ja toiminta ovat ajautuneet erilleen sillä seurauksella, että tietojärjestelmät eivät ole yhteensopivia toisensa kanssa.
Organisaatiotasoinen kokonaisarkkitehtuuri on eräs keino ohjata tietotekniikkaa lähem
mäs toimintaa ja mahdollistaa paremman yhteentoimivuuden toiminnan prosessien tu
kemisessa tietotekniikan keinoin.
Työssä muodostetaan kokonaisvaltainen käsitys kokonaisarkkitehtuuriin liittyvistä käsit
teistä ja valitaan kehikko menetelmineen kaupunkiorganisaation tietotekniikan ja sen arkkitehtuurien kokonaishallintaan. Lisäksi tutkitaan palvelukeskeisen arkkitehtuurin suhdetta kokonaisarkkitehtuuriin sekä tietojärjestelmien yhteentoimivuuden mahdollis
tamista ja pirstaloitumisen ehkäisemistä arkkitehtuureilla. Työ on luonteeltaan kirjalli
suustutkimus.
Federalistinen kokonaisarkkitehtuuri osoittautuu julkishallinnossa laajasti käytetyksi tavaksi ohjata tietotekniikkaa strategisesti. Soveltuvimmaksi kokonaisarkkitehtuurin ke
hikoksi valitaan TOGAF, johon voidaan liittää myös palvelukeskeisen arkkitehtuurityy- lin menetelmä. Palvelukeskeinen arkkitehtuuri havaitaan keinoksi toteuttaa ketterästi toiminnan prosessien tarvitsemia palveluita teknologiariippumattomasti. Keskeiset ko
konaisarkkitehtuurin työkohteet ovat hallintamalli ja arkkitehtuurimenetelmä. Työn tu
loksien perusteella voidaan suosittaa kokonaisarkkitehtuurin kattavaa käyttöönottoa.
Avainsanat: Kokonaisarkkitehtuuri, palvelukeskeinen arkkitehtuuri, TOGAF, integraatio
HELSINKI UNIVERSITY OF TECHNOLOGY
Department of Computer Science and Engi
neering
ABSTRACT OF MASTER’S THESIS
Author
Mika Rajanen
Date
24 Januarv 2008
Pages
10 + 91
Title of thesis
IT Architectures for Improved Interoperability and Operations
Professorship
Telecommunications software
Professorship Code
T-110
Supervisor
Professor Jukka Antti Ylä-Jääski
Instructor
Tuomo Karakorpi. M.Soc.Sc.
More effective service production is demanded from the public sector. Information tech
nology is an instrument for the effective service production but IT and business are separated causing interoperability problems in IT systems. An organisation-wide Enter
prise Architecture is a one way to achieve business-IT alignment and to enable better interoperability needed by the business processes.
This thesis forms a holistic view to the concept of the Enterprise Architecture based on the literature. An Enterprise Architecture framework including a methodology is chosen for the city government. In this thesis we studied how a Service Oriented Architecture is related to the EA, how to enable the interoperability between IT systems and how to prevent IT systems to shatter IT silos.
It turns out that Federal Enterprise Architecture is widely utilised for a strategic IT co
ordination in the public sector. In this thesis the most suitable EA framework for the city government was chosen. TOGAF. A method for the Service Oriented Architecture can be associated with the TOGAF methodology. This study shows that the Service Ori
ented Architecture is a technology independent style to an agile business service imple
mentation. Architecture governance and an architecture development method are the most essential tasks in the EA work. Based on the results from the thesis, establishing full EA program is recommended.
Keywords: Enterprise Architecture, EA, Service Oriented Architecture, SOA, TOGAF, integration
Alkusanat
Tämä diplomityö on tehty Teknillisen korkeakoulun Tietotekniikkaosaston Tietoliiken
neohjelmistojen ja Multimedian Laboratorioon. Työ on tehty Helsingin kaupungin Talo
us-ja suunnittelukeskukselle.
Haluan esittää kiitokset työtä koskevista neuvoista ja ohjeista työn valvojalle, Antti Ylä- Jääskille. Lisäksi haluan esittää työn ohjaajalle, Tuomo Karakorvelle, kiitoksen mahdolli
suudesta tehdä diplomityö haastavasta aiheesta ja kiitoksen työhön liittyvästä ohjaukses
ta.
Helsingissä 24.1.2007 Mika Rajanen
Sisällysluettelo
Alkusanat... iv
Sisällysluettelo... v
Lyhenneluettelo...vii
1 Johdanto...1
1.1 Tausta ja motivaatio... 3
1.2 Työn tavoite...5
2 Arkkitehtuurit ja organisaation toiminta... 6
2.1 Arkkitehtuurit strategian mahdollistajana... 6
2.2 Organisaation toimintamallit... 7
2.3 Kokonaisarkkitehtuuri...S 2.3.1 Kokonaisarkkitehtuurikehikot...8
2.3.2 Kokonaisarkkitehtuurin kypsyyden mittaaminen... 11
2.4 IT:n sitouttamismalli... 12
2.5 Palvelukeskeinen arkkitehtuuri... 14
2.6 Yhteenveto... 16
3 Kokonaisarkkitehtuurit... 18
3.1 Kokonaisarkkitehtuurin määritelmä...18
3.2 Kokonaisarkkitehtuurikehikon soveltuvuuden arvioinnin kriteerit...21
3.3 Kokonaisarkkitehtuurikehikot... 22
3.3.1 Zachman Framework for Enterprise Architecture...22
3.3.2 TOGAF...24
3.3.3 FEAF...25
3.3.4 ValtIT...27
3.4 Kokonaisarkkitehtuurikehikkojen soveltuvuuden arviointi... 28
3.4.1 Kattavuus... 28
3.4.1 Jatkuvuus... 29
3.4.2 Referenssit... 30
3.4.3 Toteuttamiskelpoisuus... 30
3.4.4 Vertailun tulokset...31
3.5 Yhteenveto...32
4 Palvelukeskeinen arkkitehtuuri... 35
4.1 Palvelukeskeinen kokonaisarkkitehtuuri... 35
4.2 Palvelukeskeiset osa-alueet kokonaisarkkitehtuurikehikossa... 36
4.3 SOA:n keskeiset piirteet... 37
4.4 Integraatio osana arkkitehtuuria...40
4.4.1 Integrointitasot...41
4.4.2 Integrointitavat...43
4.4.3 Prosessien ohjaus...46
4.5 Web Services... 47
4.5.1 Perustoiminnallisuus... 48
4.5.2 Fluomioita tietoturvallisuudesta... 49
4.6 Yhteenveto...51
5 Kaupunkiyhteinen arkkitehtuuri ja sen komponentit... 53
5.1 Toimialojen vaikutus arkkitehtuuriin... 53
5.2 Modulaaristen tietojärjestelmäresurssien edellytykset...57
5.3 Kaupunkiyhteiset arkkitehtuurikomponentit...60
5.4 Arkkitehtuurikomponentit palvelukeskeiselle infrastruktuurille...63
5.5 Yhteenveto...65
6 Arkkitehtuurin hallintamalli...67
6.1 Arkkitehtuurin hallinnan tavoitteet...67
6.2 Arkkitehtuurin hallinnan osa-alueet... 69
6.2.1 Hallintaan liittyvä organisaatio... 70
6.2.2 Hallinnan prosessit...71
6.2.3 Arkkitehtuurin politiikat ja perusperiaatteet... 72
6.2.4 Edistymisen mittarit... 73
6.2.5 Sidokset hankehallintaan ja kehitysprojekteihin... 74
6.3 Haasteet kokonaisarkkitehtuurin hallinnassa...75
6.4 Yhteenveto...76
7 Tulosten arviointi ja jatkotoimet... 78
7.1 Tuloksien arviointi suhteessa tutkimuskysymyksiin...78
7.2 Suositus jatkotoimenpiteistä... 80
8 Yhteenveto... 82
Kuvaluettelo... 85
Taulukkoluettelo...86
Lähdeluettelo... 87
Lyhenneluettelo
ABB: Architecture Building Block
ACMM2: IT Architecture Capability Maturity Model
AGATE: Atelier de Gestion de 1'ArchiTEcture des systémes d'information et de commu
nication
API: Application Programming Interface BAM: Business Activity Monitoring BITAM: Business-1T Alignment Method BPM: Business Process Management
BPML: Business Process Modeling Language BPMN: Business Process Modeling Notation BPMS: Business Process Management System
C4ISR: Command, Control, Computers, Communications (C4), Intelligence, Surveil
lance, and Reconnaissance (ISR)
CIMOSA: Computer Integrated Manufacturing Open System Architecture CMM: Capability Maturity Model
CMMI: CMM Integration
COBIT: Control Objectives for Information and related Technology CORBA: Common Object Request Broker Architecture
DCOM: Distributed Component Object Model DoC: Department of Commerce
DoDAF: Department of Defence Architecture Framework DSDM: Dynamic Systems Development Method
GERAM: Generalised Enterprise Reference Architecture and Methodology E2AF: Extended Enterprise Architecture Framework
EA: Enterprise Architecture
EAI: Enterprise Application Integration
EIF: European Interoperability Framework EJB: Enterprise Java Beans
ESB: Enterprise Service Bus EU: European Union
EWTA: Enterprise-Wide Technical Architecture FEAF: Federal Enterprise Architecture Framework FTF: Federal Transition Framework
HTTP: Hypertext Transfer Protocol HTTPS: HTTP Secure
IAF: Integrated Architecture Framework
I AFC: International Federation of Automatic Control
IDEAS: International Defence Enterprise Architecture Specification IFEAD: Institute For Enterprise Architecture Developments
IFIP: International Federation for Information Processing IEEE: Institute of Electrical and Electronics Engineers IEEE APG: IEEE Architecture Planning Group IEC: International Electrotechnical Commission IP: Internet Protocol
IT: Information Technology ITG: IT Governance
ITIL: IT Infrastructure Library
ISO: International Organization for Standardization J2EE: Java 2 Platform Enterprise Edition
JCA: J2EE Connector Architecture JMS: Java Message Service KPI: Key Performance Indicator MDA: Model Driven Architecture MDM: Master Data Management
MoDAF: Ministry of Defence Architecture Framework
NAF: NATO Architecture Framework
NASCIO: National Association of State Chief Information Officers NATO: North Atlantic Treaty Organization
OASIS: Organization for the Advancement of Structured Information Standards OGF: Open Grid Forum
OGSA: Open Grid Services Architecture OMA: Object Management Architecture OMB: Office of Management and Budget OMG: Object Management Group
00: Object Oriented
OSI: Open Systems Interconnection
OSOA: Open Service Oriented Architecture PERA: Purdue Enterprise Reference Architecture RM1: Remote Method Invocation
RPC: Remote Procedure Call
SAGA: Standards and Architectures for E-Government Applications SAML: Security Assertion Markup Language
SB A: Space-Based Architecture SBB: Solutions Building Block
SC A: Service Component Architecture SEI: Software Engineering Institute SIB: Standards Information Base SLA: Service Level Agreement
SMART: Service Oriented Migration and Reuse Technique SMTP: Simple Mail Transfer Protocol
SOA: Service Oriented Architecture SOAP: Simple Object Access Protocol SOE: Service Oriented Enterprise
SOEA: Service Oriented Enterprise Architecture
SOI: Service Oriented Infrastructure tai Service Oriented Integration
SPA: Service Paradigm Adoption SSO: Single Sign-On
STP: Service Transition Planning
TAFIM: Technical Architecture Framework for Information TEAF: Treasury Enterprise Architecture Framework
TISAF: Treasury Information Systems Architecture Framework TOGAF: The Open Group Architecture Framework
TOGAF ADM: TOGAF Architecture Development Model
TOGAF III-RM: TOGAF Integrated Information Infrastructure Reference Model UDD1: Universal Description, Discovery and Integration
UML: Unified Modeling Language
ValtIT: Valtion IT- toiminnan johtamisyksikkö W3C: World Wide Web Consortium
WS-*: Web services
WS-BPEL: Web Services Business Process Execution Language WSDL: Web Services Description Language
WSS: Web Services Security WWW: World Wide Web
XACML: extensible Access Control Markup Language XKMS: XML Key Management Specification
XML: Extensible Markup Language
ZIFA: Zachman Institute for Framework Advancement
1 Johdanto
Tietotekniikan hyödyntäminen organisaatioiden toiminnassa on saavuttanut vakiintuneen aseman 2000-luvulla. Teknologia-, pankki- ja palvelusektorin yritykset ovat tehostaneet toimintaansa tietotekniikan avulla 1980-luvulta asti, jolloin henkilökohtaiset tietokoneet ja hajautetut järjestelmät levisivät organisaatioihin ja niiden tavallisille käyttäjille. World Wide Web:n (WWW) keksimisen jälkeen 1990-luvulla Internetiin kytkettyjen tietokonei
den, sekä koti- että yrityskäyttäjien, määrä on kasvanut eksponentiaalisesti. Nopeasti kas
vava tietokoneiden verkottaminen standarditavoilla toi mahdollisuuksia liiketoiminnan tehostamiseen koko arvoketjussa, alkutuotannosta aina asiakastoimitukseen saakka tieto
tekniikan avulla. 1990-luvulla yritykset ottivat käyttöön asiakastiedon ja toimitusketjun hallintajärjestelmiä sekä toiminnanohjausjärjestelmiä, joilla pyrittiin ohjaamaan yrityksen resursseja entistä paremmin. Yritysten toiminnan tietokoneistaminen ja Internetin yhdis
tämä maailma 2000-luvulla toi uusia liiketoimintamahdollisuuksia maantieteellisten ra
joitusten hämärtyessä. Reaaliaikainen tiedonsiirto ja viestintä osana yrityksen tuotanto
prosessia pilkkoi arvoketjun eri maihin kustannustehokkaasti ja avasi globaalit markkinat sekä kilpailun. Tätä suurelta osalta tietotekniikasta johtuvaa ekonomian muutosta on kut
suttu Globalisaatio 3.0:ksi [1], Liiketoiminnan näkökulmasta keskeisen informaation no
peampi käsittelyjä välittäminen ovat muuttaneet tietotekniikan roolia yrityksissä tukevas
ta toiminnosta erääksi tärkeäksi kilpailutekijäksi.
Verkottuneen yhteiskunnan ja ekonomian tuomat muutokset ovat heijastuneet myös jul
kishallinnon organisaatioiden tavoitteisiin. Yritysten kilpailukyvyn ja tuottavuuden ko
hottamiseksi ja sitä kautta kansalaisten hyvinvoinnin ja elämänlaadun parantamiseksi.
Euroopan Unioni sekä useat sen jäsenvaltiot Suomi mukaan luettuna, ovat laatineet tieto
yhteiskuntaohjelmia. Tietoyhteiskuntaohjelmissa pyritään parantamaan ja tehostamaan myös julkishallinnon omia prosesseja ja palveluja, jossa tieto- ja viestintätekniikka ovat keskeisiä välineitä muutokseen. Palvelutuotannon ja sen prosessien uudistaminen on kes
keinen parannuskohde Euroopassa jo pelkästään väestön ikääntymisen vuoksi. Suomessa
vuoteen 2015 mennessä työvoimasta jää eläkkeelle noin 670000 henkilöä, jotka tulevat tarvitsemaan julkisia palveluja enenevässä määrin eläkkeelle jäätyään [1], Samaan aikaan työelämään tulee uusia sukupolvia, jotka ovat tottuneet käyttämään sähköisiä palveluja ajastaja paikasta riippumatta.
Nämä sekä yksityisiin että julkisiin organisaatioihin kohdistuvat odotukset tietotekniikan suhteen edellyttävät keskitettyä tietoa toiminnan prosesseista ja niitä tuottavista resurs
seista. Yritysten fuusioissa sekä liiketoimintatarpeiden muuttuessa strategiset resurssit tulisi ohjata ketterästi ja tehokkaasti keskeisten palvelujen tarpeisiin. Järjestelmien väli
set, organisaation poikki kulkevat prosessit ja niiden automatisointi tulisi olla sisäänra
kennettu ominaisuus organisaation resurssien kokonaishallinnassa. Yrityksen tai organi
saation keskeisten toimintojen ja palvelujen tukeminen tietotekniikan avulla on osoittau
tunut nopeista muutostarpeista johtuvan ennustamattomuuden sekä järjestelmien moni
naisuuden ja monimutkaisuuden takia haasteelliseksi.
Monimutkaisen ongelman havainnollistamiseen ja ymmärtämiseen käytetään matemaat- tis-teknisillä aloilla perinteisesti abstrahointia, jolla ongelma pilkotaan käsitteellisesti yleisimmiksi ja pienemmiksi osakokonaisuuksiksi, määritellään osakokonaisuuksien väli
set aktit ja näiden koosteena konstruoidaan ongelmakokonaisuus ylemmän tason objek
tiksi, ja edelleen kehysmalliksi tai skeemaksi. Kehysmallin osat muodostavat rakenteen tai arkkitehtuurin1. Arkkitehtuuri kuvataan usein kerroksellisena, jossa alemmat ja ylem
mät tasot tai kerrokset muodostavat jonkin abstrahointiperiaatteen mukaisen riippuvuus
suhteen. Eräänä tunnettuna kerroksellisen kehysmallin esimerkkinä voidaan mainita ISO:n (International Organization for Standardization) OSI-malli (Open Systems Inter
connection), joka jakaa tietoliikenteen kommunikaation seitsemään teknologianippumat- tomaan kerrokseen ja niiden välisiin palveluihin.
Liiketoiminnan, sen prosessien ja niitä tukevien tietotekniikkaresurssien sekä niiden muu
toksien kokonaisuuden kuvaamiseen on kehitetty useita kehysmalleja. Tätä kokonaisuutta
' Arkkitehtuurin laajennettu alkukielinen merkitys kattaa myös monimutkaisten rakenteiden suunnittelun, esimerkiksi tietoteknisen järjestelmän, rakennustaiteen lisäksi (Oxford English Dictionary, 2nd ed. 1989).
kuvaavia kehysmalleja kutsutaan kokonaisarkkitehtuurin1 kehikoiksi11 (Enterprise Archi
tecture Frameworks). Useat suuret yksityisen ja julkisen sektorin organisaatiot ovat li
säämässä tai ovat jo lisänneet kokonaisarkkitehtuurin erääksi strategisen ohjauksen väli
neeksi.
1.1 Tausta ja motivaatio
Helsingin kaupungin tietotekniikkaa ohjataan keskitetysti Talous- ja suunnittelukeskuk
sen tietotekniikkaosaston toimesta. Tietotekniikkaosasto koordinoi kaupungin atk- toiminnan kehittämistä, huolehtii kaupungin tietotekniikan kokonaistoimivuudesta ja ko
konaisarkkitehtuurista sekä kaupungin yhteisestä tietoteknisestä infrastruktuurista. Kau
punkitasoista tietotekniikan ohjausta on tehty strategiaperustaisesti 1990-luvun alkupuo
lelta lähtien. Tietotekniikkastrategia tehdään yhteisstrategioiden jälkeen, joten tietotek
niikan toimenpidealueet saadaan täsmäytettyä toiminnan strategisten vaatimusten mukai
seksi. Kaupunkitasoisen strategiaohjauksen lisäksi virastot ja liikelaitokset valmistelevat toimialansa tietotekniikkastrategiat ja toteutussuunnitelmansa. Kaupunkikonserniin kuu
luu 35 virastoa ja laitosta, 117 tytäryhtiötä ja 9 säätiötä sekä lukuisia osakkuus-ja omis
tusyhteisöjä. Hallintokunnat eli virastot ja kunnalliset liikelaitokset jakaantuvat kaupun
ginjohtajan toimialaan, kaupunkisuunnittelu- ja kiinteistötoimeen, sivistys- ja henkilöstö- toimeen, sosiaali-ja terveystoimeen sekä rakennus-ja ympäristötoimeen. Hallintokunnis
sa on noin 38000 työntekijää, joista tietotekniikan parissa työskentelee noin 430 henkilöä.
Fyysinen tietotekniikkaympäristö koostuu noin 34000 työasemasta ja palvelimesta sekä niitä yhdistävästä, usean tuhannen toimipisteen kattavasta tietoliikenneverkosta.
Hallintokunnilla on oma tietohallintonsa, jonka vastuulla on tietotekniikan tehokas ja ta
loudellinen hyödyntäminen hallintokunnan palveluissa sekä johtamisessa. Hallintokunti
en tietohallinnon vastuut ja ohjausmenettelyt on määritelty seuraavasti: Hallintokuntien on noudatettava kaupunkitasoisia strategioita, arkkitehtuureja, standardeja ja käytettävä yhteisiä tietojärjestelmiä ja yhtenäistä tietoteknistä infrastruktuuria. Lisäksi hallintokun-
' Suomessa käytetään yleisesti yritysarkkitehtuurin (Enterprise Architecture, EA) sijasta määritystä koko
naisarkkitehtuuri.
" Tässä työssä käytetään jatkossa termin framework suomennosta kehikko.
takohtaisten järjestelmien on toteutettava yhteensopivuusperiaatetta yhteisten ja tarvitta
vilta osin toisten hallintokuntien järjestelmien kanssa.
Kaupunki aloitti toimipisteiden yhdistämisen yhteiseen tietoverkkoon noin 20 vuotta sit
ten. Hallintokunnat ottivat 1980-ja 1990-luvulla suuren joukon sekä hajautettuja ja asia
kas/palvelin -tyyppisiä tietojärjestelmiä toimintansa tueksi. 1980-luvulla otettiin käyttöön myös laajoja perustietovarantoja, esimerkiksi pääkaupunkiseudun tietorekisterijärjestel- män (PTRJ) ja kaupungin henkilöstöhallinnan tietorekisterejä. 1990-luvun loppupuolella aloitettiin ympäristön vakiointi kaupungin tietoliikenne-ja työasemaverkoissa ja kaupun
kitasoiset tietojärjestelmäratkaisut yleistyivät. Suurin osa kaupungin tietotekniikkainfra- struktuurista oli vakioitu vuoteen 2005 mennessä. Samaan aikaan kaikkia virastoja palve
levat yhteiset tietojärjestelmät, kuten sähköposti- ja kalenterijärjestelmät, asian- ja doku- menttienhallintajärjestelmät, www-palvelut, olivat laajasti virastojen käytössä. Edellisellä strategiakaudella havaittiin, että poikkihallinnollisia, usean hallintokunnan läpi kulkevia prosesseja tai muita useamman osapuolen välisiä prosesseja sekä aitoa sähköistä asiointia oli hankala toteuttaa kahdenkymmenen vuoden aikana kerääntyneillä tietojärjestelmillä.
Kaupungin tietojärjestelmiä ja niiden tuottamia palveluja on ratkaistu pääasiassa hanke
kohtaisilla ratkaisuilla, jotka eivät mahdollista hallinnollisesti läpinäkyviä poikkihallin
nollisia prosesseja tai palveluita tietojärjestelmätasolla. Kutakin ongelmaa on ratkaistu pääasiassa hallintokuntakohtaisesta tai toimintokohtaisesta näkökulmasta, jolloin ongel
man ratkaiseva järjestelmä on muodostanut erillisen siilon. Siilotyyppiset, hankekohtaiset järjestelmät ovat aiheuttaneet aikojen saatossa sekä osittain päällekkäisiä järjestelmiä että keskenään epäyhteensopivia tietojärjestelmiä. Toiminnan prosessien ja tietojärjestelmien keskinäisen tiedonvaihdon näkökulmasta infrastruktuuri on pirstaloitunut, eikä se tue pal
velujen tehostamista ilman muutoksia. [2]
Kaupungin uusimmassa tietotekniikkastrategiassa tietotekniikan yhteentoimivuuteen kiinnitetään erityistä huomiota kokonaisuuden ohjaamisen lisäksi. Näiden ongelmien rat
kaisemiseksi strategiassa on luotu perusta kaupunkiyhteisen arkkitehtuurityön aloittami
selle.
1.2 Työn tavoite
Tämän työn tavoitteena on kaupunkiorganisaatioon soveltuvan kokonaisarkkitehtuurin valinta sekä erityisesti palvelukeskeisen arkkitehtuurin määrittely strategian toteuttamisen mahdollistamiseksi. Työssä valitaan kehikko menetelmineen kaupungin tietotekniikan ja sen arkkitehtuurien kokonaishallintaan. Lisäksi tutkitaan palvelukeskeisen arkkitehtuurin suhdetta kokonaisarkkitehtuuriin sekä tietojärjestelmien yhteentoimivuuden mahdollis
tamista ja pirstaloitumisen ehkäisemistä arkkitehtuureilla. Yhteentoimivuuteen haetaan ratkaisua ensisijaisesti toiminnan prosessien tasolla, mikä mahdollistetaan sopivalla alus- tatekniikalla. Työn tulokset koostavat kokonaisvaltaisen käsityksen arkkitehtuurilähtöi- sestä toiminnan kehittämisestä ja vastaavat seuraaviin avainkysymyksiin:
Kuinka arkkitehtuureilla voidaan tehostaa palveluja ja niiden prosesseja?
- Minkälainen kokonaisarkkitehtuuri soveltuu kaupunkiorganisaation nykyiseen ja tulevaan käyttöön?
Kuinka arkkitehtuurityöstä saadaan hyötyjä riittävän nopeasti?
Miten palvelukeskeinen arkkitehtuuri liittyy kokonaisarkkitehtuuriin?
Mistä komponenteista palvelukeskeinen arkkitehtuuri koostuu?
Kuinka arkkitehtuuria hallitaan?
Kysymyksiin etsitään vastauksia alan kirjallisuudesta sekä tutkimuksista, seminaareista ja toteutusmalleista. Arkkitehtuurikehikkojen soveltuvuutta arvioidaan kattavuuden, jatku
vuuden, referenssien ja toteuttamiskelpoisuuden perusteella.
2 Arkkitehtuurit ja organisaation toiminta
Tässä luvussa etsitään vastauksia siihen perusongelmaan, kuinka tietotekniikalle ja orga
nisaation toiminnalle saadaan yhteinen kehityssuunta. Saman kehityssuunnan lisäksi etsi
tään ratkaisua monimutkaisen tietoteknisen ympäristön hallintaan niin, että resursseja voidaan ohjata paremmin ja tietojärjestelmien yhteensopivuus voidaan varmistaa. Kirjal
lisuudesta etsitään strategian jalkauttamiseen keinoja tietotekniikan arkkitehtuureista - kokonaisarkkitehtuureista ja palvelukeskeisestä arkkitehtuurista.
2.1 Arkkitehtuurit strategian mahdollistajana
Tutkimusten mukaan suurin syy kokonaisarkkitehtuurin käyttöönottoon liikeyrityksissä on ollut liiketoiminnan ja lT:n suuntaaminen lähemmäs toisiaan, samaan suuntaan (Bu- siness-IT Alignment) [3], Julkishallinnossa kokonaisarkkitehtuurin odotukset ovat hie
man erilaisia verrattuna liikeyritysten toiminnan muutoksiin, jossa yrityskauppojen tuo
mat fuusiot sekä palvelujen ketterä tuottaminen markkinoille oikeaan aikaan ovat keskei
siä kilpailutekijöitä. Julkishallinnossa kokonaisarkkitehtuurien odotetaan parantavan hal
linnon välisten järjestelmien yhteensopivuutta sekä prosessien tehokkuuden parantamista vuonna 2006 tehdyn kyselyn mukaan [6].
Ross, Weill ja Robertson ovat tehneet joukon tutkimuksia kokonaisarkkitehtuurin käytös
tä yli 400 suuressa yrityksessä USA:ssa ja Euroopassa. Tutkimuksessa löydettiin kaikista yrityksistä yhteisiä tekijöitä strategian toimeenpanemiseen. Tutkimuksen mukaan tehok
kaan strategian jalkauttamisen perustaksi organisaatio tarvitsee kolme asiaa [7];
• toimintamallin,
• kokonaisarkkitehtuurin ja
• IT:n sitouttamismallin.
IT:n sitouttamismalli sisältää IT-toimintojen kokonaisvaltaisen hallintamallin. Vastaavan
laisista komponenteista koostuu myös Business-IT Alignment Method (BITAM), jonka tavoitteena on suunnata IT ja toiminta lähemmäs toisiaan iteratiivisella hallintamallilla ja toiminnan ohjaamalla arkkitehtuurilla [8],
IT-toimintojen ketterää suuntaamista ja joustavuutta sekä järjestelmien yhteensopivuutta voidaan parantaa myös palvelukeskeisellä arkkitehtuurilla (Service Oriented Architectu
re, SOA) [8]. SOA on arkkitehtuurityyli, tapa ajatella asioita, millä toimintaa tukevat tie
totekniikkapalvelut suunnitellaan modulaarisiksi ja uudelleen käytettäviksi komponen
teista.
2.2 Organisaation toimintamallit
Neljään Rossin luettelemaan organisaation toimintamalliin luetaan diversifioitu, koordi
noitu, replikoitu ja unifioitu malli [7]. Diversifioidussa mallissa toimintayksiköt, esimer
kiksi hallintokunnat, ovat toiminnallisesti uniikkeja ja IT-päätökset tehdään toimintayksi
kön sisällä. Prosesseja ei ole integroitu eikä standardoitu organisaatiossa. Koordinoidussa mallissa toimintayksiköt ovat uniikkeja, mutta jakavat osan yhteisestä datasta ja palve
luista, kuten IT-infrastruktuurista. Replikointimallissa toimintayksiköt ovat samankaltai
sia, prosessit ovat standardoituja ja IT on keskitettyä. Unifiointimallissa toiminta ja pro
sessit ovat yhtenäistettyjä, standardoituja sekä integroituja, ja IT-palvelut hallitaan keski
tetysti. Toimintamalli voi olla konsernitasolla ja (liike)toimintayksikön sisällä erilaisia - esimerkiksi konserni voi toteuttaa koordinoitua mallia ja toimintayksikkö replikoitua mallia. Kokonaisarkkitehtuurilla voidaan toteuttaa organisaation toimintamallia painot
tamalla sopivassa suhteessa prosessien standardointia ja toisaalta toiminnan integraatiota.
2.3 Kokonaisarkkitehtuuri
Kokonaisarkkitehtuurin sanotaan olevan väline organisaation perustan rakentamiseen, millä selviydytään nykyisistä ja tulevista toiminnan asettamista haasteista. Kokonaisark
kitehtuuri identifioi organisaation peruskomponentit - henkilöstön, toimintaprosessit, teknologian sekä muut organisaatioon liittyvät resurssit. Oikein tehtynä kokonaisarkki
tehtuuri varmistaa oikeiden komponenttien valinnan ja niiden välisen joustavan toimin
nan. [11]
Kokonaisarkkitehtuuri ei ole teknologiaa, vaan se toimii päätöksenteon tukena, muutok- senhallinnan välineenä, parantaa kommunikaatiota IT:n ja toiminnan välillä sekä varmis
taa tietotekniikan tukevan strategista toimintaa [12]. Tyypillinen kokonaisarkkitehtuuri koostuu näkymistä, jotka ovat tarkoitettu eri osapuolten nähtäviksi. Liiketoiminnasta vas
taavat näkevät liiketoiminnan näkökulmasta arkkitehtuurin ja teknologiasta vastaavat nä
kevät toimenkuvaansa vastaavan näkymän. Koska sama asia on kuvattu eri abstrak
tiotasoilla, arkkitehtuuri toimii suoraan resurssien dokumentointina kaikilla tasoilla sekä erinomaisena kommunikaation välineenä kahden eri näkökulman välillä. Kokonaisarkki
tehtuuri pitää sisällään myös tavoitetilan ja nykytilan, jolloin näiden tilojen siirtymävälin hallinta on oleellinen johtamisen apuväline monimutkaisen ympäristön jatkuvassa muu
toksessa. Kokonaisarkkitehtuurin voidaan myös hahmottaa ajatusmallina tietotekniikan vuorovaikutuksesta organisaation toimintaympäristöön. Ajatusmalli on osa oppivan orga
nisaation systeemiajattelua, jossa nähdään kokonaisuuksia pienten palojen sijasta [13].
2.3.1 Kokonaisarkkitehtuurikehikot
Kokonaisarkkitehtuurin komponenttien jäsentämistä varten on kehitetty kokonaisarkki- tehtuurikehikoita. Kehikot voidaan jakaa käyttäjiensä perusteella seuraaviin tyyppeihin;
kaupallisin ja yleiskäyttöisiin kehikoihin, julkishallinnon ja puolustusvoimien kehikoihin sekä organisaatioiden itse kehittämiinsä kehikoihin. Vuonna 2005 tehdyn tutkimus- kyselyn mukaan 45 prosenttia organisaatioista käytti yleisiä kehikolta, 22 prosenttia jul
kishallinnon kehikolta, 22 prosenttia käyttivät omaa kehikkoaan ja loput muita kehikolta [3].
Yleiset kehikot
John Zachmanin kokonaisarkkitehtuurikehikkoa pidetään ensimmäisenä kokonaisarkki
tehtuurin välineenä [14]. Zachman loi ensimmäisen version kehikosta vuonna 1987 olles
saan IBM:n palveluksessa. Architecture Forum lähti kehittämään vuonna 1994 yleiskäyt
töistä kehikkoa ja avointa standardia kokonaisarkkitehtuuriin. Vuotta myöhemmin jul
kaistiin The Open Group Architecture Framework (TOGAF) versio 1. Institute For En
terprise Architecture Developments (IFEAD) on kehittänyt Extended Enterprise Archi
tecture Frameworkm (E2AF) vuonna 2003.
Julkishallinnon kehikot
Valtiot ovat kehittäneet omat kehikkonsa. USA aloitti kehikoiden tekemisen 1990-luvun puolessa välissä. Näistä laajin kehikko on USA:n liittohallituksen Federal Enterprise Ar
chitecture Framework (FEAF). USA:ssa on kehitetty Treasury Enterprise Architecture Framework (TEAF, aiemmin TISAF). Euroopan Unioni (EU) on tehnyt yhteensopivuus- kehikon, European Interoperability Frameworkm (EIF) [15]. Kansallinen kokonaisarkki- tehtuuriohjelma on Kanadassa, Tanskassa, Virossa, Koreassa, Singaporessa, Japanissa, Taiwanissa, Sveitsissä, Alankomaissa ja Iso-Britanniassa [6]. Useat EU-maat ovat aloitte
lemassa kokonaisarkkitehtuuriohjelmaa, Suomi mukaan luettuna. Suomessa valtionhallin
to Valtiovarainministeriön ohjauksella on valmistellut valtionhallinnolle yhteentoimivuu
den kehittämisohjelman, joka aloitetaan vuoden 2007 aikana. Kehittämisohjelma kattaa kokonaisuudessaan valtionhallinnon arkkitehtuurin hankkeet [16].
Puolustusvoimien kehikot
Eri maiden puolustusvoimat ja -liitot ovat luoneet omat kehikkonsa - USAdla on De
partment of Defence Architecture Framework (DoDAF, aiemmin C4ISR), Iso-
Britannialla Ministry of Defence Architecture Framework (MoDAF), Ranskalla Atelier de Gestion de I'ArchiTEcture des systémes d'information et de communication (AGATE), North Atlantic Treaty Organizatiomn (NATO) NATO Architecture Framework (NAF) sekä Kanadalla ja Australialla omansa. International Defence Enterprise Architecture Specification (IDEAS) Group pyrkii mahdollistamaan eri maiden puolustusvoimien tieto
jen vaihtoa kehittämällä formaalia ontologiaa1 käsitteille [17].
FEAF 1999
E2AF
XAF 2002 ISO/IEC
14252
UVA IAF VI
Zachman 2003 DODAF 2003
TEAF 2000
TI S AF 1997
TOGAF 2002
Zachman 1987
C4ISR 1999
EAP1992 FEAF TAFIM
TOGAF 1995 DODTRM
IAF V3 EE
CIMOSA
SAGA PERÄ
Kuva 1. Kokonaisarkkitehtuurien historia. |14|
Meta kehikot
International Federation for Information Processing / International Federation of Auto
matic Control (IFIP-1AFC) Task Force sai valmiiksi vuonna 1999 Generalised Enterprise Reference Architecture and Methodologym (GERAM), geneerisen viitemallin kokonais
arkkitehtuuriin. mihin ISO 15704 -standardi perustuu [18]. GERAM sulautti aiemmin
1 Ontologia auttaa eri osapuolten välillä termien merkityksen sopimisessa. Ontologia on eksplisiittinen ku
vaus termin merkityksestä sekä sen suhteista toisiin termeihin.
tehdyt CIMOSA:n ja PERA:n viitemalliin. IF1P-IAFC on pääasiassa keskittynyt organi
saation integraatioratkaisuihin, eikä GERAM:ia ole tarkoitus käyttää kehikkona suoraan.
IEEE:n Architecture Planning Group (APG) on määritellyt ohjelmistointensiivisten jär
jestelmien arkkitehtuurikuvauksista suosituksen (IEEE 1471-2000), joka yhdistettiin kan
sainväliseksi ISO/lEC-standardiksi [19] vuonna 2007.
Kokonaisarkkitehtuurikehikkoja tarkastellaan tarkemmin luvussa 3 Kokonaisarkkitehtuu
rit.
2.3.2 Kokonaisarkkitehtuurin kypsyyden mittaaminen
Kokonaisarkkitehtuurin kokonaisvaltainen käyttöönotto on pitkä ja vaativa prosessi. Or
ganisaatioissa on valmiita tietojärjestelmiä, joihin toiminta on sidottu tiukasti. Kokonais- arkkitehtuuriohjelman suorittamisen aikana on yhtä aikaa vanhoja järjestelmiä, joiden suunnittelussa ei ole käytetty arkkitehtuuriohjausta sekä kokonaisarkkitehtuurimielessä kärkihankkeita, jotka tehdään suoraan arkkitehtuurimenetelmien edellyttämällä tavalla.
Tästä seuraa se, että organisaation eri osissa kokonaisarkkitehtuuri on eri kypsyystasolla.
Tasapainoinen ja kokonaisvaltainen kehittäminen edellyttää kypsyystason asteittaista nostamista suunnitelmallisella tavalla. Ross listaa neljä arkkitehtuurista kypsyystasoa, jotka peilaantuvat hyvin aiemmin esitettyihin organisaation toimintamalleihin [20]:
- Siilojärjestelmät, jossa tietojärjestelmät hankitaan toimintayksikkötasolla tai hankekohtaisesti. Integrointi järjestelmien kesken on hidastaja kallista.
- Standardoitu teknologia, jossa osa järjestelmistä on keskitetty ja ratkaisuja standardoitu. Tämä on kustannustehokkaampi kuin edellinen kypsyystaso, mutta ei ratkaisu siilo-ongelmaan.
Optimoitu ydintoiminnallisuus, jossa ydinprosessit ja data hallitaan keskitetys
ti. Prosessien muuttaminen on hankalampaa, mutta uusien palvelujen käyt
töönotto nopeampaa.
Modulaarinen toiminnallisuus, prosessit ja palvelut ovat uudelleen käytettäviä ja modulaarisia. Modulaarinen toiminnallisuus edellyttää myös standardointia ja optimoitua ydintoiminnallisuutta. Modulaarisuus ja uudelleen käytettävä toiminnallisuus ovat SOA:n perusperiaatteita.
National Association of State Chief Information Officers (NASCIO) Enterprise Architec
ture Maturity Model (EAMM) jakaa organisaation arkkitehtuurikypsyyden kuuteen luok
kaan. Tasolla 6 ei ole ohjelmaa, tasolla 1 epävirallinen ohjelma, tasolla 2 toistettava oh
jelma, tasolla 3 hyvin määritelty ohjelma, tasolla 4 hallittu ohjelma ja tasolla 5 jatkuvasti kehittyvä ohjelma. [21]
Arkkitehtuurin kypsyystasoon liittyviä mittareita on useita. Useimmat keskittyvät proses
seihin ja kyvykkyyksiin (Capability Maturity Model, CMM). Software Engineering Insti
tute (SEI) on kehittänyt useita kypsyystasomalleja, erityisesti ohjelmistokehityksen näkö
kulmasta, 1990-luvun alusta lähtien. SEI:n CMM Integration -kehikko' on tarkoitettu eri
tyisesti monimutkaisuuden hallintaan ja sopii myös arkkitehtuurin prosessien kehittämi
seen. USA:n Department of Commerce (DoC) on kehittänyt IT Architecture Capability Maturity Model:n (ACMM), jossa on kolme eri mittaria; arkkitehtuurin kypsyystasomal- li, arkkitehtuurin prosessien kypsyysmalli ja arkkitehtuurikyvykkyyden score card (SC) [22], Näillä mittareilla voidaan saavuttaa tuottava arkkitehtuuriprosessi. ACMM jakaan
tuu kuuteen eri kypsyystasoon, jotka ovat jaettu samantyyppisesti kuin NASCIOm mal
lissa.
2.4 IT:n sitouttamismalli
Fonstadin ja Robertsonin tutkimuksessa IT:n sitouttamismalli sisältää kolme osaa; orga
nisaation laajuisen IT-hallintamallin" käytön, standardoidun projektinhallinnan ja kahden edellisen yhdistämismekanismin [Kuva 2], Sitouttamismalli on systemaattinen hallinta-
Lisätietoja CMMEstä http://www.sei.cmu.edu/cmmi/.
IT-hallintamalli on tässä IT Governance, joka on suomennettu myös hyväksi tietohallintotavaksi
menetelmä, jolla IT-projekteissa saavutetaan toiminnan tavoitteet koko organisaation ta
solla. Vaikka organisaatiossa on käytössä IT-hallintamalli ja projektinhallinta, projektien tulokset eivät välttämättä vastaa toiminnan strategiassa asetettuja tavoitteita [23]. Tämän tavoitteen takia sitouttamismallissa on yhdistämismekanismi mukana.
Tutkimuksessa määriteltiin myös kolme tapaa tehokkaalle yhdistämismekanismille; liike- toimintalinkitys, arkkitehtuurilinkitys ja suuntaamislinkitys. Liiketoimintalinkitys kytkee projektit organisaatio- ja toimintayksikkötason strategioihin. Arkkitehtuurilinkitys kytkee projektit organisaatio- ja toimintayksikkötason arkkitehtuureihin. Suuntaamislinkitys kytkee IT:n muuhun toimintaan toimintayksikkötasolla.
ALIGNMENT
© 2005 MIT Sloan CISR and IMD International - Fonstad and Robertson
Kuva 2. IT:n sitouttamismalli. [23]
IT:n kattavaan hallintaan (IT Governance) löytyy laaja valikoima kehikolta, esimerkiksi riski-ja suorituskykyhänintaan Control Objectives for Information and related Technolo
gy (COBIT)', palveluihin keskittyvä IT Infrastructure Library (ITIL)" sekä sen pohjalta tehty ISO/IEC 20000-1:2005 -standardi ja tietoturvan hallintaan keskittyvä ISO/IEC 27002:2005 -standardi. COBIT on näistä malleista myös strateginen väline, joka on ta- 1
1 Lisätietoja IT Governance Institute, www.itgi.org.
" Lisätietoja www.itil-officialsite.com/.
voineiltaan samankaltainen verrattuna kokonaisarkkitehtuuriin - molemmilla tavoitellaan yhdensuuntaisuutta liiketoiminnan kanssa.
Arkkitehtuurien hallintamallia tarkastellaan luvussa 6.
2.5 Palvelukeskeinen arkkitehtuuri
Arkkitehtuureja suunnitellaan ylhäältä-alaspäin (top-down), alhaalta-ylöspäin (bottom- up) tai keskeltä (meet-in-the-middle). Kokonaisarkkitehtuureissa menetelmä ohjaa suun
nittelun strategisista tavoitteista lähtien, ylhäältä toimintaprosessien kautta niitä tukevaan teknologiaan alaspäin. Lähestymistapana tämä on teoreettisesti oikea ja suositeltava, mut
ta käytännössä organisaatiossa on valmiita siiloutuneita tietojärjestelmiä, joita ei ole suunniteltu organisaatiolaajuisesta toiminnan prosessien näkökulmasta. Tämä lähestymis
tapa vaatii myös eniten aikaa - toiminnan prosessit suunnitellaan ennen järjestelmiä - tilanteessa, jossa lähdetään arkkitehtuurin alimmilta kypsyystasoilta.
Laajan tietoteknisen ympäristön omaavissa organisaatioissa joudutaan käyttämään mo
lempia lähestymiskulmia arkkitehtuurityön alkuvaiheessa. Alhaalta-ylöspäin näkökulmasta suunnitellaan ja implementoidaan tekninen kivijalka myöhempiä toiminta- tarpeita varten. Tämän näkökulman omaavien projektien strateginen soveltuvuus ja riski tulee analysoida tarkoin, ettei kokonaisarkkitehtuurimielessä tehdä tulevaisuudessa tar
peettomiksi jääviä palveluja. Arkkitehtuurimielessä keskeltä suunnittelu tapahtuu silloin, kun valmiiseen järjestelmään tai sovelluspalveluun on liityntä, jonka kautta järjestelmä integroidaan uuteen palveluun tai prosessin osaksi. SOA:a voidaan suunnitella näillä kolmella tavalla, joskin ylhäältä-alaspäin on suositeltavin tapa toiminnan ja IT:n eheäm- pään sitomiseen.
SOA:lle ei ole yksikäsitteistä määrittelyä. SOA ei ole teknologia, eikä arkkitehtuuri, vaan (arkkitehtuuri)tyyli tai malli tehdä palveluja. Organization for the Advancement of Struc
tured Information Standards (OASIS) määrittelee viitearkkitehtuurissaan SOA:n olevan malli hajautettujen kyvykkyyksien, jotka voivat olla eri tahojen hallinnoimia, organisoin
tiin ja käyttöön [24], Erilaisia SOA-kehikoita on tarjolla standardointiorganisaatioista, sovellustoimittajilta, tutkimusyrityksiltä ja julkishallinnosta. Palvelukeskeisen arkkiteh
tuurin kehikot ovat pääsääntöisesti sovelluskehittäjiä varten tehtyjä menetelmäkokoelmia, mutta osa kehikoista toimii myös laajempana kehikkona. Seuraavaksi esitellään muuta
mia avoimia ja teknologianippumattomia kehikolta, jotka soveltuvat SOA:n kehittämi
seen.
Model Driven Architecture (MDA) on Object Management Groupin (OMG) eri arkkiteh- tuurinäkökulmiin perustuva tapa kehittää ohjelmistoja. MDA:n taustalla on OMG:n ai
empi työ olioarkkitehtuurien, Object Management Architecturem (OMA) ja Common Object Request Broke Architecturem (CORBA) kanssa, mutta MDA laajentaa näistä ha
jautetuista olio- tai agenttipohjaisista sovellusarkkitehtuureista fokuksen malleihin. Nä
kökulmien mallit tai näkymät ovat Platform Independent Model (PIM), Computation In
dependent Model (CIM), Platform Specific Model (PSM) ja Platform Model, joista saa
daan teknologianippumattomat kuvaukset sekä tekniseen ympäristöön liittyvät kuvauk
set. Mallit luodaan OMG:n kehittämällä UML (Unified Modeling Language) - kuvauskielellä.[25]
Service Component Architecture (SCA) on joukko määrittelyjä, jotka kuvaavat mallin sovellusten ja systeemien tekemiseen palvelukeskeiseen arkkitehtuuriin [25]. SCA on Open Service Oriented Architecturem (OSOA) luoma avoin, teknologianippumaton komponenttiarkkitehtuuri. SCAm ohjelmointimalli mahdollistaa toteutuksen useilla eri ohjelmointikielillä. Ohjelmointimalli kattaa palvelujen rakentamisen, heterogeenisten komponenttien sijoittamisen verkkoon sekä heterogeeniseen ympäristöön. SCAm määrit
telyjen standardointi on aloitettu 2007 OASIS-konsortion kanssa. OASIS-konsortio on pyrkinyt standardoimaan SOA-käsitteitä kehittämällä myös viitemallin SOA:lle (Refe
rence Model for SOA) vuonna 2006 [24]. Viitemallissa pyritään sitomaan sovelluspalve
lut tiiviimmin liiketoimintaan samaan tapaan kuin kokonaisarkkitehtuurikehikoissa.
Service Oriented Migration and Reuse Technique (SMART) on SEI:n esittelemä tekniik
ka, jolla voidaan helpottaa organisaatioiden legacy-järjestelmien1 tai osajärjestelmien in
tegrointia SOA:han. SMART:ssa otetaan mukaan sovellukseen liittyvät osapuolet, kuva
taan olemassa olevat kyvykkyydet ja legacy-järjestelmän SOA-valmius, analysoidaan tarvittavat muutokset ja mahdollinen ero halutun tilan välillä. [27]
The Open Group on muodostanut työryhmän vuonna 2005 SOA:a varten [28]. Työryh
män tavoitteina oli yhtenäisen ymmärryksen kehittäminen liiketoiminnan ja IT:n välille SOA:sta. Työryhmän ohjelmaan on valittu SOA:n määrittely, esimerkkitapausten tutkin
ta, kypsyysmalli, viitemalli, SOA:n ja EA:n liitännät, hallintamalli, ontologia, legacy- järjestelmien evoluutio ja suorituskykymittarit. Kesällä 2007 työryhmän listalle lisättiin Service Oriented Infrastructure (SOI) ja SOA:n tietoturvallisuus. Näiden ominaisuuksien avulla SOA voidaan ottaa osaksi kokonaisarkkitehtuurikehikkoa ja erityisesti TOGAF:n kehittämissykliä, ADM:ää.
Palvelukeskeistä arkkitehtuuria käsitellään luvussa 4 Palvelukeskeinen arkkitehtuuri.
2.6 Yhteenveto
Tietotekniikan ja organisaation toiminnan suuntaamiseen organisaatio tarvitsee toimin
tamallin, kokonaisarkkitehtuurin ja IT:n sitouttamismallin. IT:n sitouttamismalli sisältää organisaation laajuisen IT-hallintamallin käytön, standardoidun projektinhallinnan ja näi
den yhdistämismekanismin. Kokonaisarkkitehtuuri mielletään kirjallisuudessa keinoksi järjestää organisaation tietotekniikka niin, että organisaation toimintaa voidaan tukea jat
kuvassa muutoksessa tehokkaasti ja järjestelmällisesti. Kokonaisarkkitehtuuri ja lT:n hal
lintamalli ohjaavat organisaation päätöksentekoa ja kohdistaa resursseja tehokkaasti. Ko- konaisarkkitehtuurityötä voidaan mitata parhaiten kypsyystasomittareilla. Kokonaisarkki
1 Legacy.ksi kutsutaan organisaatiossa olemassa olevaa sovelluksesta ja laitteistosta koostuvaa systeemiä, jonka katsotaan olevan vanhanaikainen nykyiseen teknologiaan verrattuna. Arkkitehtuurin näkökulmasta legacy-järjestelmät ovat usein monoliittisia, jossa järjestelmä sisältää toimintalogiikan, datan ja käyttöliit
tymät järjestelmään tiiviisti upotettuna.
tehtuurista voidaan ulosmitata nopeasti hyötyjä esimerkiksi palvelukeskeisellä arkkiteh- tuurityylillä, SOA:lla. SOA:a voidaan suunnitella myös alhaalta lT:n ja tietoteknisen inf
rastruktuurin näkökulmasta ylöspäin liiketoimintakerrokselle.
Kokonaisarkkitehtuureja on kehitetty noin 20 vuotta, jonka ansiosta useita erilaisia arkki- tehtuurikehikoita on tarjolla. Kokonaisarkkitehtuuriin katsotaan kuuluvan kehikko, mene
telmä sekä hallintamalli. Palvelukeskeiseen arkkitehtuurityyliin on kehitetty useita kehi
kolta pääsääntöisesti sovelluskehityksen tarpeisiin.
Suurten organisaatioiden, joksi Helsingin kaupunki voidaan laskea Suomen mitta- asteikolla, ongelmaksi on muodostunut kokonaisarkkitehtuurin ja tietotekniikan linkittä
minen toiminnan kehittämiseen. Julkisen sektorin ongelmana on usein omistajan löytä
minen poikkihallinnollisille prosesseille ja laajoille hankkeille tai ohjelmille1. Toimintaa kehitetään usein vain ydintoiminnan näkökulmasta eikä tietotekniikkaa hyödynnetä aikai
sessa vaiheessa. Toisaalta tietotekniikan vastuutaho ei voi omistaa toiminnan kehittämi
seen tähtäävää hanketta, vaikka siihen sisältyisi huomattavissa määrin tietotekniikkaa.
Kokonaisarkkitehtuurin mukainen tietotekniikan ja toiminnan menestyksekäs kehittämi
nen edellyttää kattavaa linkitysmenetelmää sekä hallintamallia. Linkitystä voidaan paran
taa osaltaan koko organisaatioita käsittävällä hankehallinnalla, jossa on mukana arkkiteh- tuurinäkökulma. Kokonaisarkkitehtuurin toimintaan sidottu hallinta puolestaan ohjaa or
ganisaatioita kohti unifioitua toimintamallia.
' Helsingin kaupungilla hanke on laajempi käsite kuin projekti. Hanke sisältää laajemman kehittämisohjel
man tai -kokonaisuuden ja vastaa siten englanninkielistä sanaa program. Hankkeella voi olla useita projek
teja.
3 Kokonaisarkkitehtuurit
Tässä luvussa tarkastellaan yleisimpiä kokonaisarkkitehtuureja ja niiden rakennetta sekä kattavuutta. Kehikoiden soveltuvuuden kriteerit asetetaan standardikatsauksen jälkeen.
Standardeista katsotaan arkkitehtuurin konseptuaalista mallia, IEEE 1471-2000:ta. Paras
ta soveltuvuutta kaupungin kokonaisarkkitehtuurikehikoksi arvioidaan yleisimpien jul
kishallinnossa käytettyjen kehikoiden kesken.
3.1 Kokonaisarkkitehtuurin määritelmä
Kokonaisarkkitehtuurista on monta määritelmää. IEEE Std 610.12-1990, standardi oh
jelmistosuunnittelun terminologiasta määrittelee arkkitehtuurin olevan systeemin tai komponentin organisoitu rakenne [29], IEEE 1471-2000 -standardissa tunnistetaan erilli
senä käyttäjäryhmänä henkilöt, järjestelmien kehittäjien ja ylläpitäjien lisäksi, jotka suun- nittelevat koko organisaation laajuista infrastruktuuria sisältäen muuan muassa metodo
logian ja prosessit. Tässä mielessä standardi pitää sisällään myös kokonaisarkkitehtuurin käsitemallin. Standardissa mainitaan arkkitehtuurikuvauksien (Architectural Description, AD) käyttökohteista:
Systeemin': ja sen evoluution ilmaiseminen, - systeemin osapuolten välinen kommunikaatio,
arkkitehtuurien evaluointi ja vertailu yhdenmukaisella tavalla,
systeemin kehitystoimintoihin liittyvä suunnittelu, hallinta ja suoritta
minen,
hyväksyttävään muutokseen ohjaavien tekijöiden, kuten systeemin py
syvien tuntomerkkien ja tukiperiaatteiden ilmaiseminen,
systeemin implementoinnin verifiointi arkkitehtuurikuvauksia vasten ja - arkkitehtuuritietämyksen kasvattaminen tuloksien seurannalla.
' IEEE 1471-2000 määrittelee systeemin olevan joukko järjestettyjä komponentteja, joilla saavutetaan tietty funktio tai joukko funktioita. Systeemi voi olla ohjelmistokomponentti tai laajennetussa merkityksessä, organisaation koko ympäristö toimintoineen ja sitä tukevine järjestelmineen.
Standardin konseptuaalinen malli [Kuva 3] arkkitehtuurikuvauksesta sijoittaa systeemin ympäristöön, kontekstiin, mikä määrittää ja aiheuttaa systeemille kehityksellisiä, operaa- tionaalisia, poliittisia ja muita vaikutuksia. Systeemillä on yksi tai useampi osallinen, jol
la on odotuksia tai vaatimuksia esimerkiksi suorituskyvyn, luotettavuuden, turvallisuu
den, toimittamisen tai ylläpidettävyyden suhteen. Systeemi toteuttaa yhtä tai useampaa missiota, jossa osapuolet ovat määritelleet tavoitteita. Jokaisella systeemillä on arkkiteh
tuuri, josta voidaan tehdä kuvaus, AD. AD voidaan järjestää yhteen tai useampaan näky
mään tai näkökulmaan1, joista kukin näkymä osoittaa osallisensa tarvitsemat tiedot. Nä
kökulma sisältää perustavat kunkin näkymän luomiseen ja analysoimiseen sekä määritte
lee notaatiot, mallit metodeineen sekä kuvaustyypit näkymän kuvaamiseen. Arkkitehtuu
rikuvauksen näkökulmien valinta tehdään osallisten tarvitsemista näkymistä. AD:n mää
rittely voi sisältää näkymät tai näkymät voidaan tuottaa valmiista näkymäkirjastoista.
Näkymä koostuu yhdestä tai useammasta arkkitehtuurimallista, jotka ovat kehitetty nä
kymän tarpeista lähtien.
IEEE 1471-2000:n määritelmä arkkitehtuurista on terminologiastandardia tarkempi ku
vaus: Arkkitehtuuri koostuu systeemin ja sen komponenttien fundamentaalinen järjestyk
sestä, komponenttien välisistä sekä komponenteista ympäristöön kohdistuvista suhteista ja periaatteista, joilla hallitaan arkkitehtuurin suunnittelua ja kehitystä.
' IEEE 1471-2000 liite B määrittelee näkökulman (viewpoint) näkymän (view) abstraktioksi. Näkymä on siten reaalinen esitys tietystä järjestelmästä.
fulfills 1..*
influences has an
System Environment
inhabits
has 1..*
is important to
provides Architectural
Description Stakeholder
addressed to participates in
organized by identifies
conforms to Viewpoint
Concern
used to
consists of participates in
has source aggregates
establishes methods for Library
Viewpoint
Architecture Mission
Rationale
Kuva 3. Arkkitehtuurikuvauksen konseptuaalinen malli (ISO/IEC 42010:2007 IEEE Std 1471-2000).
Kokonaisarkkitehtuurin määritelmiä on useita-jokainen kokonaisarkkitehtuurin kehikon kehittäjä on määritellyt omansa. Esimerkiksi Valtiovarainministeriön ValtlTm kokonais- arkkitehtuurityössä on määritelty seuraavasti: ”Kokonaisarkkitehtuuri on toiminnan pro
sessien ja palvelujen, tietojen sekä tietojärjestelmien ja teknologiaratkaisujen tuottamien palvelujen muodostaman kokonaisuuden rakenne. Rakenteella tarkoitetaan kokonaisuu
den rakenneosia, rakenneosien suhteita toisiinsa ja ympäristöönsä. ” [30]. Tämä määri
telmä on ylätasolla kattava. Ainoa aukikirjoittamaton asia määritelmässä on toiminnan kehityskaari, evoluutio, mikä mainitaan IEEE-standardin arkkitehtuurimääritelmässä.
Edellä mainitusta arkkitehtuurimääritelmistä voidaan päätellä, että kokonaisarkkitehtuuri ei ole teknologiaa, ainakaan määräävässä osassa. Kokonaisarkkitehtuurin komponentit sisältävät liiketoiminnan ja teknologian rakenteet ohjeineen ja periaatteineen. Kokonais
arkkitehtuuri sisältää nykyisen ja tulevan tilanteen sekä mallin näiden tilanteiden väliseen
siirtymään. Arkkitehtuurikuvauksilla jäsennetään komponenttien evoluutiota, hallintape- riaatteita sekä suhteita toisiinsa ja ympäristöön eri näkymistä, esimerkiksi liiketoiminnan tai teknologian näkökulmasta. Nämä arkkitehtuurikuvaukset muodostavat merkittävän osan kokonaisarkkitehtuurikehikosta (Enterprise Architecture Framework).
3.2 Kokonaisarkkitehtuurikehikon soveltuvuuden arvioinnin kriteerit
lEEE-standardin suositusten perusteella voimme asettaa periaatteita arkkitehtuurikehikol- le. Kehikossa tulisi olla kuvaukset eri näkökulmia palveleville näkymille, jotka tuotetaan mallintamalla tai esimerkiksi analyyttisillä metodeilla. Näkökulman ja mallin määrittely saadaan arkkitehtuuri kuvauksesta. Arkkitehtuurikuvauksen tulisi identifioida tarvittavat osapuolet sekä sisältää kuvausten kattavuuden tarkastelemiseen tarvittavat välineet. Li
säksi kokonaisarkkitehtuurikehikon tulisi sisältää menetelmä kehitystyötä varten sekä sii
hen tulisi olla liitettävissä IT-hallintamalli. IT-hallintamallissa tulee ottaa huomioon kau
pungin federalistinen toimintamalli tietohallinnon ohjausmenettelyissä. Federalistisessa mallissa on useita melko itsenäisiä osapuolia, joita ohjataan kokonaan tai osittain organi
saatiorajat ylittävästä keskushallinnosta.
Koska kohdeorganisaatiolla ei ole valmiita prosesseja tai hallintamenetelmiä järjestelmäl
liseen tietotekniikan kokonaisuuden hallintaan, kehikon tulisi sisältää metodologia arkki
tehtuurin kehittämiseen. Jatkossa, kun arkkitehtuurityön kypsyys ja ohjaus organisaatios
sa on riittävä, voidaan käyttää myös vaativampia kokonaisarkkitehtuurikehikoita ja mene
telmiä [31]. Otettaessa kokonaisarkkitehtuuria ensimmäisen kerran käyttöön, kehikon ja sen menetelmien tulisi olla riittävän ketteriä todellisten hyötyjen saamiseksi kohtuullises
sa ajassa.
Kehikon soveltuvuutta arvioidaan seuraavista näkökulmista:
- Kattavuus: Kehikko toteuttaa lEEE-standardin periaatteet.
- Jatkuvuus: Kehikkoa kehitetään aktiivisesti ja se avoimesti saatavilla.
- Referenssit: Kehikosta on käyttökokemusta julkishallinnon organisaati
oissa.
- Toteuttamiskelpoisuus: Kehikko on käyttöönotettavissa kaupungin ym
päristössä ja kaupunkiorganisaation toimintamallissa, rajallisilla resurs
seilla.
Arvioinnissa käytetään apuna aiemmin tehtyjä tutkimuksia.
3.3 Kokonaisarkkitehtuurikehikot
Kokonaisarkkitehtuurikehikoista tarkastellaan kahta tunnettua yleistä kehikkoa, Zach- man-arkkitehtuuria sekä The Open Group Architecture Frameworkia (TOGAF). Näistä molemmat ovat käytössä myös julkishallinnon organisaatioissa. Julkishallintoon räätä
löidyistä arkkitehtuureista katsotaan Suomen valtionhallinnon kokonaisarkkitehtuuria (ValtIT) ja USA:n hallituksen kokonaisarkkitehtuuria (Federal Enterprise Architecture, FEA).
3.3.1 Zachman Framework for Enterprise Architecture
Zachmanin noin 20 vuotta sitten esittelemä kokonaisarkkitehtuurikehikko on 5 x 6 mat
riisi1 *. Matriisin rivit ovat näkökulmia organisaation resursseihin. Matriisin sarakkeet ovat malleja kuhunkin näkökulmaan. Jokaisessa matriisin solussa on artefakti" tai entiteetti111, joka on esimerkiksi kuvaus tai kaavio. Sarakkeet määrittelevät [Kuva 4]:
• Mitä tietoa (data) entiteetti käyttää, esim. tietomallit.
• Kuinka entiteetti toimii (function), esim. prosessit ja systeemisuunnitel- man.
• Missä entiteetti toimii (network), esim. sijainti fyysisesti ja loogisesti.
• Kuka (people) käyttää entiteettiä, työnkulku, verkostot jne.
1 Matriisissa on todellisuudessa kuusi riviä, joista alin rivi kuvaa implementoitua systeemiä.
“ Artefakti (engl. artifact) määritellään ihmisen luomaksi, keinotekoiseksi tuotteeksi (Oxford English Dic
tionary, 2nd ed. 1989).
111 Entiteetti (engl. entity) määritellään mm. olemassa olevaksi, eksistentiaaliseksi, ilman riippuvuuksia tai ominaisuuksia olevaksi asiaksi tai ilmentymäksi (Oxford English Dictionary, 2nd ed. 1989).
• Milloin (time) entiteettiä käytetään, e Miksi (motivation) entiteettiä käytetään.
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why
SCOPE (CONTEXTUAL)
List of Things Important to the Business
List of Processes the Business Performs
List of Locetions n which the Business Operates
List of Organizations importart to the Business
List of Events/Cycles Significant to the Business
Ust of Business
Goals/3ratgies SCOPE
(CONTEXTUAL)
i a a ■ a
Planrur ENTITY = Class ol Busness Thing
Process : Class of Business Process
Node = Meier Business People - Major Organization 1 ime = Major Business Evert/C vde
Ends/Means = M^er Business
Goal/Strategy PIvmr
BUSINESS e g Semantic Model e g Business Process Model e g Business Logistics eg Work Flow Model e g Master Schedule e g Business Plan BUSINESS MODEL
(CONCEPTUAL)
s Æ. & (CONCEPTUAL)MODEL
cw Ent = Business Entity
Rein = Business Relationship
Proc = Business Process I/O = Bus ness Resources
Node = Business Location Link = Business Linkage
People = Organzabon Unt Work = Work Product
lime = Business Event Cyde = Business C^tle
End = Business OtxecDve Means = Busr ess Strategy
<w
SYSTEM
eg tog cal Data Model e g Application Architecture e g Distributed System Architecture
e g Human interface Architecture
e g Processing Structure e g.. Business Rule Model SYSTEM MODEL
(LOGICAL) —O*
Node = l/S Function iProcessor Storaoe etc) Unk = Line Character sties
sfe,
Time = System Event Cyde = Processing Cyde
Æ*
(LOGICAL)D.,^r
Ent = Date Entity Rein = Data Relationship
Proc = Application Function Peoole = Role
VWfk = Deliverable
Fnd = Structural Assertion
Means sActlon Assertion Deagrur TECHNOLOGY e g Physical Data Model eg System Design eg Technology Architecture e g Presentation Architecture eg Control Structure e g Rule Design TECHNOLOGY MODEL
(PHYSICAL)
as A *x*
(PHYSICAL)Builder Ent i Segment/Tabie/etc Rein = Pomter/Keyretc
Proc = Computer function 1/0 = Data Elements'Sets
Node = Hardware/Systems Link = Lne SpeaStations
People = User Work = Screen Format
T ime = Execute Cyde = Compcoont Cycle
Fnd = Conn ihon Means = Action
Builder
DETAILED REPRESEN
TATIONS (OUT-OF- CONTEXT)
eg DataDefinhon
■
e g Program
■
e g Network Architecture
■
e g Seemly Architecture
■
eg Timing Definition
■
e g Rule Specihcation
■
DETAILED REPRESEN
TATIONS (OUT-OF CONTEXT)
Contractor
Rain i Address
Proc = Language Statement Node - Address 1 ink = Protocol
People - identity Time - Interrupt Cycle = Machine Cyde
Fnd = fiutMxmdition
Means = Step Contractor
FUNCTIONING
ENTERPRISE I eg ORGANZATlON eg SCHEDULE »C STRATEGY FUNCTIONING
ENTERPRISE
© John A. Zachman, Zachman International Kuva 4. Zachmanin kokonaisarkkitehtuurin kehikko. [32)
Zachman-kehikko toimii erinomaisesti koko organisaation, erityisesti teollisuussektorin yrityksen, resurssien dokumentaationa. Kehikko luokittelee eri toiminnot erillisiksi koko
naisuuksiksi. Kehikossa ei ole mukana metodologiaa eikä prosessia, jolla näkymät luo
daan. Kehikossa ei määritellä, missä järjestyksessä arkkitehtuurikuvauksia luodaan. Nä
mä puutteet tekevät kehikosta joustavan ja laajennettavan, mikäli organisaatiolla on val
miita menetelmiä näihin [33]. Jos organisaatiolla ei ole valmistaja soveltuvaa metodolo
giaa tai prosessia kokonaisarkkitehtuurin osien kehittämiseen, Zachmanin käyttö edellyt
tää jonkin muun kehikon käyttöä samanaikaisesti. Zachmanin näkökulmien mallit ovat liiketoimintalähtöisiä, mikä edellyttää vahvaa toiminnan osallistumista arkkitehtuurin määrittelyyn.
Zachman-kehikkoa kehitetään kaupallisen The Zachman Institute for Framework Advan
cements (ZIFA1,) toimesta. Kehikko ei ole saatavilla ilmaiseksi.
3.3.2 TOGAF
TOGAF-kehikkoa on kehittänyt Architecture Forum, joka toimii yhteistyössä OMG:n ja DSDM:n" kanssa. Kolmentoista kehitysvuoden jälkeen TOGAF on nyt versiossa 8.1.1.
TOGAF on avoin standardi, jossa on sertifiointijärjestelmä; käyttäjille oma sertifiointi sekä työkaluille ja palveluille omansa. Aiemmin TOGAF oli teknologiapainotteinen ko
konaisarkkitehtuuri, mutta versiosta 8 lähtien mukaan on tullut liiketoimintanäkökulma vahvemmin esiin. TOGAF sisältää ohjeet muiden arkkitehtuurikehikkojen käyttämiseen TOGAFrn rinnalla.
TOGAF-kehikko sisältää arkkitehtuurin kehittämismenetelmän (Architecture Develop
ment Model, ADM), organisaatiojatkumon (Enterprise Continuum) sekä tietoresurssin (TOGAF Resource Base) [34]. ADMissa on kehittämismalli, arkkitehtuurinäkymät, linkit case-esimerkkeihin sekä ohjeistus kehittämisen työkaluista. Organisaatiojatkumo sisältää mallit, menetelmät ja tavat organisaation strategisten resurssien suunnitteluun. Organisaa- tiojatkumossa on kaksi valmista viitemallia; TOGAFrn perusarkkitehtuuri ja integroidun tiedon infrastruktuurin viitemalli (Integrated Information Infrastructure Reference Model, Ill-RM) yleiseen systeemiarkkitehtuuriin. TOGAFrn tietoresurssissa on ohjeistuksia, val
miita suunnittelupohjia ja taustatietoa arkkitehtuurisuunnitteluun sekä arkkitehtuurin ko
konaishallintaan. Lisäksi TOGAF:ssa on kehikko osaamiselle, henkilöiden tarvitsemat tiedot ja taidot eri arkkitehtuuritöihin. Osaamiskehikkoa voidaan käyttää apuna esimer
kiksi rekrytoinnissa ja konsulttipalveluhankinnoissa.
TOGAFrn arkkitehtuurisykli koostuu kahdeksasta vaiheesta [Kuva 5]; arkkitehtuurivisi- osta, toiminta-arkkitehtuurista, tietojärjestelmäarkkitehtuurista (sovellukset ja data), tek
nologia-arkkitehtuurista, mahdollisuuksista ja ratkaisuista, migraatiosuunnittelusta, im-
1 Lisätietoja www.zifa.com
" Lisätietoja http://www.dsdm.org/.
plementaation hallinnasta ja arkkitehtuurin muutoksenhallinnasta. Kuhunkin vaiheeseen liittyy askellettu etenemismalli (esim. vaihe D kuvassa 5) vaiheen suorittamiseen niin, että seuraavaan vaiheeseen siirryttäessä, tietyt perusperiaatteet, tarkastelut ja dokumen
taatiot siirtyvät seuraavan vaiheen lähtötiedoiksi. TOGAF ei määrittele tarkasti lähtötieto
jen dokumentointitapaa tai -hetkeä kehityssyklissä, mikä edellyttää organisaatiossa stan
dardoitujen dokumentointikäytäntöjen asettamista TOGAF:ia käytettäessä.
Prelim:
Framework and Principles
Requirements Management
create arch model
confirm bus. objs
Kuva 5. TOGAF, arkkitehtuurin kehityssykli. |35|
3.3.3 FEAF
FEAF on USA:n Office of Management and Budgetm (OMB) kehittämä kokonaisarkki- tehtuurikehikko USA:n liittohallitukselle. Kokonaisarkkitehtuurien kehittämiseen on
vahvat perusteet USA:ssa lainsäädännön takia1. FEA on luonteeltaan federalistinen koko
naisarkkitehtuuri. Kokonaisarkkitehtuurityössä federalisoitu malli sopii hyvin julkishal
linnon organisaatioihin. FEA koostuu viidestä liiketoimintalähtöisestä kehikosta tai vii
temallista [36]:
Performance Reference Model (PRM) mittaa IT-investointien tehok
kuutta suhteessa arkkitehtuuriohjelmaan sekä investointien onnistumi
seen.
- Business Reference Model (BRM) sisältää näkymät eri toimintoihin hal
lituksen linjaorganisaatioissa.
- Service Component Reference Model (SRM) luokittelee toimintaa tu
kevat palvelut ja niiden komponentit.
- Data Reference Model (DRM) on yhteisten tiedon kuvausten, käytön ja tiedonjakamisen malli.
- Techical Reference Model (TRM) kategorioi standardit ja teknologiat SRM:n komponentteja varten.
03 Ctfl
A Owned By
Performance Reference Model (PRM)
• Inputs, outputs, and outcomes
• Uniquely tailored performance indicators
9
3
■o o 3ro
3(T do m VIro
Dro
V»V) 1 01
Line of Business Owners
J
>
--- ► Business Reference Model fBRM)• Lines of Business (functions and sub-functions)
• Agencies, customers, partners
<ro r——► Service Comoonent Reference Model fSRM)
3 A
• Service domains, service types Q.
■o • Business and service components
n o
vvvi icvi vy
Federal --- ► Data Reference Model (DRM) 5'3; Q>
n CIO Council • Business-focused data standardization (T>
• Cross-agency information exchanges o
c
ft
\/ J • Service component interfaces, interoperability
Kuva 6. FEA:n viitemallit. [37]
1 Clinger-Cohen Act (The Information Technology Management Reform Act of 1996) asetti velvoitteita julkishallinnon tietohallintojohtamiselle, kustannusten suuntaamiselle ja esimeerkiksi it-arkkitehtuurien
hallinnalle.
