Palvelun Hallinnointiorganisaation perustaminen

Johdanto

palvelu, olipa se fyysinen kuten kuljetuspalvelu tai ohjelmistoagentin toteuttama, on aina suunniteltu ja hiottu niin, että mahdollisimman monet kuluttajat voivat käyttää sitä uudelleen. Tämä on palvelukeskeisen arkkitehtuurin ydin: rakennusratkaisujen kustannusten, riskien ja viivästysten alentaminen factoringoimalla ja toteuttamalla tietotekniset resurssit siten, että ne voidaan käyttää uudelleen, usein suunnitteluaikana tuntemattomissa tilanteissa. Näin SOA: n hallinnointi ei eroa datan ja tietotekniikan hallinnoinnista, joiden tavoitteena on suunnitella tietomalleja tai valita teknologioita, joita voidaan käyttää uudelleen yli tietyn hankkeen rajojen. Palveluja on säänneltävä siten, että niistä tulee uudelleenkäytettäviä: kaikkien ennakoitavissa olevien kuluttajien on voitava ilmaista vaatimuksensa, jotka priorisoidaan ja vaiheistetaan samalla, kun palvelun omistaja nimetään ja rahoitusmalli määritellään.

aiemmassa kirjoituksessaan Stefan Tilkov tarkasteli tarkemmin SOA: n hallintorooleja (1). Tavoitteenani on auttaa sinua luomaan palveluhallinnointiorganisaatio ihmisten, prosessien ja teknologioiden osalta.

Palveluhallintoa koskeva peruskirja

palveluhallinnan päätavoitteena on saavuttaa palvelukeskeisen arkkitehtuurin edut edistämällä uudelleenkäytettävien, yritysluokan palvelujen luomista. Cross functional organization-organisaationa Palveluhallinto varmistaa ongelmien ja ristiriitojen oikea-aikaisen ratkaisun yhteisten vaatimusten määrittelyssä tehtyjen välttämättömien kauppojen vuoksi.

erityisesti Palveluhallinto-organisaatio on vuokrattu määrittelemään selkeät palvelun omistamisen rajat ja määrittelemään oikeudenmukainen rahoitusmalli.

Palveluhallinnossa seurataan palveluiden käyttöönottoa ja uudelleenkäyttöä koko organisaatiossa. Korkea palvelujen uudelleenkäyttöaste, tasainen virta enterprise-luokan palvelujen käyttöönotosta sekä ongelmaton palvelueläke ovat onnistuneen hallinnon indikaattoreita.

Palveluhallinto ei saa olla päällekkäinen perinteisen IT-hallinnon ja kokonaisarkkitehtuurin kanssa; niissä määritellään SOA-teknologioiden standardit ja tiekartta, jotka johtavat SOA-kypsyysasteen kasvuun, kun taas Palveluhallinnointiorganisaation tehtävänä on kehittää palvelumaisemaa.

yleisesti Palveluhallinnon rooli on passiivinen ja prosessipalveluehdokas, joka yksilöidään yksittäisissä hankkeissa tai liiketoimintayksikkötasolla. Vasta kun organisaatio on saavuttanut korkean kypsyystason, Palveluhallinto voi käynnistää systemaattisen ylhäältä alas tunnistamisen yrityspalveluista ja peruskirjan niiden toteuttamisesta riippumatta mistä tahansa projektista.

hallinto-organisaatiolla olisi joka tapauksessa oltava valtuudet rakentaa yrityspalveluja riippumatta hankkeen budjetista ja resurssirajoituksista, jotka alun perin kuluttavat palveluehdokasta. Syynä on se, että uudelleenkäytettävyys tulee yleensä laajemmalla soveltamisalalla, mikä merkitsee korkeampaa hintalappua.

hallinto-organisaatio on yritysomaisuutena hallinnoitavien palvelumääritelmien hoitaja. Se vastaa myös yrityksen muiden omaisuuserien, kuten liiketoimintaprosessimallien ja viitetietomallin, jäljitettävyyden ylläpidosta ja noudattamisesta. Palaamme sidoksiin viite-tai yritystietomalliin asiakirjan viimeisessä osassa.

