Unifikovaná definice služby

Unifikovaná definice služby Lukáš Burkoň Katedra informačních technologií Vysoká škola ekonomická Praha [email protected] Abstrakt Pojem služba je pro dnešní dobu velmi důležitým termínem, existuje však celá řada různých definic a kontextů, co tento pojem opravdu obnáší, jaký je jeho obsah a účel. Jako příklady je možné uvést např. fráze business služba, informační služba, webová služba apod. Tato práce se pokusí shrnout základní významy a použití pojmu služba a vytvoří obecnou unifikovanou metodu popisu služby, jež by měla vyhovět všem jejím použitím. Výsledná metoda tedy bude schopna vytvořit parametrizovaný popis služby libovolného významu, účelu a obsahu a ukázat, jak je možné tyto služby vzájemně propojovat. Klíčová slova: Service Modeling, Service Management, IT Service Management, Services Science, Service-Oriented Architecture. Abstract The concept of service is very important for today's times, but there is a wide variety of definitions and contexts, as this concept really entails, what is its content and purpose. It’s possible to mention examples such as business service, information service, web service, etc. This paper will attempt to summarize the basic meaning and application of the concept of service and create a unified method of description of general services, which should meet all its use. The resulting method will be able to create a parameterized description of any meaning, purpose and content and show how it‘s possible to connect these services to each other. Keywords: Service Modeling, Service Management, IT Service Management, Services Science, Service-Oriented Architecture.

1. Služba jako prostředek komunikace Pojem služba je významným a často skloňovaným termínem dnešní doby. Na jeho popularitě se podílí jak rostoucí podíl terciárního sektoru (čili sektoru služeb) vyspělých ekonomik, tak i architektura orientovaná na služby (SOA – ServiceOriented Architecture), která dává standardně vnímanému termínu nový obsah a směr. Služba tedy již není chápána pouze ve svém tradičním významu standardní business služby, ale objevily se i nové významy jako např. služba informační či služba webová. Nové významy pojmu služba přišly ze sféry IT, která se s jejich pomocí snaží v rámci konceptu SOA nastolit jednotnou a srozumitelnou komunikaci businessu a IT a překonat tak nezdary minulosti, kdy tyto dva segmenty nebyly schopny nalézt společnou řeč, což zpravidla vyústilo v řadu neúspěšných a finančně náročných investic do IT, které samotnému businessu nebyly schopny přinést prakticky žádný užitek. IT tedy převzalo pojem, kterému business přirozeně rozumí a snaží se s jeho využitím vytvořit most spojující tyto dvě odlišné sféry – svět businessu se světem informačních technologií.

32

SYSTÉMOVÁ INTEGRACE 3/2009

Unifikovaná definice služby

Popularita pojmu služba v dnešní době přinesla zájem řady organizací o fundovanou analýzu tohoto termínu a jeho explicitní popis a zakomponování do různých existujících frameworků a metodik. Setkáváme se tak např. se třetí verzí knihovny ITIL (Information Technology Infrastructure Library) [1], která snaží ukázat, jak exaktním způsobem využít služeb při řízení a strukturování IT oddělení ve větších organizacích. Na tomto poli dále můžeme najít i bohaté snahy společností IBM, HP či Oracle v podobě disciplíny ITSM (IT Service Management) [16], která se také věnuje tématu řízení IT služeb, avšak kombinuje ho i s technologickou podstatou konceptu SOA, jenž se snaží vytvořit agilní IT prostředí v organizacích na bázi webových služeb schopné vhodně podporovat business cíle. Obdobným způsobem se tomuto tématu věnuje i prof. Voříšek, který v rámci svého modelu SPSPR [3] ukazuje, jak je možné propojit IT a business procesy prostřednictvím vrstvy informatických služeb, která obaluje IT procesy do podoby srozumitelné pro business, jenž je pak schopen tyto služby díky správnému porozumění vhodně využívat. Perspektiva IT však není jediným pohledem, který se tématu služeb věnuje. Z pohledu tradičního businessu je pojem služba stejně tak významným a z tohoto důvodu se zrodil nový vědní obor Services Science, který se službami snaží zabývat spíše z business perspektivy s cílem popsat základní zákonitosti fungování a využívání služeb a jejich úspěšný rozvoj. Tomuto oboru se věnuje spíše řada akademických institucí, avšak je možné najít i snahy společnosti IBM v podobě konceptu SSME (Service Science, Management and Engineering) [15]. Ač dnešní doba oplývá řadou výzkumných a business aktivit v oblasti služeb, tyto aktivity se zpravidla dělí na dva směry – IT pohled a business pohled. IT pohled se v podobě SOA sice snaží proniknout do oblasti businessu a IT funkce tak zaobalit do business služeb srozumitelných business manažerům, avšak stále zde je primární zacílení na IT segment a tyto snahy tedy příliš neřeší ostatní business služby v rámci organizace, jímž schází IT podpora. Business pohled naopak řeší čistě business rovinu služeb, podstatné je zde zacílení na marketing a kontakt se zákazníkem, ovšem na druhou stranu schází řešení technologické a procesní podstaty fungování služeb. Chybí tedy nějaká významná snaha, která by unifikovala oba směry do jednoho konzistentního celku, tzn. popsala prostředí veškerých business služeb v rámci organizace, ukázala, jak je vzájemně propojit a dále jak je zkombinovat se službami informatickými čili realizovat jejich technologickou podporu prostřednictvím konceptu SOA. Tento cíl primárně vyžaduje sjednocení různých významů pojmu služba, tedy jak jeho business podstatu, tak i význam informační či webový. Tímto úkolem se tedy bude zaobírat právě tento článek, čili výstupem tohoto článku by měl být obecný unifikovaný model služeb, jenž bude sestávat z různých sjednocených parametrů. Nastavením hodnot těchto parametrů pak dojde k definici jedné konkrétní libovolné služby a jejího charakteru, ať už půjde o službu business, informační či webovou. Unifikovaný model služby bude postaven na základě už existujících definic a modelů, které budou vhodně sjednoceny. Výsledný model služby následně bude obohacen i o metodu, jak služby na obecné úrovni spojovat a vytvářet tak funkční model kombinovaných služeb v rámci organizace.


33

Lukáš Burkoň

2. Služba z různých pohledů Chceme-li sjednotit různé významy pojmu služba, je nejprve třeba si každý z těchto významů nezávisle definovat a blíže zanalyzovat. Základní pojmy, které budeme využívat, jsou business, IT a webová služba, jež budou dále blíže představeny.

