Introduksjon
en tjeneste, enten den er fysisk som en frakttjeneste, eller implementert av en programvareagent, er alltid designet og raffinert for å bli gjenbrukt av så mange forbrukere som mulig. Dette er Essensen Av Serviceorientert Arkitektur: å redusere kostnader, risiko og forsinkelser i byggeløsninger ved å factoring OG implementere IT-eiendeler slik at DE kan gjenbrukes, ofte i situasjoner som er ukjente på designtidspunktet. SOM sådan ER SOA-styring ikke annerledes enn data og IT-styring som tar sikte på å designe informasjonsmodeller eller velge teknologier som kan gjenbrukes utenfor grensene til et gitt prosjekt. Tjenester må styres for å bli gjenbrukbare: alle forutsigbare forbrukere må kunne uttrykke sine krav som senere prioriteres og fases, mens en tjenesteeier er tildelt og en finansieringsmodell er definert.
I En tidligere artikkel så Stefan Tilkov mer spesifikt på ROLLENE I SOA-styresett (1). Mitt mål her er å hjelpe deg å etablere En Service Governance organisasjon i form av mennesker, prosess og teknologi.
Service Governance Charter
Hovedmålet Med Service governance er å oppnå fordelene med En Tjenesteorientert Arkitektur ved å fremme etableringen av gjenbrukbare tjenester i bedriftsklassen. Som en tverrfunksjonell organisasjon sikrer Service governance rettidig løsning av problemer og konflikter på grunn av de nødvendige avvikene som gjøres når felles krav er definert.
Spesielt er Servicestyringsorganisasjonen chartret for å definere klare grenser for tjenesteeierskap og angi en rettferdig finansieringsmodell.
Service Governance overvåker distribusjon og gjenbruk av tjenester på tvers av organisasjonen. En høy grad av gjenbruk av tjenester, en jevn strøm av tjenesteutplasseringer i bedriftsklassen, samt problemfri tjenesteavgang er indikatorene for vellykket styring.
tjenesteledelse bør ikke overlappe med tradisjonell IT-styring og Bedriftsarkitektur; de definerer standardene FOR SOA-teknologier og veikartet som fører til økte NIVÅER AV SOA-modenhet, mens Servicestyringsorganisasjonen har til oppgave å utvikle servicelandskapet.
Generelt er Rollen Som Service governance passiv og prosess service kandidater identifisert av bestemte prosjekter eller på forretningsenhetsnivå. Det er først når en organisasjon har nådd et høyt nivå av modenhet At Service governance kan initiere en systematisk top-down identifikasjon av enterprise services og charter deres realisering uavhengig av ethvert prosjekt.
i alle fall bør styringsorganisasjonen ha myndighet til å bygge bedriftstjenester uavhengig av budsjett – og ressursbegrensningene i prosjektet som i utgangspunktet vil forbruke tjenestekandidaten. Årsaken er at gjenbrukbarhet vanligvis kommer med et større omfang som oversetter til en høyere prislapp.
styringsorganisasjonen er forvalter av tjenestedefinisjoner som forventes å bli forvaltet som bedriftsmidler. Det er også ansvarlig for å opprettholde sporbarheten og overholdelse av andre virksomhetsaktiva som forretningsprosessmodeller og referansedatamodellen. Vi vil komme tilbake på båndene til en referanse eller enterprise datamodell i den siste delen av dokumentet.
Personer
artikkelen nevnt før beskrev roller1 involvert I service governance aktiviteter fra et tjenesteimplementeringsperspektiv. Når en organisasjon starter Sin Serviceorienterte Arkitektur, er disse rollene tilstrekkelig til å garantere levering av bedriftsklassetjenester, spesielt når DE tilhører ET SOA Center Of Excellence.
| Rolle | Beskrivelse |
| Business Service Eier |
|
| Teknisk Service Eier |
|
| SOA Platform Architect |
|
| Tjenester Utvikler |
|
når en organisasjon er moden og antall tjenestekandidater øker, er det nyttig å introdusere en styreleder som vil eie prosessen og ressursene for å sikre at styrings aktiviteter utføres på riktig måte og problemer løses i tide. Han bør assisteres av et tverrfunksjonelt styringsråd og en tjenestebibliotekar.
| Rolle | Beskrivelse |
| Ledelse |
|
| Governance council |
|
| Service Bibliotekar |
|
vi ser tre hovednivåer av modenhet i Forhold Til Service Governance organisasjon.
| Modenhet | Organisasjon |
| Etablering |
|
| Utførelse |
|
| Optimalisert |
|
Figur 1 representerer noen av samspillet mellom rollene som er involvert I Tjenestestyring.
Figur 1. Samhandling mellom ulike styrings bestanddeler
nøkkelen i å bygge en vellykket Service governance organisasjon er igjen å være smidig og sette sammen akkurat nok ressurser, prosesser og teknologier for å møte dine behov, men ikke mer. En stor service governance organisasjon uten en rimelig rørledning av service kandidater vil raskt miste steam og savner muligheten til å gi tilstrekkelig tilbakemelding på noen service kandidater.
du vil bygge en organisasjon som vil fremme gjenbruk av tjenester, intet mindre, ingenting mer.
Prosess
Prosesser og aktiviteter
det er fem typer aktiviteter utført AV SOA governance organization:
- Service Candidate Management
- Service Change Management
- Service Consumer Management
- Service Roadmap Management
- SOA Governance Policyendringer
Figur 2 representerer noen av aktivitetene som kan utføres under Service Candidate Management-prosessen. Et prosjektteam kan identifisere en tjeneste og opprette et tjenesteforslag. Dette forslaget godkjennes, godkjennes med endringer eller avslås (som virksomhetstjeneste) når denne tjenestekandidaten ikke potensielt kan gjenbrukes av andre deler av virksomheten.
når tjenestekandidaten er akseptert, defineres eier-og finansieringsmodellen og Sla-Ene og Olaene spesifiseres ved hjelp av tjenesteeier og potensielle forbrukere.
når tjenesten er realisert, publiseres metadataene til registeret og depotet. I store organisasjoner anbefales det å holde oversikt over tjenestene under bygging for å unngå samtidige tjenesteforslag.
Endringsledelsesaktiviteter er ofte identiske med aktiviteter som utføres under en servicekandidatgjennomgang. Aktiviteter som tjenesteeierskap, finansieringsmodell eller Sla / OLAs-spesifikasjon kan v re valgfrie.
et kritisk aspekt ved endringsledelse er effektiv styring av forwards-kompatible tjenester (2).
Tjenesteforbrukeradministrasjonsaktiviteter utføres for det meste av tjenestebibliotekaren, med mindre det er endringer som er nødvendige for at denne nye forbrukeren skal kunne bruke tjenesten. Bibliotekaren kan hjelpe tjenesteforbrukerne med å identifisere måltjenesten og skaffe seg en kopi av metadataene.
Service Roadmap Management aktiviteter er gitt hvis Service Governance fungerer proaktivt for å identifisere tjenester uten spesifikke prosjektforespørsler. På det tidspunktet Bør Tjenestestyringen ha budsjetter for å utføre utviklingen av disse tjenestene foran prosjektene som vil forbruke dem. Dette er kritisk suksessfaktor for styring siden design og implementering av gjenbrukbare tjenester kan gå langt utover omfanget, midlene og tidsplanen for et gitt prosjekt. Styringsaktiviteter selv ta tid og kan anbefale lange oppgraderinger til en tjeneste kandidat. Det er derfor det er så viktig at styringsorganisasjonen håndterer tidsplaner og faser forbrukerspesifikke krav i tide, og minimerer virkningen av løsningsleveringsplaner.
Figur 2. Service Candidate Management Activities
Endelig kan en styringsorganisasjon engasjere IT-styring for å definere eller endre sine driftspolicyer.
Tjenestemetadata
tjenestekandidatforslaget inneholder en beskrivelse av tjenestegrensesnittet (ikke nødvendigvis i maskinlesbar form) samt alle funksjonelle og ikke-funksjonelle krav knyttet til tjenesten som for eksempel skal brukes til å definere Sla-Ene og Ola-Ene. CBDI Forum Service Architecture & Engineering meta model FOR SOA (3) gir en god oversikt over informasjonen i forhold til en tjeneste som er fanget i de tidlige stadiene av livssyklusen og raffinert over tid.
CBDI Forum SAETM metamodel inneholder en tjenestedefinisjon, inkludert foreslåtte operasjoner, retningslinjer og relaterte tjenester, samt en tjenesteklassifisering. CBDI forum anbefaler også å inkludere en business level service definisjon som relaterer forretningsprosesser, forretningsmuligheter, forretningsregler… til tjenestedefinisjonen.
All denne informasjonen kan potensielt brukes når en forbruker søker etter en bestemt tjeneste. Derfor er det viktig å fange det på en strukturert måte, selv om maskinlesbare beskrivelsesstandarder som WSDL ikke (ennå) støtter denne typen informasjon.
CBDI Forum SAE™ metamodel gir en egen seksjon for tjenestespesifikasjonen. Det interessante aspektet ved denne delen av metamodelen er at den holder styr på informasjonstypene som er involvert i tjenesten som operasjonsargumenter. Denne funksjonen er ikke godt støttet AV WSDL, for EKSEMPEL, som bare definerer representasjoner av forretningstyper som utveksles som deler av drift besvergelser, men ikke forretningstypene selv.
sporbarheten av informasjonstyper er kritisk fordi den forhindrer innføring av operasjonsspesifikk semantikk. En meldingstype skal alltid defineres med nære bånd til referansedatamodellen. FAKTISK BØR SOA-styringsprosessene sørge for at ingen ytterligere semantikk er definert i meldingstypen sammenlignet med referansedatamodellen.
CBDI Forum SAE™ metamodel holder også oversikt over forretningskomponentene som brukes i en tjenesteimplementering.
faktorer for Gjenbruk av Tjenester
det er tre viktige faktorer å vurdere når du bidrar til å fremme spesifikasjonen av gjenbrukbare tjenester. Først må et servicegrensesnitt være komplett med hensyn til nåværende og potensielle forbrukere. En god beregning å spore er antall grensesnitt og implementeringsendringer etter hvert som nye forbrukere kommer om bord, for både de som er fremover kompatible og de som ikke er.
For Det Andre må vi vurdere de aktuelle Service-Og Driftsnivåavtalene (Sla og OLAs). Noen SLA kan fungere perfekt for en forbruker og være en show stopper for en annen. SLAs og OLAs kan også være vanskelig å oppnå. SOA-styringsorganisasjonen skal holde oversikt over hendelsene og overvåke antall endringer I Sla-Er og Ola-Er som følge av disse hendelsene, samt antall endringer i tjenesteimplementeringen for effektivt å oppfylle Sla-Er og Ola-Er.
Til Slutt bør En Organisasjon For Tjenestestyring søke å identifisere alle potensielle forbrukere av en tjenestekandidat og involvere dem i prosessen med å ratifisere forslaget til tjenestegrensesnitt. En god beregning for å spore det er antall uventede kunder funnet etter at en tjeneste ble designet. Denne beregningen bør tolkes nøye siden det kan bety at tjenesten var godt utformet og tiltrukket mange forbrukere, eller det kan bety at det ikke ble brukt nok tid til å identifisere de riktige forbrukerne som resulterte i mange påfølgende endringer.
Service Governance aktiviteter og roller er ofte støttet av en governance løsning som er bygget rundt en tjeneste register og depot. Selv om det er ganske trivielt å si dette, er det viktig å alltid huske på at en eiendel bare kan gjenbrukes så mye som det kan bli funnet. Et register er katalogen eller indeksen som fungerer som «system of record» for tjenester i EN SOA (4).
ET SOA-register og depot støtter vanligvis følgende funksjoner:
- Lagrer tjenestemetadata som beskrivelser (meldingsformater og operasjoner), bindinger (kommunikasjonsprotokoller), endepunkter (den nettverkstilgjengelige ressursen som implementerer tjenesten)
- Gir en klassifiseringsmekanisme for å kategorisere og organisere tjenester
- lar brukere publisere nye tjenester (slik de identifiseres, realiseres og distribueres) i registret og bla gjennom og søke etter eksisterende eller planlagte tjenester
- Varsle tjenesteforbrukere av planlagte endringer
- administrer sla-og ola-rapporter samt forbruk statistikk
- Administrer sikre styringsprosesser og leveranser
- Gi revisjonsfunksjoner for å spore sporet av endringer og autorisasjon som brukes til ressursbeskrivelser
Styringsprosesser er geografisk fordelt i naturen og samarbeidende. Forvaltningen av disse prosessene er avgjørende for å få ulike parter til enighet om tjenestedefinisjonen og realiseringen.
siden registeret og depotet er systemet for registrering for tjenesteinformasjon både på designtid og kjøretid, er sikkerheten rundt «tjenesteposten» kritisk for å unngå erstatning av endepunkter for eksempel.
Forhold til Andre Styringsaktiviteter
Tjenestestyring er en ny type styring som en del av de bredere IT-styringsaktivitetene som ledes av Bedriftsarkitekturgrupper. IT-styring bør forbli i kontroll over SOA-plattformstyringen selv, Mens Tjenestestyring bør fokusere sine aktiviteter på å designe tjenester for gjenbruk på Bedriften, Tjenestealisering og Løsningsleveringsnivå (Figur 3). På bedriftsnivå Bør Tjenestestyring samarbeide tett MED IT-styring for å høste selskapets forretningsprosessmodell for å identifisere tjenestekandidater basert på en top-down analyse og etablere et veikart for distribusjon av disse tjenestene. Som vi har sett i prosessdelen tidligere, er servicenivået der DE fleste AKTIVITETENE I SOA-styring finner sted. Alle disse aktivitetene støttes av et register og depot.
På løsningsnivå bør Organisasjonen For Tjenestestyring evaluere og styre nivået for samsvar med SOAS retningslinjer for infrastruktur og tjenester.
Service Governance har sterke bånd til Datastyring via utnyttelse av enterprise Reference Data Model. Tjenestestyringsteamet bør håndheve bruken av referansedatamodellsemantikken for utformingen av operasjonsmeldingstyper.
målet her er ikke å skape en «Kanonisk Informasjonsmodell». I En Tjenesteorientert Arkitektur ville det na v re naï a tenke at forbrukerne alltid vil v re i stand til a vedta leverandorens synspunkt eller at bade leverandoren og forbrukeren alltid kan vedta samme synspunkt. Selv om dette var sant i dag, kan overtid, forbrukere og leverandører ikke være i stand til å utvikle seg samtidig mot en nyere versjon av grensesnittet (det være seg fremover eller bakoverkompatibel).
Figur 3. Forholdet MELLOM SOA-styring og andre styringsaktiviteter
denne divergerende utviklingen håndteres ofte ved hjelp av en mellommann, og spesielt meldingstransformasjoner. Selv om mekling ikke er eksplisitt i W3CS webtjenestearkitektur (5), HAR SOA-utøvere for lenge siden brukt det systematisk for å oppnå et høyere nivå av løs kopling og muliggjøre autonome utviklinger mellom forbrukere og leverandører. Disse transformasjonene er uunngåelige, og denne evnen bør bygges inn I SOA-infrastrukturen. For øvrig krever mekling ikke en «Felles Informasjonsmodell». Hvis du skulle bruke en slik «felles informasjonsmodell» uavhengig av leverandør og forbrukergrensesnitt og fortsatt ønsker å oppnå løs kobling, vil du pådra deg kostnaden for to transformasjoner, for ikke å nevne at du fortsatt trenger å forvandle meldingsformatet til et datasettforbrukbart ved implementering av leverandør og forbruker.
de første skrittene mot mer håndterbare transformasjoner, er å utlede forbruker – og leverandørgrensesnitt fra referansedatamodellen. I referansedatamodellen er datastrukturen mindre viktig enn normalisering av semantikken. Disse semantikken styres med stor presisjon Av datastyring. Vanligvis etablerer referansedatamodellen sporbarhet til fysiske gjenstander som databaseskjemaer og COBOL-kopibøker. Denne sporbarheten kan være svært nyttig under implementeringen av tjenesten, mens bruken av normalisert semantikk vil bidra til å forenkle utviklingen av transformasjonskart mellom forbrukere og leverandører.
Konklusjon
Tjenestestyring er et viktig aspekt ved en Vellykket Tjenesteorientert Arkitektur. Etableringen må planlegges og testes ut tidlig i de første fasene AV ET SOA-initiativ. Imidlertid bør en fullskala styringsorganisasjon drevet av en streng prosess bare lanseres når servicerørledningen er stor nok til å holde teamet motivert og kunnskapsrik. Hvis styringsaktiviteter er for fjernt i tid, kan teamet miste interessen og den kritiske kunnskapen til å utføre sine aktiviteter på riktig måte. Registeret & Repository er en viktig ingrediens for vellykket styring som den administrerer «service record». Det endelige målet Med Service Governance er å muliggjøre spesifikasjon, realisering og drift av gjenbrukbare IT-eiendeler. Overtid er det forventet At Service Governance vil utvikle seg mot å være mye mer proaktiv i igangkjøring gjennomføringen av virksomhetskritiske tjenester.