Navodila za pisanje diplomskih nalog UM FERI · 2017-11-28 · Primerjava SOA zrelostnih modelov...

Primerjava SOA zrelostnih modelov

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Matej Nosan

Primerjava zrelostnih modelov vpeljave storitvene arhitekture

Diplomsko delo

Maribor, april 2016


Primerjava zrelostnih modelov vpeljave

storitvene arhitekture

Diplomsko delo

Študent(ka): Matej Nosan

Študijski program: Visoko strokovni

Računalništvo

Smer: Programska oprema

Mentor(ica): red. prof. dr. Peter Kokol

Somentor(ica): red. prof. dr. Marjan Heričko, univ. dipl. inž.

Lektor(ica): Maja Vačun, prof. slo in fil

Maribor, april 2016

ZAHVALA

Zahvaljujem se mentorjema, red. prof. dr. Petru Kokolu in

red. prof. dr. Marjanu Heričku, za pomoč in vodenje pri

opravljanju diplomskega dela.

Zahvala gre mojim staršem in družini, ki mi stojijo ob

strani.

Posebna zahvala tudi trenutnemu delodajalcu, podjetju

Informatika d.d., ki mi je omogočilo zaključek študija.


II

PRIMERJAVA ZRELOSTNIH MODELOV

VPELJAVE STORITVENE ARHITEKTURE

Ključne besede: storitvena arhitektura, informacijski sistemi, zrelostni modeli, principi

načrtovanja

UDK: 004.2:004.72(043.2)

Povzetek

V diplomskem delu smo predstavili osnovne principe in pridobitve vpeljave storitvene

arhitekture ter raziskali koncept zrelostnega modela. Na podlagi pridobljenih znanj smo

izbrali in opisali pet največkrat omenjenih modelov zrelosti storitvene arhitekture.

Zrelostne modele smo medsebojno primerjali po predstavljenih nivojih, obsegu in namenu.

V zaključku naloge je predstavljen eden od poenostavljenih načinov ocene zrelosti vpeljave

storitvene arhitekture na primeru konkretne informacijske rešitve.


III

A COMPARISON OF SOA MATURITY MODELS

Key words: service oriented architecture, information systems, maturity model, design

principles

UDK: 004.2:004.72(043.2)

Abstract

In this diploma work the basic principles and achievements of introducing service-oriented

architecture are presented and the concept of maturity model is researched. Five most

recognized maturity models were selected and we made a comparison of maturity models

according to presented levels, dimensions and purposes. At the end of this work we

presented a simplified approach to assessing SOA maturity.


IV

KAZALO

1 UVOD ......................................................................................................................................... I

2 PRINCIPI NAČRTOVANJA STORITVENE ARHITEKTURE ....................................... III

2.1 Storitev ......................................................................................................................................... III

2.2 Storitvena paradigma .................................................................................................................... IV

2.3 Načela SOA .................................................................................................................................... IV

2.3.1 Standardizirane storitvene pogodbe .............................................................................................. IV

2.3.2 Šibka sklopljenost............................................................................................................................. V

2.3.3 Abstrakcija storitve ......................................................................................................................... VI

2.3.4 Ponovna uporaba ............................................................................................................................ VI

2.3.5 Avtonomija ..................................................................................................................................... VII

2.3.6 Storitve brez stanja ........................................................................................................................ VII

2.3.7 Možnost odkrivanja storitev .......................................................................................................... VII

2.3.8 Kompozicija storitev ....................................................................................................................... VII

2.3.9 Storitvena arhitektura in interoperabilnost ................................................................................... VII

2.4 Cilji in pridobitve SOA ................................................................................................................... IX

2.4.1 Povečana notranja interoperabilnost ............................................................................................. IX

2.4.2 Povezanost uporabe IT rešitev ......................................................................................................... X

2.4.3 Raznovrstnost programske opreme ................................................................................................ XI

2.4.4 Usklajevanje poslovanja s tehnološkimi rešitvami ......................................................................... XII

2.4.5 Povečana donosnost naložb ......................................................................................................... XIII

2.4.6 Večja dovzetnost za spremembe .................................................................................................. XIII

2.4.7 Zmanjšana obremenitev oddelkov za informatiko ....................................................................... XIV

2.5 Uvajanje storitvene arhitekture ................................................................................................... XV

2.6 Združena storitvena arhitektura .................................................................................................XVII

2.7 Ogrodje storitvene arhitekture..................................................................................................XVIII

3 OSNOVE ZRELOSTNIH MODELOV .............................................................................. XIX


V

3.1 Pomen in vloga SOA zrelostnih modelov ..................................................................................... XXI

3.2 Kritike SOA zrelostnih modelov ................................................................................................... XXI

4 SOA ZRELOSTNI MODELI ............................................................................................. XXII

4.1 Process – Sonic SOA Maturity model .......................................................................................... XXII

4.2 Zrelostni model OSIMM ............................................................................................................ XXV

4.3 Zrelostni model korporacije ORACLE ........................................................................................ XXVI

4.4 SOA zrelostni model družbe HP .............................................................................................. XXVIII

4.5 Model ESOMM ........................................................................................................................... XXX

5 PRIMERJAVA MODELOV ........................................................................................... XXXII

5.1 Nastanek in zgodovina zrelostnih modelov .............................................................................. XXXII

5.2 Primerjava nivojev zrelosti ...................................................................................................... XXXIII

5.3 Primerjava dimenzij ............................................................................................................... XXXIV

5.4 Primerjava namena modela (samoocenitev, smernice, orodja) ............................................... XXXV

6 POENOSTAVLJEN PRISTOP K OCENI ZRELOSTI SOA ............................................. XL

6.1 Primer ocene zrelosti obstoječe rešitve ..................................................................................... XLIV

7 ZAKLJUČEK ...................................................................................................................... XLIX

VIRI ................................................................................................................................................ LII


VI

KAZALO SLIK

SLIKA 1: STORITEV DOSTAVE HRANE[15]. ................................................................................................................... III

SLIKA 2: NAČRTOVALSKA NAČELA IN CILJI STORITVENE ARHITEKTURE[15].......................................................................... IV

SLIKA 3: PRI NAČRTOVANJU STORITVE JE POTREBNO RAZMIŠLJATI O NOTRANJI IN ZUNANJI SKLOPLJENOSTI[15]. ........................ V

SLIKA 4: NIVO PRIMERNE ABSTRAKCIJE JE POVEZAN Z LOGIKO, KI JO ZAJEMA STORITEV. (PRIREJENO PO [15].) ......................... VI

SLIKA 5: SEDEM DEFINIRANIH CILJEV LAHKO OPREDELIMO KOT STRATEŠKE CILJE IN POSLEDIČNE PRIDOBITVE[15]. ..................... IX

SLIKA 6: INTEROPERABILNOST STORITEV. [15] .............................................................................................................. X

SLIKA 7: USKLAJENO IT OKOLJE. [15] ........................................................................................................................ XI

SLIKA 8: KOMPOZICIJA STORITEV. [15] ..................................................................................................................... XII

SLIKA 9: VEČJA ZAČETNA INVESTICIJA S CILJEM KASNEJŠE VEČKRATNE UPORABE. [15] ........................................................ XIII

SLIKA 10: PRIMER ENAČBE IZVEDBE SOA PROJEKTA. [15] ........................................................................................... XIV

SLIKA 11: ZMANJŠANJE OBSEGA IT OB VPELJAVI SOA. [15] .......................................................................................... XV

SLIKA 12: DEFINICIJA LOČENIH OBSEGOV V ENI ORGANIZACIJI.[15] ................................................................................ XVI

SLIKA 13: TRENDI APLIKACIJSKE ARHITEKTURE. (PO GARTNER 2014) ............................................................................ XVII

SLIKA 14: NIVOJI ZRELOSTI PO SONIC SOA MATURITY MODELU[1]. ............................................................................. XXII

SLIKA 15: MATRIKA ZRELOSTI MODELA OSIMM.[11] ............................................................................................... XXV

SLIKA 16: DOMENE ZRELOSTI SOA PO MODELU ORACLE[6]. ..................................................................................... XXVI

SLIKA 17: MERJENJE ZRELOSTI IN SPREJETOSTI SOA [6]. .......................................................................................... XXVII

SLIKA 18: PROCES HP OCENJEVANJA ZRELOSTI SOA. [13] ...................................................................................... XXVIII

SLIKA 19: PRIMER RAZGRADNJE DOMENE NA PODDOMENE IN DEFINIRANIH HIPOTEZ [13]................................................ XXIX

SLIKA 20: ESOMM MATRIKA ZMOŽNOSTI ZA POSAMEZEN NIVO[9]. ............................................................................ XXX

SLIKA 21: PRIMER OCENE ZRELOSTI POSAMEZNEGA NIVOJA [9]. ................................................................................. XXXI

SLIKA 22: ANALIZA AGILNOSTI POSAMEZNIH STORITEV[13]. .................................................................................... XXXIX

SLIKA 23: PREDLAGAN POSTOPEK OCENE ZRELOSTI ZA VIDIK POSLOVNE ANALIZE[12]. ....................................................... XLII

SLIKA 24: PREDLAGAN POSTOPEK OCENE IN VPELJAVE ZRELOSTI SOA Z VIDIKA ZASNOVE ................................................... XLIII

SLIKA 25: PREDLAGAN POSTOPEK OCENE ZA VIDIK IZVAJALNEGA OKOLJA[12]. ............................................................... XLIV

SLIKA 26: PROCES MENJAVE DOBAVITELJA ELEKTRIČNE ENERGIJE. ................................................................................. XLV

SLIKA 27: KOMPONENTE PROCESA MENJAVE DOBAVITELJA. ...................................................................................... XLVII

../../in1089.IN/Downloads/DiplomaMatej.doc#_Toc447709417


VII

KAZALO TABEL

TABELA 1: MATRIKA ZRELOSTNEGA MODELA SONIC.[1] ............................................................................................ XXIII

TABELA 2: CILJI IN KLJUČNE PRAKSE MODELA SONIC.[1] ............................................................................................ XXIV

TABELA 3: VRHNJI NIVO HP ZRELOSTNEGA MODELA[13]. ......................................................................................... XXIX

TABELA 4: OSNOVNI VPRAŠALNIK OSIMM ZA POSLOVNO DOMENO .......................................................................... XXXVI

TABELA 5: OSIMM ZRELOSTNI INDIKATORJI ZA POSLOVNO DOMENO........................................................................ XXXVII

TABELA 6: POVZETEK REZULTATOV PRIMERJAVE ZRELOSTNIH MODELOV............................................................................ XL

TABELA 7: SKLADNOST UPORABLJENIH KOMPONENT S SPREJETIMI STANDARDI SOA ........................................................ XLVI

TABELA 8: RAZVRSTITEV UPORABLJENIH STORITEV. .................................................................................................. XLVII


VIII

KRATICE

API - Application Program Interface

BAM - Business Activity Monitor

BPEL - Business Process Execution Language

BPM - Business Process Modeling

CMM - Capability Maturity Model

CMMI - Capability Maturity Model Integration

CMU - Carnegie Mellon University

ESOMM - Enterprise Service Orientation Maturity Model

IaaS - Information as a service

ISO - International Organization for Standardization

IT - Information Tehnologies

OSIMM - Open Group Service Integration Maturity Model

REST - Representational State Transfer

ROI - Return Of Investment

SLA - Service Level Agreement

SOA - Service Oriented Arhitecture

WS - Web Service

WSRR – WebSphere Service Registry and Repository

XML - Extensible Markup Language

1 UVOD

Storitveno usmerjena arhitektura, ali krajše SOA, je arhitekturni stil, pri katerem

komponente ponujajo storitve drugim komponentam programske opreme po nekem

komunikacijskem protokolu. Večinoma se komunikacija odvija po omrežju. Storitve naj bi

bile neodvisne glede na tehnologijo oziroma ponudnika programske opreme. Storitev je

opredeljena kot samostojna funkcionalnost, torej diskretno izvedljiva operacija.[15]

Storitve lahko tako poljubno kombiniramo in kot takšne nudijo nove funkcionalnosti v

obsežnejši informacijski rešitvi. SOA ponuja tudi enostavno povezljivost, saj je vsaka

storitev implementirana tako, da se lahko poveže z različnim številom drugih storitev brez

pomoči človeka in brez sprememb aplikacije, ki je podlaga za njeno delovanje.[7]

Sprejetje SOA kot smernice razvoja večinoma še zmeraj izvajamo z adaptacijo izbrane

storitvene platforme. Izkaže se, da zgolj implementacija le-te ne prinese prednosti, ki jih

praviloma pričakujemo od storitvene paradigme.

Preden zgradimo rešitev s storitvenim pristopom, mora biti le-ta dobro razumljen že ob

začetku projekta.[4]

Predmet raziskovanja diplomske naloge so zrelostni modeli storitvene arhitekture. Za lažje

razumevanje pojmov zrelostnih modelov je potrebno poznavanje principov načrtovanja

storitvene arhitekture, ki jih glede na literaturo lahko razdelimo na osnovne principe SOA

ter na cilje in pridobitve same vpeljave. Osnovne pojme storitvenih arhitektur bomo

predstavili v uvodnih poglavjih.

V tretjem poglavju bomo na podlagi virov in literature opredelili osnove zrelostnih modelov

(Maturity models) na področju razvoja programske opreme. Na podlagi dognanj bomo v

naslednjih poglavjih predstavili pomen in vlogo zrelostnih modelov ter opisali nekaj

najpogosteje omenjenih.

Med cilje naloge smo uvrstili tudi končno primerjavo zrelostnih modelov glede na

nastanek, nivoje, ki jih opredeljujejo, področja, ki jih zajemajo, in namenu zaradi katerega