2.1 Business služba Business službou zde bude myšlen původní význam pojmu služba čili úkon, který někdo vykonává pro někoho. Třetí verze knihovny ITIL definuje službu jako [1]: „Služba je prostředek dodávky hodnoty zákazníkům prostřednictvím podpory výstupů, které chtějí zákazníci dosáhnout bez vlastnictví specifických nákladů a rizik.“ Pro porovnání je možné uvést další definici služby z knihy Marketing Management [12]: „Služba je jakýkoliv akt nebo výkon, který může jedna strana poskytnout jiné. Svojí podstatou je služba nehmatatelná a nevyústí ve vlastnictví čehokoliv. Může nebo nemusí být svázána s nějakým fyzickým výrobkem.“ Obě definice se v podstatě shodují na obecné představě služby jako prostředku k dodávce hodnoty zákazníkovi, která se snaží pokrýt jeho cíle bez potřeby vlastnictví specifických nákladů či rizik zákazníkem. Třetí verze knihovny ITIL definuje přímo i pojem business služby, ale dává jej do přímého a nerozdělitelného vztahu k IT službám, čili neuvažuje o čistě business službách bez IT pozadí, a proto tato definice pro nás v tomto kontextu není relevantní a využijeme pouze definice obecné služby. Pojem business služby tedy v podstatě ztotožníme se standardně vnímaným obsahem obecného pojmu služba, přičemž takto obecný pohled pro nás bude žádoucí. Business služba tedy může v rámci své interní logiky obsahovat IT podporu, ale není to povinností. Business služba může být např. poskytnutí úvěru, což je proces, který zpravidla obsahuje podporu IT prostředky v kombinaci s lidským činitelem z běžné bankovní domény. Business služba ale může být např. i údržba domu čili proces, který zpravidla žádným IT pozadím nedisponuje, avšak není to vyloučeno. Zásadní je zde pohled odstiňující technické řešení služby a hlavní důraz je kladen na přidanou hodnotu zákazníkovi a redukce potřeby vlastnictví specifických nákladů či rizik. Business služby je samozřejmě dále možné kategorizovat zpravidla dle doménových oborů, ale podstatný je náhled na poskytovatele a zákazníka služby, jež jsou v tomto ohledu lidé či firmy a ne neživé artefakty. Proto v podstatě i IT služby (viz. dále) je možné chápat jako business služby spadajících do business oboru IT, jelikož každý obor má svá specifika a v tomto ohledu není IT ničím výjimečným, aby bylo nutné IT služby z business množiny vytěsňovat.

2.2 IT služba V kontextu výše popsaného pojmu business služba můžeme IT službu chápat jako jednu z kategorií business služeb, tzn. business doménou je IT a služby tohoto oboru pak můžeme nazývat IT službami. Obdobným způsobem pak můžeme hovořit např. o marketingových službách čili business službách, které poskytuje doménový obor marketing apod. Specifikum IT služeb, které opodstatňuje i jejich 34



zvláštní název, je technologické pozadí většiny těchto služeb, jež se opírá o využití IT technologií a know-how z oboru IT. Nahlédneme-li na dostupné definice IT služby, pak můžeme opět v rámci třetí verze knihovny ITIL nalézt následující definici [1]: „Služba poskytovaná jednomu či více zákazníkům poskytovatelem IT služeb. IT služba je založena na využití informačních technologií a podporuje zákaznické business procesy. IT služba sestává z kombinace lidí, procesů a technologií a měla by být specifikována v rámci dohody o úrovni poskytování služby (SLA).“ Obsah této definice se v podstatě shoduje s výše uvedenou představou a navíc zdůrazňuje použití patřičně nadefinovaného SLA (Service Level Agreement), které specifikuje obsah služby a podmínky její dodávky. Český autor Jiří Skála pak definuje ICT službu, tedy v podstatě IT službu rozšířenou o segment komunikačních technologií, kterou však pro naše účely můžeme bez problémů využít, jako [13]: „Služba ICT je definována jako taková funkcionalita infrastruktury informačních a komunikačních technologií, která umožňuje a / nebo podporuje chod nějakého obchodního procesu.“ Definice Jiřího Skály je v podstatě zkrácenou obecnější verzí výše zmíněné definice IT služby z ITIL, avšak postrádá z mého pohledu důležitou dohodu o úrovni poskytování služby, čili SLA. Zároveň tato definice mluví o ICT službě jako o funkcionalitě, z čehož není zřejmé, zda autor chápe v rámci ICT technologií i lidi a procesy jako ITIL definice, či pouze neživé funkční artefakty. Ze zmíněných důvodů je dle mého názoru pro účel tohoto článku vhodnější definice IT služby z knihovny ITIL. Nakonec můžeme zmínit ještě definici taktéž ICT služby prof. Voříška [3]: „ICT služba jsou aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci (odběrateli, zákazníkovi) služby.“ Poslední velice jednoduchá definice akcentuje především vztah mezi příjemcem a poskytovatelem ICT služby, přičemž jako předmět tohoto vztahu chápe aktivity a informace spadající do oboru informatiky. V porovnání s definicí knihovny ITIL již explicitně nejmenuje subjekty a objekty v pozadí zajišťování ICT služeb, implicitně je ale tato skutečnost zřejmá. Definice by ale mohla z pozice důrazu na samotný vztah mezi poskytovatelem a příjemcem ICT služby obecně specifikovat i formální úpravu tohoto vztahu podobně, jak o tom hovoří definice knihovny ITIL ve formě dohody o úrovni poskytování služby.

2.3 Webová služba Webová služba (resp. webové služby) je dle [2] definována jako: „Rodina technologií sestávající ze specifikací, protokolů a oborových standardů, které jsou využívány heterogenními aplikacemi za účelem komunikace, spolupráce a výměny informací mezi nimi bezpečnou, spolehlivou a interoperabilní formou. Jedná se o základní technologii pro umožnění a realizaci SOA.“ Dle W3C je pak webová služba definována jako [10]: „Webová služba je softwarový systém uzpůsobený k podpoře interoperabilní komunikace mezi počítači skrze síť. Služba disponuje rozhraním ve strojověSYSTÉMOVÁ INTEGRACE 3/2009

35

Lukáš Burkoň

