Navodila za pisanje diplomskih nalog UM FERI · 2017-11-28 · Primerjava SOA zrelostnih modelov...
Transcript of 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 SOA zrelostnih modelov
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.
Primerjava SOA zrelostnih modelov
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.
Primerjava SOA zrelostnih modelov
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.
Primerjava SOA zrelostnih modelov
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
Primerjava SOA zrelostnih modelov
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
Primerjava SOA zrelostnih modelov
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
Primerjava SOA zrelostnih modelov
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
Primerjava SOA zrelostnih modelov
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
Abstrakcija kakovosti
Odvisna abstrakcija tehnologije
Povečana funkcijska abstrakcija
Odvisna abstrakcija logike
Abstrakcija kakovosti
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.
Formalna definicija poslovnih procesov organizacije.
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.
Formalna definicija poslovnih procesov organizacije.
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.
Formalna definicija poslovnih procesov organizacije.
Č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.
Formalna definicija poslovnih procesov organizacije.
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.
Formalna definicija poslovnih procesov organizacije.
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.
Formalna definicija poslovnih procesov organizacije.
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: silos
Zrelostni nivo: silos
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].
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].