so nastali. V zaključku naloge bomo poskušali zrelostne modele ovrednotiti ter na

konkretni storitveni aplikaciji uporabiti poenostavljen pristop k ocenitvi zrelosti.

2 PRINCIPI NAČRTOVANJA STORITVENE ARHITEKTURE

Ključ do uspeha pri implementaciji storitvene arhitekture je v znanju, kako izdelati resnično

storitveno usmerjeno rešitev. Znanje je zajeto v obliki pristopa in zavezanosti specifičnim

ciljem pri načrtovanju. Naslednja podpoglavja opisujejo koncepte, s katerimi je mogoče

razumeti, kaj se šteje za resnično storitveno usmerjene rešitve.[15]

2.1 Storitev

V svetu okoli nas so storitve nekaj vsakdanjega. Vsak posameznik, ki opravi neko opravilo

v podporo drugim udeležencem, nudi storitev. Podobno, vsaka skupina ali organizacija, ki

združeno izvede opravila, ponuja storitev. Vse dokler je to opravilo dobro definirano in je

lahko izolirano od ostalih povezanih opravil, ga je mogoče označiti kot storitev.[15] Primer

sestavljene storitve iz realnega sveta prikazuje slika 1.

Trgovec- sprejema naročila

- izdaja račune

Kuhar- pripravlja hrano

Dostavljalec- dostavlja naročila

Storitev dostave hrane

Slika 1: Storitev dostave hrane.[15]

V svetu SOA izraz storitev povzema enolične karakteristike zasnove. Samo če so storitve

izdelane s temi značilnostmi, lahko govorimo o uspešni implementaciji storitvene

arhitekture. Ena izmed takšnih značilnosti storitve je ponovna uporaba. V kolikor storitve

dejansko zasnujemo kot generične in uporabne za različne scenarije, se to v organizaciji

pozna v šibko sklopljenih delovnih procesih, posledica tega je širša ponovna uporaba. Ko

govorimo o storitvah, ne smemo pozabiti, da lahko te ponujajo več zmožnosti. Združene

so zaradi funkcionalnega okvirja, ki ga storitev ponuja. Storitev je tako izpostavljena kot

nabor povezanih zmožnosti v obliki storitvene pogodbe (service contract), ki opisuje, kaj je

na voljo uporabnikom storitve.[15]

2.2 Storitvena paradigma

Paradigma se kot pristop k načrtovanju rešitve tudi pri storitveni arhitekturi nanaša na

teorijo členitve nalog (separation of concerns). Bistvo je, da večje probleme razbijemo na

več manjših, ki so lažje obvladljivi. Za porazdeljene sisteme obstaja več pristopov k takšni

členitvi. Kar razlikuje pristop SOA od ostalih, je, kako se členitev izvaja in kako se

oblikujejo posamezne enote. Tako izvedeno rešitev lahko nato imenujemo storitveno

usmerjeno, posamezne enote pa storitve. V pomoč pri načrtovanju so cilji in načrtovalski

pristopi, ki jih prikazuje slika 2.

Pogodba

Šibka sklopljenost

Abstrakcija

Avtonomija

Brez stanja

Možnost odkrivanja

Ponovna uporaba

Sestavljivost

Povečana interoperabilnost

Povečano sodelovanje

Raznovrstnost programske

opreme

Izboljšana uskladitev

tehnologije s poslovanjem

Povečana donosnost naložbe

Agilnost

Zmanjšana obremenitev

IT

Storitev

Poslovanje

Slika 2: Načrtovalska načela in cilji storitvene arhitekture.[15]

2.3 Načela SOA

2.3.1 Standardizirane storitvene pogodbe

Storitve izpostavljajo svoje zmožnosti preko standardizirano definiranega vmesnika.

Storitveni vmesnik je osnovni pristop storitvene arhitekture in zahteva, da se preučijo

specifične zahteve ter se ocenita narava in obseg vsebine, ki bo izpostavljena

uporabnikom storitve. Velik poudarek pri načrtovanju oziroma oblikovanju tako imenovane

storitvene pogodbe je način, kako je odprta funkcionalnost navzven, kako so opredeljeni

podatki in kako so pripete politike dostopa. Potrebno se je osredotočiti na cilj, da so

vmesniki optimizirani in razdelani tako, da bodo storitve konsistentne, zanesljive in jih bo

mogoče upravljati.[15]

2.3.2 Šibka sklopljenost

Koncept šibke sklopljenosti spodbuja neodvisno načrtovanje in evolucijo storitve z

zagotavljanjem izhodiščne interoperabilnosti uporabnikov, ki se zanašajo na storitev. Pri

načrtovanju storitve moramo paziti na več vrst sklopljenosti, ki jih prikazuje slika 3 in ki

vplivajo na vsebino in razdrobljenost:

– uporabniki storitve so sklopljeni preko vmesnika,

– vmesnik in logika storitve sta sklopljena z nadrejenim procesom,

– logika storitve je izvedena s specifično programsko opremo, posledično tudi

sklopljena s to programsko opremo,

– logika storitve je sklopljena z različnimi viri, ki so del sistema,

– logika storitve je sklopljena s storitvami, ki jih orkestrira,

– vmesnik storitve je sklopljen z implementacijo.

Logika storitve

StoritvenapogodbaStoritvena

pogodbaStoritvenapogodba

Storitvena pogodbaJe lahko sklopljena z

logiko storitveLogika storitve jelahko sklopljena s

storitveno pogodbo

StoritveStoritve

Storitve Java EE .NET

Lastniška tehnologija

Storitvena pogodba in logika storitve sta

lahko sklopljeni s poslovnim procesom

Storitvena logika je lahko sklopljena z

več storitvami Storitvena logika je lahko sklopljena z

več viri

Storitvena logika je lahko

implementirana in tako slopljena z

različnimi tehnologijami

Slika 3: Pri načrtovanju storitve je potrebno razmišljati o notranji in zunanji sklopljenosti.[15]

2.3.3 Abstrakcija storitev

Abstrakcija storitev je povezana z mnogimi vidiki storitvene arhitekture. V osnovi želimo s

storitvijo prikriti čim več implementacijskih podrobnosti. Takšno početje neposredno vpliva

na prej omenjeno sklopljenost. Abstrakcija pa ima pomembno vlogo tudi pri izvedbi

kompozicij. Ob želji po doseganju kar najvišjega nivoja abstrakcije je potrebno upoštevati

tudi druge dejavnike – predvsem povečano razdrobljenost in kasnejši strošek vzdrževanja

storitve.[15] Slika 4 prikazuje različne nivoje abstrakcije storitev.

Slika 4: Nivo primerne abstrakcije je povezan z logiko, ki jo zajema storitev. (Prirejeno po [15].)

2.3.4 Ponovna uporaba

Ponovna uporaba mora biti temeljni cilj pri načrtovanju storitve. Temu primerno so

naravnane tudi vse sodobne tehnologije, ki podpirajo storitveni pristop. Pri ponovni

Storitev ovija obstoječ sistem

Storitev ovija po meri narejene komponente

Storitev ovija druge storitve

Zmanjšana tehnološka abstrakcija

Omejena funkcijska abstrakcija

Raznolika abstrakcija logike

Abstrakcija kakovosti

Povečana tehnološka abstrakcija

Povečana funkcijska abstrakcija

Povečana abstrakcija logike


Odvisna abstrakcija tehnologije

Povečana funkcijska abstrakcija

Odvisna abstrakcija logike


uporabi je vodilo umeščanje storitev kot vira za celotno organizacijo, neodvisno od

uporabnika. Učinkovito vpeljan koncept bo svoje prednosti pokazal na dolgi rok z

znižanjem stroškov in hitrejši vpeljavi novih rešitev.[15]

2.3.5 Avtonomija

V želji, da storitve svoje zmožnosti izpostavljajo dosledno in zanesljivo, mora

implementacija storitve zagotavljati visok nivo nadzora okolja in virov, s katerimi deluje.

Visok nivo avtonomije zagotavlja zanesljivost in predvidljivost delovanja storitve.

Premajhen poudarek na avtonomiji storitve se bo pokazal predvsem pri večkratni ponovni

uporabi storitve.[15]

2.3.6 Storitve brez stanja

Upravljanje stanja v storitvi ni zaželeno, saj lahko vpliva na razpoložljivost in zmožnost

razširjanja. Storitve so idealno implementirane tako, da ne vzdržujejo stanja, če to ni nujno

potrebno.[15]

2.3.7 Možnost odkrivanja storitev

Da bi bile storitve zastavljene kot IT sredstvo in se izkazale kot večkrat izkoriščene,

morajo biti preprosto razumljive in enostavno dostopne. Načrtovanje se mora odražati v

kakovosti splošne komunikacije storitve kot njenih individualnih zmožnosti, ne glede na to,

ali je na voljo mehanizem odkrivanja in upravljanja storitev.[15]

2.3.8 Kompozicija storitev

Ko se rešitev SOA dopolnjuje, raste tudi zahtevnost pripadajočih kompozicij storitev.

Učinkovito orkestriranje oziroma kompozicija storitev (Service Composability) je eden

glavnih ciljev storitvene arhitekture. Pričakovano je, da se storitve brez napora vključujejo

v kompozicije brez sprememb. [15]

2.3.9 Storitvena arhitektura in interoperabilnost

Interoperabilnost je pojem, ki naj bi brezpogojno veljal za storitve, in ravno zaradi tega

nanjo ne smemo pozabiti. Vsak od osmih zgoraj naštetih principov za načrtovanje storitev

pripomore k interoperabilnosti. Storitveni vmesniki pripomorejo k harmonizaciji

podatkovnih modelov, šibka sklopljenost pripomore k zmanjšanju medsebojnih odvisnosti

in posledično možnosti večjega nabora odjemalcev. Abstrakcija pripomore k omejitvi na

zgolj storitveni vmesnik in zagotavlja deležnikom neodvisen razvoj. Ponovna uporaba se

kot koncept izkaže za uspešno v smislu interoperabilnosti predvsem pri vseh kasnejših

uporabnikih storitve. Z zagotavljanjem avtonomije storitev, ko njihovo obnašanje postane

bolj predvidljivo, povečujemo potencial ponovne uporabe in s tem višjo raven

interoperabilnosti. Z zasnovo storitev brez stanja sta razpoložljivost in razširljivost

povečani, kar ponuja večje možnosti sodelovanja in večjo zanesljivost. Možnost

preprostega odkrivanja storitev in njihovo preprosto razumevanje povečujeta nabor

potencialnih uporabnikov.

Storitve same po sebi niso interoperabilne, temveč mora biti to eden od ciljev.[15]

2.4 Cilji in pridobitve SOA

Vizija vpeljave storitvene arhitekture je zelo ambiciozna in pritegne vse, ki želijo iztržiti kar

največ od svojega IT. Skupne koristi in cilji pripomorejo k tej viziji, kar je v pomoč pri

definiciji končnega stanja vpeljane storitvene arhitekture, ki ga organizacija želi doseči.

Definiranim ciljem in prednostim se je dobro posvetiti pred načrtovanjem uvedbe, tako da

bodo le-ti skladni s principi storitvene arhitekture. Uspešne uvedbe storitvene arhitekture

namreč ne bomo dosegli brez jasno doseženih ciljev. Slika 5 prikazuje, kakšni naj bodo

zastavljeni cilji in kaj lahko pričakujemo kot pridobitve.

Povečana

notranja

interoperabilnost

Raznovrstnost

uporabe IT

rešitev

(Federation)

Raznovrstnost

programske

opreme

Usklajevanje

poslovanja s

tehnološkimi

rešitvami

Povečana

donosnost

naložb

Večja

dovzetnost za

spremembe

(Agility)

Zmanjšana

obremenitev IT

Strateški cilji

Pridobitve

Slika 5: Sedem definiranih ciljev lahko opredelimo kot strateške cilje in posledične pridobitve.[15]

2.4.1 Povečana notranja interoperabilnost

Interoperabilnost se nanaša na izmenjavo informacij oziroma medsebojno deljenje

podatkov. Bolj je programska oprema interoperabilna, lažje izmenjuje podatke.

Informacijske rešitve, ki nimajo takšnih lastnosti, so podvržene integraciji. Osnovna

predpostavka storitvene arhitekture je, da so storitve interoperabilne, posledica je

zmanjšana potreba po integraciji. To dosežemo z dosledno uporabo standardov in

pristopov. Le tako lahko zagotovimo okolje, ki bo v različnih projektih priskrbelo storitve, ki

bodo lahko hitro uporabljene in sestavljene v nove rešitve. Notranja interoperabilnost je

tudi ključ za dosego vseh ostalih ciljev.[15]

Storitev 1

Ekipa A

Ekipa B

Ekipa C

Storitev 2

Storitev 3

Slika 6: Interoperabilnost storitev. [15]

Kot je razvidno na sliki 6, so storitve zamišljene kot interoperabilne ne glede na to, kdaj in

kje so nastale. Razvidno je, da je lahko projektna ekipa C ponudila rešitev s kompozicijo

obstoječih storitev.[15]

2.4.2 Povezanost uporabe IT rešitev

V združenem (Federated) IT okolju so viri in aplikacije poenotene, kljub temu pa lahko

zadržijo svojo avtonomijo in življenjski cikel. Cilj vpeljave storitvene arhitekture je

povečanje federacije do največjega možnega nivoja, kar dosežemo z umestitvijo

standardiziranih in kompozicije sposobnih storitev. Vsaka od teh vključuje del poslovanja

podjetja in ga dosledno izraža. V podporo povečani federaciji je ključen poudarek na

standardizaciji načrtovanih storitev. V končni fazi tako implementiramo usklajeno okolje,

ne ozirajoč se na pripadajočo izvedbo programske opreme.[15]

S primera, izraženega na sliki 7, tri storitve ponujajo usklajeno okolje preko standardnih