ihmiset

edellä mainitussa artikkelissa kuvailtiin roleja1, joka osallistuu Palveluhallinnointiin palvelujen toteuttamisen näkökulmasta. Kun organisaatio aloittaa palvelukeskeisen arkkitehtuurinsa, nämä tehtävät riittävät takaamaan enterprise class-palveluiden toimittamisen, varsinkin kun ne kuuluvat SOA – osaamiskeskukseen.

rooli	kuvaus
yrityspalvelujen omistaja	Direct and control the service implementation, evolution and retirement Owns the functional scope of the service, the Service Level Agreements Manages effectively the capacities of the service to meet governance requests and ensure appropriate levels of reuse Report service activity to the governance organization
teknisen palvelun omistaja	Suorita palvelu implementation, evolution and retirement Owns the Operations Level Agreement and manages the service to meet its objectives as as availability, performance, security Monitors the service to identify potential issues with SLA and OLA Report service activity to the business owner
SOA Platform Architect	neuvoa ja keskustella SOA: n teknisistä standardeista IT: n ja SOA: n hallinnointiorganisaation kanssa varmista, että palvelutoteutukset ovat yhteensopivia
tiedoksianto Kehittäjä	avustaa toimiala-ja alustaarkkitehtia heidän hallintoon liittyvissä toimissaan pane täytäntöön hallintopolitiikat ja suositukset

organisaation kypsyessä ja palvelukandidaattien määrän kasvaessa on hyödyllistä ottaa käyttöön hallintojohtaja, joka omistaa prosessin ja resurssit varmistaakseen, että hallintotoimet toteutetaan asianmukaisesti ja asiat ratkaistaan oikea-aikaisesti. Hänen apunaan tulisi olla poikkitoiminnallinen hallintoneuvosto ja palvelukirjastonhoitaja.

rooli	kuvaus
johtoasema	hallinnoida kokonaishallintatoimintoja ihmisten, prosessien ja teknologian näkökulmasta vastuussa Palvelujen elinkaaresta vastuussa Palvelujen uudelleenkäytön mittareista tämä ei ole tyypillisesti kokopäiväinen rooli, ja sen voi täyttää toimialue – tai alustaarkkitehti
hallintoneuvosto	Arvostelupalvelun ehdokasehdotukset suosittele palvelun omistamista ja rahoitusta malli ratkaise kuluttajavaatimuksiin liittyvät kysymykset prioriteetit, palvelun omistus, rahoitusmalli, aikataulut, SLAs ja OLAs tämä on cross functional-tiimi, joka kattaa mahdollisimman monta osa-aluetta
Palvelukirjastonhoitaja	Hallitse palvelun elinkaaritoimintoja, jotka liittyvät palvelurekisteriin ja arkistoon ylläpitää rekisterin taksonomiaa varmista, että tarkat tiedot ja metatiedot tallennetaan arkistoon jälleen, tämä ei ole tyypillisesti kokopäiväinen rooli ja voidaan sekoittaa arkkitehdin rooli

näemme Palveluhallinto-organisaatiossa kolme kypsyystasoa.

maturiteetti	organisaatio
perustaminen	SOA-aloite on käynnistynyt äskettäin SOA: n muodostama osaamiskeskus hallinnoi kaikkia aloitteen osa-alueita, mukaan lukien alustan määrittely ja käyttöönotto, palvelujen rakentaminen ja omistajuus sekä SOA: n hallinto rakenteilla olevien palvelujen määrä on suhteellisen pieni Rekisteriä ei vielä tarvita, koska kaikki palveluun liittyvä toiminta tapahtuu pienessä ryhmässä.
suoritus	hallintaprosessin hallinnointia varten perustetaan Rekisteri ja Arkisto, ja metatiedot hallintopäällikkö ja palvelukirjastonhoitaja nimetään palveluja rakennetaan edelleen SOA CoE: n puitteissa, mutta useita kuukausia kestävällä vauhdilla tuetaan tehtäväkriittisiä ratkaisuja joissakin tapauksissa perustetaan SOA: n neuvosto keskustelemaan erityiskysymyksistä.
optimoitu	tarkastuslausuman neuvosto nimitetään ja se kokoontuu säännöllisesti keskustelemaan palveluehdokkaiden ehdotuksista palvelusuunnitelma on SOA: n hallinnointiorganisaation määrittelemä ja hallinnoima, joka auttaa käynnistämään palveluiden toteutukset ennen projektin tarpeita