zpracovatelném formátu (konkrétně WSDL). Ostatní systémy interagují s webovou službou způsobem specifikovaným v rámci jejího popisu s využitím SOAP zpráv, obvykle přenesených prostřednictvím HTTP spolu s použitím XML serializace ve shodě s dalšími webově-orientovanými standardy.“ První definice je obecnější, nejmenuje oproti druhé zmíněné definici konkrétní technologie, ve své podstatě ale obě definice hovoří o tom samém. Podstata webové služby již netkví pouze v poskytování činnosti s přidanou hodnotou mezi lidmi či organizacemi, webová služba slouží k umožnění standardizované komunikace mezi softwarovými systémy různé povahy a technologického pozadí. Přestože na první pohled je význam business služeb zcela odlišný od významu služeb webových, je možné zde najít celou řadu společných vlastností. Především jde v obou případech o poskytování určité činnosti s přidanou hodnotou poskytovatelem služby jejímu příjemci, přičemž interní logika této služby je příjemci zpravidla účelně skryta. Dalším společným znakem business služby a webové služby je absence vlastnictví specifických nákladů či rizik příjemcem služby. Chápeme-li dále, dle výše zmíněného, IT služby jako určitou podmnožinu business služeb, pak je kategorie IT služeb službám webovým ještě bližší, než obecný koncept business služby. IT služby se totiž zaobírají informačními technologiemi, mezi něž spadají i technologie, které webové služby využívají. Ostatním sdíleným rysům a jejich standardnímu popisu se bude blíže věnovat následující kapitola.

3. Sjednocení popisu služby Představené definice různých významů pojmu služba je možné společně zobecnit, přestože to na první pohled nemusí být až tak zřejmé. Obdobnou abstrakcí se zabývá např. tzv. COSMO framework [5], který však na problematiku pohlíží ze spíše návrhového pohledu a i přes svou rozsáhlou abstraktnost je velice technické povahy vycházející z predikátové logiky, a tudíž pro běžného člověka není příliš srozumitelný. Můj pohled na sjednocení různých významů pojmu služba tedy má za cíl být více přirozeně srozumitelný, avšak přesto neztratit nic na své obecnosti a komplexnosti. Předchozí část se věnovala srovnání definic různých významů pojmu služba od rozličných autorů. Zde se již zaměříme na podrobnější průzkum pojmu služba v rozdílných kontextech. Budeme se věnovat obecným popisům, které mohou specifikovat veškeré potřebné vlastnosti konkrétní služby. Představena bude kombinace různých přístupů, jak službu popsat, která vyústí v jednotný univerzální celek. Popis samotné služby rozdělíme na 2 základní části, které budou dále blíže představeny:  externí popis služby – popis rozhraní služby, jak je dostupná svému příjemci, resp. zákazníkovi  interní popis služby – popis interní logiky služby, jak ji zpracovává její poskytovatel

3.1 Externí popis služby Rozhraní služby čili její externí popis představuje vrchní vrstvu popisu služby, která je zásadní pro domluvu příjemce služby s jejím poskytovatelem. Rozhraní 36



strukturovanou formou specifikuje obsah a účel služby, způsob a podmínky jejího poskytování apod. V případě business služeb je rozhraní nejčastěji dostupné v podobě SLA (Service Level Agreement) či OLA (Operating Level Agreement), v případě služeb webových je tomu pak WSDL popis (Web Services Description Language [11]). Rozhraní služeb podstatně usnadňuje komunikace obou stran – příjemce služby s jejím poskytovatelem – jelikož zaobaluje samotnou, často složitou interní logiku fungování služby do strukturované schránky, jež je srozumitelná a dostatečně vypovídající svému příjemci, bez nutnosti znalosti vnitřního fungování služby. Budeme-li dále chtít zobecnit základní parametry rozhraní obecné služby, můžeme se na základě zmíněných definic a s pomocí dalších dostupných materiálů ([3], [4], [5], [14]) a logické úvahy dobrat k souboru atributů, který bude dále blíže specifikován. Jednotlivé zobecněné atributy je možné dále dle potřeby dělit i na podřazené atributy, jež komponují vyšší celek, což bude mít za následek tvorbu taxonomické hierarchie vlastností služby.

3.1.1 Identifikace služby Soubor znaků identifikace služby jako její název, který krátkou, ale výstižnou formou specifikuje její obsah apod.

3.1.2 Obsah služby Obsah služby by měl být pro příjemce základním vodítkem pro rozhodnutí, zda tato služba splňuje jeho věcné požadavky. Obsah služby by měl tedy specifikovat její cíl, účel, předmět a výsledek, ale zároveň také negativní vymezení, tzn. co již součástí služby není.

3.1.3 Poskytovatel služby Poskytovatelem služby může být v případě business služeb organizace, skupina či jednotlivec, v případě automatizovaných služeb pak softwarový či jiný neživý systém.

3.1.4 Příjemce služby Příjemcem služby může být stejně tak v případě business služeb organizace, skupina či jednotlivec, v případě automatizovaných služeb pak softwarový či jiný neživý systém.

3.1.5 Cena služby Cena služby má význam zvláště v případě standardních business služeb, avšak měla by být realizována i v případě služeb informatických, resp. webových pro lepší sledování interních nákladů. Cena může mít různou podobu, ať už půjde o standardní paušál, jednorázový poplatek, dynamický model závislý na spotřebovaném množství služby, provizní systém či např. barter. Cena ale nemusí být nutně vyžadována, pak se bude jednat o službu zdarma či jakýsi dar. SYSTÉMOVÁ INTEGRACE 3/2009

37

Lukáš Burkoň

V návaznosti na samotnou cenu služby je důležité definovat i platební podmínky tzn. systém pravidel, na jejichž základě budou realizovány platby poskytovateli služby jejím příjemcem. Cena služby bude dále korespondovat i se systémem měření kvality, který může v souvislosti s úrovní plnění kvality služby definovat bonusy a sankce, které budou uplatňovány v případě nadprůměrně či podprůměrně dodávané kvality služby. Vedle kvality, pak má na charakter a výši ceny taktéž vliv i její kvantita, tzn. různé charakteristiky specifikující čerpaný objem služby jako např. objem přenesených dat, prostor na disku, využití CPU, počet uživatelů, počet hodin technické podpory apod.

3.1.6 Kvantita služby Každá služba nabízí přidanou hodnotu, která, ať už je hmotné či nehmotné povahy, je definována v určité nabízené kvantitě čili objemu. Objemové charakteristiky tak mohou definovat např. počet uživatelů aplikace, počet hodin technické podpory či maximální objem uložených dat. Služby zvláště v oboru IT jsou vyžadovány s vysokou úrovní flexibility, tudíž je podstatné, aby umožňovaly snadnou a rychlou formou změnu spotřebovávaného objemu. Tento princip je nazýván škálovatelností a umožňuje příjemci služby měnit objem spotřeby služby jak v pozitivním, tak i negativním směru v závislosti na jeho aktuálních potřebách a možnostech. Kontrola dodržování kapacit a spotřeby kvantitativních atributů pak zpravidla u většiny služeb bývá jednoduchá a pro obě strany transparentní. U informatických či jiných technologicky založených služeb je možné provádět kontrolu spotřeby a kapacit objemu služeb i automatizovaně.

