Etablering av en Tjänstestyrningsorganisation

introduktion

en tjänst, vare sig den är fysisk som en frakttjänst eller implementerad av en mjukvaruagent, är alltid utformad och förfinad för att återanvändas av så många konsumenter som möjligt. Detta är kärnan i serviceorienterad arkitektur: sänka kostnader, risker och förseningar för att bygga lösningar genom factoring och implementera IT-tillgångar så att de kan återanvändas, ofta i situationer som är okända vid designtiden. Som sådan är SOA-styrning inte annorlunda än data-och IT-styrning som syftar till att utforma informationsmodeller eller välja teknik som kan återanvändas utanför gränserna för ett visst projekt. Tjänster måste regleras för att bli återanvändbara: alla förutsebara konsumenter måste kunna uttrycka sina krav som därefter prioriteras och fasas, medan en tjänsteägare tilldelas och en finansieringsmodell definieras.

i en tidigare artikel tittade Stefan Tilkov mer specifikt på rollerna i soa-styrning (1). Mitt mål här är att hjälpa dig att etablera en Service Governance organisation när det gäller människor, process och teknik.

Service Governance Charter

huvudsyftet med Service governance är att uppnå fördelarna med en serviceorienterad arkitektur genom att främja skapandet av återanvändbara tjänster i företagsklass. Som en tvärfunktionell organisation säkerställer Tjänstestyrning en snabb lösning av problem och konflikter på grund av nödvändiga avvägningar som görs när delade krav definieras.

i synnerhet är Tjänstestyrningsorganisationen chartrad för att definiera tydliga tjänsteägargränser och specificera en rättvis finansieringsmodell.

Service Governance övervakar distribution och återanvändning av tjänster i hela organisationen. En hög grad av återanvändning av tjänster, ett stadigt flöde av tjänsteutplaceringar i företagsklass samt problemfria tjänsteavgångar är indikatorerna för framgångsrik styrning.

tjänstestyrning bör inte överlappa med traditionell IT-styrning och företagsarkitektur; de definierar standarderna för SOA-teknik och färdplanen som leder till ökade nivåer av SOA-mognad, medan Service Governance-organisationen har till uppgift att utveckla servicelandskapet.

i allmänhet är Tjänstestyrningens Roll passiv och processtjänstkandidater identifierade av specifika projekt eller på affärsenhetsnivå. Det är först när en organisation har nått en hög mognadsnivå som Tjänstestyrning kan initiera en systematisk top-down-identifiering av företagstjänster och chartera deras realisering oberoende av något projekt.

i vilket fall som helst bör styrningsorganisationen ha befogenhet att bygga företagstjänster oberoende av budgeten och resursbegränsningarna för projektet som initialt kommer att konsumera tjänstekandidaten. Anledningen är att återanvändbarhet vanligtvis kommer med ett större omfång som översätter till en högre prislapp.

styrningsorganisationen är förvaltaren av tjänstedefinitioner som förväntas hanteras som företagstillgångar. Det är också ansvarigt för att upprätthålla spårbarheten och efterlevnaden av andra företagstillgångar som affärsprocessmodeller och referensdatamodellen. Vi kommer tillbaka på banden till en referens-eller företagsdatamodell i det sista avsnittet av dokumentet.

människor

den tidigare nämnda artikeln beskrev roller1 involverad i service governance-aktiviteter ur ett tjänsteimplementeringsperspektiv. När en organisation startar sin serviceorienterade arkitektur är dessa roller tillräckliga för att garantera leverans av tjänster i företagsklass, särskilt när de tillhör ett soa-center of Excellence.