Kuva 1 kuvaa joitakin palvelujen hallinnointiin liittyvien roolien välisiä vuorovaikutussuhteita.

Kuva 1. Vuorovaikutus hallinnon eri osatekijöiden välillä

onnistuneen palveluhallinnointiorganisaation rakentamisessa avain on jälleen ketteryys ja resurssien, prosessien ja teknologioiden kokoaminen juuri ja juuri tarpeidesi mukaisiksi, mutta ei enempää. Suuri Palveluhallinnointiorganisaatio ilman kohtuullista palvelukandidaattien putkea menettää nopeasti höyrynsä ja menettää mahdollisuuden antaa riittävää palautetta joistakin palvelukandidaateista.

haluat rakentaa organisaation, joka edistää palvelujen uudelleenkäyttöä, ei vähempää, ei enempää.

prosessi

prosessit ja toiminnot

SOA: n hallintoorganisaatiossa on viisi erilaista toimintaa:

Service Candidate Management
Service Change Management
Service Consumer Management
Service Roadmap Management
Soa Governance Policy Changes

Kaavio 2 kuvaa joitakin toimintoja, joita voidaan suorittaa Palvelukandidaatin johtamisprosessin aikana. Projektiryhmä voi tunnistaa palvelun ja luoda palveluehdotuksen. Tämän jälkeen ehdotus hyväksytään, hyväksytään muutoksin tai hylätään (yrityspalveluna), kun yrityksen muut osat eivät voi käyttää tätä palveluehdokasta uudelleen.

kun palvelun hakija on hyväksytty, määritellään omistus-ja rahoitusmalli sekä palvelun omistajan ja potentiaalisten kuluttajien avustuksella SLAs-ja OLAs-palvelut.

kun palvelu on toteutettu, sen metatiedot julkaistaan rekisteriin ja arkistoon. Suurissa organisaatioissa on suositeltavaa seurata rakenteilla olevia palveluita, jotta vältetään samanaikaiset palveluesitykset.

Muutosjohtamistoimet ovat usein samanlaisia kuin palvelukandidaattikatselmuksen aikana suoritetut toimet. Toiminnot, kuten palvelujen omistus, rahoitusmalli tai SLAs/OLAs-määrittely, voivat olla valinnaisia.

yksi muutosjohtamisen kriittinen näkökohta on termiiniyhteensopivien palvelujen tehokas hallinta (2).

Palvelukirjastonhoitaja hoitaa Palvelunhallintatoimet pääosin,ellei muutoksia tarvita, jotta Uusi kuluttaja voi käyttää palvelua. Kirjastonhoitaja voi auttaa palvelun kuluttajia tunnistamaan kohdepalvelun ja hankkimaan kopion sen metatiedoista.

palvelun tiekartan hallintatoimet annetaan, jos Palveluhallinto toimii ennakoivasti palvelujen tunnistamiseksi ilman erityisiä hankepyyntöjä. Siinä vaiheessa Palveluhallinnolla pitäisi olla budjetit, joilla näiden palvelujen kehittäminen voitaisiin teettää ennen niitä kuluttavia hankkeita. Tämä on hallinnon kriittinen menestystekijä, koska uudelleenkäytettävien palvelujen suunnittelu ja toteutus saattavat ylittää selvästi tietyn hankkeen soveltamisalan, keinot ja aikataulun. Hallintotoimet itsessään vievät aikaa ja saattavat suositella pitkiä päivityksiä palveluehdokkaalle. Siksi on niin tärkeää, että hallinto-organisaatio hoitaa aikataulut ja vaiheistaa kuluttajakohtaiset vaatimukset oikea-aikaisesti minimoiden ratkaisujen toimitusaikataulujen vaikutukset.