vmesnikov – kljub različnim implementacijam programske opreme, ki jo obsegajo.

Java

Storitev 1

.NETStoritev 2

SAPStoritev 3

Slika 7: Usklajeno IT okolje.[15]

2.4.3 Raznovrstnost programske opreme

Čeprav uporaba raznovrstne programske opreme različnih proizvajalcev ni nujno

zaželena oziroma takšna rešitev ne prinaša kakršnekoli prednosti, storitveno usmerjena

arhitektura ponuja rešitev za lažjo integracijo. Vseeno pa je dobro, če se lahko v takšnem

okolju kljub temu učinkovito integriramo. Tako so odprte možnosti izbire najboljšega na

tržišču. Takšno stanje organizacije pa ne prinaša samo svobodne izbire, temveč izboljšuje

možnosti sprememb, razširitev in celo zamenjavo določenih rešitev brez večjih pretresov

za celotno okolje. Z zasnovo storitvene arhitekture, nevtralno do različnih proizvajalcev, in

z umeščanjem standardiziranih storitev, ki abstrahirajo lastniško (proprietary) programsko

opremo, lahko vzpostavimo enovito komunikacijsko ogrodje. To pa nam omogoča

raznolikost rešitev skladno z našimi potrebami in željami.

Nadalje je raznovrstnost najbolje podprta z uporabo nevtralnega ogrodja za spletne

storitve, ki ne zahtevajo nekega lastniškega komunikacijskega protokola. Spletne storitve

hkrati še zmanjšujejo odvisnost med različnimi platformami.[15]

Kompozicija storitev s slike 8 prikazuje storitve, pri katerih je vsaka implementirana na

specifični lastniški platformi. V kolikor je storitvena usmerjenost pravilno zasnovana,

neskladje tehnologij ne bo zaviralo zmožnosti kombiniranja v učinkovite kompozicije.[15]

.NET

MS SQL

JAVA

DB2

JAVA

FILE10g

Storitev 1

Storitev 1

Storitev 1

Slika 8: Kompozicija storitev.[15]

2.4.4 Usklajevanje poslovanja s tehnološkimi rešitvami

Obseg, kako programska oprema izpolnjuje zahteve poslovanja, je povezan z

natančnostjo povzemanja poslovne logike pri načrtovanju. Ker so aplikacije tradicionalno

zgrajene zaradi naslavljanja trenutnih potreb, obstaja večen izziv usklajevanja s

spreminjajočimi poslovnimi potrebami. Ker se s SOA uvaja paradigma abstrakcije na

različnih nivojih, se lahko le-ta na različnih storitvenih nivojih odraža kot dosledna

predstavitev poslovnih modelov. Poslovne entitete in procesi so lahko tako predstavljeni

kot fizično implementirane storitve. To dosežemo s strukturirano analizo in modeliranjem

procesov, kjer imajo vodilno vlogo strokovnjaki s področja poslovanja organizacije.

Takšne storitve lahko, ob predpostavki interoperabilnosti, preurejamo v nove kompozicije,

ki odražajo spremembe poslovanja. Storitvena tehnologija bo tako napredovala skupaj s

poslovanjem organizacije.

2.4.5 Povečana donosnost naložb

Merjenje donosnosti programskih rešitev je nujno potrebno za določanje učinkovitosti le-

teh. Ker je narava novih in obstoječih rešitev vse kompleksnejša, se lahko proračun za IT

izkaže kot velik del proračuna celotne organizacije. Velikokrat predstavlja naraščajoč

delež brez vidnega napredka v sami funkcionalnosti ponujene rešitve. Storitvena

arhitektura v takšne namene zagovarja agnostične rešitve – to je tiste, ki niso sklopljene s

katerokoli rešitvijo ter so uporabne za več problemov. Z mislijo na to prednost na začetku

v storitve investiramo več in jih pozicioniramo kot IT sredstva z namenom dolgoročnih

finančnih donosov, kot je prikazano na sliki 9.[15]

Običajni gradnik informacijske rešitve

Storitveno zasnovan gradnik

informacijske rešitve

Cena implementacije = X

Cena implementacije = X + 30%

Običajna enota informacijske rešitve

Običajna enota informacijske rešitveObičajna enota

informacijske rešitve

Donosnost prvo leto = y Donosnost drugo leto = 2y Donosnost tretje leto = 3y

Donosnost prvo leto = 2y Donosnost drugo leto = 5y Donosnost tretje leto = 9y

Slika 9: Večja začetna investicija s ciljem kasnejše večkratne uporabe.[15]

2.4.6 Večja dovzetnost za spremembe

Dovzetnost za spremembe (Agility) se v organizaciji kaže kot hitrost, s katero se lahko

odzove na spremembe. V današnjem hitro spreminjajočem se svetu je to ena od

pomembnejših vrlin, saj lahko le tako ostanemo konkurenčni. IT oddelki so velikokrat

zaznani kot ozko grlo, saj informacijska podpora ne sledi spreminjajočemu poslovanju.

Agilni pristopi razvoja so tako pridobili na popularnosti. Storitvena arhitektura prispeva k

takšnemu razmišljanju. Ko je le-ta vzpostavljena v celotni organizaciji, so ravno

agnostičnost pripravljenih storitev, njihova standardizacija in ponovna uporaba tisto, kar

omogoča neodvisnost od nadrejenih procesov in s tem hitrejše možnosti za spremembe

le-teh. Ko inventar storitev vsebuje veliko množico storitev, ki niso v lasti posamezne

aplikacije, temveč so obravnavane kot IT sredstvo, so lahko hitro in učinkovito postavljene

v drugačne konfiguracije. Hitrost vpeljave novih procesov je lahko tako občutno

zmanjšana, kar se da tudi oceniti.[15]

Klasična rešitev

Čas dokončanja rešitve

Izdelava programske kode v celoti

Inventar storitev

SOA rešitev

Cena = x Napor = y

Čas = z

Izdelava nove programske kode 35%Ponovna uporaba 65%

Cena = x/2,5 Napor = y/3

Čas = z/3

Slika 10: Primer enačbe izvedbe SOA projekta.[15]

Izvedba projekta, kot ga prikazuje slika 10, je sestavljena na podlagi ocene trajanja za

izdelavo nove funkcionalnosti in ponovne uporabe obstoječih storitev. Časovni načrt je

glede na rešitev, ki bi bila izdelana na novo, skrajšan za 50 %, saj je vseeno potrebno kar

nekaj časa za vpeljavo obstoječih rešitev.

Zavedati se je potrebno, da je agilnost pogojena s količino storitev v repozitoriju oziroma

inventarju storitev. Postopki za modeliranje in razvoj storitev pa zahtevajo precej več časa

kot tradicionalne rešitve. Storitvena arhitektura kot cilj tako ponuja agilnost na dolgi rok,

kar ne sovpada povsem z agilnimi pristopi razvoja programske opreme, pri katerih je

poudarek na takojšnjem hitrem razvoju rešitev.[15]

2.4.7 Zmanjšana obremenitev oddelkov za informatiko

Z dosledno uporabo storitvene arhitekture lahko v organizaciji zmanjšamo obseg in

mnogokratnost rešitev. S tem ne pridobimo le nižjih operativnih stroškov, temveč

zmanjšamo tudi obseg upravljanja le-teh, kar izboljša učinkovitost pri izrabi virov. Tako

razbremenjen IT oddelek je organizaciji v manjše breme in je bolje postavljen v vlogo

tistega, ki prispeva k doseganju strateških ciljev.[15]

Inventar storitev

Okolje z integriranimi

rešitvami

Enako okolje z

inventarjem storitev

Slika 11: Zmanjšanje obsega IT ob vpeljavi SOA.[15]

Kot je razvidno iz slike 11, se v primeru tipične organizacije, ki svoje okolje zamenja s

storitveno arhitekturo, obseg programske opreme občutno zmanjša.

2.5 Uvajanje storitvene arhitekture

Glede na predhodna poglavja storitvena arhitektura zagotavlja dorečene tehnike

oblikovanja informacijskih rešitev v enote, ki jih poimenujemo storitve; vsaka od teh enot

pa zagotavlja doseganje predstavljenih ciljev. Kljub vzorcem, pristopom in tehnologijam, ki

to omogočajo, sta narava vpeljave storitvene arhitekture in doseg želenega stanja

strateška usmeritev, ki zahteva pozornost na področjih, kot so:

Timsko delo – glede na izvedbo silosnih aplikacij je v primeru SOA potrebno

sodelovanje širše skupine ljudi. Člani tima niso omejeni na poznavanje specifične

rešitve, kar prinaša novo dinamiko projektov, nove vloge ter relacije med projekti

in člani timov.

Izobraževanje – ključno za zagotavljanje zanesljivosti in zaupanja v SOA je

skupno besedišče, definicije, koncepti, metode in skupno razumevanje končnega

stanja, ki ga želimo doseči z uvedbo. Vse skupaj zahteva enotno izobraževanje

sodelujočih, ne samo v pristopih in tehnikah SOA, temveč tudi o standardih in

praksah, ki so specifične za organizacijo.

Disciplina – vse doseženo znanje mora biti tudi uporabljeno. Člani ekip morajo biti

pri uporabi le-tega skrajno dosledni. V metodologiji naj bo temu primerno

obravnavana tudi kontrola zastavljenega.

Uravnotežen obseg – podjetja z dolgo zgodovino razvoja silosnih aplikacij lahko

pri uvedbi storitvene arhitekture naletijo na težave, saj le-ta predstavlja veliko

spremembo v miselnosti. V takšnih primerih je pomembno definiranje nabora

storitev, ki naj zajema več 'silosov' in ni preobsežen. Po izboru obsega bo lažje

definirati, kaj je potrebno zajeti v smislu timskega dela, izobraževanja vključenih in

discipliniranosti le-teh. V velikih organizacijah lahko obsege definiramo ločeno, ti

so zavezani lastnemu obsegu adaptacije, rezultat pa so domensko naravnane

storitve z lastnim repozitorijem. Kot prikazuje slika 12, je v istem podjetju

definiranih več ločenih obsegov vpeljave SOA, kjer ločeno nastaja repozitorji

storitev, ki so ločeno upravljane z lastnimi standardi. Tako zasnovano storitveno

arhitekturo imenujemo tudi združena SOA (Federated SOA).[15]

Organizacija

Domena 1

Timsko delo

Izobraževanje

disciplina

Domena 2

Timsko delo

Izobraževanje

disciplina

Domena 3

Timsko delo

Izobraževanje

disciplina

Slika 12: Definicija ločenih obsegov v eni organizaciji.[15]

Glede na Gartnerjevo poročilo 2014 in njihovo krivuljo trendov (hype cycle), prikazano na

sliki 13, se je pri vpeljavi storitvene arhitekture potrebno opredeliti tudi glede združene

storitvene arhitekture (Federated SOA) in ogrodja storitvene arhitekture (SOA backplane).

Oboje je že prestopilo mejo začetnega navdušenja in se v 2-5 letih napoveduje kot zrelo

za produkcijo.

Slika 13: Trendi aplikacijske arhitekture. (po Gartner 2014)

2.6 Združena storitvena arhitektura

V združeni storitveni ahitekturi (Federated SOA) so posamezni deli organizacije razdeljeni

v delno neodvisne enote, vsako s svojo infrastrukturo, procesom upravljanja in centrom

odličnosti. Te enote so potem integrirane v celoto z ločeno infrastrukturo in procesi

upravljanja. Tak pristop se izkaže kot učinkovit tudi v primerih sodelovanja z zunanjimi

partnerji. Združevanje prav tako predstavlja izzive, saj je potrebno omogočiti upravljanje

med posameznimi domenami in urediti novo nastalo organizacijsko strukturo.

Utemeljitev za tak pristop pri implementaciji SOA je kompleksnost uvedbe v velikih

organizacijah, ki načeloma niso tako agilne, da bi bila celostna preobrazba mogoča v

doglednem času. Dodatno lahko kot pozitivno ocenimo tudi ohranjanje samostojnosti

posameznih poslovnih enot, velike razlike v načinu poslovanja pa s takim pristopom

omogočajo tudi uporabo različnih tehničnih rešitev. Tudi izzivi sodobnega digitalnega

sveta, kot so mobilne aplikacije, računalništvo v oblaku, družbena omrežja in zunanji

podatkovni viri govorijo v prid združeni arhitekturi.

Pri spodbujanju takšnega pristopa je potrebno posvetiti pozornost:

vzpostavitvi organizacijskega modela za več centrov odličnosti,

implementaciji infrastrukture za interoperabilnost čez posamezne domene,

definiciji skupnega nabora procesov upravljanja.

2.7 Ogrodje storitvene arhitekture

Ogrodje storitvene arhitekture (SOA Backplane) je referenčni model aplikacijske

infrastrukture, ki je potrebna za vpeljavo SOA. Vsebuje storitveno vodilo, ki omogoča

interoperabilnost med različnimi sistemi. Dopolnjujejo ga različni vmesniki in zmožnosti

orkestracije. Ogrodje je večinoma razširjeno tudi s programsko opremo, ki je v pomoč

upravljanju repozitorija storitev, pravilnikov, življenjskega cikla in programskih vmesnikov

(API).

Veliko organizacij aplikacijsko arhitekturo načrtuje z vizijo storitvene arhitekture, samo

ogrodje pa je nenačrtno implementirano skozi naraščajoče potrebe. Če se potreba po

posameznih komponentah v začetnih iniciativah ne izkaže za potrebno, nastopijo težave,

ko takšno dopolnjevanje ogrodja storitvene arhitekture prevalimo v stroške posamičnih

projektov.

Izvedba ogrodja storitvene arhitekture in s tem povezanega upravljanja mora biti