Roll	beskrivning
Business service ägare	Direct and control the service implementation, evolution and retirement äger tjänstens funktionella omfattning, Servicenivåavtalen hanterar effektivt tjänstens kapacitet för att möta styrningsförfrågningar och säkerställa lämpliga nivåer för återanvändning rapportera serviceaktivitet till styrningsorganisationen
teknisk service ägare	utför tjänsten implementation, evolution and retirement äger Operations Level Agreement och hanterar tjänsten för att uppfylla sina mål när det gäller tillgänglighet, prestanda, säkerhet övervakar tjänsten för att identifiera potentiella problem med SLA och OLA rapportera serviceaktivitet till företagets ägare
SOA Platform Architect	ge råd och diskutera soa tekniska standarder med IT och SOA governance organization se till att service implementeringar är kompatibla
Service Utvecklare	bistå domänarkitekten och plattformsarkitekten i deras styrningsrelaterade aktiviteter implementera styrningspolicyer och rekommendationer

när en organisation mognar och antalet tjänstekandidater ökar är det bra att införa en ledningsledare som kommer att äga processen och resurserna för att se till att styrningsaktiviteter genomförs på lämpligt sätt och att frågor löses i tid. Han bör biträdas av ett tvärfunktionellt styrningsråd och en servicebibliotekarie.

Roll	beskrivning
Governance Lead	hantera övergripande styrningsaktiviteter ur ett folk -, process-och teknikperspektiv ansvarig för tjänsternas livscykel ansvarig för mätvärden för återanvändning av tjänster detta är vanligtvis inte en heltidsroll och kan fyllas av domänen eller plattformsarkitekten
Governance council	granska tjänstekandidatförslag rekommendera serviceägande och finansiering modell Lös problem i förhållande till konsumentkrav prioriteringar, tjänsteägande, finansieringsmodell, scheman, SLA och Ola Detta är ett tvärfunktionellt team som täcker så många domäner som möjligt
Servicebibliotekarie	hantera service lifecycles aktiviteter som relaterar till service registry och repository upprätthåller registertaxonomi se till att korrekta data och metadata lagras i repository återigen är detta vanligtvis inte en heltidsroll och kan blandas med en arkitekt Roll

vi ser tre huvudnivåer av mognad med avseende på Tjänstestyrningsorganisationen.

mognadsnivå	organisation
etablering	soa-initiativet har nyligen startat ett SOA Center Of Excellence består av att hantera alla aspekter av initiativet, inklusive plattformsdefinition och distribution, servicekonstruktion och ägande samt soa-styrning antalet tjänster som byggs är relativt litet ett register behövs ännu inte eftersom alla servicerelaterade aktiviteter sker inom en liten grupp
utförande	ett register och arkiv distribueras för att hantera styrningsprocessen och metadata en ledning för styrning och en servicebibliotekarie utses tjänster byggs fortfarande inom SOA CoE men med en hastighet av flera per månader som stöder uppdragskritiska lösningar i vissa fall bildas ett SOA-råd för att diskutera specifika frågor
optimerad	ett SOA-råd utses och träffas regelbundet för att diskutera tjänstekandidatförslag en färdplan för tjänsten definieras och hanteras av SOA governance organization för att hjälpa till att initiera service realisationer före projektbehov

Figur 1 representerar några av samspelet mellan de roller som är involverade i Tjänstestyrning.

Figur 1. Interaktioner mellan olika styrningsbeståndsdelar

nyckeln till att bygga en framgångsrik Tjänstestyrningsorganisation är återigen att vara smidig och samla tillräckligt med resurser, processer och tekniker för att möta dina behov men inte mer. En stor Tjänstestyrningsorganisation utan en rimlig pipeline av servicekandidater kommer snabbt att förlora ånga och missa chansen att ge tillräcklig feedback på vissa servicekandidater.

du vill bygga en organisation som kommer att främja återanvändning av tjänster, inget mindre, inget mer.

Process

processer och aktiviteter

det finns fem typer av aktiviteter som utförs av SOA governance organization:

hantering av Tjänstekandidater
hantering av Tjänsteförändringar
hantering av Tjänstekonsument
hantering av Tjänstefärdplaner
ändringar av SOA-Styrningspolicyn

