MODELIRANJE ARHITEKTURE POSLOVNIH SISTEMOV Z ...OmniGraffle, TOGAF, Zachman Framework, case study...
Transcript of MODELIRANJE ARHITEKTURE POSLOVNIH SISTEMOV Z ...OmniGraffle, TOGAF, Zachman Framework, case study...
Jožef Vuk
MODELIRANJE ARHITEKTURE POSLOVNIH
SISTEMOV Z JEZIKOM ARCHIMATE
Diplomsko delo
Maribor, marec 2012
II
III
Diplomsko delo univerzitetnega študijskega programa
MODELIRANJE ARHITEKTURE POSLOVNIH SISTEMOV
Z JEZIKOM ARCHIMATE
Maribor, marec 2012
Študent: Jožef Vuk
Študijski program: UN ŠP računalništvo in informatika
Smer: informatika
Mentor: doc. dr. Gregor Polančič, univ. dipl. inž.
IV
V
VI
VII
ZAHVALA
Iskreno se zahvaljujem mentorju, dr. Gregorju Polančiču, za vodenje, nasvete in pomoč pri izdelavi diplomskega dela.
Posebna zahvala gre staršem in bližnjim, ki so mi omogočili študij, mi vsa leta šolanja nesebično stali ob strani, nudili podporo in me spodbujali pri ustvarjanju.
Nenazadnje se zahvaljujem še vsem
prijateljem, brez katerih ne bi bilo
vsakodnevne inspiracije.
VIII
IX
MODELIRANJE ARHITEKTURE POSLOVNIH SISTEMOV Z JEZIKOM
ARCHIMATE
Ključne besede: Archimate, poslovno-informacijska arhitektura, modeliranje
poslovno-informacijskih arhitektur, poslovni sistem, BiZZdesign Architect, Archi,
Micrsoft Visio, OmniGraffle, TOGAF, Zachmanovo ogrodje, študija primera
UDK: 004.434:[659.2:004](043.2)
Povzetek
Področje diplomskega dela je predstavitev jezika Archimate ter njegova uporaba
za modeliranje arhitekture poslovnih sistemov. Prvi del se osredotoča na sámo
področje poslovno-informacijskih arhitektur, znotraj katerega smo le-te
predstavili, raziskali njihovo vlogo pri obvladovanju informatike ter poiskali
prednosti, ki jih arhitektura prinaša v poslovni sistem. V drugem delu smo
predstavili jezik Archimate, njegovo strukturo ter pripadajoče metamodele in
vidike. Predstavili in analizirali smo tudi splošna in namenska orodja, ki
podpirajo modeliranje v jeziku Archimate ter raziskali splošno priljubljenost in
razširjenost uporabe jezika Archimate. Pregledali smo še sorodne pristope k
modeliranju arhitektur ter podrobneje predstavili pristop TOGAF in Zachman. V
zadnjem delu smo opisali empirični del diplomskega dela, kjer smo na primeru
Študentskih domov Univerze v Mariboru, izdelali študijo primera uporabe jezika
Archimate, ter z modeliranjem nekaterih izbranih delov poslovnega sistema,
prikazali praktično modeliranje z jezikom Archimate. Na koncu smo povzeli
rezultate študije primera in sprejeli oziroma zavrnili hipoteze, postavljene na
začetku.
X
XI
ENTERPRISE ARCHITECTURE MODELLING WITH ARCHIMATE
LANGUAGE
Keywords: Archimate, Enterprise Architecture modelling, enterprise
architecture, enterprise systems, BiZZdesign Architect, Archi, Micrsoft Visio,
OmniGraffle, TOGAF, Zachman Framework, case study
UDK: 004.434:[659.2:004](043.2)
Abstract
The thesis deals with presenting ArchiMate language and its use at modelling of
enterprise architecture. Firstly we focused on the area of enterprise architecture.
We presented them and researched their role at controlling the informatics and
presented the advantages that the architecture brings into the business process.
Secondly we presented the ArciMate language, its structure and accompanying
metamodels and views. We presented and analysed general and specific tools,
which support modelling with ArchiMate language. We also reviewed similar
approaches at modelling architectures and presented the TOGAF method and
Zachman in more detail. In the last part of the thesis we included the empirical
part of the topic, and presented case study of the use of ArchiMate language at
organisation of University of Maribor Student dormitories. With modelling of
some parts of the business process we showed practical use of modelling with
ArchiMate language. Lastly we proved or denied the hypothesis set at the
beginning of our research with results of our case study.
XII
XIII
KAZALO
1.UVOD 19
1.1. OPREDELITEV ARHITEKTURE POSLOVNIH SISTEMOV ......................................... 19
1.2. CILJI IN HIPOTEZE DIPLOMSKEGA DELA .................................................................. 20
1.3. PREDPOSTAVKE IN OMEJITVE DIPLOMSKEGA DELA ............................................. 20
1.4. PREDSTAVITEV OSNOVNIH METOD DELA ............................................................... 21
1.5. STRUKTURA DIPLOMSKEGA DELA ............................................................................ 21
2.POSLOVNO-INFORMACIJSKA ARHITEKTURA 23
2.1. SPLOŠNO O POSLOVNO-INFORMACIJSKIH ARHITEKTURAH ................................. 23
2.2. PREDSTAVITEV PODROČJA POSLOVNO-INFORMACIJSKIH ARHITEKTUR ........... 24
2.3. VLOGA POSLOVNO-INFORMACIJSKE ARHITEKTURE PRI OBVLADOVANJU
INFORMATIKE ............................................................................................................................ 26
2.4. ARHITEKTURNA OGRODJA IN METODE .................................................................... 28
2.5. VIDIKI NA ARHITEKTURO POSLOVNEGA SISTEMA................................................. 29
3.JEZIK ARCHIMATE 31
3.1. METAMODEL JEZIKA ARCHIMATE ............................................................................. 32
3.2. STRUKTURA JEZIKA ARCHIMATE .............................................................................. 33
3.2.1. Poslovni nivo ......................................................................................................... 35
3.2.2. Aplikativni nivo ....................................................................................................... 37
3.2.3. Tehnološki nivo ..................................................................................................... 39
3.2.4. Motivacijska razširitev jezika Archimate ................................................................ 41
3.2.5. Razširitev jezika Archimate z Implementacijo in migracijo .................................... 42
3.2.6. Relacije jezika Archimate ...................................................................................... 43
3.3. ARCHIMATE VIDIKI ....................................................................................................... 47
3.3.1. Organizacijski vidik ................................................................................................ 49
3.3.2. Vidik sodelovanja akterjev ..................................................................................... 50
3.3.3. Vidik poslovnih funkcij ........................................................................................... 51
3.3.4. Vidik poslovnih procesov ....................................................................................... 51
3.3.5. Vidik sodelovanja poslovnih procesov ................................................................... 52
3.3.6. Vidik produktov ...................................................................................................... 53
3.3.7. Vidik obnašanja aplikacij ....................................................................................... 54
3.3.8. Vidik sodelovanja aplikacij ..................................................................................... 55
3.3.9. Vidik strukture aplikacij .......................................................................................... 55
3.3.10. Vidik uporabe aplikacij ........................................................................................... 56
XIV
3.3.11. Infrastrukturni vidik ................................................................................................ 57
3.3.12. Vidik uporabe infrastrukture ................................................................................... 57
3.3.13. Vidik implementacije in uvajanja ........................................................................... 58
3.3.14. Vidik strukture informacij ....................................................................................... 59
3.3.15. Vidik realizacije storitev ......................................................................................... 60
3.4. PREGLED IN ANALIZA ARCHIMATE ORODIJ ........................................................... 61
3.4.1 Splošno namizno orodje – Microsoft VISIO ............................................................... 61
3.4.2 Splošno namizno orodje – OmniGraffle ..................................................................... 63
3.4.3 Namensko namizno orodje – Archi ............................................................................ 64
3.4.4 Namensko namizno orodje – Architect ...................................................................... 66
3.5. RAZŠIRJENOST UPORABE JEZIKA ARCHIMATE ...................................................... 68
4.PREGLED SORODNIH ARHITEKTURNIH PRISTOPOV 71
4.1. TOGAF ........................................................................................................................... 71
4.2. ZACHMANOVO OGRODJE ........................................................................................... 73
5.ŠTUDIJA PRIMERA UPORABE JEZIKA ARCHIMATE 77
5.1. METODA DELA ............................................................................................................. 78
5.2. OMEJITVE ..................................................................................................................... 78
5.3. PREDSTAVITEV PROBLEMA IN PRISTOP K REŠITVI ............................................... 78
5.4. MODELIRANJE POSLOVNO-INFORMACIJSKE ARHITEKTURE ŠTUDENTSKIH
DOMOV ....................................................................................................................................... 79
5.5. REZULTATI ŠTUDIJE PRIMERA ................................................................................. 90
6.ZAKLJUČEK 93
6.1. TESTIRANJE HIPOTEZ ................................................................................................. 93
6.2. OMEJITVE ..................................................................................................................... 94
6.3. MOŽNOSTI ZA NADALJNJE DELO .............................................................................. 94
6.4. SKLEP............................................................................................................................ 95
VIRI 97
PRILOGE 99
Priloga A: Koncepti jezika Archimate [5] .................................................................................... 99
Priloga B: Struktura Zachmanovega ogrodja – podrobnejši opis ............................................. 102
Priloga C: Primer organizacijskega vidika ................................................................................ 104
Priloga D: Del vidika poslovnega nivoja računovodstva ........................................................... 105
Priloga E: Del vidika poslovnega procesa prijave okvar ........................................................... 106
XV
KAZALO SLIK Slika 1: Jedro arhitekturnega opisa [3] ....................................................................................... 24
Slika 2: Vloga poslovno-informacijske arhitekture pri obvladovanju informatike [2] ................... 27
Slika 3: Klasifikacija vidikov poslovno-informacijskih arhitektur [5] ............................................. 29
Slika 4: Metamodeli na različnih nivojih specializacije [4] ........................................................... 32
Slika 5: Metamodel ključnih elementov Archimate [5] ................................................................ 33
Slika 6: Večplastna arhitektura in koncept storitve [7] ................................................................ 34
Slika 7: Metamodel poslovnega nivoja [5] .................................................................................. 36
Slika 8: Metamodel aplikativnega nivoja [4] ................................................................................ 38
Slika 9: Metamodel tehnološkega nivoja [4] ............................................................................... 40
Slika 10: Metamodel koncepta motivacijske razširitve jezika Archimate [5] ............................... 41
Slika 11: Metamodel koncepta implementacijske in migracijske razširitve jezika Archimate [5] . 42
Slika 12: Relacija dostop ............................................................................................................ 44
Slika 13: Relacija uporaba .......................................................................................................... 44
Slika 14: Relacija kompozicija .................................................................................................... 44
Slika 15: Relacija agregacija ...................................................................................................... 44
Slika 16: Relacija dodelitev ......................................................................................................... 45
Slika 17: Relacija realizacija ....................................................................................................... 45
Slika 18: Relacija proženje ......................................................................................................... 45
Slika 19: Relacija pretok ............................................................................................................. 45
Slika 20: Relacija asociacija ....................................................................................................... 46
Slika 21: Relacija stičišče ........................................................................................................... 46
Slika 22: Relacija specializacija .................................................................................................. 46
Slika 23: Metamodel organizacijskega vidika [5] ........................................................................ 49
Slika 24: Metamodel vidik sodelovanja akterjev [5] .................................................................... 50
Slika 25: Metamodel vidika poslovnih funkcij [5] ........................................................................ 51
Slika 26: Metamodel vidika poslovnih procesov [5] .................................................................... 52
Slika 27: Metamodel vidika sodelovanja poslovnih procesov [5] ................................................ 53
Slika 28: Metamodel vidika produktov [5] ................................................................................... 54
Slika 29: Metamodel vidika obnašanja aplikacij [5]..................................................................... 54
Slika 30: Metamodel vidika sodelovanja aplikacij [5] .................................................................. 55
Slika 31: Metamodel vidika strukture aplikacij [5] ....................................................................... 55
Slika 32: Metamodel vidika uporabe aplikacij [5] ........................................................................ 56
Slika 33: Metamodel infrastrukturnega vidika [5] ........................................................................ 57
Slika 34: Metamodel vidika uporabe infrastrukture [5] ................................................................ 58
Slika 35: Metamodel zornega kota implementacije in uvajanja [5] ............................................. 59
XVI
Slika 36: Metamodel vidika strukture informacij [5] ..................................................................... 60
Slika 37: Metamodel vidika realizacije storitev [5] ...................................................................... 60
Slika 38: Prenos standarda Archimate s spletne strani The Open Group po regijah [15] ........... 69
Slika 39: Povezave med ogrodjem TOGAF in ogrodjem Archimate [5] ...................................... 73
Slika 40: Zachmanovo ogrodje- perspektive in abstrakcije [19] .................................................. 74
Slika 41: Koncept Zachmanovega ogrodja [19] .......................................................................... 75
Slika 42: Zachmanovo ogrodje in ogrodje Archimate [22] .......................................................... 76
Slika 43: Primer organizacijskega vidika .................................................................................... 84
Slika 44: Primer vidika poslovnih funkcij ..................................................................................... 85
Slika 45: Primer vidika poslovnih produktov ............................................................................... 85
Slika 46: Primer vidika poslovnih procesov ................................................................................ 86
Slika 47: Primer vidika uporabe aplikacij .................................................................................... 87
Slika 48: Primer vidika obnašanja aplikacij ................................................................................. 88
Slika 49: Primer vidika sodelovanja aplikacij .............................................................................. 88
Slika 50: Primer vidika infrastrukture .......................................................................................... 89
Slika 51: Časovna zahtevnost razvoja izbranih delov arhitekture ŠD ......................................... 91
KAZALO TABEL Tabela 1: Prioritete strukturnih relacij [5] .................................................................................... 47
Tabela 2: SWOT analiza - Microsoft Visio in Archimate šablona ............................................... 62
Tabela 3: SWOT analiza - OmniGraffle in Archimate šablona ................................................... 64
Tabela 4: SWOT analiza - Archi ................................................................................................ 65
Tabela 5: SWOT analiza - Architect .......................................................................................... 67
Tabela 6: Prenos standarda Archimate s spletne strani The Open Group po državah [15] ........ 69
Tabela 7: Primerki identificiranih poslovnih akterjev in poslovnih vlog na obravnavanem delu
poslovnega sistema .................................................................................................................... 81
Tabela 8: Primerki identificiranih elementov poslovnega nivoja na obravnavanem delu
poslovnega sistema .................................................................................................................... 81
Tabela 9: Primerki identificiranih elementov aplikacijskega nivoja na obravnavanem delu
poslovnega sistema .................................................................................................................... 83
Tabela 10: Primerki identificiranih elementov tehnološkega nivoja na obravnavanem delu
poslovnega sistema .................................................................................................................... 83
Tabela 11: Testiranje hipotez .................................................................................................... 93
XVII
SEZNAM AKRONIMOV:
IT Informacijske tehnologije
PIA Poslovno-informacijske arhitekture
EA Enterprise Architecture
IEEE Institute of Electrical and Electronics Engineers
COBIT Control Objectives for Information and related Technology
ITIL IT Infrastructure Library
TOGAF The Open Group Architecture Framework
MDA Model Driven Architecture
MEMO Multi Perspective Enterprise Modelling
ARIS Architecture of Integrated Information Systems
RUP Rational Unified Process
ADM Architecture Development Method
UML Unified Modeling Language
BPMN Business Process Modelling Notation
SWOT Strengths, Weaknesses, Opportunities, Threats
JISC Joint Information Systems Committee
PDF Portable Document Format
OS Operating System
IAF Integrated Architecture Framework
FEAF Federal Enterprise Architecture Framework
XVIII
Uvod
19
1. UVOD
1.1. OPREDELITEV ARHITEKTURE POSLOVNIH SISTEMOV
Primarni namen razvoja arhitekture v poslovnih sistemih je podpora poslovanju
organizacije z zagotavljanjem temeljnih tehnologij in procesnih struktur.
Arhitektura opisuje podrobnosti strukture in odnose v podjetju, v poslovnem
modelu, v načinu kako bo delovalo podjetje, ter kako in na kakšen način bodo
podatki, informacijski sistemi in tehnologije, podpirali poslovni sistem pri
uresničevanju poslovnih ciljev.
Podjetja se zavedajo, da je učinkovito upravljanje in izkoriščanje informacij s
pomočjo IT, ključ do njihovega uspeha in nepogrešljivo sredstvo za doseganje
konkurenčne prednosti. Arhitektura v poslovnem sistemu jim tako zagotavlja
strateški okvir za razvoj informacijskega sistema, kot odziv na nenehno
spreminjajoče se potrebe poslovnega okolja.
Za modeliranje arhitektur poslovnih sistemov so sprejeti že številni pristopi,
ogrodja in modelirni jeziki. Na priljubljenosti in razširjenosti pa vedno bolj
pridobiva relativno mlad modelirni jezik Archimate.
Namen tega diplomskega dela je celovita predstavitev modelirnega jezika
Archimate.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
20
1.2. CILJI IN HIPOTEZE DIPLOMSKEGA DELA
Cilji diplomskega dela so:
raziskati in predstaviti pomen arhitekture v poslovnih sistemih;
predstaviti modelirni jezik Archimate;
prikazati razširjenosti uporabe jezika Archimate;
predstaviti sorodne tehnologije ter identificirati skupne točke z jezikom
Archimate;
identificirati in analizirati orodja, ki podpirajo jezik Archimate;
prikazati in uporabiti pridobljeno znanje na primeru Študentskih domov
Univerze v Mariboru - Študija primera.
Za diplomsko delo smo postavili sledeče hipoteze:
H1: Arhitektura poslovnih sistemov pozitivno vpliva na poslovanje
organizacije.
H2: Pristopi za modeliranje arhitektur so si med seboj podobni.
H3: Splošno namenska programska orodja so primerna na modeliranje
arhitektur poslovnih sistemov z jezikom Archimate.
H4: Archimate je splošno znan pristop za modeliranje PIA.
H5: PIA arhitekturo poslovnega sistema Študentskih domov lahko realiziramo
z jezikom Archimate.
1.3. PREDPOSTAVKE IN OMEJITVE DIPLOMSKEGA DELA
V diplomskem delu se bomo omejili na predstavitev modelirnega jezika
Archimate ter nekaterih sorodnih modelirnih jezikov. Analiza razširjenosti
uporabe je omejena, saj je sledljivost uporabe jezika in pristopa Archimate
zaradi njegove odprtosti otežena.
Predstavili in primerjali bomo najbolj razširjeno programsko opremo, ki
omogoča modeliranje z jezikom Archimate.
Uvod
21
S študijo primera bomo na primeru Študentskih domov Univerze v Mariboru
prikazali uporabo modelirnega jezika Archimate v praksi. Omejenost študije
primera bo odvisna od pridobljenih specifičnih podatkov s strani Študentskih
domov Univerze v Mariboru.
Predpostavljamo, da je mogoče zmodelirati arhitekturo poslovnega sistema
Študentskih domov Univerze v Mariboru.
1.4. PREDSTAVITEV OSNOVNIH METOD DELA
Pri izdelavi diplomskega dela bomo uporabili naslednje metode in tehnike:
študijo elektronskih virov;
študijo knjižnih virov;
študijo internih dokumentov Študentskih domov Univerze v Mariboru;
zbiranje ustnih virov o poslovnem sistemu v Študentskih domovih;
uporabo programskih orodij;
študijo primera.
1.5. STRUKTURA DIPLOMSKEGA DELA
Diplomsko delo je razdeljeno na pet delov. V prvem poglavju je predstavljen
osnovni problem, s katerim se ukvarjamo. Opredeljena je njegova pomembnost
za raziskovalno področje in razlog za raziskavo. V nadaljevanju so predstavljeni
cilji in hipoteze, predpostavke in omejitve ter osnovne metodološke tehnike, ki
so uporabljene pri raziskovalnem delu.
V drugem poglavju bomo raziskali področje poslovno-informacijskih arhitektur,
predstavili njihovo vlogo pri obvladovanju informatike ter razložili pomen
različnih pogledov na arhitekturo. Identificirali bomo tudi nekatera arhitekturna
ogrodja in metode.
V tretjem poglavju bomo celostno predstavili modelirni jezik Archimate.
Natančno bomo raziskali strukturo jezika in predlagane vidike na arhitekturo
poslovnega sistema ter preizkusili nekatera programska orodja, ki omogočajo
modeliranje v jeziku Archimate. V tem poglavju bomo raziskali tudi razširjenost
uporabe modelirnega jezika Archimate.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
22
V četrtem poglavju bomo opravili pregled nekaterih sorodnih pristopov
modeliranja arhitektur poslovnih sistemov ter poiskali sorodnosti z jezikom
Archimate.
V petem poglavju bomo opisali empirični del diplomskega dela, kjer bomo na
primeru Študentskih domov Univerze v Mariboru, izdelali študijo primera
uporabe jezika Archimate. Na primeru bomo prikazali modeliranje z jezikom
Archimate ter pomen različnih vidikov.
V zaključku bomo na kratko povzeli rezultate diplomskega dela, testirali
hipoteze, predstavili omejitve in morebitna področja za nadaljnjo raziskavo.
Poslovno-informacijska arhitektura
23
2. POSLOVNO-INFORMACIJSKA
ARHITEKTURA
2.1. SPLOŠNO O POSLOVNO-INFORMACIJSKIH ARHITEKTURAH
Poslovno-informacijske arhitekture (angl. enterprise architecture ali EA)
predstavljajo bazo znanja poslovnega sistema ter omogočajo celovit pogled na
njegovo delovanje ter sodelovanje navzven. Poslovno-informacijsko arhitekturo
lahko opišemo tudi kot sredstvo za učinkovitejšo komunikacijo, planiranje in
obvladovanje znanja v poslovnem sistemu. Predstavljajo torej orodje za
doseganje zveznosti in skladnosti posameznih delov poslovnega sistema,
povezanost strateških elementov s poslovnimi procesi, povezanost poslanstva in
poslovnih ciljev s cilji informatike ter za doseganje bolj informiranih odločitev o
nekaterih ključnih tematikah, kot so integracija informacijskih sistemov,
povezovanje z zunanjimi poslovnimi in informacijskimi sistemi, optimizacija
poslovnih procesov, obvladovanje poslovnih sprememb itn. [1].
Na področju poslovno-informacijskih arhitektur (krajše: PIA) obstaja več, bolj ali
manj različnih definicij. Marc Lankhorst v svoji knjigi Enterprise architecture at
work: modelling, communication, and analysis navaja naslednjo definicijo:
''Poslovno-informacijska arhitektura je skladna celota načel, metod in modelov, ki
se uporabljajo pri načrtovanju in uresničevanju organizacijske strukture poslovnih
procesov, informacijskih sistemov in infrastrukture poslovnega sistema.'' [2].
Poslovno informacijske arhitekture so zaradi naraščajočih zahtev po usklajenosti
poslovnega in informacijskega sistema ter agilnosti poslovnih sistemov postale
zelo pomembno področje, kar se dandanes zavedajo v vseh večjih organizacijah.
Učinkovito upravljanje in izkoriščanje informacij s pomočjo informacijske
tehnologije (krajše: IT) je ključ do uspeha podjetja in nepogrešljivo sredstvo za
doseganje konkurenčne prednosti.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
24
2.2. PREDSTAVITEV PODROČJA POSLOVNO-INFORMACIJSKIH
ARHITEKTUR
S sprejetjem standarda IEEE 1471-2000 (IEEE Recommended Practice for
Architectural Description of software-Intensive Systems) leta 2000 je bila
postavljena konceptualna osnova za področje arhitektur. Na področju poslovno-
informacijskih arhitektur je ta standard še vedno zelo pomemben, saj opisuje
teoretično osnovo za definiranje, analizo in opis arhitekture sistemov [2]. Leta
2007 pa je standard IEEE 1471-2000 nasledil standard ISO/IEC/IEEE
42010:2007, ki za razliko od svojega predhodnika, strogo razlikuje med
arhitekturo in arhitekturnim opisom. Na sliki 1 lahko vidimo organiziranost tega
standarda okoli različnih pojmov in konceptov. Slika 1 prikazuje vsebino
arhitekturnega opisa ter relacije med temi vsebinami, ko s pomočjo standarda
pripravljamo arhitekturni opis z namenom, da izrazimo arhitekturo za nek
zainteresiran sistem[3].
Slika 1: Jedro arhitekturnega opisa [3]
Poslovno-informacijska arhitektura
25
Poslovno-informacijska arhitektura je še posebno pomembna v kompleksnih
poslovnih sistemih, kjer se uporablja predvsem za tri ključne namene, in sicer:
kot osnova za predstavitve in komunikacijo:
Poslovno-informacijska arhitektura daje celovit pogled na delovanje poslovnega
sistema. Deležnikom predstavijo točno tisti del, ki je zanje relevanten in na način,
ki ga umešča v celostni pogled na poslovni sistem. S tem so tudi podlaga za
komunikacijo med različnimi deležniki [1];
kot osnova za načrtovanje:
Poslovno-informacijska arhitektura lahko zajema opis obstoječega stanja ali
želenega stanja. Pri tem lahko analiziramo različne variante in razhajanja med
njimi – kaj je treba spremeniti, dodati, prilagoditi, da bi dosegli želeno stanje. Pri
tem igrajo pomembno vlogo tehnike arhitekturne analize, npr. analiza vpliva
sprememb [1];
za zagotavljanje skladnosti in zveznosti vseh delov poslovnega
sistema:
Poslovno-informacijska arhitektura omogoča zagotavljanje povezanosti
poslanstva, vizije, poslovnih ciljev, poslovne strategije itn. s poslovnimi procesi
in organizacijo. S tem so strategija in cilji posameznih delov poslovnega sistema
usklajeni s strategijo in cilji celotnega poslovnega sistema, kar pomeni usmerjen
fokus delovanja posameznih delov sistema pri uresničevanju strategije in
poslanstva ter doseganju poslovnih ciljev in vizije [1].
Omenili smo že, da PIA zagotavlja strateški okvir za razvoj informacijskega
sistema, kot odziv na nenehno spreminjajoče se potrebe poslovnega okolja.
Dobra arhitektura poslovnih procesov podjetja omogoča tudi doseganje pravega
ravnovesja med IT učinkovitostjo in poslovnimi inovacijami, hkrati pa
uresničuje potrebe organizacije po celostni strategiji.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
26
Druge prednosti ob uporabi poslovno-informacijskih arhitektur so še:
učinkovitejše delovanje IT:
- nižanje stroškov razvoja programske opreme, stroškov podpore in stroškov
vzdrževanja,
- večja prenosljivost aplikacij,
- izboljšana interoperabilnost, lažje upravljanje sistema in omrežja,
- izboljšana sposobnost obravnavanja kritičnih problemov (npr. varnost),
- lažja nadgradnja in izmenjava sistemskih komponent,
boljša donosnost obstoječih naložb in zmanjšanje tveganja za bodoče
naložbe:
- zmanjšanje kompleksnosti IT infrastrukture,
- maksimalna donosnost vlaganj v obstoječo IT infrastrukturo,
- fleksibilnost pri izdelavi in kupovanju IT rešitev,
- zmanjšanje tveganja v nove naložbe in zmanjšanje stroškov lastništva
informacijskih tehnologij,
hitrejša, enostavnejša in cenejša naročila:
- odločitve o nakupu so preprostejše, saj so informacije, ki jih urejajo javna
naročila, vedno na voljo in usklajena s poslovno strategijo podjetja,
- postopek naročanja je hitrejši in fleksibilnejši ter brez žrtvovanja
arhitekturne skladnosti [4].
2.3. VLOGA POSLOVNO-INFORMACIJSKE ARHITEKTURE PRI
OBVLADOVANJU INFORMATIKE
Za uspešno obvladovanje poslovnega sistema z informacijsko tehnologijo
potrebujemo dobro definirano poslovno strategijo, ki je izhodišče za določitev
informatike in arhitekture poslovnega sistema [2].
Pri obvladovanju informatike je potrebno omeniti ogrodje COBIT (Control
Objectives for Information and related Technology), ki združuje »dobre prakse«
Poslovno-informacijska arhitektura
27
pri implementaciji strukture obvladovanja informatike ter skuša premostiti
vrzeli med poslovnimi tveganji, kontrolnimi potrebami in tehničnimi vprašanji.
Navaja kontrolne in upravljalske usmeritve, zrelostni model za obvladovanje
informatike, kritične dejavnike uspeha, idr.
Poslovno-informacijska arhitektura tvori naravno dopolnilo COBIT in se posveča
poslovnim in IT strukturam, procesom, podatkom ter tehnologiji poslovnih
sistemov (vidno na sliki 2), medtem ko COBIT odgovarja zgolj na vprašanje, kako
naj bo organizirana funkcija informatike.
Standardu COBIT je komplementaren standard ITIL (IT Infrastructure Library),
ki združuje množico najboljših praks s področja nudenja informacijskih storitev.
Jedro standarda ITIL sestavljata dve široki skupini procesov: nudenje storitev in
podpora storitvam [2].
Če povzamemo, sta standarda COBIT in ITIL pomembna dejavnika pri
implementaciji strukture obvladovanja informatike. Prvi narekuje predvsem
»Kaj je potrebno narediti«, drugi pa »Kako to narediti«.
Slika 2: Vloga poslovno-informacijske arhitekture pri obvladovanju informatike [2]
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
28
2.4. ARHITEKTURNA OGRODJA IN METODE
Poslovno-informacijsko arhitekturo razvijamo s pomočjo arhitekturnega
ogrodja, ki pospešuje in poenostavlja razvoj arhitekture ter komunicira z ne-
arhitekti. Zagotavlja bolj celovito pokritost in razumevanje zasnovanih rešitev,
dodatno razumevanje v celotnem podjetju pa omogoča hitrejše odzivanje na
spreminjajoče se poslovne potrebe.
Arhitekturno ogrodje strukturira arhitekturne opisne tehnike z identifikacijo in
povezavo različnih arhitekturnih vidikov in z njimi povezanih modelirnih tehnik
[2].
Med bolj poznanimi arhitekturnimi ogrodji so:
Zachman-ovo ogrodje (Zachman 1987);
Arhitekturno ogrodje TOGAF (The Open Group 2002);
The Model Driven Architecture – MDA (Object Management Group
Architecture Board 2001);
Arhitekturno ogrodje Archimate (Telematica Instituut 2004).
Jedro arhitekturnih ogrodij običajno predstavljajo arhitekturne metode.
Arhitekturna metoda je strukturirana zbirka tehnik in procesnih korakov za
kreiranje in vzdrževanje arhitekture poslovnega sistema. Metode običajno
določajo različne faze življenjskega cikla arhitekture. Vredno je omeniti
naslednje arhitekturne metode [2]:
MEMO – Multi Perspective Enterprise Modelling (German Research Center for
Computer Science 1994);
ARIS – Architecture of Integrated Information Systems (Scheer 1994);
RUP – Rational Unified Process (Rational Corporation 1998);
TOGAF ADM – Architecture Development Method (The Open Group 2002).
V tretjem poglavju bomo najprej natančneje spoznali jezik za modeliranje
arhitektur Archimate ter njegovo ogrodje, v četrtem poglavju pa se bomo
dotaknili tudi sorodnih arhitekturnih jezikov ter njihovih ogrodij in metod.
Poslovno-informacijska arhitektura
29
2.5. VIDIKI NA ARHITEKTURO POSLOVNEGA SISTEMA
Poslovno-informacijska arhitektura navadno opisuje veliko množico komponent
in relacij med njimi. V poslovnem sistemu nastopajo različni akterji v različnih
vlogah. Ker se poslovno-informacijska arhitektura uporablja kot podlaga za
predstavitve, komunikacijo, načrtovanje, analizo in odločanje, so posamezni
modeli namenjeni različnim deležnikom z različnimi nalogami. Za vsakega izmed
njih je relevanten le del poslovno informacijske arhitekture. Modeli, ki bi
vsebovali vse elemente in povezave med njimi, bi za posameznega deležnika
vsebovali velik del informacij, ki so zanj nebistvene, postranskega pomena ali
celo nepomembne. Poleg tega lahko na poslovno-informacijsko arhitekturo
gledamo z različnih ravni podrobnosti. Za posameznega deležnika je ustrezna
določena raven podrobnosti. To pomeni, da naj bi modeli za posameznega
deležnika vsebovali natanko tiste elemente, ki jih zanimajo, na ustrezni ravni
podrobnosti. V ta namen večina pristopov poslovno-informacijskih arhitektur
opredeljuje različne vidike glede na posamezne deležnike (slika 3). Vidik (angl.
viewpoint) določa, kateri tipi elementov in na kateri ravni podrobnosti naj bodo
vsebovani v modelu namenjenemu danemu deležniku. Na podlagi vidika in
danega opisa poslovno informacijske arhitekture dobimo pogled nanjo, ki je
ustrezen za danega deležnika. Pogled je predstavitev sistema glede na zanimanja
določenega deležnika [1].
Slika 3: Klasifikacija vidikov poslovno-informacijskih arhitektur [5]
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
30
Jezik Archimate
31
3. JEZIK ARCHIMATE
Archimate je najnovejši pristop k poslovno-informacijskim arhitekturam. Del
pristopa sestavlja odprt in neodvisen jezik za modeliranje poslovno-
informacijskih arhitektur, ki omogoča opisovanje, analizo in vizualizacijo
arhitekture tako znotraj kot tudi zunaj poslovnih domen na nedvoumen način
[6].
Leta 2004 je bil razvit na Nizozemskem s projektno skupino na Telematica
Instituut ter s sodelovanjem nizozemske vlade, industrije in akademske sfere.
Leta 2008 je bilo lastništvo in skrbništvo za Archimate preneseno v organizacijo
The Open Group1, kjer za njegov razvoj skrbi oddelek Archimate Forum. V
februarju 2009 je bil Archimate z objavo standarda Archimate® 1.0 tudi uradno
sprejet kot tehnični standard. Februarja 2012 pa je skupina The Open Group
izdala tudi posodobitev standarda 1.0 in novosti združila v tehničnem standardu
Archimate® 2.0, ki vsebuje nekaj manjših izboljšav glede na verzijo 1.0, dodali pa
so tudi dve razširitvi: razširitev »Motivacija (angl. Motivation extension)« in
razširitev »Implementacija in migracija (angl. Implementation and Migration
extension)«, o katerih bomo govorili v nadaljevanju [6] .
Archimate nudi doslej najbolj celovit integriran pristop za izgradnjo,
predstavitev in vzdrževanje arhitekture poslovnih sistemov. Glavni cilj je preseči
razhajanja med različnimi arhitekturnimi domenami, ki navadno obstajajo v
poslovnih sistemih, npr. med domenami poslovnih procesov, tehnične
arhitekture in aplikativne arhitekture[2].
1 The Open Group je organizacija, katere vizija je omogočanje na odprtih standardih in globalni interoperabilnosti temelječega dostopa do integriranih informacij znotraj in med poslovnimi sistemi. Je konzorcij, ki je neodvisen od ponudnikov rešitev. Njeni člani izhajajo iz vseh sektorjev skupnosti, povezanih z informacijsko tehnologijo - stranke, dobavitelji sistemov in rešitev, ponudniki orodij , svetovalci, akademiki in raziskovalci.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
32
Čeprav namerno spominja na jezik UML (Unified Modeling Language), je
Archimate notacija precej lažja in intuitivna, kot je trenutno predlagano v UML
2.0. Kljub temu je jezik dovolj izrazen in omogoča modeliranje na vseh nivojih,
kot tudi iz različnih vidikov organizacije [4].
Razvita so že tudi številna programska orodja, ki podpirajo jezik Archimate
(BiZZdesign, IDS Scheer, Casewise, Telelogic, in drugi). Nekatera izbrana orodja
bomo natančneje spoznali v razdelku 3.4.
3.1. METAMODEL JEZIKA ARCHIMATE
Izziv pri razvoju splošnega metamodela za arhitekturo podjetja je vzpostaviti
ravnotežje med specifičnostmi jezikov posameznih področij arhitekture in
splošnimi (generičnimi) koncepti arhitekture. Slika 4 prikazuje opis konceptov
na različnih ravneh specializacije [4].
Slika 4: Metamodeli na različnih nivojih specializacije [4]
Na dnu trikotnika najdemo metamodele arhitekturnih konceptov, ki so specifični
za posamezne poslovne sisteme. Tu se nahajajo tudi različni obstoječi standardi
in modelirni jeziki. Kot primer lahko v tej kategoriji navedemo jezik UML. Na
vrhu trikotnika pa se nahajajo najbolj splošni oz. abstraktni metamodeli za
arhitekture poslovnih sistemov, ki obsegajo zgolj pojme, kot so "objekt",
"komponente" in "relacije".
Jezik Archimate
33
Zasnova jezika Archimate se je začela iz relativno splošnih konceptov, ti pa so
bili nato specializirani za najrazličnejše arhitekturne plasti. Pri oblikovanju
jezika so upoštevali zahteve, da je le-ta čim preprostejši, vendar še vedno dovolj
izrazen za večino modelirnih nalog arhitektur poslovnih sistemov. Veliko drugih
jezikov, med njimi tudi UML 2.0, poskušajo zajeti čim več zahtev različnih
uporabnikov. Z namenom enostavnega učenja in uporabe je Archimate omejen
na koncepte, ki zadostujejo za modeliranje približno 80% praktičnih primerov
[5].
Slika 5: Metamodel ključnih elementov Archimate [5]
3.2. STRUKTURA JEZIKA ARCHIMATE
Strukturo jezika Archimate lahko delimo v tri skupine, in sicer elemente aktivne
strukture (angl. Active structure), elemente obnašanja (angl. Behaviour) in
elemente pasivne strukture (angl. Pasive structure) (vidno na sliki 5). Elementi
aktivne strukture so poslovni akterji, aplikativne komponente in naprave, ki
prikazujejo dejansko obnašanje. Elementom obnašanja so z aktivno strukturo
dodeljeni vedenjski koncepti, ki prikazujejo, kdo je zadolžen za izvajanje
določene funkcije. Elementi pasivnih struktur pa so objekti, nad katerimi se
izvaja obnašanje. Na področju informacijsko intenzivnih domen, na katere se
jezik tudi osredotoča, so takšni elementi običajno informacije ali podatkovni
objekti, skozi pasivno strukturo pa so lahko predstavljeni tudi fizični objekti [5].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
34
Jezik Archimate razlikuje med tremi arhitekturnimi nivoji (ali plastmi), in sicer
med poslovnim, aplikativnim in tehnološkim nivojem. Razlikuje tudi med
zunanjim (angl. external view) in notranjim pogledom (angl. internal view) na
sistem (slika 5), zato lahko arhitekturne nivoje razdelimo še v dve ravni, in sicer
[5]:
Storitvena raven – t.i. zunanje storitve, ki jih plast daje svojemu zunanjemu
okolju in se uporabljajo na višjih arhitekturnih plasteh;
Implementacijska raven – t.i. notranje storitve (uporabljajo se znotraj
posamezne plasti) ter komponente in relacije med njimi.
Implementacijska raven realizira storitveno raven. Slika 6 ponazarja posamezne
nivoje in njihovo povezovanje s konceptom storitve.
Slika 6: Večplastna arhitektura in koncept storitve [7]
Iz vidika obnašanja odražajo storitveno usmerjenost zunanji in notranji pogledi,
koncept storitve pa igra v ogrodju Archimate osrednjo vlogo. Za Archimate je
storitev enota funkcionalnosti, ki jo dana entiteta (poslovni sistem, aplikativni
sistem, organizacijska enota itn.) ponuja svojemu (zunanjemu ali notranjemu)
okolju. Storitve so lahko po naravi in po granularnosti zelo različne. Storitvena
usmerjenost vodi v večplastni pogled na poslovno-informacijsko arhitekturo, pri
čemer je storitev osrednja vez med različnimi plastmi (nivoji) [5].
Jezik Archimate
35
3.2.1. POSLOVNI NIVO
Poslovni nivo (angl. Business Layer) nudi izdelke in storitve zunanjim strankam,
ki so v organizaciji realizirani s poslovnimi procesi, te pa izvajajo poslovni akterji
[2]. Na sliki 7 je v Archimate notaciji prikazan metamodel poslovnega nivoja. Kot
smo že omenili, lahko posamezne elemente na podlagi njihovih lastnosti
razvrstimo v tri skupine. Najprej bomo opisali aktivno strukturo poslovnega
nivoja, ki z akterji in njihovimi relacijami tvori organizacijsko strukturo
obravnavanega podjetja.
Poslovni akter (angl. Business actor) je centralni element v aktivni strukturi in
ga lahko opišemo kot aktivno entiteto, ki opravlja »obnašanje«. Poslovni akter je
lahko posameznik (npr. kupec ali zaposleni), lahko pa tudi skupina ljudi ali
poslovne enote (npr. oddelki).
Poslovne vloge(angl. Business role). Posamezni akter ima lahko več različnih
vlog, posamezno vlogo pa lahko zavzema tudi več različnih poslovnih akterjev.
Oddelki v organizaciji so običajno sestavljeni iz različnih stalnih vlog (običajno se
menjajo akterji, ki te vloge zavzemajo, vloge v oddelkih pa se ne spreminjajo).
Archimate notacija pa skozi element Poslovno sodelovanje (angl. Business
collaboration) združuje tudi vloge, ki nimajo stalnega statusa v organizaciji.
Element Poslovno sodelovanje je usmerjen predvsem na določeno začasno
interakcijo oz. niz interakcij med vlogami [4].
Aktivno strukturo še sestavljajo:
Poslovni vmesnik (angl. Business interface), ki je logična ali fizična lokacija,
kjer je lahko nudena poslovna storitev (npr. preko pošte, telefona ali
interneta) in
element Lokacija (angl. Location). Element Lokacija je bil dodan s
posodobitvijo tehničnega standarda na Archimate® 2.0 in je namenjen za
modeliranje porazdeljenih strukturnih elementov. Prikazuje torej odvisnost
strukturnega elementa do neke lokacije. Posredno je lahko element Lokacija
dodeljen tudi elementom obnašanja ter na ta način prikazuje, kje se ti
elementi izvajajo [5].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
36
Slika 7: Metamodel poslovnega nivoja2 [5]
Pasivno strukturo poslovnega nivoja sestavljajo naslednji elementi [4]:
Poslovni objekti (angl. Business object) – predstavljajo pomembne
''informativne'' elemente. Objekti so pasivni elementi v smislu, da ne sprožijo
ali izvajajo poslovnih procesov.
Predstavitev (angl. Representation) – zaznavna oblika informacij, ki jih lahko
prenašajo poslovni objekti. Če kot objekt vzamemo dokument, potem so kot
možni elementi predstavitev lahko HTML, PDF, grafi, itd..
Pogodba (angl. Contract) – formalna ali neformalna specifikacija sporazuma,
ki določa pravice in obveznosti povezane s produktom.
Produkt (angl. Product) – zbirka storitev, ki skupaj s pogodbo določajo
lastnosti, pravice in zahteve za njihovo uporabo.
Vrednost (angl. Value)
Pomen (angl. Meaning) – prispevek strokovnega znanja poslovnemu objektu
s strani akterja glede na kontekst.
2 Slika 8 ne prikazuje vseh dovoljenih relacij v poslovnem nivoju
Jezik Archimate
37
Na začetku razdelka 3.2. smo že zapisali, da igra koncept storitve osrednjo vlogo
v ogrodju Archimate, ter da je storitev za Archimate enota funkcionalnosti, ki jo
dana entiteta ponuja svojemu okolju.
Poslovna storitev (angl. Business services) je element obnašanja in jo lahko
predstavimo kot skladen del funkcionalnosti, ki ponuja dodano vrednost
svojemu okolju ne glede na to, kako je ta funkcionalnost navznoter realizirana
[2]. Iz slike 7 lahko vidimo, da je poslovna storitev realizirana z drugimi
elementi obnašanja, ti elementi pa so:
Poslovni proces (angl. Business process) – pretok aktivnosti z vsaj enim
začetnim izhodiščem, ki vodi do jasno definiranega rezultata;
Poslovna funkcija (angl. Business function) – nudi funkcionalnosti, ki so
lahko koristne za enega ali več poslovnih procesov;
Poslovna interakcija (angl. Business interaction) – obnašanje, ki ga s
sodelovanjem izvajajo dve ali več poslovnih vlog;
Poslovni dogodek (angl. Business event) – nekaj, kar se zunanjemu okolju
zgodi in vpliva na poslovni proces, poslovno funkcijo ali poslovno interakcijo.
Poslovni dogodek se pri modeliranju najpogosteje pojavlja kot element, ki
proži elemente obnašanja.
3.2.2. APLIKATIVNI NIVO
Aplikativni nivo (angl. Application Layer) podpira poslovni nivo z uporabo
storitev, ki so jih ustvarile aplikacije. Na sliki 8 je v Archimate notaciji prikazan
metamodel aplikativnega nivoja.
Najpomembnejši strukturni koncept aplikativnega nivoja je aplikacijska
komponenta (angl. Application component). Aplikacijska komponenta je
samostojni del sistema, ki povzema njegovo vsebino ter z naborom vmesnikov
omogoča njegove funkcionalnosti.
Medsebojno sodelovanje aplikacijskih komponent opisuje element Aplikacijsko
sodelovanje (angl. Application collaboration), katerega lahko definiramo kot
skupek aplikacijskih komponent, ki izvajajo aplikacijske interakcije.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
38
Dostope do storitev, ki so jih ustvarile aplikacijske komponente modeliramo z
elementi aplikacijskih vmesnikov (angl. Application interface). Rečemo lahko,
da aplikacijski vmesnik definira sklop operacij in dogodkov, ki se zagotavljajo z
aplikacijsko komponento oz. se zahtevajo iz okolja.
V aplikativnem nivoju je definirana tudi pasivna različica aplikacijske
komponente- pasivni strukturni element podatkovni objekt (angl. Data object).
Podatkovni objekt je skladen in samostojen podatek ustrezen za avtomatsko
procesiranje.
Slika 8: Metamodel aplikativnega nivoja [4]
Elemente obnašanja na aplikativnem nivoju je možno opisati na podoben način,
kot smo opisali elemente obnašanja na poslovnem nivoju. Aplikacijske storitve
(angl. Application services) lahko prav tako delimo na zunanje in notranje
storitve. Aplikacijske storitve so iz zunanjega okolja vidna funkcionalnost, ki jo
skozi natančno določen aplikacijski vmesnik zagotavlja ena ali več aplikacijskih
komponent.
Aplikacijske storitve izpostavljajo v okolje aplikacijske funkcije (angl.
Application function) s katerimi modeliramo notranje obnašanje aplikacij,
potrebne za realizacijo ene ali več aplikacijskih storitev. Skupinskega obnašanje
dveh ali več delov aplikacije pa prikažemo z elementi aplikacijskih interakcij
(angl. Application interaction).
Jezik Archimate
39
3.2.3. TEHNOLOŠKI NIVO
Tehnološki nivo (angl. Technology Layer) nudi infrastrukturne storitve (npr.
procesiranje, shranjevanje in komunikacijske storitve), potrebne za izvajanje
aplikacij, ki jih poganjajo računalniki in komunikacijska strojna in sistemska
programska oprema. Na sliki 9 je v Archimate notaciji prikazan metamodel
tehnološkega nivoja. Strukturni elementi, ki jih najdemo na tem nivoju so:
Vozlišče (angl. Node) – predstavlja strukturno entiteto na tehnološkem
nivoju. Definirano je kot računalniški vir, na katerem se lahko hranijo in
uporabljajo podatki za izvedbo. Vozlišča so aktivni procesni elementi, ki
izvršujejo in procesirajo predmete, ki predstavljajo komponente in
podatkovne objekte. Vozlišča se uporabljajo kot npr. aplikacijski strežniki in
podatkovni strežniki.
Infrastrukturni vmesnik (angl. Infrastructure interface) – dostopna točka,
kjer so infrastrukturne storitve vozlišča dostopne drugim vozliščem in
aplikacijskim komponentam.
Naprava (angl. Device) – stojna oprema, na kateri so predmeti shranjeni ali
razviti z namenom izvršitve. Naprava je specializirano vozlišče, ki predstavlja
fizični vir s procesnimi zmogljivostmi. Običajno so naprave skupaj s sistemsko
programsko opremo deli vozlišč.
Sistemska programska oprema (angl. System software) – predstavlja
programsko okolje (angl. software environment) za specifične vrste
komponent, ki so razvite na njej v obliki objektov. Je specializirana oblika
vozlišča, ki se uporablja za modeliranje programskega okolja, v katerem
delujejo objekti. To so npr. operacijski sistemi in JEE aplikacijski strežnik.
Običajno je sistemska programska oprema kombinirana z napravo, ki
predstavlja strojno opremo, ki oblikuje splošni vmesnik.
Komunikacijska pot (angl. Comumunication path) – povezava med dvema ali
več vozlišči, po kateri si ta vozlišča izmenjujejo podatke. Komunikacijska pot
se uporablja za modeliranje logičnih komunikacijskih odnosov med vozlišči.
Realizirana je med enim ali več omrežji, ki so predstavljena kot fizične
komunikacijske povezave.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
40
Omrežje (angl. Network) – komunikacijski medij med dvema ali več
napravami. Predstavlja fizično komunikacijsko infrastrukturo. Najbolj
osnovno omrežje je enojna povezava med dvema napravama, običajno pa
povezuje več komunikacijskih poti.
Artefakt (angl. Artifact) – fizični del podatkov, ki se uporablja ali ustvarja v
procesu delovanja programske opreme. Običajno se uporablja za modeliranje
npr. izvornih datotek, podatkovnih tabel ali dokumentov.
Slika 9: Metamodel tehnološkega nivoja [4]
Elementi obnašanja, ki jih najdemo na tehnološkem nivoju so:
Infrastrukturna funkcija (angl. Infrastructure function) – element
obnašanja, ki združuje infrastrukturno obnašanje, ki ga lahko izvede vozlišče.
Opisuje notranje obnašanje vozlišča in je nevidna za uporabnika vozlišča, ki
izvaja infrastrukturno funkcijo. Njegovo obnašanje je navzven opazno preko
ene ali več infrastrukturnih storitev.
Infrastrukturna storitev (angl. Infrastructure service) – funkcionalnost
enote, ki je opazna navzven in jo zagotavljata eno ali več vozlišč.
Infrastrukturna storitev izpostavlja funkcionalnost vozlišča njegovemu
okolju. Ta funkcionalnost pa je na voljo preko infrastrukturnih vmesnikov in
lahko zagotovi, uporablja in proizvaja artefakte.
Jezik Archimate
41
3.2.4. MOTIVACIJSKA RAZŠIRITEV JEZIKA ARCHIMATE
Ključni koncepti jezika Archimate se osredotočajo na opis arhitekture
poslovnega sistema. S tehničnim standardom Archimate 1.0 pa koncepti ne
zajemajo elementov, ki v raznih pogledih motivirajo in oblikujejo delovanje
podjetja. S posodobitvijo standarda na Archimate 2.0 je ena izmed razširitev tudi
koncept ''Motivacija''.
Koncept motivacijske razširitve dodaja jeziku Archimate motivacijsko
komponento, kot so cilji, principi in pogoji. Motivacijski elementi so definirani
kot elementi, ki predstavljajo razloge in vzvode, ki so prisotni v ozadju
arhitekture poslovnega sistema podjetja. [5]. Metamodel motivacijske razširitve
je prikazan na spodnjem diagramu (glej slika 10).
Slika 10: Metamodel koncepta motivacijske razširitve jezika Archimate [5]
Deležnik (angl. Stakeholder) – deležnik lahko predstavimo kot vlogo
posameznika, ekipe ali organizacije, ki predstavljajo svoje interese v rezultatu
arhitekture podjetja. Deležniki lahko imajo več interesov ali zadržkov v
organizaciji in strukturi podjetja.
Gonilo (angl. Driver) – gonilo lahko poimenujemo, kot nekaj, kar kreira,
motivira in spodbuja spremembe v organizaciji. Gonilniki so lahko locirani
znotraj organizacije, v tem primeru so navadno povezani z deležnikom, ali pa
zunanji, npr. ekonomske ali zakonodajne spremembe.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
42
Ocena/Presoja (angl. Assessment) – definiramo jo lahko kot rezultat analize
posameznega gonila. Ocena oz. presoja lahko prikazuje prednosti, slabosti,
priložnosti in nevarnosti določenega interesnega področja.
Cilj (angl. Goal) – je definiran kot končno stanje, ki ga deležnik želi doseči. V
principu lahko končni rezultat predstavlja katerokoli željo deležnika.
Zahteva (angl. Requirement) – se smatra kot nujnost, ki jo mora sistem
zagotoviti. Načela in principi modelirajo lastnosti elementov, ki so nujni za
dosego končnega cilja.
Omejitev (angl. Constraint) – je definirana kot restrikcija na poti do
realizacije sistema.
Princip (angl. Principle) – pa kot normativna lastnost vseh sistemov v danem
kontekstu na poti do realizacije [5].
3.2.5. RAZŠIRITEV JEZIKA ARCHIMATE Z IMPLEMENTACIJO IN MIGRACIJO
Razširitev jezika Archimate s konceptom implementacije in migracije dodaja
podporo in omogoča preslikavo z arhitekturno metodo ADM v sorodni
tehnologiji TOGAF. Diagram (glej slika 11) prikazuje metamodel implementacije
in koncepta migracij. Konceptualno je ta delovni paket zelo podoben
poslovnemu procesu, saj je sestavljen iz enostavno povezanih nalog, ki so
naravnane k določenemu cilju.
Slika 11: Metamodel koncepta implementacijske in migracijske razširitve jezika Archimate [5]
Jezik Archimate
43
Delovni paket (angl. Work package) – serija aktivnosti, ki so ustvarjene za
doseganje unikatnih ciljev znotraj določenega časa. Je osrednji koncept
obnašanja, ki ima natančno definiran začetni in končni čas ter dobro
definirane cilje in rezultate. Uporablja se za modeliranje projektov in nalog
znotraj določenega projekta.
Rezultat (angl. Deliverable) - natančno definiran končen produkt delovnega
paketa. Delovni paket proizvaja rezultate. To so lahko raznovrstni rezultati,
kot so poročila, storitve, programska oprema, fizični produkti ipd. Rezultat je
lahko tudi implementacija arhitekture.
Plato (angl. Plateau) – relativno stabilno stanje arhitekture, ki obstaja v
določenem času.
Razlika (angl. Gap) – rezultat med analizama dveh platojev.
3.2.6. RELACIJE JEZIKA ARCHIMATE
Do sedaj smo si ogledali koncepte, ki jih ponuja jezik Archimate. Jezik Archimate
pa prav tako zagotavlja različne relacije, ki povezujejo raznovrstne entitete. Ob
predstavitvi metamodelov različnih konceptov (glej predhodna podpoglavja)
smo že prikazali nekaj od teh relacij, vendar bomo v tem poglavju razložili vsako
relacijo posebej. Archimate zagotavlja formalno metodo za deljenje relacij glede
na koncepte, katero bomo v nadaljevanju tudi predstavili.
V jeziku Archimate je na voljo 11 relacij, ki jih večinoma lahko delimo na
dinamične ali strukturne relacije. Strukturne relacije se uporabljajo za
definiranje strukturne koherence med entitetami, medtem ko se dinamične
relacije uporabljajo za definiranje koherence med entitetami obnašanja.
Opazimo lahko, da deli jezika Archimate izhajajo iz že obstoječih standardov.
Večina relacij na primer, izhaja iz odnosov, ki so definirani v UML.
Predvidevamo, da je to dobro izhodišče, saj je večina arhitektov že seznanjena z
relacijami in njihovimi definicijami [5].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
44
STRUKTURNE RELACIJE:
Dostop (angl. Access) - Relacija, ki prikazuje, kako proces, funkcija, storitev
ali dogodek, dostopajo do poslovnega ali podatkovnega objekta.
Slika 12: Relacija dostop
Uporaba (angl. Used-by) - Relacija, ki prikazuje medsebojno uporabo
gradnikov, npr. proces uporablja storitev. Ta relacija se lahko uporablja tudi
za modeliranje dostopa vlog in komponent do vmesnika.
Slika 13: Relacija uporaba
Kompozicija (angl. Composition) – Relacija, ki kaže, da je objekt sestavljen iz
drugih objektov. Ta relacija je podobna kompozicijskemu odnosu v UML
razrednih diagramih, vendar se v jeziku Archimate uporablja za sestavljanje
konceptov v širšem razponu.
Slika 14: Relacija kompozicija
Agregacija (angl. Aggregation) – Relacija, ki kaže na to, da objekt združuje
skupino drugih objektov. Tudi relacija je podobna kompozicijskemu odnosu v
UML razrednih diagramih, vendar se v jeziku Archimate uporablja za
sestavljanje konceptov v širšem razponu.
Slika 15: Relacija agregacija
Jezik Archimate
45
Dodelitev (angl. Assignement) – Relacija, ki se lahko uporablja za dodelitev
določenega elementa obnašanja aplikativni komponenti ali funkciji. Če je npr.
poslovni proces dodeljen aplikativni komponenti, to pomeni, da aplikativna
komponenta avtomatizira proces.
Slika 16: Relacija dodelitev
Realizacija (angl. Realization) - Relacija, ki prikazuje, kako so logične entitete,
npr. storitve, realizirane z bolj oprijemljivimi entitetami, npr. z aplikativno
komponento.
Slika 17: Relacija realizacija
DINAMIČNE RELACIJE:
Proženje (angl. Triggering) - Relacija med dvema entitetama obnašanja, npr.
procesoma, ki pomeni, da konec prve entitete sproži začetek druge.
Slika 18: Relacija proženje
Pretok (angl. Flow) - Opisuje izmenjavo informacij ali vrednosti med procesi,
funkcijami, dogodki ali interakcijami. Relacija se uporablja za modeliranje
relacij med elementi obnašanja in procesi.
Slika 19: Relacija pretok
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
46
DRUGE RELACIJE:
Asociacija (angl. Association) – Relacija prikazuje odnos med objekti, ki niso
povezani z bolj specifičnimi relacijami. Prav tako pa se uporablja za povezavo
informacijskih strukturnih elementov z drugimi elementi.
Slika 20: Relacija asociacija
Stičišče (angl. Junction) – Relacija se uporablja za povezavo med relacijami
istega tipa.
Slika 21: Relacija stičišče
Specializacija (angl. Specialisation) – Relacija nakazuje, da je objekt
specializirana oblika drugega objekta. Ta relacija je podobna
specializacijskemu odnosu v UML razrednih diagramih, vendar se v jeziku
Archimate uporablja za sestavljanje konceptov v širšem razponu.
Slika 22: Relacija specializacija
Jezik Archimate
47
PRAVILA RELACIJ:
Jezik Archimate zagotavlja formalno metodo za deljenje relacij glede
na koncepte, kar je bistvenega pomena predvsem za arhitekturne modelirne
jezike. S pomočjo te funkcionalnosti dovoljuje arhitektom, da izpustijo
podrobnosti v obravnavanem modelu, ne da bi ogrozili skladnost metode [5].
Pri strukturnih relacijah je definirano pravilo kompozicije, ki vpliva na moč
relacij. V verigi relacij je najšibkejša relacija na koncu te verige. V tabelo 1 smo
zapisali moč, ki jo imajo posamezne relacije.
Tabela 1: Prioritete strukturnih relacij [5]
RELACIJA MOČ
asociacija 1 dostop 2 uporaba 3 realizacija 4 dodelitev 5 agregacija 6 kompozicija 7
3.3. ARCHIMATE VIDIKI
Vidik (zorni kot, angl. viewpoint) v ogrodju Archimate je izbira ustreznih
podmnožic Archimate konceptov in njihovih relacij, ki so bili razviti na podlagi
praktičnih izkušenj ter predstavitev tega dela arhitekture skozi različne
diagrame [5]. Nekateri izmed teh vidikov imajo obseg omejen samo na eno plast.
Kot primer lahko vzamemo: vidik poslovne funkcije in poslovnega procesa, ki
prikazujeta dva pomembna pogleda na poslovno obnašanje; vidik organizacije
prikazuje strukturo podjetja v smislu njegovih oddelkov, vlog, itd.; vidik
informacijske strukture opisuje uporabljene informacije in podatke; vidik
aplikacijske strukture, obnašanja in sodelovanja prikazuje aplikacije, komponente
ter njihove medsebojne relacije; vidik infrastrukture pa prikazuje infrastrukturo
in platformo, ki je podlaga za informacijski sistem te organizacije (npr. omrežje,
naprave in sistemska programska oprema).
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
48
Nekateri vidiki pa lahko povezujejo tudi več plasti in/ali pogledov; Vidik
sodelavca in produkta povezuje poslovni sistem z njegovim okoljem; Vidik
uporabe aplikacij povezuje aplikacije z njihovo uporabo, npr. v poslovnih
procesih; Vidik razvrstitve pa prikazuje način, kako so aplikacije preslikane na
osnovno infrastrukturo [5].
Za predstavitev arhitekture poslovnega sistema iz vseh možnih pogledov,
ogrodje Archimate navaja 27 osnovnih vidikov, ki so razviti na podlagi
praktičnih izkušenj [5]:
Uvodni vidik (angl. Introductory viewpoint),
Organizacijski vidik (angl. Organization viewpoint),
Vidik sodelovanja akterjev (angl. Actor Co-operation Viewpoint),
Vidik poslovnih funkcij (angl. Business Function viewpoint),
Vidik poslovnih procesov (angl. Business Process viewpoint),
Vidik sodelovanja poslovnih procesov (angl. Business Process Co-operation
viewpoint),
Vidik produktov (angl. Product viewpoint),
Vidik obnašanja aplikacij (angl. Application Behavior viewpoint),
Vidik sodelovanja aplikacij (angl. Application Co-operation viewpoint),
Vidik strukture aplikacij (angl. Application Structure viewpoint),
Vidik uporabe aplikacij (angl. Application Usage viewpoint),
Infrastrukturni vidik (angl. Infrastructure viewpoint),
Vidik uporabe infrastrukture (angl. Infrastructure Usage viewpoint),
Vidik implementacije in uvajanja (angl. Implementation and Deployment
viewpoint),
Vidik strukture informacij (angl. Information Structure viewpoint),
Vidik realizacije storitev (angl. Service Realization viewpoint),
Vidik nivojev (angl. Layered viewpoint),
Celostni vidik (angl. Landscape Map viewpoint),
Vidik deležnikov (angl. Stakeholder viewpoint),
Vidik realizacije ciljev (angl. Goal Realization viewpoint),
Vidik prispevanja k cilju (angl. Goal Contribution viewpoint),
Vidik načel (angl. Principles viewpoint),
Vidik realizacije zahtev (angl. Requirements Realization viewpoint),
Jezik Archimate
49
Vidik motivacije (angl. Motivatin viewpoint),
Vidik projekta (angl. Project viewpoint),
Vidik migracije (angl. Migration viewpoint),
Vidik implementacije in migracije (angl. Implementation and Migration
viewpoint).
Z različnimi programskimi orodji, ki podpirajo jezik Archimate, lahko ustvarimo
tudi svoje vidike, odvisno od želja deležnikov in specifike arhitekture poslovnega
sistema organizacije.
V nadaljevanju se bomo omejili samo na nekatere osnovne vidike ter prikazali
koncepte in relacije teh vidikov. Omejili se bomo predvsem na vidike, katere
bomo uporabili v študiji primera v 5. poglavju.
Za lažji pregled in primerjavo med različnimi vidiki, bomo pri vsakem vidiku
zajeli naslednje točke:
opis ter deležniki vidika,
arhitekturni nivo ter vrsta elementov, ki so prikazani s posameznim vidikom,
metamodel vidika.
3.3.1. ORGANIZACIJSKI VIDIK
Organizacijski vidik se osredotoča predvsem na notranjo organiziranje
podjetja, oddelka, mreže podjetij ali katere druge organizacijske enote. Modeli v
tem vidiku so lahko predstavljeni s pomočjo diagramov, lahko pa tudi s pomočjo
organizacijskih grafikonov. Organizacijski vidik je zelo uporaben pri ugotavljanju
sposobnosti (kompetenc), pristojnosti in odgovornosti v organizaciji.
Slika 23: Metamodel organizacijskega vidika [5]
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
50
Pogled je namenjen arhitekturnim in procesnim arhitektom, menedžerjem,
zaposlenim ter drugim deležnikom. Pogled se uporablja na poslovnem nivoju in
prikazuje elemente strukture [5].
3.3.2. VIDIK SODELOVANJA AKTERJEV
Vidik sodelovanja akterjev se osredotoča na odnose med akterji in njihovim
okoljem. Pogost primer tega vidika je kontekstni diagram, ki postavlja
organizacijo v svoje okolje, okolje pa sestavljajo zunanje entitete, npr. stranke,
dobavitelji in poslovni partnerji. V tem pogledu torej določimo zunanje
odvisnosti in sodelovanja ter prikažemo mrežo, v kateri akter deluje. Druga
pomembna uporaba tega pogleda je prikaz, kako sodelovanje poslovnih akterjev
in/ali aplikacijskih komponent, tvori poslovni proces.
Slika 24: Metamodel vidik sodelovanja akterjev [5]
Pogled je prilagojen za poslovno-informacijske in procesne arhitekte, vidik
povezuje med sabo poslovni in aplikacijski nivo, dotika pa se predvsem
elementov obnašanja in strukture [5].
Jezik Archimate
51
3.3.3. VIDIK POSLOVNIH FUNKCIJ
Vidik poslovnih funkcij prikazuje glavne funkcije organizacije in njihove
relacije (pretok informacij, vrednosti). Poslovne funkcije uporabljamo tudi za
predstavitev najstabilnejših vidikov družbe glede na primarne dejavnosti, ki jih
opravlja in neodvisno od organizacijskih sprememb in tehnološkega razvoja.
Vidik poslovnih funkcij omogoča vpogled v splošno poslovanje organizacije,
uporabljamo pa ga lahko tudi za identifikacijo potrebnih kompetenc ter za
zmanjševanje kompleksnosti.
Slika 25: Metamodel vidika poslovnih funkcij [5]
Pogled je prilagojen za poslovno-informacijske in procesne arhitekte, vidik
povezuje med sabo elemente obnašanja in elemente strukture poslovnega
nivoja [5].
3.3.4. VIDIK POSLOVNIH PROCESOV
Vidik poslovnih procesov se uporablja za prikaz visokonivojskih struktur in
kompozicij enega ali več poslovnih procesov. Ob prikazu samih procesov, ta
vidik zajema tudi druge koncepte, ki so v neposredni povezavi s procesi, kot npr.:
storitve, ki jih poslovni proces ponuja uporabnikom, s prikazom prednosti, ki
jih proces doprinese realizaciji produktov določenega podjetja;
določitev nalog udeležencem poslovnega procesa, kar omogoči vpogled v
naloge in zadolžitve udeležencev procesa;
informacije, ki se v poslovnem procesu uporabljajo.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
52
Slika 26: Metamodel vidika poslovnih procesov [5]
Vidik je prilagojen za procesne arhitekte ter operativne vodje oddelkov, pogled
pa povezuje element obnašanja na poslovnem nivoju [5].
3.3.5. VIDIK SODELOVANJA POSLOVNIH PROCESOV
Vidik sodelovanja poslovnih procesov se uporablja za prikaz razmerja med
enim ali več poslovnih procesov z njihovim okoljem ali v njihovem okolju. V obeh
primerih lahko ustvarimo visoko-nivojski modeliran poslovni proces znotraj
lastnega konteksta ter zagotovimo operativnega vodjo (angl. operational
manager), ki je zadolžen za enega ali več takšnih procesov in ima vpogled v
njihove odvisnosti.
Pomembni vidiki sodelovanja poslovnih procesov so:
splošna razmerja med glavnimi poslovnimi procesi organizacije;
preslikava poslovnih procesov v poslovne funkcije;
realizacija storitev s poslovnimi procesi;
uporaba skupnih podatkov.
Jezik Archimate
53
Slika 27: Metamodel vidika sodelovanja poslovnih procesov [5]
Vidik je prilagojen za procesne arhitekte ter operativne vodje oddelkov, pogled
pa povezuje elemente obnašanja na poslovnem in aplikativnem nivoju [5].
3.3.6. VIDIK PRODUKTOV
Vidik produktov prikazuje vrednosti, ki jih proizvodi nudijo strankam in
prikazuje sestavo enega ali več proizvodov v smislu predstavitve sestavljenih
storitev in povezanih naročil ali sporazumov. Prav tako se lahko uporablja za
prikaz različnih možnosti prodaje produkta. Proizvodni vidik se navadno
uporablja v proizvodni fazi produkta za oblikovanje produkta s
sestavljanjem obstoječih storitev ali z iskanjem novih, ki morajo biti
ustvarjeni za ta produkt z upoštevanjem njegove vrednosti na trgu. Služi
lahko kot začetna informacija za arhitekta poslovnega procesa ali drugih, ki
jo potrebujejo za oblikovanje procesov.
Vidik je prilagojen razvijalcem produktov, vodjem proizvodnje in procesnim
arhitektom. Vidik povezuje elemente obnašanja in pasivne strukture na
poslovnem in aplikativnem nivoju [5].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
54
Slika 28: Metamodel vidika produktov [5]
3.3.7. VIDIK OBNAŠANJA APLIKACIJ
Vidik obnašanja aplikacij opisuje notranje obnašanje določene aplikacije, npr.
kako izvaja eno ali več storitev. Ta vidik je uporaben pri oblikovanju ključnega
obnašanja ali pri identifikaciji prekrivanj funkcij med različnimi aplikacijami.
Slika 29: Metamodel vidika obnašanja aplikacij [5]
Vidik je prilagojen poslovnim, procesnim in aplikativnim arhitektom, vidik pa
povezuje elemente pasivne strukture, elemente obnašanja in elemente aktivne
strukture na aplikativnem nivoju [5].
Jezik Archimate
55
3.3.8. VIDIK SODELOVANJA APLIKACIJ
Vidik sodelovanja aplikacij opisuje odnose med komponentami aplikacij v
smislu prenosa informacij med njimi ali med storitvami, ki jih uporabljajo ali
ustvarjajo. Ta vidik se najpogosteje uporablja pri ustvarjanju pregleda nad
strukturo aplikacij znotraj organizacije. Prav tako pa se uporablja za prikaz
sodelovanja podpornih storitev, ki so pomembne za izvajanje poslovnega
procesa. Vidik je prilagojen poslovnim, procesnim in aplikativnim arhitektom, in
povezuje elemente obnašanja ter elemente strukture na aplikativnem nivoju [5].
Slika 30: Metamodel vidika sodelovanja aplikacij [5]
3.3.9. VIDIK STRUKTURE APLIKACIJ
Vidik strukture aplikacij prikazuje strukturo ene ali več aplikacij ter njenih
delov. Vidik je zelo uporaben pri oblikovanju in razumevanju glavne strukture
aplikacije ali njenih delov ter z njimi povezanimi podatki, npr. če želimo
razčleniti strukturo sistema, ki je v izdelavi, ali če želimo identificirati sestavne
dele predhodne aplikacije, ki so primerni za nadaljnjo uporabo in vključitev v
proces. Vidik je prilagojen poslovnim, procesnim in aplikativnim arhitektom ter
povezuje elemente strukture na aplikativnem nivoju [5].
Slika 31: Metamodel vidika strukture aplikacij [5]
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
56
3.3.10. VIDIK UPORABE APLIKACIJ
Vidik uporabe aplikacij opisuje, kako se aplikacije uporabljajo za podporo
enega ali več poslovnih procesov, ter kako neko aplikacijo uporablja druga
aplikacija. Vidik se lahko uporablja za oblikovanje aplikacije, tako da identificira
storitev, ki jo uporablja poslovni proces ali druga aplikacija. Uporablja se lahko
tudi za oblikovanje poslovnega procesa, tako da opiše storitve, ki jih proces
zajema. Ker vidik opisuje odvisnost poslovnega procesa od aplikacij, je prav tako
lahko uporaben operativnemu vodji, ki je odgovoren za poslovne procese.
Slika 32: Metamodel vidika uporabe aplikacij [5]
Vidik je prilagojen poslovnim, procesnim, aplikativnim arhitektom in
operativnim vodjem, ter povezuje elemente obnašanja in strukture na
aplikativnem nivoju [5].
Jezik Archimate
57
3.3.11. INFRASTRUKTURNI VIDIK
Infrastrukturni vidik vsebuje infrastrukturne elemente programske in strojne
opreme, ki podpirajo delovanje poslovnega sistema na aplikacijskem nivoju
(slika 33). To so lahko fizične naprave, omrežja ali sistemska programska
oprema (npr. operacijski sistem, podatkovne baze).
Slika 33: Metamodel infrastrukturnega vidika [5]
Vidik je prilagojen infrastrukturnim arhitektom in operativnim vodjam, ter
povezuje elemente obnašanja in strukture na tehnološkem nivoju [5].
3.3.12. VIDIK UPORABE INFRASTRUKTURE
Vidik uporabe infrastrukture skozi diagram (glej sliko 34) prikazuje, kako
programska in strojna oprema podpirata aplikacije: naprave omogočajo
infrastrukturne storitve, sistemska programska oprema in omrežje sta na voljo
aplikacijam. Ta vidik ima pomembno vlogo pri analiziranju zmogljivosti in
razširjenosti, ker povezuje fizične infrastrukture z logičnim svetom aplikacij. To
je zelo uporabno pri določanju zahtev glede kakovosti infrastrukture, ki temelji
na zahtevah različnih aplikacij, ki jo uporabljajo.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
58
Slika 34: Metamodel vidika uporabe infrastrukture [5]
Vidik je prilagojen aplikacijskim in infrastrukturnim arhitektom ter operativnim
vodjem. Vidik povezuje elemente obnašanja in strukture na aplikativnem in
tehnološkem nivoju [5].
3.3.13. VIDIK IMPLEMENTACIJE IN UVAJANJA
Vidik implementacije in uvajanja prikazuje način, kako je ena ali več aplikacij
realizirana z infrastrukturo (slika 35). Vidik obsega preslikavo logičnih aplikacij
in njenih komponent na fizične artefakte (npr. Enterprise Java Beans) ter
preslikavo informacij, ki jih uporabljajo aplikacije in njene komponente, na
osnovne elemente infrastrukture (npr. tabele podatkovnih baz ali druge
datoteke). Vidik uvajanja ima pomembno vlogo tudi pri analizi zmogljivosti in
razširjenosti, saj povezuje fizični svet infrastrukture z logičnim svetom aplikacij.
Pri analizi varnosti in tveganja se vidik uvajanja uporablja za identifikacijo
kritičnih stanj in tveganj.
Jezik Archimate
59
Slika 35: Metamodel zornega kota implementacije in uvajanja [5]
Vidik je prilagojen aplikacijskim in infrastrukturnim arhitektom ter operativnim
vodjem. Vidik povezuje elemente obnašanja in strukture na aplikativnem in
tehnološkem nivoju [5].
3.3.14. VIDIK STRUKTURE INFORMACIJ
Vidik strukture informacij je primerljiv s tradicionalnimi informacijskimi
modeli, ki so bili ustvarjeni za delovanje na večini informacijskih sistemov.
Prikazuje strukturo informacij v podjetju ali specifičnem poslovnem procesu iz
vidika tipov podatkov ali struktur razredov. Prav tako lahko prikaže strukturo
informacij v poslovnem procesu na aplikativni ravni in obliko podatkovne
strukture, ki se na tej ravni uporablja, in kako so te preslikane na osnovno
infrastrukturo, npr. s prikazom sheme podatkovnih baz.
Vidik je prilagojen informacijskim arhitektom ter povezuje elemente pasivne
strukture na poslovnem, aplikacijskem in tehnološkem nivoju [5].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
60
Slika 36: Metamodel vidika strukture informacij [5]
3.3.15. VIDIK REALIZACIJE STORITEV
Vidik realizacije storitev se uporablja za prikaz realizacije ene ali več
poslovnih storitev s povezovalnimi procesi (in včasih s komponentami
aplikacij). Ta vidik ustvarja most med vidikom poslovnih produktov in
vidikom poslovnih procesov. Prikazuje enega ali več poslovnih procesov v
povezavi z zunanjim svetom.
Vidik je prilagojen procesnim arhitektom, operativnim vodjem in vodjem
produktov. Vidik povezuje elemente obnašanja in strukture na poslovnem in
aplikacijskem nivoju [5].
Slika 37: Metamodel vidika realizacije storitev [5]
Jezik Archimate
61
3.4. PREGLED IN ANALIZA ARCHIMATE ORODIJ
V nadaljevanju bomo naredili pregled programskih orodij, ki podpirajo jezik
Archimate. Ker je teh programskih orodij kar nekaj, se bomo omejili na najbolj
razširjene in priljubljene programske rešitve. Za predstavitev izbranih orodij
bomo uporabili podatke in informacije iz njihovih uradnih spletnih strani, nato
pa bomo izbrana orodja tudi namestili in preizkusili. Zaključke bomo zapisali s
pomočjo SWOT analize.
Izmed izbranih orodij se bomo nato odločili, katero Archimate orodje si bomo
izbrali za izvedbo študije primera. Upoštevali bomo predvsem:
kompatibilnost orodja z Archimate specifikacijami z vidika notacije in
semantike,
preglednost in preprostost uporabniškega vmesnika,
prilagoditev orodja glede na lastne preference,
podprte dodatne funkcionalnosti.
Archimate orodja lahko razdelimo v dve skupini:
splošno namizno orodje (Microsoft Visio, OmniGraffle )
namensko namizno orodje (Archi, BiZZdesign Architect)
3.4.1 SPLOŠNO NAMIZNO ORODJE – MICROSOFT VISIO
Programsko orodje Microsoft Visio je zelo dobro poznano komercialno
diagramsko orodje, ki uporabnikom omogoča vizualno predstavitev idej,
procesov, konceptov, struktur, programskih modelov, načrtov itd. Orodje za
izdelavo diagramov uporablja vektorsko grafiko in deluje izključno na
operacijskih sistemih Microsoft Windows. Na voljo so tri različice orodja
Microsoft Visio – standardna, profesionalna in premium različica. Pri vseh treh
so uporabniški vmesnik in osnovne funkcionalnosti enake. Razlike se kažejo pri
naprednih predlogah in dodatnih funkcionalnostih, pri povezovanju diagramov s
podatkovnimi viri, ki so vključene v profesionalno različico ter še dodatna
podpora k tehnologijam SharePoint Workflow, BPMN, Six Sigma, ki jih vključuje
premium različica [8].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
62
Za seznanitev z orodjem, smo uporabili verzijo Microsoft Visio 2010
Professional. Čeprav Microsoft Visio 2010 Professional že privzeto nudi številne
predloge in šablone, podpora jeziku Archimate ob namestitvi še ni vključena.
Za modeliranje smo namestili brezplačno Archimate šablono3.
Kot komercialno, splošno namensko modelirno orodje ima Visio 2010 svoje
prednosti in slabosti, ki smo jih povzeli s pomočjo SWOT analize (glej tabela 2).
Tabela 2: SWOT analiza - Microsoft Visio in Archimate šablona
PREDNOSTI
Več modelirnih kategorij v enem
orodju.
Pri modeliranju ne postavlja
nobenih omejitev.
Možnost povezovanja z drugimi
orodji (Excel, SharePoint).
Stabilnost in varnost (servisni
paket).
Šablona, ki podpira vse gradnike in
pravila Archimate.
Enostavna uporaba.
SLABOSTI
Ne podpira preverjanja veljavnosti
Archimate diagramov.
Zahtevno vzdrževanje zmodelirane
arhitekture.
Privzeto ne vsebuje Archimate
predloge.
Plačljiv.
Deluje samo na sistemu Windows.
PRILOŽNOSTI
Večja prepoznavnost in
uveljavljenost jezika Archimate
zaradi vplivnosti podjetja Microsoft.
Del Microsoft Office aplikacij.
Sodelovanje z drugimi podjetji z
namenom ustvariti dodatne
funkcionalnosti.
NEVARNOSTI
Ukinjena podpora s strani
Microsofta.
Brezplačno in namensko
programje.
Slabša ažurnost glede posodobitev
in novosti Archimate.
3 Archimate šablono smo brezplačno pridobili na spletni strani (http://www.orbussoftware.com/downloads/free-visio-stencils/archimate-visio-stencil-and-template).
Jezik Archimate
63
3.4.2 SPLOŠNO NAMIZNO ORODJE – OMNIGRAFFLE
Programsko orodje OmniGraffle 5 je komercialno diagramsko orodje, ki zelo
spominja na orodje Microsoft Visio. Orodje za izdelavo diagramov prav tako
uporablja vektorsko grafiko, vendar deluje izključno na operacijskih sistemih
Mac OS X. Uporabnikom omogoča vizualno predstavitev idej, procesov,
konceptov, struktur, programskih modelov, načrtov itd. Na voljo sta dve različici
orodja OmniGraffle – standardna in profesionalna različica. Pri obeh so
uporabniški vmesnik in osnovne funkcionalnosti enake. Razlike se kažejo v
dodatnih funkcionalnostih, kot so uvoz in izvoz Microsoft Visio datotek, SVG
izvoz, predstavitveni način, ipd. [9] [10].
Tudi OmniGraffle 5.3.6 razširja področja modeliranja z uporabo šablon, vendar
podpora jeziku Archimate ob namestitvi še ni vključena. Za modeliranje
potrebujemo brezplačno Archimate šablono4 (angl. stencil).
Kot komercialno, splošno namensko modelirno orodje, ima OmniGraffle 5 svoje
prednosti in slabosti, ki smo jih povzeli s pomočjo SWOT analize (glej tabela 3).
4 Archimate šablono smo brezplačno pridobili na spletni strani (http://sourceforge.net/projects/grafflemate).
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
64
Tabela 3: SWOT analiza - OmniGraffle in Archimate šablona
PREDNOSTI
Več modelirnih kategorij v enem
orodju.
Pri modeliranju ne postavlja
nobenih omejitev.
Možnost povezovanja z drugimi
orodji (Visio).
Stabilnost in varnost (servisni
paket).
Šablona, ki podpira vse gradnike in
pravila Archimate.
Enostavna uporaba.
SLABOSTI
Ne podpira preverjanja veljavnosti
Archimate diagramov.
Zahtevno vzdrževanje zmodelirane
arhitekture.
Privzeto ne vsebuje Archimate
predloge.
Plačljiv.
Deluje samo na sistemu Mac OS X.
Dodatne funkcionalnosti.
PRILOŽNOSTI
Večja prepoznavnost in
uveljavljenost jezika Archimate
zaradi vplivnosti podjetja
OmniGroup.
Sodelovanje z drugimi podjetji z
namenom ustvariti dodatne
funkcionalnosti.
NEVARNOSTI
Ukinjena podpora s strani The
OmniGroup.
Slabša ažurnost glede
posodobitev in novosti
Archimate.
Brezplačno in namensko
programje.
3.4.3 NAMENSKO NAMIZNO ORODJE – ARCHI
Medtem ko orodji Visio in OmniGraffle omogočata notacijo Archimate samo
skozi dodatno nameščene šablone, je Archi samostojno namensko programsko
orodje za modeliranje v jeziku Archimate. Archi5 je brezplačno in odprto kodno
orodje napisano v Javi ter deluje na operacijskih sistemih Windows, Mac OS X in
Linux. Orodje Archi je razvil Inštitut za izobraževalno kibernetiko Boltonske
Univerze (Institute of Educational Cybernetics at the University of Bolton),
5 Orodje Archi je brezplačno na voljo na spletnem naslovu (http://archi.cetis.ac.uk/download.html)
Jezik Archimate
65
razvoj pa je financirala organizacija JISC (Joint Information Systems Committee)
[11].
Archi med drugim omogoča:
popolno podporo standardu Archimate 2.0,
kreiranje različnih poročil (Jasper Reports) in dokumentov (PDF, Word) ter
priročne izvozne in uvozne funkcije,
prilagodljivo oblikovanje,
dinamične Archimate poglede oz. vidike,
številne predloge (angl. templates) in vodič za uporabo.
Prednosti in slabosti, ki smo jih identificirali pri uporabi, smo povzeli v SWOT
analizi (glej tabela 4).
Tabela 4: SWOT analiza - Archi
PREDNOSTI
Brezplačen.
Preverjanja veljavnosti Archimate
diagramov.
Enostavno vzdrževanje
zmodelirane arhitekture.
Deluje na Windows, Mac OS X in
Linux sistemih.
Ažurne posodobitve.
Povezava z internetom.
Enostavna uporaba.
Kreiranje poročil in dokumentov.
Podpora vsem osnovnim Archimate
vidikom.
SLABOSTI
Možnost povezovanja z drugimi
orodji (Visio).
Slabša uporabniška izkušnja.
Prilagodljivost relacij je otežena.
Samo enouporabniška podpora.
Pomanjkanje dodatnih
funkcionalnosti.
Modeliranje omogočeno samo z
Archimate pristopom.
PRILOŽNOSTI
Sodelovanje z drugimi podjetji z
namenom ustvariti dodatne
funkcionalnosti.
Možnost povezovanja z drugimi
arhitekturnimi pristopi.
NEVARNOSTI
Ukinjena podpora s strani JISC.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
66
3.4.4 NAMENSKO NAMIZNO ORODJE – ARCHITECT
Orodje Architect6 je samostojno namensko programsko orodje za modeliranje v
jeziku Archimate. Razvilo ga je podjetje BiZZdesign, ki nudi široko paleto
programskih rešitev in izobraževanj za upravljanje s poslovnimi sistemi. Orodje
deluje na operacijskih sistemih Microsoft Windows [12].
Poleg osnovnih funkcionalnosti modeliranja v jeziku Archimate, Architect nudi
tudi nekatere napredne funkcionalnosti, katerih pri konkurenčnih rešitvah ne
najdemo.
Orodje Architect tako omogoča [12]:
Modeliranje produktov, storitev, poslovnih funkcij, vlog, aplikacij,
infrastrukture in podatkov, z modelirnim jezikom Archimate.
Ustvarjanje najrazličnejših pogledov ter zornih kotov.
Analizo vpliva sprememb ter možnost definiranja lastnih analiz.
Vizualizacijo sprememb v arhitekturi skozi čas (t.i. roadmapping).
Objava arhitektur v formatu, ki je berljiv internetnim brskalnikom.
Uvoz in izvoz podatkov z uporabo standardov, kot so: XMI, XML, Excel,
Visio.
Večuporabniška podpora.
Modeliranje in vizualizacijo poslovno-informacijskih arhitektur z drugimi
pristopi (TOGAF, Zachman, Tapschott, DYA® in IAF).
Orodje je sicer plačljivo, vendar smo ga lahko 30 dni brezplačno preizkušali.
Prednosti in slabosti, ki smo jih identificirali pri uporabi tega orodja, smo povzeli
v SWOT analizi (glej tabela 5).
6 Testna različica orodja Architect je brezplačno na voljo na spletnem naslovu (http://www.bizzdesign.com/tools/architect)
Jezik Archimate
67
Tabela 5: SWOT analiza - Architect
PREDNOSTI
Preverjanja veljavnosti Archimate
diagramov.
Enostavno vzdrževanje
zmodelirane arhitekture.
Ažurne posodobitve.
Enostavna uporaba.
Kreiranje poročil in dokumentov.
Podpora vsem osnovnim Archimate
vidikom.
Dodatne funkcionalnosti (Analiza
vpliva sprememb, roadmapping).
Možnost povezovanja z drugimi
orodji (Excel, Visio).
Večuporabniška podpora.
Možnost modeliranje drugimi
pristopi (TOGAF, Zachman,
Tapschott, DYA® in IAF).
Dobra uporabniška izkušnja.
Prilgodljivost povezav med
elementi.
SLABOSTI
Plačljivo orodje in draga licenca.
Deluje samo na operacijskem
sistemu Windows.
Draga izobraževanja.
PRILOŽNOSTI
Sodelovanje z drugimi podjetji z
namenom ustvariti dodatne
funkcionalnosti.
NEVARNOSTI
Ukinjena podpora s strani
BiZZdesign.
Konkurenčno cenejše programje.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
68
3.5. RAZŠIRJENOST UPORABE JEZIKA ARCHIMATE
Pri pregledu priljubljenosti in razširjenosti jezika Archimate, se moramo omejiti
na obstoječe informacije ter podatke, ki so nam na voljo. Ker je jezik oz. standard
Archimate brezplačen ter odprt, je njegova sledljivost uporabe otežena. Skozi
pisanje diplomskega dela nisem zasledil praktično nobenih konkretnih
kvantitativnih podatkov o uporabi in tržnem deležu jezika Archimate, zato sem
za podatke zaprosil direktorico oddelka Archimate Forum (The Open Group) go.
Raino Wissing ter uveljavljenega Archimate arhitekta in avtorja knjige Enterprise
architecture at work, g. Lankhorst Marc-a.
Čeprav tudi pri The Open Group ne beležijo statističnih podatkov o tržnem deležu
njihovega jezika, sem vseeno pridobil nekaj koristnih informacij, s katerimi
bomo prikazali razširjenost uporabe jezika Archimate.
Vse od svoje uveljavitve kot univerzalnega jezika za modeliranje poslovno-
informacijskih arhitektur, je imel Archimate majhno skupino oboževalcev,
predvsem na Nizozemskem, ki je počasi pridobivala na svoji številčnosti. Danes
je slika seveda drugačna. S prevzemom lastništva nad jezikom Archimate s strani
dobro poznane in uveljavljene organizacije The Open Group, je jezik pridobil na
prepoznavnosti ter s tem številne nove uporabnike [13].
Uporaba jezika Archimate je prisotna predvsem pri modeliranju poslovno-
informacijskih arhitektur finančnih institucij, vladnih služb ter drugje v javnem
sektorju [14]. Vladne službe se na primer soočajo z zahtevami javnosti po
učinkovitejšem delovanju in manj birokratskih ovir. Kot rezultat omenjenega se
strukture mnogih podjetij in organizacij že reorganizirajo, javni zavodi pa se tudi
vedno bolj zavedajo potrebe po standardizaciji arhitekturnih opisov.
V javnih organizacijah na Finskem in Nizozemskem se Archimate že uporablja
kot standardni arhitekturni jezik, v Angliji pa tudi beležijo povečanje zahtev po
Archimate podpori. Podoben trend je opaziti tudi v drugih evropskih državah
[14].
Jezik Archimate
69
Na največjem poslovnem omrežju LinkedIn ima skupina Archimate več kot 1850
aktivnih članov. Na podlagi prejetih podatkov s strani organizacije The Open
Group lahko vidimo še spletni prenos standarda Archimate po regijah (slika 38),
s tabelo 6 pa tudi po posameznih državah.
Slika 38: Prenos standarda Archimate s spletne strani The Open Group po regijah [15]
Tabela 6: Prenos standarda Archimate s spletne strani The Open Group po državah [15]
Archimate prenosi po regijah
Afrika
Azija
Avstralija/ Pacifiški otoki
Centralna Amerika
Europa
Severna Amerika
Južna Amerika
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
70
DRŽAVA Št. prenosov DRŽAVA Št. prenosov
ZDA 741 Litva 6 Nizozemska 548 Tajska 6 Združeno kraljestvo 466 Izrael 5 Avstralija 269 Venezuela 5 Kanada 227 Kostarika 4 Indija 192 Ekvador 4 Francija 163 Pakistan 4 Nemčija 148 Katar 4 Belgija 124 Ukrajina 4 Švedska 100 Alžirija 3 Kolumbija 98 Azerbajdžan 3 Kitajska 85 Bolivija 3 Južnoafriška republika 82 Kuvajt 3 Poljska 80 Tajvan 3 Finska 72 Bangladeš 2 Švica 66 Barbados 2 Rusija 64 Bocvana 2 Nova Zelandija 54 Hrvaška 2 Brazilija 48 Kuba 2 Italija 47 Jordan 2 Norveška 42 Južna Koreja 2 Mehika 41 Makedonija 2 Portugalska 38 Malta 2 Češka 37 Filipini 2 Danska 35 Škotska 2 Singapur 34 Aruba 1 Španija 32 Bahrajn 1 Saudska Arabija 25 Belorusija 1 Združeni Arabski Emirati 24 Belize 1 Avstrija 23 Butan 1 Japonska 15 Komori 1 Romunija 13 Ciper 1 Argentina 12 Estonija 1 Grčija 12 Etiopija 1 Čile 11 Gabon 1 Centralna Francija 11 Islandija 1 Indonezija 11 Jamajka 1 Slovenija 10 Kazahstan 1 Hong Kong 9 Kenija 1 Madžarska 9 Latvija 1 Irska 9 Libanon 1 Luxembourg 9 Mauritius 1 Slovaška 9 Mozambik 1 Vietnam 9 Namibija 1 Iran 8 Nigerija 1 Turčija 8 Oman 1 Malezija 7 Panama 1 Maroko 7 San Marino 1 Peru 7 Šrilanka 1 Afganistan 6 Tunizija 1 Bolgarija 6 Urugvaj 1 Egipt 6 Jugoslavija 1 Anglija 6
Pregled sorodnih arhitekturnih pristopov
71
4. PREGLED SORODNIH
ARHITEKTURNIH PRISTOPOV
V tem poglavju bomo naredili pregled sorodnih arhitekturnih pristopov za
modeliranje PIA. Najstarejše in eno izmed najbolj razširjenih ogrodij poslovno-
informacijskih arhitektur je Zachmanovo ogrodje, pomemben pristop, ki
poslovno-informacijsko arhitekturo obravnava celostno, pa je ogrodje TOGAF
(The Open Group Architecture Framework). Pomembnejša in hkrati zelo
razširjena pristopa sta še FEAF (Federal Enterprise Architecture Framework) in
Gartnerjevo ogrodje za poslovno-informacijske arhitekture. Obstaja še kar nekaj
drugih arhitekturnih pristopov, vendar se ti že precej razlikujejo od pristopa
Archimate. V diplomskem delu se bomo omejili na sorodni pristop TOGAF in
Zachman, saj sta trenutno najbolj razširjena in priljubljena pristopa za
modeliranje PIA.
4.1. TOGAF
TOGAF (The Open Group Architecture Framework) je arhitekturno ogrodje, ki
omogoča celovit pristop za oblikovanje, načrtovanje, izvajanje in upravljanje
poslovno-informacijske arhitekture [16].
Ogrodje TOGAF je arhitekturno ogrodje, ki je sestavljeno iz niza med sabo tesno
povezanih arhitektur [5]:
Poslovna arhitektura (angl. Business architecture): opredeljuje poslovno
strategijo, upravljanje, organizacij in ključne poslovne procese organizacije.
Aplikacijska arhitektura (angl. Applications architecture): zagotavlja načrt
za posamezne aplikacije sistemov, ki bodo uporabljene. Zagotavlja tudi načrt
interakcije med aplikacijskimi sistemi in njihovo relacijo do ključnih
poslovnih procesov organizacije.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
72
Podatkovna arhitektura (angl. Data architecture): opisuje strukturo logičnih
in fizičnih podatkov organizacije in s tem povezanih podatkov za upravljanje
virov.
Tehnična arhitektura ali arhitektura tehnologije (angl. Technical
architecture): opisuje strojno in programsko opremo ter mrežno
infrastrukturo, potrebno za podporo uvajanja ključnih in kritičnih aplikacij.
TOGAF skuša podati splošen, dobro preizkušen začetni model, katerega lahko
arhitekti enostavno nadgrajujejo, ter se zanaša na modularizacijo,
standardizacijo ter že obstoječe in preizkušene tehnologije in izdelke [17].
Ključna metoda pri ogrodju TOGAF je metoda ADM (Architecture Development
Method), ki velja za zanesljivo in dobro preizkušeno metodo za razvijanje IT
arhitektur poslovnih procesov [17].
Archimate in TOGAF se med seboj dopolnjujeta, lahko pa se uporabljata tudi v
kombinaciji drug z drugim [4]. Struktura jezika Archimate se lepo ujema s tremi
glavnimi TOGAF strukturami (slika 39). Te povezave kažejo na dokaj enostavno
preslikavo med TOGAF pogledi in Archimate vidiki.
Slika 39: Povezave med ogrodjem TOGAF in ogrodjem Archimate [5]
Pregled sorodnih arhitekturnih pristopov
73
Nekateri TOGAF pogledi se ne ujemajo z vidiki v ogrodju Archimate oz. jih ni
mogoče enostavno preslikati. Delno zato, ker nas načeloma v ogrodju TOGAF
zanima širša slika poslovnih procesov, ukvarjamo pa se predvsem z visoko
nivojskimi strateškimi vprašanji.
S standardom Archimate 2.0 se je združljivost in podpora z ogrodjem TOGAF še
okrepila. Motivacijska razširitev ogrodja Archimate obravnava predvsem
potrebe v zgodnjih TOGAF fazah, implementacijska in migracijska razširitev pa
obravnava potrebe predvsem v kasnejših fazah cikla TOGAF ADM.
Vidiki v ogrodju Archimate, ki se ukvarjajo z relacijami med arhitekturnimi
plastmi (npr. vidik uporabe produkta in aplikacije), je težko preslikati v
strukturo TOGAF, kjer so pogledi omejeni samo na eno arhitekturno plast.
Čeprav nekaterih TOGAF pogledov ne moremo preprosto preslikati v Archimate
vidike in obratno, je med njima še vedno veliko povezav, ki omogočajo dobro
sodelovanje. Velikokrat pa se ukvarjata z enakimi stvarmi, pa čeprav sta si
različna v pristopu in obsegu delovanja [5].
4.2. ZACHMANOVO OGRODJE
Zachmanovo ogrodje je eno izmed ogrodij za gradnjo poslovno-informacijske
arhitekture, ki omogoča formalen in zelo strukturiran način ogledovanja in
definiranja poslovno-informacijskega sistema. Jedro ogrodja predstavlja matrika
dimenzije 6 x 6, ki identificira 36 pogledov na arhitekturo. Pri tem stolpci
temeljijo na vprašalnicah: Kaj? Zakaj? Kdaj? Kdo? Kje? Kako? Vrstice pa temeljijo
na konkretizaciji in predstavljajo različne zorne kote: identifikacija, opredelitev,
predstavitev, specifikacija, konfiguracija in konkretizacija (vidno na sliki 40)
[18].
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
74
Slika 40: Zachmanovo ogrodje- perspektive in abstrakcije [19]
Zachmanovo ogrodje je najstarejše in med najbolj razširjenimi ogrodji poslovno-
informacijskih arhitektur. Ogrodje je leta 1987 pri IBM-u razvil John Zachman.
Od svojega začetka pa do danes je bilo ogrodje večkrat posodobljeno, trenutno
pa je aktualna verzija 3.0 [20].
Zachmanovo ogrodje ni metodologija in zato ne opisuje posebne metode ali
postopka za zbiranje, upravljanje ali uporabo podatkov [18].
Zachmanovo ogrodje je shema, ki omogoča klasifikacijo artefaktov poslovno-
informacijskih arhitektur (z drugimi besedami oblikovanje dokumentov,
specifikacij in modelov) in opisuje različne poglede deležnikov na poslovni
sistem v skladu z njihovimi interesi [21].
Lahko bi rekli, da je matrika predloga, katero je potrebno izpolniti s cilji/pravili,
postopki, materiali, vlogami, lokacijami in dogodki, ki jih zahteva organizacija.
Dodatno modeliranje s preslikavo med stolpci v matriki pa identificira in določa
vrzeli v dokumentiranem stanju te organizacije [18].
Pregled sorodnih arhitekturnih pristopov
75
Slika 41: Koncept Zachmanovega ogrodja [19]
Okvir je preprost (glej sliko 41) in vsebuje logično strukturo za razvrščanje in
organiziranje opisne predstavitve podjetja. To je pomembno tako za vodstvo
podjetja, kot tudi za vse druge akterje, ki sodelujejo pri delovanju in razvijanju
poslovno-informacijskega sistema [2].
Čeprav prioriteta oz. vrstni red med stolpci ni pomembna, ima vrstni red vrstic
ključno vlogo pri pozicioniranju poslovnih konceptov in dejanske organizacije.
Raven podrobnosti v ogrodju pa je odvisna od vsake celice (in ne vrstice).
Nekaj podobnosti in povezav lahko najdemo tudi med pristopom Archimate in
Zachmann. Ujemanje strukture jezika Archimate s celicami ogrodja Zachman je
vidno na sliki 42.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
76
Slika 42: Zachmanovo ogrodje in ogrodje Archimate [22]
Zachmanovo ogrodje je torej grafična predstavitev medsebojne povezanosti
različnih modelov poslovno-informacijske arhitekture in predstavlja različne
poglede deležnikov na poslovni sistem v skladu z njihovimi interesi.
Prednosti, ki sem jih zasledil so predvsem: razumljivost, predstavitev poslovno-
informacijskega sistema kot celoto, neodvisnost od orodij in metodologij.
Slabosti, ki jih nekateri navajajo pa so: veliko število celic in slaba definiranost
medsebojnih povezav med celicami [2].
Študija primera uporabe jezika Archimate
77
5. ŠTUDIJA PRIMERA UPORABE
JEZIKA ARCHIMATE
V tem poglavju bomo opisali empirični del diplomskega dela, kjer smo na
primeru Študentskih domov Univerze v Mariboru izdelali študijo primera
uporabe jezika Archimate. Namen tega poglavja je, da na konkretnem primeru
prikažemo modeliranje s jezikom Archimate ter pomen različnih vidikov. Najprej
smo predstavili izbrano področje delovanja Študentskih domov ter identificirali
glavne akterje, vloge, funkcije in poslovne procese izbranega področja.
Identificirali smo tudi glavne aplikacijske ter tehnološke elemente, ki
zagotavljajo nemoteno delovanje poslovnega sistema. Na podlagi pridobljenih
kvalitativni ter kvantitativnih podatkov, smo zmodelirali arhitekturo poslovno-
informacijskega sistema Študentskih domov tako, da smo dovolj podrobno
prikazali praktično uporabo jezika Archimate ter različne vidike, ki jih jezik
Archimate predpisuje. Kot zaključek študije primera, smo preverili, ali je
arhitektura zmodelirana v jeziku Archimate primerna za izbran primer, ter
pregledali časovno zahtevnost modeliranja PIA.
Študijo primera in prikaz modeliranja arhitekture poslovnega sistema smo
vsebinsko razdelili na 6 korakov:
postavitev ciljev in definiranje pričakovanih izboljšav;
izbira pristopa za modeliranje PIA;
izbira programskega orodja, s katerim bomo modelirali;
izbiranje informacij o poslovnem sistemu Študentskih domov;
identificiranje elementov arhitekture;
modeliranje arhitekture poslovnega sistema.
Izvedbo posameznega koraka smo sproti opisovali, hkrati pa smo merili tudi čas,
ki smo ga za posamezni korak porabili. Z merjenjem časa smo dobili okvirno
informacijo o časovni zahtevnosti posameznega koraka ob gradnji arhitekture.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
78
5.1. METODA DELA
Za izvedbo študije primera (case study) uporabe jezika Archimate v domeni
Študentskih domov, smo najprej pridobili potrebne podatke in informacije o
izbranem delu poslovnega sistema. Na podlagi pridobljeni podatkov in
informacij smo se odločili katere dele poslovnega sistema Študentskih domov
bomo modelirali.
Za študijo primera smo uporabili naslednje metode dela:
pregled elektronskih virov
(www.studentskidomovi.uni-mb.si, www.uni-mb.si);
pregled internih pravilnikov in dokumentov Študentskih domov Univerze v
Mariboru (domski red, pravilnik o preselitvi…);
intervjuji z vodji posameznih oddelkov;
modeliranje z izbranim programskim orodjem;
5.2. OMEJITVE
V empiričnem delu diplomske naloge smo se omejili samo na nekatere dele
arhitekture poslovnega sistema Študentskih domov. S študijo primera smo želeli
prikazati praktično uporabo jezika Archimate, zato smo izbrali predvsem tiste
dele arhitekture, za katere smo pridobili dovolj informacij. Namenoma smo
izpustili tudi nekatere ponavljajoče se dele arhitekture.
5.3. PREDSTAVITEV PROBLEMA IN PRISTOP K REŠITVI
Študentski domovi Univerze v Mariboru nudijo 2975-im študentom Univerze v
Mariboru bivanje v času študija. Študentski domovi se organizacijsko delijo na
naselja (t.i. študentski kampusi), kjer za interakcijo s študenti skrbijo referati za
študentske zadeve, uprava Študentskih domov pa nudi administrativno podporo.
Zaradi številnih raznolikih oddelkov ter potrebe po zagotavljanju številnih
funkcij (vselitve, preselitve izselitve, vzdrževalna dela, popravila, idr.) lahko
poslovni sistem Študentskih domov označimo za dokaj kompleksnega. Pogledi
na posamezne dele poslovnega sistema ter komunikacija med različnimi
deležniki je otežena. Nekatere sistemske komponente so specifične, procesi, ki bi
Študija primera uporabe jezika Archimate
79
te sistemske komponente podpirali, pa niso jasno predstavljeni. Posledično se že
pojavljajo težave pri uporabi kupljenih IT rešitev, saj te rešitve ne izpolnjujejo
zahtev uporabnikov.
ZA ŠTUDIJO PRIMERA SMO SI POSTAVILI NASLEDNJA CILJA:
identificirati osnovne elemente poslovnega sistema
zmodelirati osnovno oz. izhodiščno arhitekturo izbranih delov poslovnega
sistema in tako prikazati uporabo modelirnega jezika Archimate
Osredotočali smo se na naslednje dele poslovnega sistema:
pisarna za študentske zadeve postopek podaljšanje bivanja
računovodstvo proces izstavitve plačilnih nalogov
tehnična služba vzdrževanje in popravila
5.4. MODELIRANJE POSLOVNO-INFORMACIJSKE
ARHITEKTURE ŠTUDENTSKIH DOMOV
IZBIRA PRISTOPA ZA MODELIRANJE PIA:
Za študijo primera smo izbrali pristop Archimate, ki nudi celovit integriran
pristop za izgradnjo, predstavitev in vzdrževanje arhitekture poslovnih
sistemov. Z jezikom Archimate smo prikazali odvisnosti med različnimi
arhitekturnimi domenami, ki navadno obstajajo v poslovnih sistemih.
IZBIRA PROGRAMSKEGA ORODJA S KATERIM BOMO MODELIRALI PIA:
V poglavju 3.4 smo naredili pregled najbolj razširjenih in priljubljenih
programskih orodij, ki podpirajo jezik Archimate. Na podlagi SWOT analize smo
se odločili za programsko orodje BiZZdesign Architect 3.3.0.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
80
ZBIRANJE INFORMACIJ O POSLOVNEM SISTEMU ŠTUDENTSKIH DOMOV:
Osnovne podatke in informacije o poslovnem sistemu Študentskih domov smo
zbirali s pregledovanjem uradne spletne strani Študentskih domov [23], spletne
strani stanovalcev Študentskih domov [24] ter spletne strani Univerze v
Mariboru [25]. S pridobljenimi informacijami smo identificirali osnovne funkcije
poslovnega sistema Študentskih domov ter se na osnovi teh informacij pripravili
na intervju z vodji posameznih oddelkov.
Podatke o sodelovanju poslovnega sistema s študenti smo pridobili tudi iz
internih pravilnikov in dokumentov Študentskih domov Univerze v Mariboru
(pravilnik o domskem redu [26], pravilnik o subvencioniranju bivanja
študentov [27], razpis za sprejem in podaljšanje bivanja študentov [28]).
Največ uporabnih informacij in podatkov o poslovnem sistemu Študentskih
domov smo pridobili s strani vodij posameznih oddelkov Študentskih domov. Na
podlagi intervjujev z vodjo službe za študentske zadeve, oddelka za
računovodstvo, pisarne za študentske domove, blagajne), referata za študentske
zadeve ter z direktorico Študentskih domov, smo pridobili podatke o osnovnih
funkcijah, procesih, akterjih, vlogah in storitvah, ki so del njihovega poslovnega
sistema. Skupaj smo identificirali tudi aplikacijske in tehnološke elemente
poslovnega sistema ter preučili relacije med njimi.
IDENTIFICIRANJE ELEMENTOV ARHITEKTURE:
Poslovni sistem Študentskih domov združuje številne procese, ki definirajo
funkcije poslovnega sistema. Za praktični prikaz uporabe jezika Archimate smo
se omejili le na izbrane dele poslovnega sistema. Najprej bomo navedli primerke
elementov, ki smo jih identificirali skozi proces pridobivanja informacij in
priprave na modeliranje. V tabeli 7 navajamo poslovne akterje in poslovne
vloge, ki jih ti akterji zasedajo, v tabeli 8 pa navajamo še ostale elemente
poslovnega nivoja. Primerki identificiranih elementov aplikacijskega nivoja so
prikazani v tabeli 9, primerki tehnološkega nivoja pa so prikazani v tabeli 10.
Študija primera uporabe jezika Archimate
81
Tabela 7: Primerki identificiranih poslovnih akterjev in poslovnih vlog na obravnavanem delu poslovnega sistema
Tabela 8: Primerki identificiranih elementov poslovnega nivoja na obravnavanem delu
poslovnega sistema
ELEMENTI POSLOVNEGA
NIVOJA PRIMERKI ELEMENTOV POSLOVNEGA NIVOJA
Poslovni procesi
Podaljšanje bivanja
Prošnja za podaljšanje bivanja
Sprejemanje prošenj
Pridobivanje dokazil
Pregled prošenj
Obravnavanje prošenj in pritožb
Pisanje pritožbe
Pošiljanje odgovora prosilcu
Podpis aneksa k nastanitveni pogodbi
Izselitev iz študentskega doma
Prijava okvare
Vodenje evidence okvar
PRIMERKI AKTERJEV (elementi poslovnega nivoja)
PRIMERKI VLOG (elementi poslovnega nivoja)
Vodstvo študentskih
domov
Direktorica študentskih domov
Pomočnik direktorice
Pisarna za študentske
domove
Vodja pisarne za študentske domove
Komisija za obravnavo prejetih prošenj
Služba za študentske
zadeve Vodja službe za študentske zadeve
Računovodstvo Računovodja
Blagajnik
Referat za študentske
zadeve
Referent za študentske zadeve
Gospodinja
Tehniška služba
Vodja tehniške službe
Vzdrževalec
Serviser
Upravitelj garaže
Pralnica
Receptor
Študent
Član študentskega sveta
Novo vseljen študent
Preseljen študent
Izseljen študent
Prosilec za podaljšanje bivanja
Prijavitelj okvare
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
82
Pregled prijavljenih okvar
Naročilo rezervnih delov
Popravilo okvare
Prevzem blagajne
Poslovne funkcije
Bivanje v času študija
Finančno poslovanje
Vzdrževanje
Administrativna podpora
Odnosi s stanovalci
Poslovni objekti
Obrazci in navodila za izplačila
Tedenski razpored dela
Razpisna dokumentacija za podaljšanje bivanja
Podatki o študentu
Račun
Poslovno sodelovanje Komisija za sprejem
Disciplinska komisija
Poslovni vmesnik
Navadna pošta
Elektronska pošta
Telefon
Spletna stran
Poslovni dogodek
Objava razpisa za podaljšanje bivanja
Zaključen rok za oddajo prošenj za podaljšanje
bivanja
Tehnična okvara
Poslovna interakcija
Disciplinska izselitev
Odobritev bivanja v Študentskih domovih
Odobritev podaljšanja bivanja v Študentskih
domovih
Poslovni produkt Nastanitev
Poslovna storitev
Bivanje v študentskih domovih
Podaljševanje bivanja
Popravila tehničnih okvar
Izstavljanje računov za stanarine
Vrednost Biti vseljen v Študentski dom
Pomen Navodila za izpolnjevanje obrazca
Predstavitev
Elektronski obrazec
Fizično potrdilo (na papirju)
Vnos v bazi
Prošnja (na papirju)
Pogodba Pogodba o nastanitvi
Lokacija Referat Lent
Uprava Študentskih domov
Študija primera uporabe jezika Archimate
83
Tabela 9: Primerki identificiranih elementov aplikacijskega nivoja na obravnavanem delu
poslovnega sistema
ELEMENTI
APLIKACIJSKEGA NIVOJA PRIMERKI ELEMENTOV APLIKACIJSKEGA NIVOJA
Aplikacijska
komponenta
Aplikacija za finance
Računovodska komponenta
Komponenta za obračun storitev
Aplikacijsko
sodelovanje Administriranje transakcij
Aplikacijski vmesnik Vmesnik za izmenjavo podatkov o transakciji
Aplikacijska storitev
Zaračunavanje
Računovodstvo
Obdelava transakcij
Kreiranje plačilnega naloga
Izpis statusa plačila
Pošiljanje plačilnega naloga
Aplikacijska funkcija
Administracija financ
Vodenje računov
Zaračunavanje storitev
Aplikacijska interakcija Administracija transakcij
Podatkovni objekt Podatki o transakciji
Tabela 10: Primerki identificiranih elementov tehnološkega nivoja na obravnavanem delu
poslovnega sistema
ELEMENTI
TEHNOLOŠKEGA NIVOJA PRIMERKI ELEMENTOV TEHNOLOŠKEGA NIVOJA
Artefakt Del kode
Omrežje LAN
Infrastrukturna storitev Dostop do podatkov
Upravljanje podatkov
Infrastrukturna funkcija Zagotavljanje dostopa do podatkov
Upravljanje podatkov
Vozlišče Aplikacijski strežnik
Podatkovni strežnik
Sistemska programska
oprema
Microsoft Windows
CRM
Naprava
Spletni strežnik
Strežnik referata
Strežnik uprave
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
84
MODELIRANJE ARHITEKTURE POSLOVNEGA SISTEMA:
Skladno s standardom Archimate 2.0 prikazujemo nekatere izmed osnovnih
vidikov arhitekture poslovnega sistema Študentskih domov.
Na sliki 43 je prikazan vidik organizacijske strukture Komisije za sprejem v
Študentske domove. Zraven akterjev in njihovih vlog, je vidno tudi poslovno
sodelovanje teh vlog znotraj komisije, ki običajno zaseda v sejni sobi.
Slika 43: Primer organizacijskega vidika
S primerom vidika poslovnih funkcij (glej slika 44) prikazujemo glavne funkcije
tehnične službe in referata za študentske zadeve ter njihove relacije (pretok
informacij, vrednosti). Poslovne funkcije uporabljamo tudi za predstavitev
najstabilnejših vidikov družbe glede na primarne dejavnosti, ki jih opravlja in
neodvisno od organizacijskih sprememb in tehnološkega razvoja. Vidik
poslovnih funkcij omogoča vpogled v splošno poslovanje izbranih oddelkov,
uporabljamo pa ga lahko tudi za identifikacijo potrebnih kompetenc ter za
zmanjševanje kompleksnosti.
Študija primera uporabe jezika Archimate
85
Slika 44: Primer vidika poslovnih funkcij
S primerom vidika produktov (glej slika 45) prikazujemo proizvod
nastanitev, ki ga Študentski domovi nudijo študentom. Vidne so relacije
elementov, ki omogočajo nastanitev, to so številne storitve, pogodba ter
vrednost, ki jo nastanitev predstavlja študentu. Proizvodni vidik se navadno
uporablja v proizvodni fazi produkta. Služi lahko kot začetna informacija za
arhitekta poslovnega procesa ali drugih, ki jo potrebujejo za oblikovanje
procesov.
Slika 45: Primer vidika poslovnih produktov
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
86
Na primeru delovanja referata za študentske zadeve smo sestavili vidik
poslovnih procesov, ki tečejo znotraj poslovnega sistema referata. Slika 46
prikazuje kompozicijo več poslovnih procesov ter odgovornost posameznih vlog,
ki te procese upravljajo.
Slika 46: Primer vidika poslovnih procesov
Študija primera uporabe jezika Archimate
87
Z vidikom uporabe aplikacije (glej sliko 47) smo prikazali, kako aplikacija za
finance FIPS, katero uporabljajo na oddelku za računovodstvo, nudi podporo
poslovnemu procesu plačevanja stanarin. Vidik tudi identificira storitev, ki jo
uporablja poslovni proces, zato bi ga lahko ob bolj podrobni predstavitvi
uporabljali tudi za oblikovanje aplikacije za finance. Ker vidik opisuje odvisnost
poslovnega procesa od aplikacij, je lahko ta vidik tudi zelo uporaben vodji
računovodstva, ki je odgovoren za poslovne procese.
Slika 47: Primer vidika uporabe aplikacij
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
88
Vidik obnašanja aplikacije za finance opisuje notranje obnašanje te aplikacije,
medtem ko izvaja storitev pošiljanje plačilnega naloga (glej sliko 48).
Slika 48: Primer vidika obnašanja aplikacij
Z vidikom sodelovanja aplikacije za finance (slika 49) opisujemo odnose med
njenima komponentama in aplikacijskim vmesnikom. Komponenta za
vodenje računov in komponenta za obračun storitev , skupaj sodelujeta pri
administraciji transakcij ter tvorita interakcijo Administracija transakcij.
Slika 49: Primer vidika sodelovanja aplikacij
Študija primera uporabe jezika Archimate
89
Z osnovnim primerom infrastrukturnega vidika (slika 50) prikazujemo
umeščenost infrastrukturnih elementov programske in strojne opreme, ki
podpirajo delovanje poslovnega sistema na aplikacijskem nivoju. S primerom
prikazujemo proces vseljevanja in podaljšanja bivanja študentov, kjer referenti
dostopajo in posodabljajo podatke študentov. Podatkovni strežnik nudi funkcijo
upravljanja in zagotavljanja dostopa do podatkov. Naprave so med seboj
povezane z omrežjem LAN ter uporabljajo operacijski sistem Microsoft
Windows.
Slika 50: Primer vidika infrastrukture
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
90
5.5. REZULTATI ŠTUDIJE PRIMERA
Za izvedbo študije primera smo izbrali modelirno orodje BiZZdesign Architect
3.3.0, ki v celoti podpira jezik Archimate, dodatno pa omogoča še številne
funkcionalnosti, ki olajšajo gradnjo arhitekture. Orodje ima vgrajene tudi
številne mehanizme, ki preverjajo sintaktično pravilnost ter odpravljajo
morebitne napake. Orodje se je izkazalo za zelo priročno, enostavno in dovolj
prilagodljivo lastnim željam. Za podrobno seznanitev z orodjem (dokumentacija,
vodič, testni primeri) smo porabili približno 8 ur.
Zelo pomemben del študije primera ter gradnje PIA na splošno, je dobro
poznavanje celotnega poslovnega sistema, poslovnih procesov, funkcij, vlog, itn.
Poznavanje obravnavanega poslovnega sistema je ključno za arhitekta, ki razvija
PIA. Skozi zbiranje informacij in spoznavanjem izbranih delov poslovnega
sistema, smo pridobili veliko količino podatkov, katerih pa brez pravilnega
razumevanja ne znamo povezati in jih vpeti v arhitekturo. Za nedvoumno
razumevanje smo z zaposlenimi številne procese najprej narisali. V tej fazi smo
odkrili tudi številne pomanjkljivosti, ki so se kasneje pokazale tudi v sami
arhitekturi. Za podrobno seznanitev z izbranimi deli poslovnega sistema
(pisarna za študentske zadeve, računovodstvo, tehnična služba) ter za pregled
dokumentacije in pravilnikov, smo potrebovali približno 15 ur.
Zaradi dobrega poznavanja obravnavanega poslovnega sistema nismo zasledili
večji težav pri samem modeliranju. V orodju Architect smo najprej modelirali
poslovni nivo, nato smo elemente tega nivoja povezali v posamezne vidike
poslovnega nivoja. Podobno smo naredili pri aplikacijskem in tehnološkem
nivoju. Nekaj več pozornosti smo morali posvetiti povezovanju elementov
različnih nivojev. Za modeliranje izbranih delov poslovnega sistema smo
porabili približno 9 ur.
Študija primera uporabe jezika Archimate
91
Ob gradnji delne arhitekture smo merili čas, ki smo ga porabili pri posameznem
koraku, zato bomo zraven vmesnih rezultatov študije primera (izdelani vidiki
obravnavane arhitekture), podali tudi subjektivno oceno časovne zahtevnosti
gradnje arhitekture. Rezultat podajamo v odstotkih (glej slika 51) glede na
časovno zahtevnost posameznega zastavljenega koraka.
Slika 51: Časovna zahtevnost razvoja izbranih delov arhitekture ŠD
Delež porabljenega časa pri razvoju obravnavane arhitekture ŠD
Postavitev ciljev
Izbira PIA pristopa
Izbira in spoznavanjeprogramskega orodja
Zbiranje informacij inidentificiranje elementov PIA
Modeliranje PIA
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
92
Pregled sorodnih arhitekturnih pristopov
93
6. ZAKLJUČEK
V zaključku bomo predstavili rezultate diplomskega dela. Najprej bomo testirali
hipoteze in komentirali njihove rezultate, nato pa bomo z njihovo pomočjo
opisali omejitve diplomskega dela. Na koncu bomo podali še možnosti za
nadaljnje delo in raziskavo ter sklepne misli.
6.1. TESTIRANJE HIPOTEZ
Hipoteze, ki smo jih postavili na začetku diplomskega dela, bomo ob zaključku
testirali ter jih na podlagi subjektivne presoje potrdili ali ovrgli. Tabela 11
prikazuje seznam prvotno zastavljenih hipotez iz poglavja 1.2 s končnimi
rezultati, ki so tudi ustrezno komentirani.
Tabela 11: Testiranje hipotez
HIPOTEZA REZULTAT KOMENTAR
H1 potrjena Na podlagi pregleda področja PIA, lahko potrdimo, da PIA
zagotavlja učinkovitejše delovanje IT, boljšo donosnost
obstoječih naložb in zmanjšanje tveganja za bodoče naložbe ter
hitrejše, enostavnejše in cenejše naročanje storitev.
H2 nismo ovrgli Pri obravnavi jezika Archimate s sorodnimi arhitekturnimi
pristopi smo sicer našli številne podobnosti, vendar bi bila
potrebna podrobna analiza, da bi lahko z gotovostjo to hipotezo
potrdili.
H3 ovržena Z nekaterimi splošno namenskimi programskimi orodji je sicer
omogočeno modeliranje PIA, vendar zaradi zahtev po različnih
vizualizacijah posameznih delov arhitekture, prikazovanja
njenih kompleksnih soodvisnosti ter vzdrževanja arhitekture,
splošno namenska orodja niso primerna.
H4 nismo ovrgli S sprejetjem standarda Archimate pod okrilje dobro poznane in
uveljavljene organizacije The Open Group, je jezik veliko
pridobil na prepoznavnosti. Vseeno pa iz podatkov, ki so nam
bili na voljo, ne moremo z gotovostjo potrditi splošne
prepoznavnosti jezika Archimate.
H5 potrjena S študijo primera smo prikazali modeliranje arhitekture
izbranih delov poslovnega sistema Študentskih domov z
jezikom Archimate ter tako potrdili začetno hipotezo.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
94
6.2. OMEJITVE
Ob predstavitvi modelirnega jezika Archimate smo se pri opisu vidikov, ki jih le-
ta navaja, omejili predvsem na najosnovnejše vidike ter tiste, ki smo jih
uporabili v študiji primera. Archimate sicer navaja 27 osnovnih vidikov, ki so
razviti na podlagi praktičnih izkušenj. Pri pregledu priljubljenosti in razširjenosti
jezika Archimate nismo zasledili praktično nobenih konkretnih kvantitativnih
podatkov o uporabi in tržnem deležu jezika Archimate, zato smo se omejili na
najdene informacije ter podatke, ki smo jih preko elektronske pošte pridobili s
strani organizacije The Open Group.
Pri predstavitvi sorodnih pristopov modeliranja arhitektur smo se omejili na
tiste, ki so v gospodarstvu najbolj razširjeni in priljubljeni. Prav tako smo se pri
pregledu programskih orodij, ki podpirajo jezik Archimate, omejili na najbolj
razširjene in priljubljene programske rešitve.
Pri študiji primera smo se prav tako omejili na razpoložljive podatke in
informacije, hkrati pa smo želeli prikazati praktično uporabo modelirnega jezika
Archimate, zato nismo poskušali z modeliranjem celotnega poslovnega sistema,
temveč samo z nekaterimi njegovimi deli.
6.3. MOŽNOSTI ZA NADALJNJE DELO
V diplomskem delu smo celostno predstavili jezik Archimate. Raziskovanje bi
lahko razširili še na praktično analizo arhitektur, ki so zgrajene s pristopom
Archimate, kjer bi lahko analizirali njegov vpliv na poslovanje organizacije ipd.
Na trgu najdemo tudi številne sorodne rešitve, zato bi lahko raziskovalno delo
nadaljevali tudi v smeri podrobne primerjave med njimi.
Največ možnosti za nadaljnje delo pa je pri praktičnem modeliranju poslovno-
informacijskih arhitektur, kjer so pomembne predvsem izkušnje. Izdelali bi
lahko še celostno izhodiščno arhitekturo poslovnega sistema Študentskih
domov. Nato bi identificirali slabosti in pomanjkljivosti poslovnega sistema, jih
odpravili ter nadgradili izhodiščno arhitekturo s popravki. S spremljanjem
učinkov, ki jih ima arhitektura na poslovanje, bi pridobili kar nekaj povratnih
informacij, predvsem o pozitivnih vplivih arhitekture na poslovni sistem.
Zaključek
95
6.4. SKLEP
Hitro spreminjajoče se okolje in močna konkurenca, silita podjetja v nenehna
vlaganja v informacijsko tehnologijo in spreminjanje poslovnih procesov. Da
podjetje lahko sledi spremembam, se mora stalno prilagajati. Podjetja se vedno
bolj zavedajo, da je učinkovito upravljanje in izkoriščanje informacij s pomočjo
IT, ključ do uspeha in nepogrešljivo sredstvo za doseganje konkurenčne
prednosti. Arhitektura v poslovnem sistemu jim tako zagotavlja strateški okvir
za razvoj informacijskega sistema, kot odziv na nenehno spreminjajoče se
potrebe poslovnega okolja.
V diplomskem delu smo predstavili najnovejši pristop k modeliranju poslovno-
informacijskih arhitektur, jezik Archimate. Potrdimo lahko navedbe, da je jezik
Archimate preprost, razumljiv in enostaven za uporabo. Lahko tudi rečemo, da je
jezik Archimate primeren za celostno modeliranje PIA arhitekture Študentskih
domov, kot tudi vseh drugih organizacij.
Modeliranje, analiza, vizualizacija in vzdrževanje poslovno-informacijske
arhitekture zahtevajo primerno programsko rešitev. Uporaba samo preprostih
diagramskih orodij ni le nepraktična, ampak tudi nezadostna zaradi
kompleksnih soodvisnosti v poslovno-informacijskih arhitekturah. Različni
deležniki zahtevajo različne vizualizacije posameznih delov arhitekture, kar je
skoraj nemogoče modelirati z uporabo splošno namenskih orodij, kot je na
primer Microsoft Visio.
Če posplošimo, je bistvo arhitekture definiranje in opis strukture. Organizacije se
soočajo z vse bolj kompleksnimi strukturnimi težavami, s tem se povečuje tudi
vloga poslovno-informacijskih arhitektov, katerih glavna naloga je reševanje teh
strukturnih težav. Torej reševati, ne rešiti! Z vsakim dnem se vloga PIA
povečuje in s tem tudi vloga modelirnih pristopov, kot je Archimate. Zagotovo
lahko na področju PIA pričakujemo številne izboljšave in novosti, trenutno pa je
ta novost jezik Archimate.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
96
Viri
97
VIRI
[1] A. Šaša and M. Krisper, “Analitski vzorci za poslovno-informacijske arhitekture.”
[Online]. Available: http://www.dlib.si/stream/URN:NBN:SI:DOC-OELOEUTZ/5473c054-
f4ef-4d56-a527-d622f2a127f7/PDF. [Accessed: 20-Feb-2012].
[2] M. Lankhorst, Enterprise architecture at work: modelling, communication, and
analysis. Springer, 2005.
[3] “Conceptual Framework for ISO/IEC 42010:2007 – IEEE 1471:2000.” [Online].
Available: http://www.iso-architecture.org/42010/cm/cm-1471-2000.html. [Accessed: 22-
Feb-2012].
[4] The Open Group, “ArchiMate® 1.0 Specification- Technical Standard.” Van
Haren Publishing, 2009.
[5] The Open Group, “ArchiMate® 2.0 Specification- Technical Standard.” The Open
Group, 2012.
[6] “ArchiMate® | The Open Group.” [Online]. Available:
http://www3.opengroup.org/subjectareas/enterprise/archimate. [Accessed: 23-Feb-2012].
[7] M. Lankhorst, “ArchiMate:_An Emerging Standard in _Enterprise Architecture,”
EAC Orlando, 2006.
[8] “Microsoft Visio 2010 - Office.com.” [Online]. Available:
http://office.microsoft.com/en-us/visio/. [Accessed: 08-Mar-2012].
[9] “OmniGraffle for Mac - Products - The Omni Group.” [Online]. Available:
http://www.omnigroup.com/products/omnigraffle/. [Accessed: 09-Mar-2012].
[10] The Omni Group, “OmniGraffle 5 Professional - Manual.” 2008.
[11] “Archi: Archimate Modelling.” [Online]. Available:
http://archi.cetis.ac.uk/index.html. [Accessed: 09-Mar-2012].
[12] “Architect.” [Online]. Available: http://www.bizzdesign.com/tools/architect.
[Accessed: 12-Mar-2012].
[13] E. Roovers, “ArchiMate is gaining weight | ARIS BPM Community.” .
[14] M. Lankhorst, “Elektronsko pošta,” 16-Feb-2012.
[15] R. Wissing, “Elektronska pošta,” 05-Mar-2012.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
98
[16] “TOGAF® Trademark Success | The Open Group Blog.” .
[17] “TOGAF®.” [Online]. Available: http://www.opengroup.org/togaf/. [Accessed: 26-
Feb-2012].
[18] “Zachman FrameworkTM.” [Online]. Available: http://www.zachman.com/about-
the-zachman-framework. [Accessed: 26-Feb-2012].
[19] IT Architects of Ontario, “Zachman Framework Overview,” 2012.
[20] J. P. Zachman, “The Zachman FrameworkTM Evolution.” [Online]. Available:
http://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution.
[Accessed: 26-Feb-2012].
[21] R. Sessions, “A Comparison of the Top Four Enterprise-Architecture
Methodologies,” 2007. [Online]. Available: http://msdn.microsoft.com/en-
us/library/bb466232.aspx. [Accessed: 26-Feb-2012].
[22] “Zachman Framework Associates.” [Online]. Available:
http://zachmanframeworkassociates.com/. [Accessed: 26-Feb-2012].
[23] “Študentski domovi Univerze v Mariboru - Več kot le dom.” [Online]. Available:
http://www.studentskidomovi.uni-mb.si/. [Accessed: 29-Feb-2012].
[24] “Home | www.stanovalci.net.” [Online]. Available: http://www.stanovalci.net/.
[Accessed: 15-Mar-2012].
[25] “Univerza v Mariboru.” [Online]. Available: http://www.uni-mb.si/. [Accessed: 29-
Feb-2012].
[26] Študentski domovi Univerze v Mariboru, “Pravilnik o domskem redu
stanovalcev Študentskih domov Univerze v Mariboru.” Univerza v Mariboru, 06-Jul-2007.
[27] Ministrstvo za šolstvo, znanost in šport, “Pravilnik o subvencioniranju bivanja
študentov.” Uradni list RS, 06-Apr-2001.
[28] Ministrstvo za šolstvo, znanost in šport, “RAZPIS za sprejem in podaljšanje
bivanja študentov.” Študentski domovi v visokošolskih središčih v Ljubljani, Mariboru,
Kranju in Kopru, 01-Jun-2011.
Priloge
99
PRILOGE
PRILOGA A: KONCEPTI JEZIKA ARCHIMATE [5] KONCEPT OPIS NOTACIJA
Poslovni akter Organizacijska entiteta, ki ima sposobnost izvajanja "obnašanja".
Poslovna vloga Odgovornost za izvajanje določenega obnašanja,
ki ga lahko izvaja akter.
Poslovno sodelovanje
Skupek ene ali več poslovnih vlog, ki delujejo skupaj in izvajajo skupno obnašanje.
Poslovni vmesnik
Dostopna točka, na kateri je poslovni proces na voljo okolju.
Lokacija Konceptualna točka ali stopnja v prostoru.
Poslovni objekt Pasiven element, ki je pomemben iz poslovne
perspektive.
Poslovni proces Element obnašanja, ki združuje obnašanja, ki
temeljijo na razvrščenosti aktivnosti.
Poslovna funkcija
Element obnašanja, ki združuje obnašanja, ki temeljijo na različnih kriterijih (običajno so to potrebna poslovna znanja ali kompetence).
Poslovna interakcija
Element obnašanja, ki opisuje obnašanje poslovnega sodelovanja.
Poslovni dogodek
Nekaj kar se zgodi in vpliva na obnašanje.
Poslovna storitev
Storitev, ki izpolnjuje poslovno potrebo stranke.
Predstavitev Zaznavna oblika informacije, ki jo nosi objekt.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
100
Pomen Znanje ali izkušnje, ki se nahajajo v poslovnem objektu ali v njegovi zaznavni obliki, v določenem kontekstu.
Vrednost Relativna veljava, pripomoček ali pomembnost
poslovne storitve ali produkta.
Produkt Nabor storitev, ki jih spremlja pogodba/skupek dogovorov, ki so kot celota ponujeni strankam.
Pogodba Formalna ali neformalna specifikacija dogovora, ki določa pravice in dolžnosti povezane s produktom.
Aplikacijska komponenta
Modularni, premostljiv in nadomestljiv del programske opreme, ki zajema njegovo obnašanje in podatke ter jih razkriva preko različnih vmesnikov.
Aplikacijsko sodelovanje
Skupek dveh aplikacij ali več, ki delujejo vzajemno in tvorijo sodelovalno obnašanje.
Aplikacijski vmesnik
Dostopna točka, kjer je aplikacijska storitev na voljo uporabniku ali drugi aplikacijski komponenti.
Podatkovni objekt
Pasiven element primeren za avtomatsko procesiranje.
Aplikacijska funkcija
Element obnašanje, ki združuje avtomatska obnašanja, ki jih lahko opravlja katerakoli aplikativna komponenta.
Aplikacijska interakcija
Element obnašanja, ki opisuje obnašanje aplikacijskega obnašanja.
Aplikacijska storitev
Storitev, ki izpostavlja avtomatsko obnašanje.
Vozlišče Računalniški vir na katerem so artefakti
shranjeni ali pripravljeni za izvršitev.
Naprava Strojni vir na katerem so artefakti shranjeni ali
pripravljeni za izvršitev.
Omrežje Komunikacijski medij med dvema ali več
napravami.
Komunikacijska pot
Povezava med dvema ali več voliščema, preko katerih si vozlišča izmenjujejo informacije.
Infrastrukturni vmesnik
Dostopna točka kjer so infrastrukturne storitve, ki jih ponuja vozlišče na voljo ostalim vozliščem in aplikacijskim komponentam.
Priloge
101
Sistemska programska oprema
Okolje programske opreme za specifične komponente in predmete, ki so na njej odloženi v obliki artefaktov.
Infrastrukturna funkcija
Element obnašanja, ki združuje infrastrukturna obnašanja, ki jih lahko izvaja vozlišče.
Infrastrukturna storitev
Zelo vidna enota funkcionalnosti, ki jo izvaja eno ali več vozlišč in je izpostavljena preko zelo definiranih vmesnikov, pomembnih za okolje.
Artefakt fizičen del podatka, ki se uporablja ali pa je
proizveden v procesu razvoja programske opreme ali delovanja sistema.
Deležnik Vloga posameznika, skupine ali organizacije, ki
je zainteresirana oz. ima zadržke do rezultata arhitekture.
Gonilo Nekaj kar ustvarja, motivira ali poganja
spremembo v organizaciji.
Ocena oz. presoja
Rezultat analize določenega gonilnika.
Cilj Končno stanje, ki ga deležnik želi doseči.
Zahteva Potreba, ki jo mora sistem doseči oz. udejanjiti.
Omejitev Ovira na poti po kateri se sistem realizira.
Načelo oz. princip
Normativna lastnost vseh sistemov v določenem kontekstu ali na poti po kateri se realizira.
Delovni paket Serija aktivnosti, ki so ustvarjene za doseganje
unikatnih ciljev znotraj določenega časa.
Rezultat Natančno definiran končen produkt delovnega
paketa.
Plato Relativno stabilno stanje arhitekture, ki obstaja
v določenem času.
Razlika Rezultat med analizama dveh platojev.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
102
PRILOGA B: STRUKTURA ZACHMANOVEGA OGRODJA – PODROBNEJŠI OPIS
Osnovna ideja Zachamnovega ogrodja je, da lahko enako kompleksno stvar ali
predmet, opišemo za različne namene, na različne načine in z različnimi vrstami
opisov (npr. tekstovno, grafično) . Zachmanovo ogrodje zagotavlja 36 kategorij, s
katerimi lahko opišemo karkoli, še posebej zapletene stvari, kot so končni izdelki
(npr. aparati), zgrajeni objekti (npr. stavbe) ali podjetja (torej organizacija, vsi
njeni cilji, zaposleni in tehnologija). Ogrodje določa šest različnih transformacij
abstraktne ideje iz šestih različnih perspektiv, kar omogoča, da različni ljudje
gledajo na isto stvar iz različnih perspektiv. To seveda ustvarja celovit pogled na
okolje, organizacijo in njeno poslovanje [18].
POGLEDI STOLPCEV:
Vsaka vrstica predstavlja skupni pogled na rešitev iz določene perspektive. Višja
vrstica ali perspektiva ne pomeni nujno bolj celovitega razumevanja celote od
nižje vrstice. Vsaka vrstica predstavlja poseben, edinstven pogled. Seveda pa
mora vsaka vrstica zagotavljati dovolj podrobnosti za opredelitev rešitve na
ravni trenutne perspektive in hkrati te podrobnosti explicitno prenašati na nižje
vrstice.
V vsaki vrstici (perspektivi) je potrebno upoštevati zahteve in omejitve drugih
perspektiv. Omejitve vsake perspektive se seštevajo (npr. omejitve višjih vrstic
vplivajo na nižje vrstice). Včasih lahko tudi omejitve nižjih vrstic vplivajo na
perspektive v višjih vrsticah [18].
POGLEDI STOLPCEV:
Napisali smo že, da se lahko iz različnih perspektiv osredotočamo na isto
temeljno vprašanje in nato odgovorimo na neko vprašaje iz določene
perspektive. S tem ustvarjamo različne opisne predstavitve (npr. modele), ki se
prevajajo iz višjih v nižje perspektive. Osnovni model, na katerega smo
osredotočeni (abstrakcija), pa ostaja nespremenjen. Osnovni model vsakega
stolpca je enolično določen, vendar še vedno povezan navzdol po matrici [18].
Priloge
103
V Zachmanovem ogrodju se v stolpcih predstavljajo naslednji osnovni modeli:
1. Opis podatkov – KAJ?
2. Opis funkcij – KAKO?
3. Opis lokacij – KJE?
4. Opis ljudi – KDO?
5. Opis časa – KDAJ?
6. Opis prihodnosti – ZAKAJ?
Pri Zachmanu pravijo, da je njihovo ogrodje edinstveno predvsem zato, ker se
vsak element na obeh oseh matrike razlikuje od vseh drugih elementov na tej
osi. Vsebina posameznih celic matrike ni zgolj zaporedno večanje podrobnosti,
ampak so dejansko drugačne predstavitve. Torej drugačne v kontekstu, pomenu,
motivaciji in uporabi. Ker so elementi na obeh oseh drugačni drug od drugega, je
mogoče natančno opredeliti, kaj spada v katero celico.
PRAVILA ZACHMANOVEGA OGRODJA:
Sicer smo že našteli nekaj lastnosti, ki jih imajo posamezne vrstice, stolpci in
celice. Za lažje delo in razumevanje, pa ogrodje narekuje tudi nekaj pravil in
usmeritev [18]:
Pravilo 1: Pri stolpcih ni pomemben vrstni red. Stolpci so zamenljivi, vendar jih
ni mogoče zmanjšati ali povečati.
Pravilo 2: Vsak stolpec ima preprost generični model. Vsak stolpec ima lahko
tudi svoj lasten meta-model.
Pravilo 3: Osnovni model vsakega stolpca mora bi edinstven. Prav tako morajo
biti edinstvene relacije med objekti in struktura.
Pravilo 4: Vsaka vrstica opisuje poseben, edinstven pogled. Vsaka vrstica
opisuje pogled posamezne poslovne skupine
Pravilo 5: Vsaka celica je unikatna. Kombinacije pravil 2, 3 in 4 morajo določati
unikatne celice, kjer vsaka celica predstavlja poseben primer.
Pravilo 6: Integracija oz. sestavljanje vseh celic neke vrstice predstavlja celostni
model glede iz vidika na to vrstico.
Pravilo 7: Logika je rekurzivna. Logika je relacijska med dvema instancama iste
entitete.
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
104
PRILOGA C: PRIMER ORGANIZACIJSKEGA VIDIKA
Priloge
105
PRILOGA D: DEL VIDIKA POSLOVNEGA NIVOJA RAČUNOVODSTVA
Modeliranje arhitekture poslovnih sistemov z jezikom Archimate
106
PRILOGA E: DEL VIDIKA POSLOVNEGA PROCESA PRIJAVE OKVAR