podvržena podrobni analizi poslovnih in tehničnih zahtev. Pristop »načrtuj globalno, deluj

lokalno« se priporoča tudi za načrtovanje ogrodja storitvene arhitekture. V začetni fazi bi

se tako implementiralo zgolj storitveno vodilo, kasnejši projekti pa bi glede na potrebe

dopolnili ogrodje z novimi zmožnostmi. Tudi od proizvajalcev tehnologij SOA je zaželeno,

da ponudbo storitvenih tehnologij oblikujejo v posamične združljive module.

3 OSNOVE ZRELOSTNIH MODELOV

Ko je rešitev vpeljana ali začrtan projekt zaključen in to ne prinese pričakovanih koristi, je

včasih težko definirati, kaj je šlo narobe. Tudi če želimo obstoječe stanje izboljšati, je

najbolje postaviti zrelostni model, ki nas osredotoči na posamezna področja, nato pa

lahko določimo, kje smo in kaj želimo doseči. Tako imenovani zrelostni modeli

predstavljajo poenostavljen oziroma osredotočen pogled na resnično stanje in so običajno

razdeljeni po področjih in po nivojih, ki jih na nekem področju želimo doseči. Pri obravnavi

nivojev pa ni vedno cilj doseči tistega najvišjega, ki je mogoče zaradi celovitosti modela

neuresničljiv ali pa za neko organizacijo predstavlja prevelike stroške. Vsak nivo mora

imeti kar najbolje definirane kriterije in zmožnosti, ki ga opisujejo. Ob vrednotenju je

potrebno paziti, da so kriteriji dobro razumljeni, pri obravnavanju le-teh pa moramo biti kar

se da objektivni.

Glede na Software Engineering Institute vsebuje Capability Maturity Model (CMM), ki je

eden bolj znanih zrelostnih modelov na področju razvoja programske opreme in

informacijskih rešitev, osnovne elemente učinkovitih procesov. Zagotavljal naj bi smernice

za zmogljive, stabilne in zrele postopke in predstavljal vodilo za upravljanje razvoja,

prevzema in vzdrževanja izdelkov in storitev. Seveda ne smemo pozabiti tudi na trditev,

da direktna preslikava procesov modela na procese organizacije ni mogoča. V letu 2002

je bila predlagana različica CMMI (Capability Maturity Model Integration) usmerjena na

integracijo sistemov in ne več le na izdelavo programske opreme. Nivoji zrelosti so

definirani kot nabor pričakovanih rezultatov, posledične izboljšave procesov pa naj bi

pripomogle k učinkovitemu predvidevanju novih zmogljivosti organizacije.

Večina zrelostnih modelov se naslanja na omenjeni CMM in njegovo razširitev CMMI, vsaj

po nivojih zrelosti. CMMI vključuje pet zrelostnih nivojev:[2]

1. Začetni – Initial

Procesi so kaotični in priložnostni, organizacija pa ne predstavlja stabilnega okolja. Uspeh

delovanja je zagotovljen s sposobnimi posamezniki in ne zaradi vzpostavljenih procesov.

Na takšnem nivoju organizacije izdelke običajno pripravijo s prekoračenimi roki in

povečanimi sredstvi.

2. Upravljani – Managed

Na takšnem nivoju je organizacija dosegla vse zadane cilje glede predpisanih postopkov

za drugi nivo. Z drugimi besedami – projekti zagotavljajo, da se upravlja z zahtevami in so

procesi načrtovani, izvajani, merjeni in nadzorovani. Disciplina v postopkih je zagotovljena

tudi v stresnih situacijah in projekti so izvršeni glede na dokumentacijo in načrte. Sprejete

so zaveze s strani interesnih skupin, po potrebi so tudi revidirane. Izdelki so pregledani s

strani vseh deležnikov, izdelki pa zadovoljujejo zahtevam, standardom in ciljem.

3. Definiran – Defined

Procesi na tem nivoju so dobro razumljeni in predstavljeni kot standardi, procedure, orodja

in metode. Le-ti se s časom tudi izboljšujejo in zagotavljajo enotnost čez celotno

organizacijo.

4. Kvantitativno upravljan – Quantitatively Managed

Na tem nivoju so procesi opremljeni s podprocesi, ki pripomorejo k skupni učinkovitosti.

Podprocesi so statistično nadzorovani. Merjenje kakovosti in učinkovitosti procesov je

vpeljano na način, da omogoča boljše odločanje v prihodnosti. Kritična razlika glede na

tretji nivo je predvidljivost poteka procesov.

5. Optimizacija – Optimizing

Na tem nivoju se procesi konstanto izboljšujejo glede na postavljena merila.

Napredovanje čez nivoje je mogoče doseči na posameznih projektih, izkušnje se

prenesejo čez celotno organizacijo, nikoli pa glede na model ni zaželeno preskakovanje

nivojev, saj vsak nivo predstavlja temelj, na katerem lahko gradimo pot do naslednjega

nivoja.[2]

3.1 Pomen in vloga SOA zrelostnih modelov

Uspešna implementacija SOA ni omejena na računalniške sisteme in tehnologije, zahteva

namreč spremembe na celotnem nivoju organizacije. Da bi lahko obvladovali

kompleksnost, je mogoče izvesti prehod po korakih v smislu evolucije. Takšen pristop pa

ni primeren le za čiste začetke, temveč ga lahko uporabimo tudi v primerih že izvedene

implementacije storitvene arhitekture.[14]

Zrelostni modeli ponujajo podporo pri načrtovanju evolucijskega pristopa. Uporabimo jih

lahko tako za merjenje napredka, kot za oceno trenutnega stanja. Tudi izbira nivoja, ki ga

želimo doseči, je pomemben dejavnik, saj najvišji nivo, ki ga predstavlja model, ni nujno

primeren ali potreben za vse situacije. Obljubljene koristi morajo biti zmeraj uravnotežene

s stroški razvoja doseganja in vzdrževanja posameznega nivoja. Za lažjo opredelitev se

od modela pričakuje opis nivojev preko zmožnosti, ki jih je potrebno obvladovati, da lahko

s SOA obvladujemo poslovne procese. Dodatno je torej zaželeno, da se vsak nivo

opredeli tudi s prednostmi in stroški. Poleg tega mora biti model neodvisen od uporabljene

tehnologije.[14]

3.2 Kritike SOA zrelostnih modelov

Ob pojavu SOA zrelostnih modelov je bilo največ kritik argumentiranih z izjavami, da tudi

sama storitvena arhitektura ni zadovoljivo definirana in je tako tudi merjenje zrelosti

nemogoče. Kritizirali so preveč tehnično naravnanost modelov z bojaznijo, da bodo

organizacije zasnovale merjenje zrelosti zgolj na tehničnem nivoju in IT oddelkih, medtem

ko bodo ostali vidiki poslovanja, ki naj bi bili prav tako podvrženi spremembi proti storitveni

usmerjenosti, spregledani. Modeli naj bi predstavljali samo del zrelosti celotne

organizacije, oziroma naj bi opisovali zgolj zrelost izvedenih storitev in ne arhitekture kot

celote. Izraženi so bili dvomi v kasnejšo uvedbo celostne arhitekture (enterprise

architecture), ko podjetje že napreduje v nivoju zrelosti. Nekateri so dvomili, da so modeli

zgolj orodje za promocijo izdelkov velikih proizvajalcev programske opreme in ti ne bi

smeli biti avtorji takšnih modelov. Ne glede na navedbo, da je največ kritik na račun

prezgodnjega nastanka modelov, to ne znižuje vrednosti samih modelov.[8]

4 SOA ZRELOSTNI MODELI

V naslednjih podpoglavjih bomo opisali osnovne značilnosti petih izbranih zrelostnih

modelov. V prvi vrsti smo se pri izbiri osredotočili na modele znanih proizvajalcev

programske opreme, ki v naboru svojih rešitev ponujajo komponente, ki omogočajo

vpeljavo storitvene arhitekture. Kriterij izbire sta bila tudi čas nastanka modelov in njihov

razvoj. Izbrane modele smo največkrat zasledili na spletu in v literaturi. V virih pa najdemo

še več zrelostnih modelov vpeljave storitvene arhitekture kot na primer iSOAMM,

SOAMM, SIMM.

4.1 Process – Sonic SOA Maturity model

Zrelost je v modelu, ki ga je razvilo podjetje Sonic, predstavljena v petih nivojih, ki so

uparjeni s širše prepoznanim modelom CMMI.

Slika 14: Nivoji zrelosti po Sonic SOA Maturity modelu.[1]

V tabeli 1 so predstavljeni ključni dejavniki pri doseganju zrelosti in prikazujejo vpliv na

poslovanje, razsežnost obsega dela, faktorje uspeha in standarde, ki jih je potrebno zajeti.

Dodatno so v tabeli 2 predstavljeni potrebni cilji in njihova izvedba za doseganje želenega

nivoja. Za vsak prehod v nadaljnji nivo je potrebno izpolniti zahteve predhodnih nivojev.

Model so kritizirali predvsem zaradi marketinške naravnanosti, saj je vezan na ponudbo

produktov podjetja Sonic.[1]

Tabela 1: Matrika zrelostnega modela Sonic.[1]

Nivo zrelosti Poslovne koristi

Obseg Tehnološki faktorji uspeha

Organizacijski faktorji uspeha

Ustrezni standardi

1 Prve storitve.

Nova funkcionalnost.

Pilotni projekti. Posamezna integracija. Majhno število storitev.

Standardi. Integracija obstoječih aplikacij.

Razvoj se usposobi za izdelavo storitev. Sponzorstvo razvojnega vodje.

XML, XSLT, WSDL, SOAP, JAVA EE, .NET.

2 Načrtovane storitve.

Znižanje stroškov IT.

Več integriranih aplikacij.

Podpora porazdeljenim in heterogenim sistemom. Mediacije. Zanesljivo sporočanje. Preprostost nameščanja (deployment). Verzioniranje. Upravljanje z razpoložljivostjo.

Vodenje prevzame skupina za arhitekturo. SOA kompetenčni center. Sponzorstvo vodstva, direktorja.

UDDI, WS-ReliableMessaging, WS-Policy, WS-Addressing, XQuery, WS-Security, SAML UDDI, WS-ReliableMessaging, WS-Policy, WS-Addressing, XQuery, WS-Security, SAML.

3a Poslovne storitve.

Poslovna odzivnost, podpora hitrim notranjim spremembam.

Poslovni procesi čez celotno poslovno domeno.

Ponovna uporaba. Dostopnost. Poslovna pravila. Dogodkovno proženi procesi. Kompozitne aplikacije.

Partnerstvo IT in poslovnih oddelkov. Upravljanje z življenjskim ciklom SOA. Zaveza vodstva. Sposobnost načrtovanja na podlagi dogodkov. Podpora vodstva poslovne enote.

WS-BPEL.

3b Sodelujoče (collaborative) storitve.

Poslovna odzivnost, sodelovanje z zunanjimi partnerji.

Storitve so na voljo zunanjim partnerjem.

Omogočanje zunanjih storitev. Varnost čez celotno poslovno domeno, podjetje. Dalj časa trajajoče transakcije.

RosettaNet, ebXML, WS-Trust.

4 Merjene poslovne storitve.

Takojšne spremembe poslovnih procesov. Metrike poslovnih procesov.

Poslovna enota ali celotno podjetje. Povezanost med podjetji.

Spremljanje procesov. Procesiranje dogodkovnih tokov. Procesiranje kompleksnih dogodkov. Nadzor nad procesnimi dogodki.

Ažurno modeliranje in spremljanje procesov. Sponzorstvo finančnega direktorja.

5 Optimizirane poslovne storitve.

Avtomatična optimizacija poslovanja.

Poslovna enota ali celotno podjetje. Povezanost med podjetji.

Avtomatizacija optimizacije na podlagi dogodkov.

Kultura stalnega napredka, izboljšanja. Sponzorstvo generalnega direktorja.

Tabela 2: Cilji in ključne prakse modela Sonic.[1]

Nivo zrelosti Ključni cilji Ključne prakse

1

Prve storitve.

1. Učenje SOA. 2. Uporaba storitvenega pristopa

za trenutne potrebe podjetja. 3. Definicija merjenja donosnosti

(ROI) za prve SOA projekte.

1. Definicija storitev. 2. Integracija SOA v

metodologijo razvoja. 3. Ovrednotenje stroškov, časa,

poslovnih prednosti pilotskih projektov.

2

Načrtovane storitve.

1. Predpisati uporabo SOA. 2. Vzpostaviti vodenje storitvene

arhitekture. 3. Dokazati donose zaradi

uporabe standardov. 4. Predvideti uporabo SOA za

optimizacijo poslovanja.

1. Specifikacija tehnoloških standardov SOA.

2. Integracija SOA v razvoj čez celotno podjetje.

3. Poskrbeti za izobraževanje čez celotno podjetje.

4. Postopna integracija.

3a

Poslovne storitve.

1. Za upravljanje s SOA ustvariti trajno partnerstvo med poslovnimi in tehnološkimi deli organizacije.

2. Polna podpora poslovnim procesom s SOA.

3. Dokazati donose pri ponovni uporabi in odzivnosti na spremembe.

1. Predpisi za uporabo SOA pri definiciji novih in spremembah obstoječih procesov.

2. Uporabiti prednosti dogodkovne naravnanosti in uporabo mediacij pri izboljšavi poslovnih procesov.

3b

Sodelujoče (collaborative) storitve.

1. Razširiti poslovne procese na zunanje partnerje.

2. Dokazati donosnost uporabe 'sodelujočih' storitev.

1. Predpisi za uporabo SOA pri sodelujočih partnerjih.

2. Implementacija varnostne politike čez celotno podjetje.

4

Merjene poslovne storitve.