Figur 2 representerar några av de aktiviteter som kan utföras under hantering av Tjänstekandidater. En projektgrupp kan identifiera en tjänst och skapa ett tjänsteförslag. Detta förslag godkänns sedan, godkänns med ändringar eller avvisas (som en företagstjänst) när den här tjänstekandidaten inte kan återanvändas av andra delar av företaget.

när tjänstekandidaten har godkänts definieras ägande-och finansieringsmodellen och SLA: erna och Ola: erna specificeras med hjälp av tjänsteägaren och potentiella konsumenter.

när tjänsten är realiserad publiceras dess metadata till registret och förvaret. I stora organisationer rekommenderas det att hålla reda på de tjänster som är under uppbyggnad för att undvika samtidiga serviceförslag.

Förändringshanteringsaktiviteter är ofta identiska med aktiviteter som utförs under en servicekandidatgranskning. Aktiviteter som tjänsteägande, finansieringsmodell eller sla/OLAs-specifikation kan vara valfria.

en kritisk aspekt av förändringshantering är effektiv hantering av framåtkompatibla tjänster (2).

Servicekonsumenthanteringsaktiviteter utförs oftast av servicebibliotekarien om det inte finns ändringar som är nödvändiga för att denna nya konsument ska kunna konsumera tjänsten. Bibliotekarien kan hjälpa tjänstekonsumenterna att identifiera måltjänsten och skaffa en kopia av dess metadata.

Service Roadmap Management-aktiviteter tillhandahålls om Tjänstestyrningen agerar proaktivt för att identifiera tjänster utan specifika projektförfrågningar. Vid den tidpunkten bör Tjänstestyrningen ha budgetar för att beställa utvecklingen av dessa tjänster före de projekt som kommer att konsumera dem. Detta är avgörande framgångsfaktor för styrning eftersom utformningen och genomförandet av återanvändbara tjänster kan gå långt utöver omfattningen, medlen och schemat för ett visst projekt. Styrningsaktiviteterna tar tid och kan rekommendera långa uppgraderingar till en servicekandidat. Det är därför det är så viktigt att styrningsorganisationen hanterar scheman och faser konsumentspecifika krav i tid, vilket minimerar effekten av lösningsleveransscheman.

Figur 2. Servicekandidathanteringsaktiviteter

slutligen kan en styrningsorganisation engagera IT-styrning för att definiera eller ändra sin verksamhetspolicy.

Service Metadata

tjänstekandidatförslaget innehåller en beskrivning av servicegränssnittet (inte nödvändigtvis i maskinläsbar form) samt alla funktionella och icke-funktionella krav som är kopplade till Tjänsten som kommer att användas till exempel för att definiera SLA och Ola. CBDI Forum Service Architecture & Engineering meta model för SOA (3) ger en bra bild av informationen i förhållande till en tjänst som fångas under de tidiga stadierna av livscykeln och förfinas över tiden.

CBDI Forum SAETM metamodel innehåller en tjänstedefinition, inklusive föreslagna operationer, policyer och relaterade tjänster, samt en tjänsteklassificering. CBDI-forumet rekommenderar också att man inkluderar en tjänstedefinition på affärsnivå som relaterar affärsprocesser, affärsmöjligheter, affärsregler… till tjänstedefinitionen.

All denna information kan eventuellt användas när en konsument söker efter en viss tjänst. Det är därför det är viktigt att fånga det på ett strukturerat sätt även om maskinläsbara beskrivningsstandarder som WSDL inte (ännu) stöder denna typ av information.

CBDI-forumet SAE Ukrainian metamodel tillhandahåller ett separat avsnitt för servicespecifikationen. Den intressanta aspekten av denna del av metamodellen är att den håller reda på de informationstyper som är involverade i tjänsten som operationsargument. Denna förmåga stöds inte väl av WSDL, till exempel, som bara definierar representationerna för de affärstyper som utbyts som delar av operationsåkallanden men inte själva affärstyperna.