kuva 2. Palvelukandidaattien johtaminen

lopuksi hallinto-organisaatio saattaa sitoutua IT-hallintoon toimintaperiaatteidensa määrittelemiseksi tai muuttamiseksi.

palvelun metatiedot

palveluehdokkaan ehdotus sisältää kuvauksen palveluliittymästä (ei välttämättä koneellisesti luettavassa muodossa) sekä kaikki palveluun liittyvät toiminnalliset ja ei-toiminnalliset vaatimukset, joita käytetään esimerkiksi SLAs-ja OLAs-palvelujen määrittelyssä. CBDI Forum Service Architecture & Engineering meta model for Soa (3) tarjoaa hyvän näkymän palveluun liittyvästä informaatiosta, joka otetaan talteen elinkaaren alkuvaiheessa ja tarkennetaan ajan myötä.

CBDI Forum SAETM metamodel sisältää palvelumääritelmän, mukaan lukien ehdotetut toiminnot, toimintaperiaatteet ja niihin liittyvät palvelut, sekä palveluluokituksen. CBDI forum suosittelee myös liiketoimintatason palvelumääritelmän sisällyttämistä liiketoimintaprosesseihin, liiketoimintaominaisuuksiin ja liiketoimintasääntöihin… palvelun määrittelyyn.

kaikkia näitä tietoja voidaan mahdollisesti käyttää, kun kuluttaja etsii tiettyä palvelua. Siksi on tärkeää tallentaa se jäsennellyllä tavalla, vaikka koneellisesti luettavissa olevat kuvausstandardit, kuten WSDL, eivät (vielä) tue tällaista tietoa.

CBDI Forum SAE™ – metamodelissa on erillinen osio palvelun määrittelyä varten. Mielenkiintoista tässä osassa metamodelia on, että se pitää kirjaa tietotyypit, jotka ovat mukana palvelun käyttöargumentteina. Tätä ominaisuutta ei tue hyvin esimerkiksi WSDL, joka määrittelee vain vaihdettavien liiketoimintatyyppien edustukset operaatiokutsujen osina, mutta ei itse liiketoimintatyyppejä.

tietotyyppien jäljitettävyys on kriittistä, koska se estää operaatiospesifisten semantiikkojen käyttöönoton. Viestityyppi olisi aina määriteltävä siten, että se liittyy läheisesti viitetietomalliin. SOA: n hallintaprosesseissa olisi itse asiassa varmistettava, että viestityypissä ei ole muita semantiikoita verrattuna viitetietomalliin.

CBDI Forum SAE™ metamodel pitää myös kirjaa liiketoiminnan komponenteista, joita käytetään palvelun toteutuksessa.

palvelujen Uudelleenkäytettävyystekijät

on kolme tärkeää tekijää, jotka on otettava huomioon edistettäessä uudelleenkäytettävien palvelujen määrittelyä. Ensinnäkin palveluliittymän on oltava täydellinen suhteessa sen nykyisiin ja mahdollisiin kuluttajiin. Hyvä mittari seurata on määrä käyttöliittymä ja täytäntöönpano muutoksia uusia kuluttajia tulla aluksella, sekä ne, jotka ovat eteenpäin yhteensopivia ja ne, jotka eivät ole.

toiseksi on otettava huomioon asianmukaiset palvelu-ja Toimintatasosopimukset (SLAs ja OLAs). Jotkut SLA voisi toimia täydellisesti yhdelle kuluttajalle ja olla show tulppa toiseen. Myös SLAs-ja OLAs-järjestelmät voivat olla hankalia toteuttaa. SOA: n hallinnointiorganisaation tulisi seurata häiriötilanteita ja seurata näistä häiriöistä johtuvien muutosten määrää SLAs: iin ja OLAs: iin sekä palvelujen toteutukseen tehtyjen muutosten määrää täyttääkseen tehokkaasti sen palvelutasosopimukset ja OLAs: t.