1. Predpisati transformacijo podjetja za izvajanje procesov v realnem času.

2. Opredeliti poslovne metrike.

1. Zbiranje in analiza metrik. 2. Implementacija obstoječih

procesov, presoja in predelava.

5

Optimizirane poslovne storitve.

1. Vodenje poslovnega in SOA upravljanja čez celotno podjetje.

2. Dokazati donose SOA podprtega izboljševanja poslovanja.

1. Implementacija procesov, ki se samodejno izboljšujejo.

4.2 Zrelostni model OSIMM

OSIMM (Open Group Service Integration Maturity Model – Verzija 2) predlaga način

merjenja nivoja storitvene integracije organizacije, njihovih informacijskih sistemov in

poslovnih aplikacij. Dodatno ponuja usmeritve in vprašalnike za doseganje posameznih

nivojev storitvene zrelosti in oceno poslovnih prednosti.

OSIMM predpisuje sedem dimenzij spremljanja s po sedmimi nivoji zrelosti. Vsak nivo

predstavlja občutno povečanje zrelosti pri zavedanju in implementaciji storitvene

arhitekture. V modelu tako napredujemo v zrelosti storitvene integracije, sam model pa je

lahko uporabljen tudi za oceno zrelosti SOA napredka. Čeprav obstaja veliko tehnik in

tehnologij za izvedbo storitvene arhitekture, model OSIMM vključuje vse, tudi novo

razvijajoče se tehnike, kot je na primer računalništvo v oblaku, sam model pa spodbuja

razširjanje modela z lastnimi dognanji. Ogrodje je namenoma zastavljeno tako, da ga je

mogoče razširiti z novimi koncepti. OSIMM je predstavljen kot orodje z vprašalniki in

definiranimi utežmi za posamezne nivoje, ki jih podjetje dosega ali želi doseči. Zastavljen

je kot neodvisen glede na ponudnike rešitev in je prosto dostopen. Za hiter pregled so

nivoji z zahtevanimi zmožnostmi glede na posamezno domeno predstavljeni v matriki

zrelosti.[11]

Slika 15: Matrika zrelosti modela OSIMM.[11]

4.3 Zrelostni model korporacije ORACLE

Oracle SOA Maturity Model definira naslednje ključne koncepte: zmožnost – sposobnost

(capability), domeno, zrelost in uveljavitev – sprejetje. Skoraj 90 zmožnosti (capabilities),

ki povzemajo tudi najboljše prakse, je bilo zbranih na podlagi izkušenj pri delu z različnimi

podjetji. Le-te predstavljajo podrobnosti, s katerimi lahko merimo in nadgrajujemo zrelost

storitvene arhitekture.[6]

Tehnologija

Organizacijske vede

Infrastruktura

Arhitektura Poslovna strategija

Organizacija

Informacija

Projekt in portfelj storitev

Upravljanje

Administracija in upravljanje

Slika 16: Domene zrelosti SOA po modelu Oracle.[6]

Za merjenje zrelosti in sprejetosti se spremlja osem domen:[6]

poslovna strategija s konstrukti, kot so: poslovna motivacija, pričakovane

izboljšave, pričakovani stroški, omogočanje napredovanje v SOA iniciativi;

arhitektura zagotavlja oziroma predpisuje celovito arhitekturo ter smernice

skladnosti pri uporabi;

infrastruktura se ukvarja z orodji in infrastrukturo s tehničnega vidika omogočanja

storitvene arhitekture;

informacija zajema zmožnosti z vidika informacije, kot je na primer IaaS –

informacija kot storitev; zajema skupne podatkovne modele, oblike sporočil,

upravljanje z matičnimi podatki, upravljanje vsebin itd.;

projekti in portfelj storitev – v tej domeni se model ukvarja s planiranjem in z

razvojem storitev ter napotki za uporabo le-teh;

administracija in upravljanje je pogled na zrelost po namestitvi v produkcijsko

okolje;

organizacijska domena je vidik usposobljenosti celotnega podjetja, njegove

strukture in razvoja veščin, ki so potrebne za učinkovit prehod na storitveno

arhitekturo;

upravljanje – Governance: zadostna mera upravljanja je glavni indikator pri

prehodu na storitveno arhitekturo.

Za uspešno uvedbo storitvene arhitekture je glede na model potrebno sočasno

napredovanje v vseh osmih domenah, ključnega pomena pa je identifikacija

pomanjkljivosti v posamezni domeni. Model zato predlaga opise posameznega nivoja, ki

naj bi karseda zmanjšal subjektivno oceno dosežene ravni. Zrelost posamezne domene

se meri v šestih nivojih, z enakim številom nivojev se lahko spremlja tudi sprejetost v

celotni organizaciji.

Slika 17: Merjenje zrelosti in sprejetosti SOA.[6]

4.4 SOA zrelostni model družbe HP

Ocena zrelosti SOA, kot jo predlagajo v družbi Hewlett Packard, temelji na dveh ključnih

delih. V prvem delu se ocenjuje sredstva in zmožnosti, kar imenujejo SOA ocena zrelosti

(SOA Maturity Assessment), in je prikazano na sliki 18. Preveri in oceni se tudi razpon

sredstev in zmogljivosti, ki so zahtevane za uspešno uvedbo SOA. V drugem delu sledi

ocena SOA agilnosti (SOA Agility Assessment). Preveri se samo podjetje in njegova

sposobnost preoblikovanja. Ocena se v osnovi vrši na HP SOA domenskem modelu, ki

predstavlja poenoteno ogrodje za oceno tako zrelosti kot agilnosti.[13]

HP SOA domenski model

Nivoji zrelosti

Domene

Trenutno stanje Želeno stanjeAnaliza agilnosti

Načrt SOA transformacije

Slika 18: Proces HP ocenjevanja zrelosti SOA.[13]

HP SOA domenski model definira osem področij ocenjevanja: poslovno (business),

človeško (people), vodstveno (program management), upravljalsko (governance),

arhitekturno (architecture), tehnološko za podporo (enabling technologies), poslovanje in

upravljanje (operations and management) ter ponudbo in povpraševanje (supply and

demand). Podobno kot ostali modeli za posamezno domeno definira pet nivojev zrelosti,

ki jih lahko dosežemo pri uvajanju SOA. Z osnovno matriko, prikazano v tabeli 3, lahko

dobimo visokonivojski pregled nad zrelostjo podjetja.

Tabela 3: Vrhnji nivo HP zrelostnega modela.[13]

Nivoji 1. Ad-Hoc 2. Osnovni 3. Standardizirani 4. Upravljani 5. Prilagodljiv

Poslovna domena.

Minimalen interes za SOA.

Zavedanje SOA.

Vsesplošno skladen s SOA.

SOA kot aktivna podpora.

Osnova za poslovanje je SOA.

Vodstvena domena.

SOA prisotna na nivoju projekta.

SOA prisotna na nivoju poslovne enote.

SOA med vsemi enotami (Federated not Integrated).

SOA na nivoju celote.

SOA razširjena do partnerjev.

Upravljanje. Nekaj prepoznanih težav.

Nekaj procesov, individualna odgovornost.

Definirane in uporabljene smernice.

Razumevanje doprinosa upravljanja.

Napredno razumevanje upravljanja.

Arhitektura. Omejena oziroma neučinkovita arhitektura.

Arhitektura je dobro zastavljena.

Vse iniciative IT so skladne.

Poslovno usmerjena in povezana.

Arhitektura in poslovanje sta povezana.

Poslovanje in upravljanje.

Ni upravljanja storitev, samo določeni elementi infrastrukture.

Delno upravljanje.

Upravljanje poslovnih storitev.

Aktivno upravljanje s storitvami povezanimi z osnovnimi komponentami.

Integrirano upravljanje storitev v samo operativno upravljanje.

Ponudba in povpraševanje.

Poslovne potrebe zadovoljene s tehničnimi komponentami.

Interno zagotovljene storitve.

Vrednotenje na podlagi virov.

Viri iz različnih ponudnikov.

Dinamična izbira virov različnih ponudnikov.

Ljudje. Malo ali nič SOA znanja.

Znanje omejeno na vodstvo IT in arhitekte.

SOA znanje zahtevano za ves IT.

Neprestano izobraževanje za vse zaposlene.

SOA sprejeta v celoti.

Tehnologije za podporo.

Ni storitveno podprte infrastrukture.

Omejena SOA infrastruktura.

SOA kot standard čez celotno podjetje.

Infrastruktura, ki omogoča upravljanje SOA.

Integrirana dinamična SOA infrastruktura.

Visokonivojski pogled nad SOA zrelostjo podjetja se izdela s podrobno razdelanimi

poddomenami, ki morajo za vsak nivo vsebovati tudi natančen opis doseženega nivoja.

Posamezne domene ali poddomene pa so nadalje ocenjene s hipotezami, kot to prikazuje

slika 19. Hipoteze zagotavljajo utemeljitve za posamezne zmožnosti (capabilites).[13]

4.5 Model ESOMM

Vodilo podjetja Microsoft je bila pri snovanju modela potreba po preprostem ocenjevanju

in načrtovanju prehoda na storitveno arhitekturo. Tudi ta model črpa predvsem iz izkušenj

njihovih strank. Osnova za izpeljavo je bil CMM (Carnegie Mellon's Capability Maturity

Model). Model je zasnovan okrog štirih nivojev, razdeljenih na tri poglede. Vsak nivo

zahteva za vsak pogled vpeljavo oziroma obvladovanje treh zmožnosti. Nabor oziroma

matrika, prikazana na sliki 20, je tako zamišljena kot pomoč pri načrtovanju vpeljave SOA.

Prvi nivo, z nazivom uporaben (usable), predpisuje uporabo standardov in protokolov za

načrtovanje ter implementacijo storitev v neki organizaciji. Ponovljiv (repeatable) nivo

naslavlja učinkovit razvoj storitev, namestitev in vzdrževanje storitev. Podporni

(supportable) zajema zmožnosti, potrebne za zagotavljanje zanesljivosti, zagotavljanja

operativne podpore in samopostrežnosti (selfservice). Nivo z imenom razširljiv

(extensible) je vrhunec pri doseganju poslovne prilagodljivosti (agility), ki jo obljublja

storitvena arhitektura. V kasnejših predstavitvah so nivoje modela v predstavitveni matriki

preimenovali v osnovnega, standardiziranega, naprednega in dinamičnega.[10]

Slika 20: ESOMM matrika zmožnosti za posamezni nivo.[9]

Čeprav je model namenjen bolj kot pomoč pri načrtovanju vzpostavitve storitvene

arhitekture, za oceno trenutnega stanja priporoča oceno posameznega nivoja ob začetku

in nato sprotne ocene samega napredka. Ocene naj se po priporočilu raztezajo od 1 do 5

s polovičnimi koraki. Ocena 1 pomeni, da se s tematiko še nismo ukvarjali, medtem ko

ocena 5 označuje, da predstavljene zmožnosti v celoti obvladujemo. Primer ocene je

prikazan na sliki 21. S takšnimi ocenami je po modelu potrebno operirati pri načrtovanju

kratkoročnih in dolgoročnih ciljev pri vpeljavi SOA.[9]

Slika 21: Primer ocene zrelosti posameznega nivoja.[9]

5 PRIMERJAVA MODELOV

Začetni zagon pri poveličevanju storitvene arhitekture in pristopov se je že polegel. Glede

na izkušnje marsikaterega podjetja ali posameznika so bili začetni zagon in pričakovanja

prevelika. Ob pomanjkanju začetnega zavedanja, da bo sprejetje storitvenega načina

razmišljanja dolgotrajen proces za celotno organizacijo, pa je ta zagon še bolj zamrl.

Pojavili so se zrelostni modeli, ki za takšno stanje ponujajo oceno narejenih sprememb in

pomoč pri načrtovanju. V tem poglavju zato želimo primerjati modele in odgovoriti na

vprašanja:

Zakaj so nastali, motivacija, njihova zgodovina?

Ali se sistematično razvijajo, posodabljajo?

Kakšne so razlike in podobnosti?

Kakšne nivoje zrelosti zajemajo in ali ponujajo primerljiv koncept uvajanja

SOA?

Ali ponujajo kakšna orodja za samoocenitev in spremljanje napredka?

Ali ponujajo smernice za uvedbo in nadaljevanje?

5.1 Nastanek in zgodovina zrelostnih modelov

V letu 2005 so pri podjetju IBM začeli z razvojem zrelostnega modela (SIMM), v katerem

storitvene koncepte predstavljajo kot podporo fleksibilnosti informacijskih tehnologij, sam

model pa kot način, kako to speljati skozi sosledje zaporednih korakov. Z letom 2007 je

odgovornost za razvoj modela z imenom OSIMM prevzel neodvisni konzorcij The Open

Group. Ta je bil v osnutku 0.3a v celoti povzet po IBM SIMM. Člani konzorcija so postala

vodilna podjetja na področju SOA, kot so Capgemini, EDS, HP, IBM in drugi. The Open

Group je tako v avgustu 2009 izdelala prvi standard OSIMM Version 1. Ta ponuja model

in metode ocenjevanja pri vzpostavljanju storitvene arhitekture. Nadaljnji načrtovan korak

je bila standardizacija ISO, zato je v 2011 nastala verzija Open Group Service Integration

Maturity Model Technical Standard (Version 2), ki naslavlja komentarje, posredovane s

strani ISO.[11]

Oralce, čeprav član konzorcija The Open Group, ločeno objavlja svoj model v obliki bele

knjige. V večini opaženih komentarjev[3] je razlog predvsem preprostejša predstavitev

vpeljave in nadgradnje SOA, posledično promocija produktov, ki jih podjetje ponuja.

Zadnja verzija je datirana s septembrom 2013.