3.1.7 Kvalita služby Vedle specifikace systému kvantitativních parametrů služby je běžně nutné definovat i atributy kvalitativní. Kvalitativní atributy mohou být vymezovány dle tvrdých či měkkých metrik v závislosti na sledovaných vlastnostech služby. Z pohledu tvrdých metrik tak může být sledována např. dostupnost, rychlost či stabilita služby. Ze zorného úhlu metrik měkkých pak můžeme sledovat např. spokojenost zákazníků, míru zralosti produktu či výslednou úroveň znalostí studentů po dokončení školení apod. Zmíněné metriky stanovují způsob a veličiny, dle kterých bude kvalita služby posuzována, a na základě naměřených hodnot budou následně vyvozovány náležité důsledky. V případě nedostatečné kvality služby budou uplatněny na poskytovatele domluvené sankce a naopak v případě nadprůměrné kvality mohou být poskytovateli uznány přiměřené bonusy specifikované v rámci sekce ceny služby. Z pozice měření kvality je vhodnější využít tvrdých metrik, jelikož se lépe měří a zpravidla jsou objektivnější. V řadě případů ale aplikace tvrdých metrik není možná vzhledem k charakteru obsahu služby. Dále je důležité, aby měření hodnot pro vyhodnocování metrik bylo dostatečně časté a podrobné a z pohledu příjemce transparentní, což má pozitivní vliv na důvěru v poskytovatele.

38



Stejně jako kvantitativní, tak i kvalitativní charakteristiky služby je možné dle potřeby škálovat a umožňovat tak příjemci flexibilně měnit úroveň kvality služby dle jeho aktuální situace.

3.1.8 Pravidla poskytování a spotřeby služby Poskytování a spotřeba služby mohou být upraveny či specifikovány definicí patřičných podmínek a omezení. Mezi zmíněná pravidla můžeme zařadit časové a místní dispozice použití, kontext použití, bezpečnostní restrikce, způsob a možnosti rozvoje služby či různé legislativní možnosti a omezení, které specifikují charakter poskytování a spotřeby služby. V prostředí webových služeb je definována celá řada standardů [2], které tuto problematiku koncepčním způsobem řeší. Jedná se např. o standardy WS-Policy (specifikace a komunikace politik používání webových služeb), WS-Security (zajištění bezpečnosti webových služeb), WS-Resource (provázání webových služeb s jejich disponibilními zdroji) apod.

3.1.9 Způsob poskytování a spotřeby služby Vnitřní procesní logika fungování služby sice má být příjemci skryta, avšak využívání služby příjemcem implikuje kontaktní body, které propojují příjemce s poskytovatelem služby. V případě webových služeb se v podstatě jedná jen o výstupy a vstupy služby specifikované v rámci WSDL, avšak business služby vyžadují daleko hlubší oboustranné propojení procesů poskytovatele a příjemce služby, jelikož služba není zakonzervovaný produkt, ale je naplňována teprve v rámci svého poskytování. Business služba by tedy měla definovat procesní model rozhraní, který musí příjemce implementovat, aby mohl službu od poskytovatele využívat. Tento model obsahuje na jedné straně zodpovědnosti příjemce služby a na straně druhé zodpovědnosti poskytovatele služby a procesní formou jsou tyto zodpovědnosti propojeny obdobně, jako je to řešeno v rámci frameworku pro tvorbu hodnotových řetězců služeb [4]. Procesní model rozhraní služby je kompletní v tradičním vyjádření, kromě procesní logiky tedy obsahuje i potřebné vstupy, výstupy, události, účastníky apod. Dle rozsahu a komplexnosti služby je možné vybrat různé typy modelovacích nástrojů od jednodušších jako je framework pro tvorbu hodnotových řetězců služeb [4], až po robustnější nástroje jako je např. UML. Další kapitoly blíže představí, jak může být tato procesní logika zpodobněna a modelována. Důležité je v tomto kontextu ještě zmínit, že tato sekce zpodobňuje nejdůležitější styčný bod kontaktu interní logiky služby s jejím rozhraním. Způsob poskytování a spotřeby služby tedy tvoří hlavní spojovací článek mezi externím a interním popisem služby. Procesní vrstvy obou popisů se tedy v tomto bodě setkávají a tvoří tak konzistentní celek. Ostatní atributy externího popisu služby ale mají na interní popis také vliv, resp. tento vztah je obousměrný.

3.1.10 Srovnání s jinými popisy služby Výše specifikované rozhraní služby jsem stanovil v této podobě z důvodů dostatečné jednoduchosti a obecnosti. Zmíněný popis jsem zkonstruoval jako SYSTÉMOVÁ INTEGRACE 3/2009

39

Lukáš Burkoň

kompozici a generalizaci popisů jiných (konkrétně jde o specifikaci struktury SLA informatické služby prof. Voříška [3] a p. Učně [14]), přičemž kompatibilita mapování jednotlivých atributů mezi mým a výchozími popisy je přehledně vyobrazena v následující tabulce: Burkoň (v tomto článku navrhovaný popis) identifikace služby obsah služby poskytovatel služby příjemce služby

cena služby kvantita služby

kvalita služby

pravidla poskytování a spotřeby služby

způsob poskytování a spotřeby služby

Voříšek [3]

Učeň [14]

identifikace služby obsah služby poskytovatel zákazník

popis služeb popis služeb poskytovatel kategorie příjemců přesné vymezení počtu a umístění příjemců dané kategorie cena, slevy, sankce a bo- cena služby nusy platební podmínky objemové charakteristiky objem poskytovaných služby služeb; měření škálovatelnost a změny ověřování výkonu služby tvrdé metriky monitorování a reporting měkké metriky kvalitativní charakteristiky měření služby ověřování škálovatelnost a změny tvrdé metriky výkonu služby měkké metriky monitorování a reporting bezpečnost; zálohování a určení a způsobu realizařešení havarijních stavů ce podpory modifikace a upgrade pravidlo pro změny služsystému by; práva a povinnosti vlastnická práva obou stran postavení SLA ostatní podmínky pro realizaci SLA služby podpory a helpnávazné podpůrné služby desku spojené s danou službou

Mé členění vlastností rozhraní služby odpovídá jejímu účelu čili schopnosti popisu libovolného typu služby, tedy nejen služby informatické. Z toho důvodu jsou některé atributy mého popisu velice obecné oproti uvedeným jiným popisům, které slouží výhradně k popisu služeb informatických. Jednotlivé obecné kategorie mého popisu mohou být dále při použití v rámci popisu konkrétní služby blíže rozpracovány a dle domény, kam vybraná služba spadá, zkonkretizovány, resp. rozděleny na více specifických vlastností lišících se obor od oboru, které pak mohou vytvářet sémantický strom.

3.2 Interní popis služby Interní popis služby specifikuje vlastní interní logiku fungování služby. Zde jsem se inspiroval tzv. work system frameworkem [4], který popisuje obecný systém, 40



