Úvod
služba, ať už fyzická jako přepravní služba, nebo implementovaná softwarovým agentem, je vždy navržena a vylepšena tak, aby byla znovu použita co největším počtem spotřebitelů. To je podstata architektury orientované na služby: snižování nákladů, rizik a zpoždění stavebních řešení faktoringem a implementací IT aktiv tak, aby mohly být znovu použity, často v situacích neznámých v době návrhu. Jako takový SOA governance se neliší od data a IT governance, jejichž cílem je navrhování informačních modelů nebo výběr technologií, které mohou být znovu použity za hranicemi daného projektu. Služby musí být řízeny tak, aby se staly opakovaně použitelnými: všichni předvídatelní spotřebitelé musí být schopni vyjádřit své požadavky, které jsou následně upřednostňovány a postupně, zatímco je přiřazen vlastník služby a je definován model financování.
v předchozím článku se Stefan Tilkov podrobněji zabýval rolemi ve správě SOA (1). Mým cílem je pomoci vám vytvořit organizaci správy služeb z hlediska lidí, procesů a technologií.
Charta správy služeb
hlavním cílem správy služeb je dosáhnout výhod architektury orientované na služby podporou vytváření opakovaně použitelných služeb podnikové třídy. Jako křížová funkční organizace zajišťuje správa služeb včasné řešení problémů a konfliktů v důsledku nezbytných kompromisů, ke kterým dochází při definování sdílených požadavků.
organizace správy služeb je zejména pověřena definováním jasných hranic vlastnictví služeb a specifikováním modelu spravedlivého financování.
Service Governance monitoruje nasazení a opětovné použití služeb v celé organizaci. Vysoký stupeň opětovného použití služeb, stálý tok nasazení služeb podnikové třídy, stejně jako bezproblémové odchody do důchodu jsou ukazateli úspěšné správy.
Správa služeb by se neměla překrývat s tradiční it správou a podnikovou architekturou; definují standardy technologií SOA a plán vedoucí ke zvýšení úrovně zralosti SOA, zatímco organizace správy služeb má za úkol vyvíjet prostředí služeb.
obecně platí, že role správy služeb je pasivní a procesní kandidáti na služby identifikovaní podle konkrétních projektů nebo na úrovni obchodní jednotky. Teprve tehdy, když organizace dosáhne vysoké úrovně zralosti, může Správa služeb zahájit systematickou identifikaci podnikových služeb shora dolů a charterovat jejich realizaci nezávisle na jakémkoli projektu.
v každém případě by měla být řídící organizace oprávněna budovat podnikové služby nezávisle na rozpočtových a zdrojových omezeních projektu, které zpočátku spotřebovávají kandidáta na službu. Důvodem je to, že opětovná použitelnost obvykle přichází s větším rozsahem, který se promítá do vyšší ceny.
řídící organizace je správcem definic služeb, u nichž se očekává, že budou spravovány jako podniková aktiva. Je také zodpovědný za udržování sledovatelnosti a souladu s ostatními podnikovými aktivy, jako jsou modely obchodních procesů a referenční datový model. Vrátíme se k vazbám na referenční nebo podnikový datový model v poslední části dokumentu.
lidé
výše uvedený článek popsal role1 zapojené do činností správy služeb z hlediska implementace služby. Když organizace začíná svou architekturu orientovanou na služby, jsou tyto role dostatečné k zajištění poskytování služeb podnikové třídy, zejména pokud patří do centra excelence SOA.
| Role | popis |
| majitel obchodních služeb |
|
| majitel technických služeb |
|
| SOA Platform Architect |
|
| služby Vývojář |
|
vzhledem k tomu, že organizace zraje a počet kandidátů na služby se zvyšuje, je užitečné představit vedoucího správy, který bude vlastnit proces a zdroje, aby se zajistilo, že správní činnosti budou řádně prováděny a problémy budou vyřešeny včas. Pomáhat by mu měla Rada pro křížovou správu a knihovník služeb.
| Role | popis |
| vedení správy |
|
| Governance council |
|
| Knihovník služeb |
|
vidíme tři hlavní úrovně zralosti s ohledem na organizaci správy služeb.
| úroveň splatnosti | organizace |
| zřízení |
|
| provedení |
|
| Optimalizováno |
|
Obrázek 1 představuje některé interakce mezi rolemi zapojenými do správy služeb.
Obrázek 1. Interakce mezi různými složkami správy
klíčem k budování úspěšné organizace správy služeb je opět být agilní a shromáždit dostatek zdrojů, procesů a technologií, aby vyhovovaly vašim potřebám, ale ne více. Velká organizace správy služeb bez rozumného potrubí kandidátů na služby rychle ztratí páru a zmešká příležitost poskytnout adekvátní zpětnou vazbu o některých kandidátech na služby.
chcete vytvořit organizaci, která bude podporovat opětovné použití služeb, nic méně, nic víc.
proces
procesy a činnosti
existuje pět typů činností prováděných organizací správy SOA:
- Service Candidate Management
- Service Change Management
- Service Consumer Management
- Service Roadmap Management
- SOA Governance Policy Changes
Obrázek 2 představuje některé z činností, které lze provádět během procesu správy Service Candidate. Projektový tým může identifikovat službu a vytvořit návrh služby. Tento návrh je poté schválen, schválen s úpravami nebo odmítnut (jako podniková služba), pokud Tento kandidát na službu není potenciálně znovu použitelný jinými částmi podniku.
jakmile je kandidát na službu přijat, je definován model vlastnictví a financování a SLA a Ola jsou specifikovány pomocí vlastníka služby a potenciálních spotřebitelů.
jakmile je služba realizována, její metadata jsou publikována do registru a úložiště. Ve velkých organizacích se doporučuje sledovat služby ve výstavbě, aby se zabránilo souběžným návrhům služeb.
činnosti řízení změn jsou často totožné s činnostmi prováděnými během kontroly kandidáta na službu. Činnosti, jako je vlastnictví služeb, model financování nebo SPECIFIKACE SLA/OLAs, mohou být volitelné.
jedním z kritických aspektů řízení změn je efektivní správa služeb kompatibilních s forwardy (2).
činnosti správy služeb pro spotřebitele jsou většinou prováděny knihovníkem služeb, pokud nedojde ke změnám, které jsou nezbytné k tomu, aby tento nový spotřebitel mohl službu spotřebovat. Knihovník může spotřebitelům služeb pomoci identifikovat cílovou službu a získat kopii jejích metadat.
činnosti správy plánu služeb jsou poskytovány, pokud Správa služeb aktivně jedná o identifikaci služeb bez konkrétních požadavků na projekt. V tomto okamžiku by Správa služeb měla mít rozpočty na to, aby pověřila rozvoj těchto služeb před projekty, které je spotřebují. To je kritický faktor úspěchu správy, protože návrh a implementace opakovaně použitelných služeb může jít daleko nad rámec, prostředky a harmonogram daného projektu. Samotné řídící činnosti vyžadují čas a mohou doporučit zdlouhavé upgrady kandidátovi na službu. To je důvod, proč je tak důležité, aby řídící organizace včas řídila plány a fáze specifických požadavků spotřebitelů a minimalizovala dopad plánů dodávek řešení.
Obrázek 2. Činnosti správy kandidátů na služby
nakonec by organizace správy mohla zapojit správu IT, aby definovala nebo změnila své provozní zásady.
Metadata služby
návrh kandidáta služby obsahuje popis rozhraní služby (nemusí být nutně ve strojově čitelné podobě) a všechny funkční a nefunkční požadavky spojené se službou, které budou použity například k definování SLA a Ola. Architektura služby CBDI Forum & inženýrský meta model pro SOA (3) poskytuje dobrý přehled o informacích ve vztahu ke službě, která je zachycena v raných fázích životního cyklu a postupem času vylepšována.
CBDI Forum SAETM metamodel obsahuje definici služeb, včetně navrhovaných operací, zásad a souvisejících služeb, jakož i klasifikaci služeb. Fórum CBDI také doporučuje zahrnout definici služeb na obchodní úrovni, která se týká obchodních procesů, obchodních schopností a obchodních pravidel… k definici služby.
všechny tyto informace by mohly být použity, když spotřebitel hledá konkrétní službu. Proto je důležité zachytit je strukturovaným způsobem, i když strojově čitelné popisné standardy, jako je WSDL, tento typ informací (zatím) nepodporují.
METAMODEL CBDI Forum SAE™ poskytuje samostatnou sekci pro specifikaci služby. Zajímavým aspektem této části metamodelu je to, že sleduje typy informací, které jsou součástí služby jako provozní argumenty. Tato schopnost není dobře podporována WSDL, například, který definuje pouze reprezentace typů podniků, které jsou vyměňovány jako součást vyvolání operací, ale nikoli samotné typy podniků.
sledovatelnost typů informací je kritická, protože zabraňuje zavedení sémantiky specifické pro provoz. Typ zprávy by měl být vždy definován s úzkými vazbami na referenční datový model. Ve skutečnosti by procesy správy SOA měly zajistit, aby v typu zprávy nebyla definována žádná další sémantika ve srovnání s referenčním datovým modelem.
METAMODEL CBDI Forum SAE™ také sleduje obchodní komponenty, které se používají při implementaci služeb.
faktory opětovného použití služby
při podpoře SPECIFIKACE opakovaně použitelných služeb je třeba zvážit tři důležité faktory. Nejprve musí být servisní rozhraní Kompletní s ohledem na jeho současné a potenciální zákazníky. Dobrou metrikou pro sledování je počet změn rozhraní a implementace, jak přicházejí na palubu noví spotřebitelé, a to jak pro ty, které jsou dopředu kompatibilní, tak pro ty, které nejsou.
za druhé musíme zvážit příslušné dohody o úrovni služeb a provozu (SLA a OLAs). Některé SLA může fungovat perfektně pro jednoho spotřebitele a být show zátkou pro jiného. Sla a OLAs může být také obtížné dosáhnout. Organizace správy SOA by měla sledovat incidenty a sledovat počet změn SLA a Ola, které vyplynuly z těchto incidentů, jakož i počet změn v implementaci služby, aby účinně splnila své SLA a Ola.
a konečně, organizace pro správu služeb by se měla snažit identifikovat všechny potenciální spotřebitele kandidáta na službu a zapojit je do procesu ratifikace návrhu rozhraní služeb. Dobrou metrikou pro sledování je počet neočekávaných zákazníků nalezených po návrhu služby. Tato metrika by měla být interpretována pečlivě, protože by to mohlo znamenat, že služba byla dobře navržena a přilákala mnoho spotřebitelů, nebo by to mohlo znamenat, že nebylo vynaloženo dost času na identifikaci správných spotřebitelů, což vedlo k mnoha následným změnám.
činnosti a role správy služeb jsou často podporovány řešením správy, které je postaveno na registru a úložišti služeb. I když je to docela triviální, je důležité mít vždy na paměti, že aktivum lze znovu použít pouze tak, jak je možné jej najít. Registr je katalog nebo index, který funguje jako „systém záznamu“ pro služby v rámci SOA (4).
registr a úložiště SOA obvykle podporují následující funkce:
- ukládá metadata služby, jako jsou popisy (formáty zpráv a operace), vazby (komunikační protokoly), koncové body (síťový přístupný prostředek, který implementuje službu)
- poskytuje klasifikační mechanismus, který pomáhá kategorizovat a organizovat služby
- umožňuje uživatelům publikovat nové služby (jak jsou identifikovány, realizovány a nasazeny) do registru a procházet a hledat stávající nebo plánované služby
- informovat spotřebitele služeb o plánovaných změnách
- Správa SLA a Ola hlásí i spotřebu statistiky
- bezpečně Spravujte procesy a výstupy správy
- poskytují funkce auditu pro sledování stopy změn a autorizace aplikovaných na popisy aktiv
procesy správy jsou geograficky distribuovány v přírodě a spolupracují. Řízení těchto procesů je zásadní pro to, aby různé strany dosáhly shody ohledně definice a realizace služby.
vzhledem k tomu, že registr a úložiště jsou systémem záznamu informací o službě jak v době návrhu, tak v době běhu, je zabezpečení obklopující „servisní záznam“ kritické, aby se zabránilo nahrazení koncových bodů.
vztah k jiným činnostem správy
Správa služeb je nový typ správy jako součást širších činností správy IT vedených skupinami podnikové architektury. Správa IT by měla zůstat pod kontrolou samotné správy platformy SOA, zatímco Správa služeb by měla zaměřit své činnosti na navrhování služeb pro opětovné použití v podniku, realizaci služeb a úrovně dodávek řešení (obrázek 3). Na podnikové úrovni by Správa služeb měla úzce spolupracovat s IT governance, aby získala model obchodního procesu společnosti, aby pomohla identifikovat kandidáty na služby na základě analýzy shora dolů a vytvořit plán pro zavádění těchto služeb. Jak jsme viděli v sekci procesů dříve, úroveň služeb je místem, kde probíhá většina činností správy SOA. Všechny tyto činnosti jsou podporovány registrem a úložištěm.
na úrovni řešení by organizace správy služeb měla vyhodnotit a řídit úroveň souladu s pokyny pro infrastrukturu a služby SOA.
Správa služeb má silné vazby na správu dat prostřednictvím využití podnikového referenčního datového modelu. Tým správy služeb by měl prosazovat využití sémantiky referenčního datového modelu pro návrh typů provozních zpráv.
cílem zde není vytvořit „kanonický informační Model“. V architektuře orientované na služby by bylo naivní si myslet, že spotřebitelé budou vždy schopni přijmout názor poskytovatele nebo že poskytovatel i spotřebitel mohou vždy zaujmout stejný názor. I kdyby to byla pravda dnes, přesčasy, spotřebitelé a poskytovatelé nemusí být schopni vyvíjet současně směrem k novější verzi rozhraní (ať už je to dopředu nebo dozadu kompatibilní).
obrázek 3. Vztah mezi řízením SOA a dalšími aktivitami správy
tento rozdílný vývoj je často řešen pomocí mediátora, a zejména transformací zpráv. Přestože mediace není v architektuře webových služeb W3C explicitní (5), praktikující SOA ji již dávno systematicky využívali k dosažení vyšší úrovně volné vazby a umožnění autonomního vývoje mezi spotřebiteli a poskytovateli. Tyto transformace jsou nevyhnutelné a tato schopnost by měla být zabudována do vaší infrastruktury SOA. Mimochodem, zprostředkování nevyžaduje „společný informační Model“. Pokud byste použili takový „společný informační model“ nezávislý na poskytovateli a spotřebitelském rozhraní a přesto chcete dosáhnout volné vazby, vzniknou vám náklady na dvě transformace, nemluvě o tom, že stále potřebujete transformovat formát zprávy na datový soubor spotřební implementací poskytovatele a spotřebitele.
prvními kroky k lépe zvládnutelným transformacím je odvození rozhraní spotřebitelů a poskytovatelů z referenčního datového modelu. V referenčním datovém modelu je datová struktura méně důležitá než normalizace sémantiky. Tyto sémantiky jsou řízeny s velkou přesností pomocí správy dat. Referenční datový model obvykle stanoví sledovatelnost fyzických artefaktů,jako jsou databázová schémata a kopírovací knihy COBOL. Tato sledovatelnost se může ukázat jako velmi užitečná při implementaci služby, zatímco použití normalizované sémantiky pomůže zjednodušit vývoj transformačních map mezi spotřebiteli a poskytovateli.
závěr
Správa služeb je základním aspektem úspěšné architektury orientované na služby. Jeho zřízení musí být naplánováno a vyzkoušeno brzy v počátečních fázích iniciativy SOA. Organizace řízení v plném rozsahu řízená přísným procesem by však měla být zahájena pouze tehdy, je-li servisní potrubí dostatečně velké, aby udrželo tým motivovaný a informovaný. Pokud jsou řídící činnosti příliš vzdálené v čase, tým může ztratit zájem a kritické znalosti, aby mohl řádně vykonávat své činnosti. Repozitář registru & je klíčovou složkou pro úspěšnou správu, protože spravuje „servisní záznam“. Konečným cílem správy služeb je umožnit specifikaci, realizaci a provoz opakovaně použitelných IT aktiv. Přesčas očekává se, že správa služeb se bude vyvíjet směrem k tomu, aby byla mnohem aktivnější při uvádění do provozu implementace kritických služeb.