spårbarheten av informationstyper är kritisk eftersom den förhindrar införandet av operationsspecifik semantik. En meddelandetyp ska alltid definieras med nära band till referensdatamodellen. I själva verket bör soa-styrningsprocesserna se till att ingen ytterligare semantik definieras i meddelandetypen jämfört med referensdatamodellen.

CBDI-forumet SAE Ukrainian metamodel håller också reda på de affärskomponenter som används i en tjänsteimplementering.

serviceåteranvändningsfaktorer

det finns tre viktiga faktorer att tänka på när man hjälper till att främja specifikationen av återanvändbara tjänster. Först måste ett servicegränssnitt vara komplett med avseende på dess nuvarande och potentiella konsumenter. Ett bra mått att spåra är antalet gränssnitt och implementeringsändringar när nya konsumenter kommer ombord, för både de som är framåtkompatibla och de som inte är det.

för det andra måste vi överväga lämpliga Service-och Driftsnivåavtal (SLA och OLAs). Vissa SLA kan fungera perfekt för en konsument och vara en show propp för en annan. SLA och OLAs kan också vara svåra att uppnå. SOA governance organization bör hålla reda på incidenterna och övervaka antalet ändringar av SLA och Ola som resulterade från dessa incidenter samt antalet ändringar i tjänsteimplementeringen för att effektivt uppfylla sina SLA och Ola.

slutligen bör en Tjänstestyrningsorganisation försöka identifiera alla potentiella konsumenter av en tjänstekandidat och involvera dem i processen att ratificera tjänstegränssnittförslaget. Ett bra mått för att spåra det är antalet oväntade kunder som hittades efter att en tjänst designades. Detta mått bör tolkas noggrant eftersom det kan innebära att tjänsten var väl utformad och lockade många konsumenter, eller det kan innebära att inte tillräckligt med tid spenderades för att identifiera rätt konsumenter vilket resulterade i många efterföljande förändringar.

Tjänstestyrningsaktiviteter och-roller stöds ofta av en styrningslösning som är uppbyggd kring ett tjänsteregister och en databas. Även om det är ganska trivialt att säga detta är det viktigt att alltid komma ihåg att en tillgång bara kan återanvändas så mycket som den kan hittas. Ett register är katalogen eller indexet som fungerar som ”system of record” för tjänster inom en SOA (4).

ett SOA-register och arkiv stöder vanligtvis följande funktioner:

lagrar tjänsten metadata såsom beskrivningar (meddelandeformat och operationer), bindningar (kommunikationsprotokoll), slutpunkter (nätverket tillgänglig resurs som implementerar tjänsten)
ger en klassificeringsmekanism för att kategorisera och organisera tjänster
tillåter användare att publicera nya tjänster (som de identifieras, realiseras och distribueras) i registret och att bläddra och söka efter befintliga eller planerade tjänster
meddela tjänsten konsumenter av planerade förändringar
hantera SLA-och Ola-rapporter samt förbrukning statistik
hantera säkert styrningsprocesser och leveranser
ge revisionskapacitet för att spåra spåret av ändringar och auktorisation som tillämpas på tillgångsbeskrivningar

styrningsprocesser är geografiskt fördelade i naturen och samarbete. Hanteringen av dessa processer är avgörande för att få olika parter att komma överens om tjänstedefinitionen och realiseringen.

eftersom registret och förvaret är systemet för rekord för serviceinformation både vid designtid och körtid, är säkerheten kring ”service record” avgörande för att undvika substitution av slutpunkter till exempel.

förhållande till andra Styrningsaktiviteter