v rámci něhož jsou vykonávány pracovní činnosti, kam systém fungování služby tudíž spadá. V rámci toho konceptu figuruje pyramida pojmů složená ze 4 vrstev, které vzestupným směrem vytvářejí hodnotu:

Obrázek 1 - Diagram Work system frameworku [4] Pro interní popis služby využijeme spodní 2 vrstvy, které budou dále blíže představeny spolu s nástroji pro reprezentaci interního popisu služby lišící se v závislosti na potřebné míře podrobnosti samotného popisu.

3.2.1 Zdroje Zdroje služby pokrývají veškeré potřebné kapacity pro fungování služby a skládají se z účastníků, informací a technologií. Účastníci představují personální role, jež zajišťují provoz služby či jej do jisté míry ovlivňují. Informace sestávají z veškerých informačních zdrojů, které jsou v rámci fungování služby využívány či vytvářeny. Technologie jsou pak využívány účastníky pro zajišťování obsahu služby.

3.2.2 Procesy a aktivity Procesní vrstva služby definuje, jakým způsobem je zajišťováno fungování z pohledu aktivit. Aktivity vzájemně propojují zdroje služby a zajišťují hodnoty pro příjemce i poskytovatel služby. Tato vrstva je dále napojena na procesní vrstvu rozhraní služby, čímž se logika služby propojuje s procesy příjemce služby a externí popis služby váže na interní, jak již bylo popsáno výše. SYSTÉMOVÁ INTEGRACE 3/2009

služby tvorbu vnitřní se tak

41

Lukáš Burkoň

3.2.3 Vrstvy abstrakce COSMO framework [5] představuje více možností návrhu služby dle různých úrovní abstrakce, což vyjadřuje určitou vnitřní bohatost logiky služby a zároveň rozpad této logiky na vzájemně propojené, ale přesto samostatné, podřazené služby. COSMO framework rozlišuje následující 3 úrovně abstrakce:  jednoduchá interakce – služba jednoduchou formou přímo poskytuje hodnotu příjemci  choreografie – služba představuje bohatý systém interakcí mezi příjemcem a poskytovatelem  orchestrace – služba je realizována jako kompozice služeb ostatních, přičemž poskytovatel služby zde v podstatě vystupuje v pozici koordinátora celého systému propojení služeb V rámci COSMO frameworku je možné tyto 3 vrstvy při procesu návrhu služby vzájemně kombinovat a vyjádřit tak libovolně spletitou interní logiku služby. Služba sama o sobě tak může být kompozicí služeb ostatních, přičemž tyto služby mohou být už jednoduché, složitější, ale také kompozitní povahy. Tento způsob návrhu služeb bude mít za následek tvorbu sítí propojených služeb, což bude blíže představeno v další kapitole.

3.3 Třída vs. instance služby Zmíněný externí a interní popis služby je abstraktním zobecněním vlastností různých významů pojmu služba. Tento popis je tedy v podstatě obdobou definice třídy v objektovém programování. Konkrétní služba pak je specifikována pomocí patřičného nastavení daných abstraktních parametrů, resp. jejich zkonkretizováním, hierarchickým rozpadem a výběrem náležitých podřízených atributů. Budeme-li pokračovat v objektové terminologii, tak konkrétní služba je pak jakousi instancí služby obecné. Představený popis služby je velice obecný, spíše definuje základní pojmy a vztahy mezi nimi. Pro popis konkrétní instance však bude potřeba vhodného popisného nástroje. Stejně jako COSMO framework i můj popis se snaží být spíše univerzální a nezávislý na konkrétním modelovacím nástroji. Proto tento popis v prvé řadě definuje základní pojmy a jejich vztahy. Specifikace konkrétní instance služby pak může být popsána kombinací různých nástrojů, jejichž výběr se bude odvíjet od charakteru dané služby. Pro specifikaci instancí obecnějších business služeb tedy budou vhodnější spíše jednodušší nástroje srozumitelné širokému poli uživatelů. Mezi tyto nástroje je možné zařadit např. tzv. Work system snapshot [4], který představuje přehlednou tabulku specifikující základní parametry systému provozu činností jako zákazníci, produkty a služby, procesy a aktivity, účastníci, informace a technologie. Tento nástroj by byl poupraven, aby obsahoval pouze části specifikující parametry dané služby. Interní logiku instance business služby a procesní vrstvu jejího rozhraní je možné snadnou formou specifikovat pomocí nástroje Service Responsibility Table [4], což je opět jednoduchá tabulka popisující dílčí aktivity mezi příjemcem a poskytovatelem v rámci vztahu poskytování služby. Tabulka má dynamický počet sloupců, které mohou být vybírány dle potřeby, kde každý sloupec dále popisuje jisté hledisko blíže rozvíjející dílčí aktivitu. Jako další sloupce tabulky je možné 42



zařadit např. potenciální problémy, použité technologie, použité informace, cíle a požadavky, business pravidla, výkonnostní metriky apod., čili libovolná hlediska, jež konkrétní organizaci v daném kontextu nejlépe představí veškeré důležité atributy aktivit daného procesu. Zmíněné jednodušší nástroje sice nejsou natolik přesné a konkrétní, ale v řadě případů postačí. Slouží především pro manažery bez hlubší znalosti IT a modelování procesů a služeb, aby mohli jednotně a strukturovaně specifikovat poskytované, resp. poptávané business služby. Konkrétní použití těchto nástrojů bude představeno v kapitole 3.5 v rámci praktického příkladu. V případě sofistikovanějších a především automatizovaných služeb však již jsou potřeba mocnější nástroje, které je možné rozdělit do 3 skupin:  nástroje určené pro návrh – UML, BPMN apod.  nástroje určené pro analýzu – OWL-DL, Petriho sítě apod.  nástroje určené pro implementaci – BPEL, WSDL apod. Výhodou společného jazyka, který se tato práce snaží specifikovat, je především v tom, že zmíněné nástroje a to ať už nástroje zjednodušené či sofistikované je možné mezi sebou kombinovat. V rámci organizace tak mohou manažeři instance vyšších služeb zprvu specifikovat prostřednictvím jednodušších nástrojů a v případě potřeby je možné provést hlubší analýzu a specifikaci instancí vybraných služeb a jejich potřebné části zpřesňovat s využitím sofistikovanějších nástrojů, pokud bychom např. chtěli dané služby nebo alespoň jejich části technologicky zautomatizovat.