lopuksi palvelujen Hallinnointiorganisaation olisi pyrittävä tunnistamaan kaikki mahdolliset palveluehdokkaan kuluttajat ja ottamaan heidät mukaan palvelurajapintaehdotuksen ratifiointiprosessiin. Hyvä metri seurata siellä on määrä odottamattomia asiakkaita löytyy sen jälkeen, kun palvelu on suunniteltu. Tämä mittari olisi tulkittava huolellisesti, koska se voi tarkoittaa, että palvelu on hyvin suunniteltu ja houkutteli paljon kuluttajia, tai se voi tarkoittaa, että ei käytetty tarpeeksi aikaa tunnistaa oikeat kuluttajat, mikä johti paljon myöhempiä muutoksia.

palveluhallinnan toimintaa ja tehtäviä tukee usein hallintaratkaisu, joka rakentuu palvelurekisterin ja arkiston ympärille. Vaikka tämän sanominen on melko triviaalia, on tärkeää pitää aina mielessä, että hyödykkeen voi käyttää uudelleen vain niin paljon kuin sitä löytyy. Rekisteri on luettelo tai hakemisto, joka toimii tarkastuslausuman (4) piiriin kuuluvien palvelujen ”tallennusjärjestelmänä”.

SOA-Rekisteri ja arkisto tukevat tyypillisesti seuraavia funktioita:

tallentaa palvelun metatiedot, kuten kuvaukset (viestimuodot ja operaatiot), sidokset (viestintäprotokollat), päätepisteet (verkkopalvelun käyttävä resurssi, joka toteuttaa palvelun)
tarjoaa luokittelumekanismin, joka auttaa luokittelemaan ja järjestämään palvelut
antaa käyttäjille mahdollisuuden julkaista uusia palveluita (sellaisina kuin ne tunnistetaan, toteutetaan ja otetaan käyttöön) rekisteriin sekä selata ja etsiä olemassa olevia tai suunniteltuja palveluita
ilmoittaa palvelun kuluttajille suunnitelluista muutoksista
hallitse SLA-ja Ola-raportteja sekä kulutusta tilastot
hallinnoivat turvallisesti hallintoprosesseja ja tuotoksia
tarjoavat tarkastusvalmiudet, joiden avulla voidaan seurata muutosten jälkiä ja valtuutuksia, joita sovelletaan omaisuuskuvauksiin

hallintoprosessit ovat maantieteellisesti hajautettuja luonteeltaan ja yhteistoiminnallisesti. Näiden prosessien johtaminen on ratkaisevan tärkeää, jotta eri tahot pääsevät yhteisymmärrykseen palvelun määrittelystä ja toteutuksesta.

koska rekisteri ja arkisto ovat palvelutietojen tallennusjärjestelmä sekä suunnitteluaikana että suoritusaikana, ”palvelutietueen” liittyvä turvallisuus on kriittinen, jotta vältetään esimerkiksi päätepisteiden korvaaminen.

suhde muuhun Hallintotoimintaan

Palveluhallinto on uudenlainen hallintotapa osana laajempia Tietohallintotoimenpiteitä, joita johtavat Kokonaisarkkitehtuuriryhmät. IT-hallinnon olisi pysyttävä itse SOA-alustahallinnan hallinnassa, kun taas Palveluhallinnossa olisi keskityttävä uudelleenkäytettävien palvelujen suunnitteluun yritys -, Palvelutoteutus-ja Ratkaisutoimitustasolla (kuva 3). Yritystasolla Palveluhallinnoinnin olisi tehtävä tiivistä yhteistyötä IT-hallinnon kanssa, jotta yrityksen liiketoimintaprosessimalli voidaan tunnistaa ylhäältä alas-analyysin perusteella ja jotta voidaan laatia etenemissuunnitelma näiden palvelujen käyttöönotolle. Kuten olemme aiemmin prosessiosiossa nähneet, palvelutaso on siellä, missä suurin osa SOA: n hallinnoinnista tapahtuu. Kaikkia näitä toimintoja tukee Rekisteri ja arkisto.

ratkaisutasolla Palveluhallinnointiorganisaation tulisi arvioida ja ohjata SOA: n infrastruktuuri-ja palveluohjeiden noudattamista.