Podobno je z modeli ostalih proizvajalcev programske opreme. Podjetje Sonic, ki se je

združilo v podjetje Progres, na spletnih straneh sicer ohranja model, ki je nastal v letu

2005, v prosto dostopnih virih pa ni opaziti novih sprememb in dodatkov po letu 2006.

Podjetje HP svoj model predstavlja v obliki članka, datiranega z marcem 2006, Microsoft

pa v omrežju za podporo (MSDN) z aprilom 2006. Vse zadnje objave omenjenih podjetij

nekako sovpadajo z nastankom modela OSIMM v okviru The Open Group.

5.2 Primerjava nivojev zrelosti

Model OSIMM je po našem mnenju v tem pogledu med najkompleksnejšimi in je najbolj

celovit. Merjenje zrelosti je zasnovano na sedmih nivojih. Prvi nivo, z nazivom Silos, je

tako postavljen kot nivo, kjer na področju storitvene arhitekture v podjetju ni nič

izvedenega. Tudi ob doseganju drugega (integrirano) in tretjega nivoja (komponentno) je z

vidika storitvene arhitekture narejenega še zelo malo. Sprejeti so določeni standardi,

postavljena infrastruktura, nekateri deli informacij in poslovanja so že komponentizirani.

Tudi sama matrika nivojev modela prikazuje prve tri nivoje kot temelj za uvajanje

storitvene arhitekture. Četrti nivo zrelosti (storitev) se osredotoča na podporo odprtih

standardov, ki ponujajo neodvisnost glede na pripadajočo infrastrukturo, varnostne

mehanizme in upravljanje SOA gradnikov. Na tem nivoju je poslovanje že razdeljeno na

posamezne storitve, zanje mora obstajati katalog. Peti nivo (sestavljene storitve) tako na

podlagi predhodnih izdelkov že ponuja uporabo BPEL. Zrelost je za podjetja na tem nivoju

že visoka, saj je razvoj agilen in so možne dopolnitve brez večjih rekonstrukcij

programske opreme ter izvedene zgolj s pomočjo poslovnih analitikov. V naslednji stopnji

(virtualizirane storitve) so vse prej definirane storitve na voljo v obliki, ki omogoča, da se

lahko na pripadajoči infrastrukturi klici le-teh spremenijo v klice storitev na drugačnih

protokolih, naslovih, spremenjeni so lahko tudi vzorci sinhronizacije. Takšne storitve so še

bolj šibko sklopljene. Zadnji nivo, ki si ga želimo doseči po modelu OSIMM, so dinamične

storitve. Slednje razvijalcem omogočajo, da izvedejo spremembe in dopolnitve v času

delovanja pod vodstvom poslovnega analitika ali jih celo sistem izvede samodejno.

Oraclov model za razliko od modela OSIMM predpisuje šest nivojev zrelosti in šest

nivojev sprejetosti. Zrelost je za razliko od OSIMM-ovega modela opredeljena v razponu

od 'No SOA' do optimizacije, kjer vsak nivo zase opredeljuje s pristopom k izdelavi in

uporabi storitev. Nivoje so tako raje razdelili še na dodatne zmožnosti, ki pa so nivojsko

definirane za posamezno domeno poslovanja. Hkrati se model ukvarja še s posebej

merjeno sprejetostjo v organizaciji, ki ima razpon v naslednjih nivojih: projektni nivo,

programski nivo (več projektov), enota poslovanja (razpeta čez celoten oddelek),

medoddelčna implementacija storitev in zadnji, najvišji nivo, ko storitveni pristop sprejme

celotno podjetje. Podobno je z Microsoftovim modelom ESOMM, ki svoje štiri nivoje

zrelosti podobno opredeljuje z zmogljivostmi za posamezno domeno.

Modela HP in Sonic/Progress predstavljata pet enakovrednih nivojev podobno kot

OSIMM. Glede na OSIMM je razlika zgolj ta, da je izpuščen prvi ali morda bolje rečeno

ničelni nivo, kjer se SOA pristopa pri razvoju še nismo lotili. V teh dveh modelih se nivoji

ne obravnavajo tako 'tehnično' kot v modelu OSIMM, temveč so kriteriji, vsaj po

predstavljenih matrikah sodeč, združeni v manjšem naboru.

Za vse modele lahko razberemo, da se, kljub razlikam v številu in opisu nivojev zrelosti,

ukvarjajo z razponom čez ključne SOA koncepte, ki bi si pri vpeljavi logično sledili:

standardi, komponentizacija in šibka sklopljenost,

napredna uporaba in spremljanje,

agilnost, dinamičnost razvoja.

Hkrati pa z napredovanjem po nivojih modeli dajejo poudarek tudi nivoju sprejetosti

storitvene paradigme v celotni organizaciji, ki je glede na izkušnje poglavitnega pomena.

5.3 Primerjava dimenzij

Ker SOA pristop ni zgolj tehnična izvedba neke programske rešitve, temveč zahteva

spremembe v celotni organizaciji, je merjenje nivoja zrelosti v vseh modelih razdeljeno na

več dimenzij. OSIMM predlaga merjenje zrelosti za sedem dimenzij:[14]

Poslovni vidik

Poudarek je na poslovnih praksah, kako se definirajo poslovni procesi, kako se jih

strukturira ter kasneje implementira in izvaja. Naslavlja razporejenost informacijskih

tehnologij po celotnem podjetju in obravnava, kako IT podpira spremembe poslovanja ter

zagotavljanja razpoložljivosti informacijske podpore. Poslovni vidik vključuje tudi sprejeto

IT strategijo.

Organizacijsko-vodstveni vidik

Fokus je na sami organizaciji in strukturi podjetja in na tem, kakšno je zavedanje

implementacije storitvene strategije v tej strukturi. Zraven strukture podjetja je potreben

pregled nad vlogami in znanjem, ki so potrebni za vpeljavo oziroma podpora SOA.

Metode razvoja

Ocena temelji na sprejetih postopkih, ki podpirajo spremembe poslovanja in informacijske

podpore pri adaptaciji SOA. Pomembni so vidiki kot npr.: upravljanje z zahtevami, ocena

stroškov, projektno vodenje, zagotavljanje kakovosti, tehnike in orodja za načrtovanje,

razvojni cikel.

Aplikacijsko

Obravnava se zasnova aplikacije, funkcijska razgradnja, ponovna uporaba, razširljivost,

razumevanje, enotna uporaba najboljših praks, celostna shema in objektni modeli.

Arhitekturno

Obravnava se sestava arhitekture: topologija, tehnike integracije, arhitekturne odločitve,

uporaba standardov, dosedanje izkušnje v SOA implementaciji, kriteriji za skladnost s

SOA pristopom. Preverjajo se že izdelani artefakti.

Informacijsko

Zanima nas, kako so sestavljene/strukturirane informacije oziroma podatki, kakšni so

modeli, kakšne so metode dostopa do informacij, abstrakcija informacije s funkcionalnega

vidika, značilnosti podatkov, zmožnost preoblikovanja podatkov, definicija storitev in

procesov, upravljanje z identifikatorji, upravljanje z znanjem, poslovni informacijski model,

upravljanje vsebine.

Upravljanje infrastrukture

Poudarek je na zmogljivostih infrastrukture, upravljanjem s storitvami, administraciji,

doseganju zahtevane ravni obratovanja storitev ter spremljanju infrastrukture (monitoring).

Sam model za posamezno domeno predlaga oceno nivoja z naborom vprašanj, ki so

povezana z indikatorji zrelosti.

Oraclov model, podobno kot OSIMM, uvaja osem primerljivih domen ter dodatno

opredeljuje zgolj upravljanje (Governance) kot lasten vidik, ločen od poslovnega. Za

oceno stanja v posamezni domeni je le-ta opisana z naborom zmožnosti, ki morajo biti

usvojene.

Tudi HP-jev model definira osem domen spremljanja. Kot posebnost glede na model

OSIMM se izkaže domena ponudbe in povpraševanja, ki v poslovnem smislu izkorišča

zmožnost hitrega preoblikovanja tako pri ponujenih kot pri povpraševanih storitvah.

Sonicov model predstavlja pet domen: poslovni učinki, obseg, tehnološki faktorji uspeha,

človeški in organizacijski faktorji uspeha, pomembni standardi. Domene so definirane s

posameznimi cilji, ki naj bi jih dosegli v nekem nivoju zrelosti. Zdi se, kot da model ponuja

le smernice za napredovanje v zrelosti, kjer je potrebno v vseh domenah po nivojih

napredovati sočasno. Temu primerno so zastavili še matriko ključnih ciljev in potrebnih

usvojenih praks.

Microsoftov model je naravnan zgolj na tehnično izvedbo SOA in se ukvarja s tremi

domenami: administracijo storitev, uporabo storitev in njihovo implementacijo.

5.4 Primerjava namena modela (samoocenitev, smernice, orodja)

Model OSIMM za vsako domeno ponuja osnovni podmodel za oceno zrelosti in tudi

načrtovanje prehodov na višji nivo. V sklopu podmodela je pripravljen vprašalnik (tabela 4

prikazuje osnovni vprašalnik za poslovno domeno) in preslikava odgovorov v zrelostne

indikatorje oziroma njegove atribute. Tabela 5 prikazuje primer osnovne preslikave

vprašalnika in pripadajoče uteži. S pomočjo uteži se za posamezno domeno določi

najbližji nivo zrelosti.[11] Model sam v prvi vrsti priporoča razširjanje indikatorjev in

pripadajočih atributov ter dopolnjevanje vprašalnikov na podlagi pridobljenih izkušenj. Tudi

sam model je predstavljen kot razvijajoče se priporočilo ob razvijajoči se implementaciji

SOA v podjetju. Vrednost modela v smislu samoocenitve pri transformaciji podjetja v SOA

je ravno sprejetje upravljanja SOA, ki naj vključuje tudi spremembe zrelostnega modela.

Tabela 4: Osnovni vprašalnik OSIMM za poslovno domeno.[11]

1. Kaj so glavna poslovna gonila za SOA iniciativo?

2. Kakšna sta poslovna vizija in cilji ter kako se ti nanašajo na to, kar počne IT oddelek?

3. Je vaša trenutna arhitektura poslovnih procesov formalno definirana, dokumentirana in upravljana?

4. Je arhitektura poslovnih procesov celovita in točna?

5. Kako so zastavljene metrike donosnosti v povezavi z upravljanjem poslovnih procesov?

6. Kako agilni so vaši poslovni procesi?

7. Kakšne so prakse zagotavljanja sredstev?

8. Kakšen je model izračunavanja stroškov?

9. Kdo je lastnik portfelja procesov, aplikacij in storitev?

10. Ali obstaja stroškovni model za zaračunavanje uporabe storitev?

11. Kako so trenutno definirani skupni stroški lastništva (strojna oprema, programska oprema in vzdrževanje)?

12. Kakšno je sodelovanje med nosilci poslovanja in nosilci informacijskih rešitev?

13. Kako se trenutno merijo nivoji poslovnih storitev?

14. Kakšna je trenutna praksa prenosa zagotovljenih poslovnih ravni storitve v dogovorjene IT ravni storitev (SLA)?

15. Ali obstaja celovita arhitektura sistema?

16. Ali obstaja celovito upravljanje arhitekture sistema?

17. Ali obstaja več vrst poslovanja? Ali so zanje potrebne različne vrste procesov?

18. Ali različne vrste poslovanja uporabljajo skupen podatkovni model? So podatki deljeni ali replicirani?

19. Ali si različne vrste poslovanja delijo stranke, dobavitelje in partnerje?

Tabela 5: OSIMM zrelostni indikatorji za poslovno domeno.[11]

Nivo zrelosti Indikator zrelosti

Atributi zrelosti Utež Preslikava vprašanj

Silos (Nivo 1) Izolirano poslovanje.

Formalna definicija poslovnih procesov organizacije.

Slaba ali neobstoječa. Celostna arhitektura ni del IT. Poslovni procesi niso definirani in dokumentirani. Omejeno obnašanje informacijskih rešitev.

10 2, 15 3 1, 9, 17, 18

Integrirano (Nivo 2) Integracija poslovnih procesov.


Omejena. Ni formalne arhitekture. Omejeni cilji poslovanja in potreba po informacijah drugih oddelkov.

20 15 1, 2, 3, 4, 6, 9, 17, 18, 19

Komponentizirano (Nivo 3) Poslovanje razdeljeno na posamične komponente.


Med oddelki. Obstaja formalna konstrukcija arhitekture. Oddelčni poslovni cilji so prepoznani čez celotno organizacijo.

30 15, 16 1, 2, 9, 17, 18, 19

Storitve (Nivo 4) Posamične komponente poslovanja ponujajo storitve in jih uporabljajo.


Čez celotno organizacijo. Formalna uporaba arhitekture sistema. Poslovni cilji so dokumentirani kot elementi poslanstva podjetja in poslovne arhitekture.

40 3, 15, 16 1, 2, 3, 8, 9, 10, 11, 17, 18, 19

Sestavljene storitve (Nivo 5) Poslovni procesi so predstavljeni kot kompozicija storitev.


Integrirana v celotno organizacijo. Formalna uporaba arhitekture in upravljanje poslovnih procesov. Poslovni cilji so dokumentirani kot elementi poslanstva podjetja in poslovne arhitekture.

50 3, 4, 5, 6, 10, 11, 15, 16 1, 2, 3, 8, 9, 10, 11, 17, 18, 19

Virtualizirane storitve (Nivo 6) Storitve naročene zunaj, BPM, BAM.


Integrirana v celotno organizacijo in s poslovnimi partnerji. Dobro definirana arhitektura, ki opisuje tako notranje procese kot zunanje s poslovnimi partnerji. Uporablja se poslovno merjenje BAM.