3.4 Vyjednávání o instanci služby Přestože poskytovatel může poskytovat jednu a tu samou službu více příjemcům, zpravidla tyto konkrétní poskytnuté služby nejsou identické, ale více či méně se mohou vzájemně lišit. Tento fakt je dán tím, že příjemce služby zpravidla není pasivním hráčem ve vztahu, jako je tomu u prodeje hotových výrobků, ale příjemce do značné míry utváří konkrétní charakter výsledné služby. Ze zmíněných důvodů je tedy v rámci procesu využívání služby důležitá fáze tzv. vyjednávání, kdy se poskytovatel služby s potenciálním příjemcem domlouvají na konkrétních detailech poskytování vybrané služby. Příjemce tedy zprvu v podstatě přichází s vlastní hrubou představou rozhraní služby, kterou v rámci procesu průzkumu trhu a následného vyjednávání s vybranými potenciálními poskytovateli zpřesňuje až do finální podoby, která vyústí až v konkrétní dohodu s vítězným poskytovatelem. Poskytovatel proto v podstatě disponuje vícero rozhraními jedné služby – obecným rozhraním specifikujícím veškeré možné základní variace dané služby, jež slouží jako obecná nabídka pro potenciální příjemce, a konkrétními domluvenými rozhraními, které jsou sjednány s jednotlivými příjemci.

3.5 Příklad Zmíněnou abstraktní teorii si pro lepší pochopení představíme na praktickém příkladu. Představme si příklad poskytování aplikační služby typu SaaS (Software as a Service), jejímž obsahem bude aplikace pro správu obsahu webové prezentace. Zjednodušený popis instance této služby by pak mohl vypadat následovně. SYSTÉMOVÁ INTEGRACE 3/2009

43

Lukáš Burkoň

3.5.1 Externí popis služby Obecné rozhraní služby, kterým poskytovatel specifikuje různé variace dané služby sloužící především pro účely nabídky potenciálním zákazníkům, může vypadat následujícím způsobem: základní atributy rozhraní služby identifikace služby

Platinum CMS

obsah služby

Aplikační hostovaná služba určená ke správě obsahu webu nabízející funkce menu, články, fotogalerie, diskuzní fóra, ankety a WYSIWYG editor. Služba dále obsahuje i zákaznickou podporu.

poskytovatel služby

Platinum Studio, s.r.o.

příjemce služby

Libovolný zákazník s potřebou provozu a správy webové prezentace.

cena služby

Služba je zpoplatněna měsíčním paušálem splatným každý 5. den následujícího měsíce.

kvantita služby

Dostupné funkce aplikace, maximální objem dat na disku a charakter zákaznické podpory se odvíjí od zvoleného cenového programu.

kvalita služby

Kvalita služby je měřena minimální garantovanou dostupností. V případě porušení minimálního limitu získá příjemce služby nárok na slevu z paušálu v poměrné procentuální výši vůči objemu času, po kterém nebyla služba dostupná.

pravidla poskytování a spotřeby služby

Zákaznická podpora je poskytována prostřednictvím zákaznické linky nebo emailu ve standardní pracovní hodiny Po – Pá 8 – 20 hod. CET, popř. non-stop.

způsob poskytování a spotřeby služby

Služba je k použití online prostřednictvím standardního webového prohlížeče. Bližší popis ovládání aplikace je dostupný v online nápovědě.

variace rozhraní služby Platinum Basic cena služby

450,- Kč

kvantita služby

funkce aplikace – menu, články, fotogalerie a WYSIWYG editor 1 GB dat na disku zákaznické podpora emailem dle standardních pracovních hodin

kvalita služby

minimální garantovaná dostupnost služby 95%

Platinum Medium 44



cena služby

650,- Kč

kvantita služby

funkce aplikace – menu, články, fotogalerie, diskuzní fóra, ankety a WYSIWYG editor 5 GB dat na disku zákaznické podpora telefonem a emailem dle standardních pracovních hodin

kvalita služby

minimální garantovaná dostupnost služby 97%

Platinum Profi cena služby

850,- Kč

kvantita služby

funkce aplikace – menu, články, fotogalerie, diskuzní fóra, ankety a WYSIWYG editor 10 GB dat na disku zákaznické podpora telefonem a emailem nonstop

kvalita služby

minimální garantovaná dostupnost služby 99,5%

Konkrétní domluvené rozhraní služby vycházející z rozhraní obecného by pro konkrétního zákazníka mohlo pak vypadat následovně: základní atributy rozhraní služby identifikace služby

Platinum CMS

variace služby

Platinum Basic

obsah služby

Aplikační hostovaná služba určená ke správě obsahu webu nabízející funkce menu, články, fotogalerie a WYSIWYG editor. Služba dále obsahuje i zákaznickou podporu.

poskytovatel služby

Platinum Studio, s.r.o.

příjemce služby

Ovoce a Zelenina, a.s.

cena služby

Služba je proplácena prostřednictvím měsíčního paušálu ve výši 450,- Kč splatného každý 5. den následujícího měsíce.

kvantita služby

funkce aplikace – menu, články, fotogalerie a WYSIWYG editor 1 GB dat na disku zákaznické podpora emailem dle standardních pracovních hodin

kvalita služby

Minimální dostupnost služby je garantována ve výši 95%. V případě porušení minimálního limitu získá příjemce služby nárok na slevu z paušálu v poměrné procentuální výši vůči objemu času, po kterém nebyla služba dostupná.


45

Lukáš Burkoň

pravidla poskytování a spotřeby Zákaznická podpora je poskytována služby prostřednictvím emailu v pracovní hodiny Po – Pá 8 – 20 hod. CET. způsob poskytování a spotřeby Služba je k použití online prostřednictvím služby standardního webového prohlížeče. Bližší popis ovládání aplikace je dostupný v online nápovědě.

3.5.2 Interní popis služby V rámci interního popisu služby nejprve formou tabulky (upravený nástroj Work system snapshot [4]) zmapujeme veškeré elementy v pozadí služby a následně je procesní formou dáme do vzájemných souvislostí. Interní logika této služby obsahuje následující elementy:

Kontinuální rozvoj aplikace pro správu obsahu Zákaznická podpora projektu Marketing projektu

Procesy a aktivity Poskytování aplikace pro správu obsahu Vedení a rozvoj strategie projektu Vedení účetnictví projektu

Zdroje Účastníci

Informace

Technologie

Zákazník Produktový manažer Vývojářský tým Tým správy aplikace Obchodní oddělení Tým zákaznické podpory Účetní oddělení Marketingové oddělení

Obsah zákaznických webů (textová data, metadata, multimédia) Zdrojové kódy aplikace pro správu obsahu Chybové hlášení zákazníka Reakce na hlášení zákazníka Objednávka Platba Reklamní materiál Specifikace strategie projektu

Aplikace pro správu obsahu Služba serverové podpory Aplikační služba helpdesku Email Telefon Nástroje pro vývoj webových aplikací Účetní systém Reklamní služby

