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

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ž.

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.

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.

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.

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


Tabela 9: Primerki identificiranih elementov aplikacijskega nivoja na obravnavanem delu


Tabela 10: Primerki identificiranih elementov tehnološkega nivoja na obravnavanem delu


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

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.


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.


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]


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.


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«


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]


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.


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]


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.


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].


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].


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.


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.


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.


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].


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


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


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]


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.


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].


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]


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.


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].


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].


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


64

Tabela 3: SWOT analiza - OmniGraffle in Archimate šablona

PREDNOSTI

Več modelirnih kategorij v enem

orodju.

Pri modeliranju ne postavlja

nobenih omejitev.


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.



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


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



funkcionalnosti.


arhitekturnimi pristopi.

NEVARNOSTI

Ukinjena podpora s strani JISC.


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


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



funkcionalnosti.

NEVARNOSTI

Ukinjena podpora s strani

BiZZdesign.

Konkurenčno cenejše programje.


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


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.


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]


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].


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].


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.


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.


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


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.


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.


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


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


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


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.


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


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


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


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


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


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.


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


92


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.


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.


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.


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.


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.


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.


104

PRILOGA C: PRIMER ORGANIZACIJSKEGA VIDIKA

Priloge

105

PRILOGA D: DEL VIDIKA POSLOVNEGA NIVOJA RAČUNOVODSTVA


106

PRILOGA E: DEL VIDIKA POSLOVNEGA PROCESA PRIJAVE OKVAR

modeliranje arhitekture poslovnih sistemov z ...omnigraffle, togaf, zachman framework, case study...

Documents