60 4, 5, 6, 7, 9, 11, 12, 13, 14, 15, 19

Dinamično preoblikovane storitve (Nivo 7) Storitve s kontekstnim zavedanjem.


Storitve na zahtevo. Dobro definirana arhitektura, ki vsebuje celovito definicijo poslovnih procesov. Modeliranje poslovnih procesov se uporablja za definicijo in testiranje procesov za doseganje definiranih zahtev.

70 5, 6, 13, 15, 16 6, 13, 14

Oracle za hitro oceno zrelosti na svojih spletnih straneh ponuja vprašalnik s 16 vprašanji.

V samem opisu modela za oceno in napredovanje v prvi vrsti priporoča intervjuje za

različne vloge v podjetju. Na podlagi intervjujev se za posamezno od predloženih

zmožnosti poda ocena, iz katere je mogoče narediti prikaz trenutnega stanja in definirati

področja, ki se jim je potrebno posvetiti za napredovanje v zrelosti. Model v osnovi ne

ponuja definiranega vprašalnika in metodologije za vrednotenje odgovorov. Na primerih

zgolj priporoča izdelavo celostnega pogleda in podrobne preglede ocen za posamezno

domeno ter različne vloge, ki nastopajo pri prehodu.

Sonicov model bolj kot samoocenitev ponuja načrt, kako v podjetju implementirati SOA. V

modelu so zato ključnega pomena cilji in prakse, ki jih je potrebno doseči za posamezen

nivo. Čeprav model deli napredek na pet domen poslovanja, so podrobnosti za posamezni

nivo najbolje definirane s tehničnega vidika. Primeri posameznega nivoja so opisani z

uporabo orodij, ki jih ponuja podjetje, ali s partnerji, s katerimi so model sestavili.

HP-jev model išče odgovore na tri ključna vprašanja s pomočjo ocene zrelosti in ocene

agilnosti:

Kje smo?

Kam želimo?

Kaj moramo narediti?

Zrelost se za posamezno domeno in njene poddomene meri preko hipotez in trditev.

Hipoteze dodatno opisujejo posamezne zmožnosti in sredstva, potrebna za dosego

želenega nivoja. Posamezni nivo se za poslovno domeno obravnava kot dosežen, ko so v

celoti izpolnjene vse hipoteze poddomene in domene same. Posamezna trditev ali

hipoteza se ocenjuje kot neizvedena, delno izvedena ali izvedena. Primer ocenjevanja

prikazuje slika 19. Po oceni trenutnega stanja je potrebno narediti načrt za dosego

želenega stanja. Tudi tukaj se uporabijo enake trditve kot pri oceni trenutnega stanja.

Model za posamezne trditve predvideva določene aktivnosti in hkrati skrbi za njihove

medsebojne odvisnosti. Za posamezni nabor aktivnosti so pripravljeni posamezni projekti,

ki jih je potrebno izvesti za napredovanje v zrelosti. Glede na model je ocena trenutne

zrelosti in načrtovanje aktivnosti za napredovanje premalo. Potrebno je izvesti še oceno

agilnosti, kot posebej pomembne zmožnosti, ki jo želimo doseči z vpeljavo storitvene

arhitekture. Za merjenje agilnosti so tako pripravljeni vprašalniki, ki nam preko intervjujev

in anket podajo odgovore za tri definirane dimenzije agilnosti:

čas – hitrost, s katero smo sposobni implementirati spremembe infrastrukture in

poslovnih procesov,

razpon – razpon sprememb, ki smo jih sposobni predstaviti ali podpreti,

enostavnost – ogrodje, s katerim smo sposobni spremembo predstaviti ali

podpreti.

Poslovne storitve je potrebno oceniti s poslovnega vidika, le-te pa so vezane na samo

industrijo. Zaradi tega so tudi vprašalniki za oceno agilnosti prirejeni za posamezno

industrijo. Pri oceni agilnosti je eden ključnih pokazateljev razmerje med potrebo po

agilnosti za posamezno storitev in dosežena agilnost. Na sliki 22 je prikazan primer grafa

ocene agilnosti. Agilne storitve se bodo nahajale na desni strani grafikona, tiste, s katerimi

se je potrebno ukvarjati, pa pri vrhu.

Slika 22: Analiza agilnosti posameznih storitev.[13]

Microsoft v svojem modelu sicer opisuje uporabnost tako za določanje trenutnega stanja

kot vodilo pri načrtovanju vzpostavitve SOA. Model je zaradi zgolj tehnične naravnanosti

preprost in tako zajema zgolj zmožnosti, ki jih v celoti obvladuje IT podpora organizacije.

Tabela 6: Povzetek rezultatov primerjave zrelostnih modelov

OSIMM Oracle Sonic HP Microsoft

Zgodovina –

nastanek,

razvoj

0.3a povzeto po IBM

SIMM.

V1 2009.

V2 2011.

Članek

nazadnje

posodobljen

2013.

Začetek 2005

Sonic.

Zadnji članek

2006.

Članek 2006. Članek 2006.

Dostopnost Za člane Open Group je

opis dostopen na spletu.

Prosto dostopen

članek.

Prosto dostopen

članek.

Prosto dostopen

članek.

Prosto dostopen

članek.

Nivoji

zrelosti

7 6 5 5 4

1. Silos.

2. Integriran.

3. Komponentiziran.

4. Storitve.

5. Sestavljene storitve.

6. Virtualizirane storitve.

7. Storitve spremenljive v

izvajanju.

1. Brez SOA.

2. Priložnostno.

3. Oportunistično.

4. Upravljano.

5. Optimizirano.

1. Začetne storitve.

2. Strukturirane

storitve.

3. Sodelujoče,

poslovne storitve.

4. Merjene

poslovne storitve.

5. Optimizirane

poslovne storitve.

1. Priložnostno.

2. Osnovni.

3. Standardizirani.

4. Upravljani.

5. Prilagodljiv.

1. Osnovni.

2. Standardizirani.

3. Napreden.

4. Dinamičen.

Obseg –

dimenzije in

domene

7 8 5 8 3

1. Poslovna.

2. Organizacija in

upravljanje.

3. Metodična.

4. Aplikacijska.

5. Arhitekturna.

6. Informacijska.

7. Infrastruktura in

upravljanje.

1. Poslovna.

2. Arhitektura.

3. Infrastruktura.

4. Informacija.

5. Projekti in

portfelj storitev.

6. Administracija.

7. Organizacijska

domena.

8. Upravljanje –

Governance.

1. Poslovni učinki.

2. Obseg.

3. Tehnološki

faktorji uspeha.

4. Človeški in

organizacijski

faktorji uspeha.

5. Pomembni

standardi.

1. Poslovno.

2. Človeško.

3. Vodstveno.

4. Upravljanje .

5. Arhitektura.

6. Tehnologije za

podporo.

7. Poslovanje in

upravljanje.

8. Ponudbo in

povpraševanje.

1. Administracija.

2. Uporaba.

3. Implementacija.

Orodja za

oceno

http://www-

01.ibm.com/software/soluti

ons/soa/soaassessment/

https://soa.oracle-

dashboard.com/en

Namen Samoocenitev za

celotno organizacijo.

Smernice za

napredovanje za

celotno organizacijo.

Možnost razširjanja.

Samoocenitev

za celotno

organizacijo.

Smernice za

napredovanje

za celotno

organizacijo.

Samoocenitev

za celotno

organizacijo.

Smernice za

napredovanje za

celotno

organizacijo.

Samoocenitev

za celotno

organizacijo

ločena na

tehnično

doseženo

raven in

sposobnost

podjetja za

sprejetje

zahtevanih

sprememb.

Smernice za

napredovanje

za celotno

organizacijo.

Samoocenitev

osredotočena

na tehnični

vidik.

Smernice za

napredovanje

osredotočene

na tehnični

vidik.

6 POENOSTAVLJEN PRISTOP K OCENI ZRELOSTI SOA

Poenostavljen pristop k zrelostnim modelom predlaga Parkitny A. v svojem članku, kjer

obravnava tri osnovne vidike razvoja in ocene obstoječih rešitev:[12]

poslovna analiza,

zasnova,

izvajanje.

Avtor predpostavlja, da sta upravljanje s spremembami (Governance) in življenjski cikel

vzdrževanja (Life cycle) v organizaciji dorečena in podprta s programsko opremo.

Na posamezna področja je mogoče gledati ločeno z različnimi ekipami, ki morajo biti

sestavljene iz kompetentnih posameznikov. Kot pomoč je naveden model OSIMM, ki naj

služi kot kontrolni seznam.

Predlagana ocena poslovne analize je predstavljena na sliki 23 in temelji na pregledu

dokumentiranih procesov v podjetju.

Poslovna analiza

Ali so poslovni procesi dokumentirani?

Dokumentiranje poslovnih procesov

NE

Pregled obstoječe dokumentacije poslovnih

procesov

DA

So poslovni procesi izolirani?

So poslovni procesi integrirani čez

poslovne domene?

So poslovni procesi integrirani s poslovnimi

funkcijami?

So poslovni procesi integrirani s storitvami?

So poslovni procesi integrirani s

sestavljenimi poslovnimi storitvami?

Zrelostni nivo: silos

Zrelostni nivo: integriran.(tesno sklopljen)

Zrelostni nivo: komponentiziran.(tesno sklopljen)

Zrelostni nivo: storitve.(šibko sklopljen)

Zrelostni nivo: sestavljene storitve.

(šibko sklopljen, orkestracija z BPEL)

DA

DA

DA

DA

DA

Nadaljnja obravnava

Nadaljnja obravnava

Nadaljnja obravnava

Nadaljnja obravnava

Slika 23: Predlagan postopek ocene zrelosti za vidik poslovne analize.[12]

Drugi vidik, zasnova programske opreme, zahteva kategorizacijo posameznih komponent

celotne informacijske podpore. V kolikor so te že upravljane z SOA modelom, jih je

potrebno preprosto izluščiti, ostale gradnike pa kategorizirati. V prvi vrsti so komponente,

ki niso storitveno zastavljene, večinoma podedovane od starejših sistemov. Nadalje so

komponente, ki so sicer tehnično zastavljene kot storitve, a so zgrajene za potrebe

specifične programske opreme, ne ozirajoč se na sprejete standarde SOA. Zadnje so

komponente, ki so definirane in skladne z zahtevami storitvene arhitekture, sprejetimi v

organizaciji. Postopek ocenitve zasnove programske opreme je predstavljen na sliki 24.

Ocena in napredovanje

v zasnovi

Ocena inventarja obstoječih komponent

Komponente podedovanih

sistemov

Neskladne komponente

Skladne komponente



Zrelostni nivo: storitve

Uporaba sprejetih SOA standardov

Uporaba sprejetih SOA standardov

Izvedba standardnih storitev

Izvedba poslovnih storitev

Zrelostni nivo: sestavljene

storitve

Slika 24: Predlagan postopek ocene in vpeljave zrelosti SOA z vidika zasnove

programske rešitve.[12]

Zadnji vidik v predlagani oceni je podoben predhodnemu. Komponente razvrstimo na

samostojne aplikacije, integracijske komponente (ne SOA), skupno ponovno uporabljeno

infrastrukturo, samostojne komponente, ki so skladne s sprejetimi SOA standardi, in

medsebojno integrirane SOA komponente. Samostojne aplikacije so ocenjene kot silosi.

Integrirane aplikacijske komponente sicer niso združljive s sprejetimi SOA standardi, a jih

ocenimo kot nivo integriran. Infrastrukturo, kot so skupni aplikacijski vmesniki, ocenimo

kot komponentiziran nivo. Z rastjo vpeljave SOA zrelosti se storitve, ki so vpeljane po

sprejetih standardih in tako tudi zavedene, označijo kot nivo storitve. Šele ko bodo te

storitve izhajale iz poslovnega nabora in bodo sestavljene iz storitve predhodnega nivoja

jih lahko označimo kot kompozitne storitve.[12]

Ocena izvajalnega

okolja

Nivo: SilosKomponente samostojnih aplikacij

Integracijske komponente

Skupna, ponovno uporabljena

infrastruktura

Projektno zastavljene komponente skladne s

SOA

Integrirane SOA komponente

Razvrščanje obstoječih komponent

Nivo: Integriran

Nivo: Komponentiziran

Nivo: Storitve

Nivo: Sestavljene storitve

Slika 25: Predlagan postopek ocene za vidik izvajalnega okolja.[12]

6.1 Primer ocene zrelosti obstoječe rešitve

V okviru prenove informacijskega sistema elektrodistribucijskih podjetij se je v sklopu

projekta prenove implementirala tudi informacijska podpora procesu menjave dobavitelja.

Cilj prenove informacijskega sistema je bila tudi vpeljava storitvene arhitekture, zato smo

izveden del projekta izbrali za primer in na njem poskusili oceniti zrelost storitvene

arhitekture.

Menjava dobavitelja je proces, ki omogoča odjemalcu električne energije izbiro

dobavitelja. Proces zaradi preverjanja podatkov merilnega mesta in pridobivanja

števčnega stanja porabljene energije upravlja operater distribucijskega omrežja. Na sliki

26 je prikazan proces menjave dobavitelja.

Dobavitelj električne energije

Oddaja vloge Dopolnjevanje vlogeMenjava odobrena Menjava izvedena

Operater distribucijskega omrežja

Pregled vlogePridobivanje podatkov o

merilnem mestuVloga popolna

Pridobivanje števčnega stanja

Izvedba menjave dobavitelja

NE

DA

Slika 26: Proces menjave dobavitelja električne energije.

Osnovni pogoj za poenostavljeno oceno zrelosti je upravljanje storitvene arhitekture. V

podjetju Informatika d.d., ki je izvajalec informacijskih rešitev elektrodistribucijskih podjetij,