Mapu procesu poskytování aplikace pro správu obsahu je možné např. zpodobnit prostřednictvím nástroje Service ResponsibilityTable následovně:

46



Aktivita zákazníka

Potenciální problémy

Zákazník kontaktuje obchodní oddělení se zájmem o využívání aplikační služby pro správu obsahu.

Z důvodu nedostatečného marketingu je malý zájem zákazníků o tuto službu.

Obchodní oddělení nabídne zákazníkovi na výběr dostupné variace služby.

Zákazník si vybírá požadovanou variaci služby.

Žádná z variací služby zákazníka nezaujala.

Obchodní oddělení zasílá zákazníkovi úvodní fakturu a smlouvu o poskytování služby.

Zákazník proplácí úvodní fakturu.

Zákazník nezaplatí.

Tým správy aplikace zřizuje zákazníkovi uživatelský účet.

Zákazník se seznamuje s aplikací a plní ji vlastními daty.

Zákazník má problémy s používáním aplikace.

Účetní oddělení zpracovává průběžné faktury. Tým zákaznické podpory je připraven k případné asistenci.

Zákazník používá službu, platí domluvený měsíční paušál a v případě problému kontaktuje zákaznickou podporu.

Zákazník neplatí.

Aktivita provozovatele

4. Propojení služeb Předchozí kapitola se zaobírala tématikou služby jako takové. Služba samozřejmě může fungovat sama o sobě pouze na bázi přímých zdrojů organizace, často však existují služby, které jsou kompozicí služeb jiných. Použité zdroje na jejich chod tedy nepředstavují přímé účastníky, informace či technologie zainteresované pouze v rámci dané služby. V seznamu použitých zdrojů fungování služby mohou figurovat i další služby té samé organizace či organizací externích, které komponují obsah služby vyšší. Použití kompozice služeb je zpravidla pro organizaci výhodné. V případě externích zdrojových služeb se organizace vyhýbá vlastnictví veškerých hmotných i nehmotných zdrojů potřebných k jejich naplňování a zároveň má jasný přehled a kontrolu nad cenou služeb, objemem jejich spotřeby a úrovní jejich kvality, což platí i pro služby interní v rámci organizace. Kompozice služeb však nemusí být nutně jednoúrovňová, tzn. že jedna služba vyšší je kompozicí služeb nižších založených již na přímých zdrojích. Služby totiž mohou tvořit kompozitní strom, tedy situaci, kdy nejvyšší služba je komponovaná ze služeb nižších, ty jsou dále komponovány ze služeb dalších atd. Hloubka tohoto stromu a jejich rozsah v rámci jedné či napříč více organizacemi je v podstatě matematicky neomezená, její omezenost je dána pouze tržní rentabilitou ceny vyšších služeb. Jedna z hlavních podstat služeb je navíc jejich znovupoužitelnost, pročež může být jedna služba použita zároveň ve více různých kompozitních stromech služeb, čímž vznikají na trhu hodnotové sítě služeb.


47

Lukáš Burkoň

Zmíněný COSMO framework tento princip kompozice služeb zpodobňuje v představené orchestraci služeb, kde jedna vyšší služba je sestavena ze služeb nižších, resp. konkrétnějších a aplikací vhodných propojovacích aktivit je systém služeb funkční jako jeden konzistentní celek. Příjemci služby je pak celý systém kompozice skryt, jelikož příjemce je od interní logiky služby, jak již bylo zmíněno, odstíněn. Zásadní je v tomto ohledu rozhraní služby, které by i při obměně interní logiky služby mělo zůstat zachován, resp. pouze obohaceno. V rámci interní logiky služby tedy může dojít k náhradě vlastních aktivit za externí služby či k výměně poskytovatele služeb bez nutnosti dopadu na příjemce služby, který službu vnímá jen skrze její stabilní rozhraní. Propojování služeb v obecném pojetí je možné opět na principu rozhraní. Příjemcem v rámci propojení bude integrátor, resp. vlastník služby vyšší a poskytovatelem pak bude provozovatel služby nižší. Procesní vrstva propojení bude realizována prostřednictvím popsaného systému aktivit mezi poskytovatelem a příjemcem. Integrátor tímto způsobem může využít více různých služeb a v rámci interní logiky komponované služby tyto služby externí vzájemně propojit prostřednictvím patřičných procesů a aktivit. Modelování těchto vztahů mezi službami může využívat různých modelovacích nástrojů dle aktuální potřeby. Pro jednodušší případy, kdy návrhářem vztahů bude běžný manažer, může postačit představený nástroj Service Responsibility Table. Pro náročnější situace nebo situace propojování webových služeb již bude potřeba nástrojů sofistikovanějších jako UML, BPMN či BPEL. Nástroje lze ale vzájemně dle potřeby a možností kombinovat a dosahovat tak maximální efektivity. Hlavní výhodou modelování interní logiky služby, resp. jejího napojení na služby další, je možnost následného sledování výkonnosti této služby a analýzy slabých článku v rámci interní logiky. K jednotlivým článkům interní logiky služby lze přiřazovat výkonnostní a finanční metriky, které jsou mimo jiné u služeb implicitně stanoveny, a sledovat tak, zda některé aktivity vykonávané vlastními zdroji by nebylo výhodnější outsourcovat formou externí služby či u využívaných externích služeb nezměnit parametry jejich odběru či poskytovatele. Sjednocení popisu různých významů pojmu služba, především pak externího popisu čili rozhraní, v kontextu propojování služeb nabízí i zásadní prostředek pro modelování propojení služeb různého významu. Standardní business služby tak mohou být v rámci své vnitřní logiky napojovány na služby informatické, které business formou zaobalují poskytovaní informačních technologií a samy mohou být komponovány obdobným způsobem např. ze služeb webových. Využití jednotného přístupu pro popis všech těchto služeb umožní jejich vzájemnou kompatibilitu především na koncepčně-strukturální úrovni, což je nutným předpokladem pro vzájemnou integraci služeb. Nelze totiž integrovat služby, které jsou vytvářeny a strukturovány dle naprosto odlišné logiky a úhlu pohledu. V rámci organizace by tedy byly definovány různé variace popisu služeb vycházející z jednoho společného základu, ale přizpůsobené logice daného typu, resp. významu služby. Každé oddělení organizace by si mohlo vytvořit vlastní variaci či více variací popisu služby adaptovaných pro svůj obor. Zásadní by zde byla aplikace principu dědičnosti ve stylu objektového programování, tedy že základní obecná struktura popisu služby zůstává původní, avšak je zpřesňována a hlouběji konkretizována dle potřeb daného oboru. Obchodní oddělení tak může např. akcentovat cenu, a proto bohatě rozvine strukturu atributu ceny služby, kde 48