Palveluhallinnolla on vahvat siteet tiedonhallintaan enterprise Reference-tietomallin hyödyntämisen kautta. Palvelun Hallintotiimin olisi valvottava viitetietomallin semantiikan hyödyntämistä käyttöviestityyppien suunnittelussa.

tässä ei pyritä luomaan ”kanonista tietomallia”. Palvelukeskeisessä arkkitehtuurissa olisi naiivia ajatella, että kuluttajat voivat aina omaksua palveluntarjoajan näkökulman tai että sekä palveluntarjoaja että kuluttaja voivat aina omaksua saman näkökulman. Vaikka tämä olisi totta tänään, ylitöitä, kuluttajat ja palveluntarjoajat eivät ehkä ole asemassa kehittyä samaan aikaan kohti uudempaa versiota käyttöliittymän (olipa se eteenpäin tai taaksepäin yhteensopiva).

kuva 3. SOA: n hallinnon ja muiden hallintotoimien välinen suhde

tätä eriävää kehitystä käsitellään usein välittäjän avulla ja erityisesti sanomamuutoksia käyttäen. Vaikka sovittelu ei ole yksiselitteinen W3C: n verkkopalveluarkkitehtuurissa (5), SOA: n harjoittajat ovat jo kauan sitten käyttäneet sitä systemaattisesti saavuttaakseen suuremman löyhän kytkennän ja mahdollistaakseen itsenäisen kehityksen kuluttajien ja palveluntarjoajien välillä. Nämä muutokset ovat väistämättömiä, ja tämä kyky pitäisi rakentaa SOA-infrastruktuuriin. Sovittelu ei muuten vaadi ”yhteistä Tiedotusmallia”. Jos käyttäisit tällaista” yhteistä tietomallia ” riippumatta palveluntarjoajasta ja kuluttajarajapinnasta ja haluat silti saavuttaa löysän kytkennän, sinulle aiheutuisi kahden muutoksen kustannukset, puhumattakaan siitä, että sinun on vielä muutettava viestimuoto tietokokonaisuudeksi, joka on kuluttava palveluntarjoajan ja kuluttajan toteuttamana.

ensimmäinen askel kohti hallittavampia muutoksia on johtaa kuluttajan ja palveluntarjoajan rajapinnat viitetietomallista. Viitetietomallissa tietorakenne on vähemmän tärkeä kuin semantiikan normalisointi. Näitä semantiikkaa hallitaan erittäin tarkasti Tiedonhallinnalla. Yleensä viitetietomalli luo jäljitettävyyden fyysisiin esineisiin, kuten tietokantojen skeemoihin ja COBOL-kopiokirjoihin. Tämä jäljitettävyys voi osoittautua erittäin hyödylliseksi palvelun käyttöönoton aikana, kun taas normalisoitujen semantiikan käyttö auttaa yksinkertaistamaan muuntokarttojen kehittämistä kuluttajien ja palveluntarjoajien välillä.

johtopäätös

Palveluhallinto on olennainen osa onnistunutta palvelukeskeistä arkkitehtuuria. Sen perustaminen on suunniteltava ja testattava SOA-aloitteen alkuvaiheessa. Tiukan prosessin vetämä täyden mittakaavan hallinto-organisaatio tulisi kuitenkin käynnistää vasta, kun palveluputki on riittävän suuri pitämään tiimin motivoituneena ja asiantuntevana. Jos hallintotoimet ovat ajallisesti liian etäisiä, tiimi saattaa menettää kiinnostuksensa ja kriittisen osaamisensa toteuttaa toimintansa kunnolla. Rekisteri & arkisto on avainasemassa onnistuneessa hallinnoinnissa, sillä se hallinnoi ”palvelurekisteriä”. Palveluhallinnan perimmäisenä tavoitteena on mahdollistaa uudelleenkäytettävien IT-laitteiden määrittely, toteutus ja käyttö. Ylityö on odotettavissa, että Palveluhallinto kehittyy paljon ennakoivammaksi tehtäväkriittisten palvelujen käyttöönoton käyttöönotossa.