je v namene upravljanja podatkovnih shem in storitvenih vmesnikov uporabljen register

storitev WSRR proizvajalca IBM. Procesi so implementirani v BPEL in tečejo na

procesnem strežniku WebSphere. Implementirano imamo verzioniranje posameznih

procesov.

Z vidika poslovne analize je sam proces menjave dobavitelja dokumentiran v BPMN in

integriran z ostalimi poslovnimi domenami, torej zadostuje nivoju zrelosti integriran.

Proces v začetku za potrebe preverjanja vloge uporablja standardno orkestrirano storitev,

to je pridobivanje podatkov o merilnem mestu. V omenjeni storitvi so uporabljene

poslovne storitve za pridobivanje podatkov soglasja za priključitev, podatkov sklenjene

pogodbe o uporabi sistema ter podatkov o nameščeni merilno-krmilni napravi na merilnem

mestu. Podobno je s storitvami za naročanje odbiranja in preverjanja o odčitanem

števčnem stanju, ki se kličejo ob odobreni vlogi, ter storitvah za obveščanje dobavitelja

električne energije o poteku procesa oziroma obravnavi vloge. Na koncu je uporabljena

orkestrirana storitev, ki zapiše spremembo dobavitelja v obračunski sistem in v podatke

merilnega mesta. Z nadaljnjo obravnavo procesa menjave dobavitelja je tako proces, z

vidika poslovne analize, umeščen na nivo sestavljene storitve. Dosežena je šibka

sklopljenost in uporaba sestavljenih storitev oziroma orkestracija z BPEL.

Za oceno vidika zasnove programske opreme je potrebno razvrstiti vse obstoječe

uporabljene komponente, kar prikazuje tabela 7.

Tabela 7: Skladnost uporabljenih komponent s sprejetimi standardi SOA.

Uporabljena komponenta Skladnost s sprejetimi standardi SOA

REST API procesnega strežnika

NE

Soglasje za priključitev DA

Pogodba o uporabi sistema DA

Pridobivanje podatkov o merilno-komunikacijski napravi

DA

Fakturirana realizacija DA

Evidenca sprememb DA

Evidenca zahtev DA

Nalog za odbiranje DA

Obračun DA

Dobavitelj na merilnem mestu DA

Pridobivanje podatkov o merilnem mestu DA

Izvedba menjave dobavitelja DA

Proces menjave dobavitelja DA

Proces menjave dobavitelja kot komponente uporablja sestavljene storitve pridobivanja

podatkov o merilnem mestu, odbirek in izvedbo menjave dobavitelja. Te so orkestrirane

na procesnem strežniku in izvedene s pomočjo uporabe standardnih storitev iz repozitorija

storitev. Tudi sam proces menjave dobavitelja je izpostavljen kot poslovna storitev. Ker

proces ni v celoti avtomatiziran, se pri orkestraciji uporabljajo uporabniška opravila

(Human task). Za implementacijo programske opreme so tako uporabljene tudi REST

storitve, ki jih izpostavlja infrastruktura, konkretno implementacija procesnega strežnika.

Te storitve niso zajete v interno sprejetih standardih SOA, zato lahko proces kot celoto, z

vidika zasnove, umestimo na nivo silos. Slika 27 prikazuje komponente programske

rešitve.

SzP PoUS MKN FR

ES EZ

NZO

OBR DOB

Podatki o MM

Izvedba menjave

Zunanji sistemi

BPEL

BPEL

Menjava dobavitelja

Slika 27: Komponente procesa menjave dobavitelja.

Z vidika izvajanja procesa lahko posamezne storitve uvrstimo, kot je prikazano v tabeli 8.

Posledično informacijsko rešitev z vidika izvajanja umestimo na komponentiziran nivo.

Tabela 8: Razvrstitev uporabljenih storitev.

Storitev Komponentizirane (nivo komponentiziran)

Projektno zasnovane komponente (nivo storitve)

Integrirane SOA komponente (nivo sestavljene storitve)

REST API procesnega

strežnika.

X

Soglasje za priključitev. X

Pogodba o uporabi

sistema.

X

Pridobivanje podatkov o

merilno-komunikacijski

napravi.

X

Fakturirana realizacija. X

Evidenca sprememb. X

Evidenca zahtev. X

Nalog za odbiranje. X

Obračun. X

Dobavitelj na merilnem

mestu.

X

Pridobivanje podatkov o

merilnem mestu.

X

Izvedba menjave

dobavitelja.

X

Proces menjave

dobavitelja.

X

Kratka analiza je pokazala, da je za napredovanje v SOA zrelosti za obstoječo rešitev

potrebno usmeriti pozornost na REST API procesnega strežnika, ga ustrezno umestiti v

sprejete standarde in implementirati kot storitve. Za dosego cilja lahko uporabimo vzorec

za ovijanje obstoječega sistema (Legacy wrapper) ter API po lastnih standardih izpostaviti

kot storitev. Tako bi obstoječo programsko podporo z vseh vidikov postavili na nivo

sestavljenih storitev, kar je glede na poenostavljen pristop najvišji možen dosežen nivo.

7 ZAKLJUČEK

Glede na nadaljnji razvoj posameznih modelov, primerjanih v diplomski nalogi, se le-ti

(razen modela OSIMM) ne razvijajo več, kar nekako sovpada z upadom začetnega

zanosa, ki ga je obljubljala storitveno usmerjena arhitektura. Kljub temu se ti še nadalje

uporabljajo in omenjajo v literaturi. Že sami modeli nakazujejo, da uspešnost storitvenega

pristopa ni odvisna zgolj od obvladovanja tehničnega znanja, temveč je za celovito

preobrazbo potrebno izpolniti še veliko drugih kriterijev. Zaradi različnosti med samimi

poslovnimi okolji je težko definirati enoten pogled in definirati enotne zahteve glede

vpeljave storitvene arhitekture. Primerjani modeli vseeno nakazujejo, da je mogoče

zastaviti lastne osnove, ki jih je potrebno usvojiti.[5]

V nalogi smo se seznanili z osnovnimi principi načrtovanja storitvene arhitekture, preko

spoznavanja zrelostnih modelov pa potrdili domnevo, da omenjena paradigma ni omejena

zgolj na tehnično izvedbo neke rešitve. V kolikor želimo doseči predlagane cilje in

pridobitve iz drugega poglavja, je potrebno vsaj na obsegu projekta izvesti samoocenitev

in definirati želeno stanje, prav na tej točki pa si lahko pomagamo z modeli vpeljave

storitvene arhitekture. Zgolj vpeljava infrastrukturnih rešitev oziroma implementacija

storitev glede na standarde ne bo prinesla pričakovanih rezultatov, v najslabšem primeru

se bo kompleksnost rešitve zgolj povečala.

S spoznavanjem osnov zrelostnih modelov, opisanih v tretjem poglavju, smo izbrali pet

najpogosteje omenjenih zrelostnih modelov, ki smo jih opisali in izluščili njihove glavne

značilnosti. Nadalje smo jih primerjali po nivojih, dimenzijah in namenu, zaradi katerega

so bili izdelani. Večina modelov je po nivojih skladna z dobro znanim modelom CMM, iz

katerega večinoma izhajajo.

SOA zrelostni modeli so z modelom CMM povezani zgolj z nivoji zrelosti, saj je slednji

namenjen definiciji procesov posameznih organizacij in spremljanju njihove rasti. Na drugi

strani se zrelost vpeljave storitvene arhitekture meri na posameznih področjih, doseženi

nivoji pa opisujejo znanja, tehnike, arhitekturo itd.

Na posameznih modelih se vidijo največje razlike v obsegu oziroma dimenzijah, ki jih

obravnavajo glede na celotno organizacijo. Kot najpopolnejši smo v okviru raziskave te

diplomske naloge prepoznali model OSIMM, ki je objavljen tudi kot tehnični standard,

zajema pa področja, ki vključujejo celotno organizacijo oziroma domene poslovanja.

Storitveno usmerjena paradigma je z modelom predstavljena tako, da se je morajo

zavedati vsi deležniki v organizaciji in ni omejena zgolj na oddelke informatike.

Iz analize posameznih modelov je razbrati, da je ob vpeljavi storitvene arhitekture

potrebno veliko dela, ki ga je najbolje izvajati po korakih, skupaj z vpeljavo in razvojem

novih rešitev. Najbolje je po posameznih projektih izvajati samoocenitev in definirati

korake za dosego želenega stanja, izkušnje pa preliti na celotno organizacijo.

Modeli, razen modela OSIMM, so večinoma zastavljeni kot članki oziroma bele knjige, iz

česar je sklepati, da so marketinško naravnani, veliki proizvajalci programske opreme pa

so jih pripravili bodisi v namene reklamiranja svojih infrastrukturnih rešitev ali pa kot

ponudbo za svetovalne storitve. Le model OSIMM je v tem pogledu oblikovan kot

standard.

Ob raziskovanju modelov v splošno dostopnih virih nismo zasledili orodij oziroma aplikacij,

ki bi bile v pomoč pri ocenjevanju zrelosti. Hitre samoocenitve na spletnih straneh IBM in

Oracle so zgolj hitri vprašalniki, ki sicer zagotovijo okvirno oceno, njihov namen pa je

izrazito marketinški.

Glede primerjave modelov je potrebno poudariti, da so nekateri viri za posamezne modele

datirani skoraj desetletje nazaj v obliki belih knjig posameznih proizvajalcev programske

opreme. Kot standard se razvija zgolj OSIMM, kar je posledica dejstva, da so vsi

ponudniki rešitev svoje znanje in izkušnje vsaj delno preslikali v skupen standard. Žal pa

nismo zasledili virov s podatki ali primeri, kako so podjetja uporabila omenjene modele in

kakšni so njihovi doseženi nivoji. S poenostavljenim pristopom smo želeli potrditi, da je

kljub obsegu modelov vpeljave SOA mogoče s kratko in hitro analizo najti pomanjkljivosti

v načrtu ali obstoječi informacijski rešitvi.

Delo bi lahko nadaljevali z raziskovanjem podobnih modelov za nove paradigme, kot je

primer računalništva v oblaku. Z dognanji o obstoječih modelih bi lahko pripravili kratek

vprašalnik za samoocenitev, ki bi uporabniku z malo truda ponudil oceno stanja in

domene, pri katerih je potrebno ukrepati.

VIRI

1. A NEW SERVICE-ORIENTED ARCHITECTURE (SOA) MATURITY MODEL. Sonic

Software Corporation, AmberPoint Inc., BearingPoint, Inc., Systinet Corporation.

Dostopno na: http://www.omg.org/soa/Uploaded%20Docs/SOA/SOA_Maturity.pdf.

[20. 3. 2015].

2. Capability Maturity Model® Integration (CMMISM), Version 1.1 Dostopno na:

http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6217. [12. 1. 2016].

3. Douwe Pieter vand den Bos, Service Oriented Arhitecture & Maturity. Ultrecth: Maj

2012. Dostopno na: http://www.slideshare.net/omebos/soa-maturity-models. [6. 4.

2015].

4. Erl, T., The principles of service-orientation part 1 of 6: Introduction to service-

orientation. Dostopno na: http://searchsoa.techtarget.com/tip/The-principles-of-

service-orientation-part-1-of-6-Introduction-to-service-orientation. [29. 3. 2015].

5. Gerić, S., SERVICE-ORIENTED ARCHITECTURES MATURITY MODELS. Dostopno

na: https://www.mtf.stuba.sk/docs/internetovy_casopis/2008/4mimorc/geric.pdf. [4. 5.

2015].

6. Hensle, B., Manas, D., SOA Maturity Model - Guiding and Accelerating SOA Success.

Redwood Shores: Oracle Corporation, 2013. Dostopno na:

http://www.oracle.com/technetwork/topics/entarch/oracle-wp-soa-maturity-model-

176717.pdf. [20. 3. 2015].

7. Jardim-Goncalves, R., Enterprise interoperability II : new challenges and approaches.

London: Springer, 2007.

8. Meier, F., Service Oriented Architecture Maturity Models: A guide to SOA Adoption?

Skövde: University of Skövde, 2006.

9. Microsoft Service-Oriented Architecture (SOA). Dostopno na:

https://msdn.microsoft.com/en-us/library/bb977471.aspx. [29. 3. 2015].

http://www.techtarget.com/contributor/Thomas-Erl

10. Oellermann, W., Enabling the Service-Oriented Enterprise. Dostopno na:

https://msdn.microsoft.com/en-us/library/bb245664.aspx. [20. 3. 2015].

11. OSIMM Version 2 Technical Standard : Preface. Dostopno na:

http://www.opengroup.org/soa/source-book/osimmv2/preface.htm. [20. 3. 2015].

12. Parkitny, A., An Approach for Assessing SOA Maturity in the Enterprise,

ServiceTehnology Magazine številka 72, 2013.

13. Pugsley, A., Assessing your SOA Program. Hewlett-Packard Development Company,

2006. Dostopno na: ftp://ftp.hp.com/pub/services/soa/info/4AA0-4824ENW.pdf. [20. 3.

2015].

14. Rathfelder, D., Henning Groenda, C., iSOAMM: An Independent SOA Maturity Model.

Karlsruhe : FZI Research Center for Information Technology, Software Engineering,

2008. Dostopno na: https://sdqweb.ipd.kit.edu/publications/pdfs/rathfelder2008a.pdf.

[30. 3. 2015].

15. Service-Orientation Principles. Dostopno na:

http://serviceorientation.com/serviceorientation/index. [3. 12. 2015].

Navodila za pisanje diplomskih nalog UM FERI · 2017-11-28 · Primerjava SOA zrelostnih modelov...

Documents

Transcript of Navodila za pisanje diplomskih nalog UM FERI · 2017-11-28 · Primerjava SOA zrelostnih modelov...