Tjänstestyrning är en ny typ av styrning som en del av de bredare it-styrningsaktiviteterna som leds av Företagsarkitekturgrupper. IT-styrning bör förbli i kontroll över soa-plattformsstyrning själv, medan Service Governance bör fokusera sin verksamhet på att utforma tjänster för återanvändning på Enterprise, Service Realization och Solution delivery nivåer (Figur 3). På företagsnivå bör Service Governance arbeta nära IT-styrning för att skörda företagets affärsprocessmodell för att identifiera servicekandidater baserat på en top-down-analys och upprätta en färdplan för utbyggnaden av dessa tjänster. Som vi har sett i processavsnittet tidigare är servicenivån där de flesta av SOA-styrningens aktiviteter äger rum. Alla dessa aktiviteter stöds av ett register och arkiv.

på lösningsnivå bör Tjänstestyrningsorganisationen utvärdera och styra nivån på efterlevnad med avseende på soa-infrastruktur och serviceriktlinjer.

Service Governance har starka band med datastyrning via användningen av enterprise Reference Data Model. Tjänstestyrningsteamet bör genomdriva användningen av referensdatamodellens semantik för utformningen av operationsmeddelandetyper.

målet här är inte att skapa en ”kanonisk informationsmodell”. I en serviceorienterad arkitektur skulle det inte vara nödvändigt att tro att konsumenterna alltid kommer att kunna anta leverantörens synvinkel eller att både leverantören och konsumenten alltid kan anta samma synvinkel. Även om detta var sant idag kanske Övertid, konsumenter och leverantörer inte kan utvecklas samtidigt mot en nyare version av gränssnittet (vare sig det är framåt eller bakåtkompatibelt).

Figur 3. Förhållandet mellan soa-styrning och andra styrningsaktiviteter

denna divergerande utveckling hanteras ofta med hjälp av en medlare, och i synnerhet meddelandetransformationer. Även om medling inte är tydlig i W3C: s webbtjänstarkitektur (5), har soa-utövare för länge sedan använt det systematiskt för att uppnå en högre nivå av lös koppling och möjliggöra autonoma utvecklingar mellan konsumenter och leverantörer. Dessa omvandlingar är oundvikliga och denna förmåga bör byggas in i din SOA-Infrastruktur. För övrigt kräver medling inte en ”gemensam informationsmodell”. Om du skulle använda en sådan ”gemensam informationsmodell” oberoende av leverantör och konsumentgränssnitt och ändå vill uppnå lös koppling, skulle du drabbas av kostnaden för två omvandlingar, för att inte tala om att du fortfarande behöver omvandla ditt meddelandeformat till en datauppsättning förbrukningsvara genom implementeringen av leverantören och konsumenten.

de första stegen mot mer hanterbara omvandlingar är att härleda konsument-och leverantörsgränssnitt från referensdatamodellen. I referensdatamodellen är datastrukturen mindre viktig än normaliseringen av semantiken. Dessa semantik hanteras med stor precision genom datastyrning. Vanligtvis fastställer referensdatamodellen spårbarhet till fysiska artefakter som databasscheman och COBOL-kopieringsböcker. Denna spårbarhet kan visa sig vara mycket praktiskt under genomförandet av tjänsten medan användningen av normaliserad semantik kommer att bidra till att förenkla utvecklingen av omvandlingskartor mellan konsumenter och leverantörer.

slutsats

Tjänstestyrning är en viktig aspekt av en framgångsrik serviceorienterad arkitektur. Dess etablering måste planeras och testas tidigt i de inledande faserna av ett SOA-initiativ. En fullskalig styrningsorganisation som drivs av en rigorös process bör dock startas först när tjänstepipelinen är tillräckligt stor för att hålla teamet motiverat och kunnigt. Om styrningsaktiviteterna är för avlägsna i tiden kan laget förlora intresse och kritisk kunskap för att utföra sina aktiviteter korrekt. Registret & Repository är en viktig ingrediens för framgångsrik styrning eftersom den hanterar ”service record”. Det yttersta målet för Tjänstestyrning är att möjliggöra specifikation, realisering och drift av återanvändbara IT-tillgångar. Övertid det förväntas att Tjänstestyrningen kommer att utvecklas mot att vara mycket mer proaktiv i driftsättning genomförandet av verksamhetskritiska tjänster.