rozpracuje cenovou politiku, systém bonusů a malusů apod. Na druhé straně IT oddělení může klást velký důraz např. na kvalitu služby, kde podrobně specifikuje různé kvalitativní metriky, technické nástroje pro jejich monitoring atd. Jakmile jsou napříč celou organizací využívány jednotné základy, jak službu popisovat, které se ale zároveň jsou schopné přizpůsobit doménové logice dané služby, pak máme zaručeno, že popisy různých typů služeb v rámci celé organizace si budou více méně podobné. Pochopitelně, že popis webové služby, tedy popis spíše technického rázu, se bude podstatně více lišit od služby ryze business povahy, ale koncepčně-strukturální základ budou mít oba popisy shodné. Rozdílnost různých variací popisů služeb se ale bude snižovat u popisů doménově blízkých. Popis IT služby a webové služby si bude již mnohem bližší, což je důležité, jelikož převážně IT služby budou služby webové do své vnitřní logiky integrovat a vyšší podobnost jejich popisu výrazně usnadní samotnou integraci. IT služby pak budou obdobně, díky vyšší podobnosti svého popisu s ostatními business službami, snáze s ryze business službami integrovatelné. Služby webové tedy zpravidla do čistých business služeb přímo integrovány nebudou, ale bude tak realizováno skrze kompozitní strom, kde standardním prostředníkem bude IT služba, která bude vyvažovat doménovou odlišnost business a webových služeb. Samotná integrace služeb bude realizována dle popsaných principů, tedy že vyšší služba v rámci své interní logiky, resp. interního popisu stanoví procesní mapu, která se napojí na rozhraní služby integrované. Modelování tohoto workflow se může u různých typů služeb lišit a bude tedy moci být vybrán nástroj více přesný, ale spíše technicky koncipovaný, anebo lidsky srozumitelnější, ale s vágnější specifikační výpovědí. Integrace služeb webových tedy bude realizována zpravidla prostřednictvím nástroje BPEL, naopak pro integraci ryze business služeb by mohl postačit nástroj Service Responsibility Table.

5. Shrnutí a další směr práce V rámci tohoto článku jsme si představili různé významy pojmu služba jako business služba, webová služba apod. a způsob jejich spojení do unifikovaného zobecněného konceptu. Obecný pojem služba jsem rozdělil do 2 částí – externí a interní popis služby. Externí popis služby zpodobňuje rozhraní služby určené pro jejího příjemce popisující atributy jako obsah služby, poskytovatel, příjemce, cena, kvantita a kvalita služby apod. Interní popis služby na druhou stranu popisuje interní logiku služby sestávající ze zdrojů zabezpečujících její fungování a procesní logiky uvádějící tyto zdroje do vzájemných souvislostí. Článek dále představuje různé nástroje pro modelování služeb a jejich vzájemného propojování a způsob, jak je možné tyto nástroje kombinovat spolu s praktickým příkladem. Představeny byly především nástroje Service ResponsibilityTable pro snadný popis procesní logiky služby a nástroj COSMO framework představující rozsáhlý abstraktní aparát návrhu struktury a logiky služeb. Mezi další použitelné nástroje je možné zařadit např. UML, BPMN či BPEL. Na základě zmíněného externího a interního popisu služby a s využitím jmenovaných nástrojů je možné namodelovat v podstatě libovolnou službu z kteréhokoliv z existujících oborů s tou výhodou, že všechny takto modelované služby budou mít kompatibilní základní strukturu, což usnadní jejich vzájemnou kompozici, standardizuje spotřebu služeb a strukturování firemního katalogu SYSTÉMOVÁ INTEGRACE 3/2009

49

Lukáš Burkoň

služeb. Takřka ale v každém případě modelování služeb na základě zmíněných popisů bude třeba tyto popisy, zvláště pak popis externí blíže zkonkretizovat vzhledem k doménovým standardům a zvyklostem. Směr dalšího rozvoje této práce by mohl být jak v hlubším rozpracování ontologie jednotlivých atributů služby, tak i v kategorizaci služeb dle různých hledisek pro usnadnění konstrukce katalogu služeb v organizaci. Blíže by mohl být dále zanalyzován a navržen i univerzální životní cyklus služby.

Použitá literatura 1.

2.

3. 4. 5.

6. 7. 8.

9.

10. 11. 12. 13. 14. 15. 16.

50

Jan van Bon, Arjen de Jong: IT Service Management: An Introduction, Based on ISO 20000 and ITIL V3, Van Haren Publishing, 2007, ISBN 9789087530518 Bieberstein N., Bose S., Fiammante M., Jones K., Shah R.: Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap, IBM Press, 2006, ISBN 0-13-187002-5 Voříšek, J. a kol.: Principy a modely řízení podnikové informatiky, Praha, Oeconomica, 2008, 446 s. ISBN 978-80-245-1440-6 Alter, S.: Service system fundamentals: Work system, value chain, and life cycle, IBM Systems Journal, leden – březen 2008, ISSN 00188670 Dick A. C. Quartel, Maarten W. A. Steen, Stanislav Pokraev, Marten J. van Sinderen: COSMO: A conceptual framework for service modelling and refinement, Springer Science + Business Media, 3. května 2007 M. Brian Blake: Decomposing Composition: Service-Oriented Software Engineers, Georgetown University, 2007 Roberto M. Saco, Alexis P. Goncalves: Service Design: An Appraisal, Design Management Review, zima 2008, ISSN 15570614 C H Tian, B K Ray, J Lee, R Cao, W Ding: BEAM: A framework for business ecosystem analysis and modeling, IBM Systems Journal, leden – březen 2008, ISSN 00188670 Robert F. Lusch, Stephen L. Vargo, Matthew O’Brien: Competing through service: Insights from service-dominant logic, Elsevier Inc. New York University, 2006 World Wide Web Consortium: Web Services Glossary, http://www.w3.org/TR/ws-gloss/ , 19. dubna 2009 World Wide Web Consortium: Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl, 15. května 2009 Kotler, P.: Marketing Management, Grada Publishing a.s., 2007, ISBN 8024713594 ITIL jako mezinárodní standard pro oblast IT Service Managementu, Jiří Skála, 2004, http://www.agris.cz/etc/textforwarder.php?iType=2&iId=144350 Učeň, P. a kol.: Metriky v informatice - Jak objektivně zjistit přínos informačního systému, Grada, 2001, ISBN 8024700808 Hefley, B., Murphy, W.: Service Science, Management and Engineering – Education for the 21st Century, Springer, 2008, ISBN 978-0-387-76577-8 O'Neill, P., Krauss, D.: Topic Overview: IT Service Management, Forrester, 20. října 2006 SYSTÉMOVÁ INTEGRACE 3/2009

Unifikovaná definice služby

Recommend Documents