Att förvalta SOA-lösningar med hjälp av pm3 : pm3 som del av SOA governance modell

••

ATT FORVALTA

••

SOA LOSNINGAR

MED HJÄLP AV

pm

3

- pm

3

_{som del}

_av

_SOA

_governance

_modell

PÅSYN:oo6A

Sedan 1984 har vi deltagit på systemförvaltningsarenan i Sverige, varav de senaste 15 åren även som kunskapsutvecklare inom ämnet. Tillsammans har vi varit med i Riksdataförbundets (nuvarande Dataföreningen) stora arbete om systemförvaltning, publicerat två avhandlingar; en licentiatavhandling och en doktorsavhandling samt författat fyra böcker om systemförvaltning. Vi har dessutom skrivit svenska och internationella artiklar när det gäller systemfötvaltning. Tillsammans med våra kollegor på På AB har vi genomfört drygt 380 förvaltningsetableringar av vår modell Affärsmässig Förvaltningsstyrning i cirka 80 organisationer. Modellen är numera vidareutvecklad till pm'

(på

maintenance management mode!) och betraktas av många som en branschstandard för systemförvaltning.

Denna rapportserie - PÅSYN - är ett sätt att bidra till kunskapsutvecklingen inom förvalt-ningsområdet. Vi har under några år publicerat rapporter som beskriver olika fenomen inom systemförvaltningsområdet (se baksidan av rapporten forforteckning överpublicerade rapportei). Alla har det gemensamt att vi baserar våra skrifter på egna pral,tiska erfarenheter samtidigt som de är teoretiskt grundade i egen eller annans forskning.

PÅSYN vänder sig till dig som studerar de här frågorna, dig som arbetar med system-förvaltning och dig som av annan anledning vill förstå vad systemsystem-förvaltning innebär. PÅSYN:006A handlar om förvaltning av SOA lösningar med hjälp av pm'. Rapporten har sitt ursprung i ett par frukostmöten i Dataföreningens regi där Malin Nordström från På var inbjuden för att tala kring just förvaltning av SOA lösningar. Intresset var stort både i Stockholm och i Göteborg varför presentationen utvecklades till en rapport. Rapporten är baserad på erfarenheter från 10-talet uppdrag med SOA lösningar samt en mindre litteraturstudie.

DANDERYD 2008-09-29

Malin Nordström & Tommy Welander

2

I.

INLEDNING

SOA - Service Oriented Architechture är ett område som för närvarande är hett inom IT-branschen. Konferenser och kurser drar fulla hus för att diskutera övergången från legacy till moderna SOA lösningar. De flesta är eniga om att SOA inte är något nytt koncept utan att det är ett naturligt nästa steg i IT-urvecklingen. Maries och Bell (2006) bekräftar att SOA inte är nytt men de är överrygade om att SOA är här för att stanna. SOA är enligt författarna uppnåeligt tack vare;

• standardisering - Microsoft och IBM har anslutit sig

• tillgänglig teknik - standardprodukter är tillgängliga för rimliga summor

• frustration - det måste vara möjligt att integrera IT-system i verksamheter på bättre sätt än dagens (ibid).

Detta innebär att SOA inte blir någon big-bang revolution, utan snarare en evolution vilket

gör att organisationer måste leva i ett både och tillstånd där vissa komponenter är realiserade

enligt SOA medan andra inte är det. Att det krävs ett nytt sätt att förvalta när det finns

tjänsteorienterade komponenter inblandade är den samlade expertisen överens om. Detta

kan belysas genom följande citat; "When a high percentage ofservice inventory is comprised of reusable services, traditional governance approaches are no longer applicable" (Erl 2004). Men hur skall man tänka? Hur skall man göra när några delar av ett förvaltningsobjekt är i SOA miljö och andra inte? Marks och Bell (2006) menar att den stora utmaningen med SOA inte bör härröras till tekniska problem utan till organisatoriska, kulturella och förhållningssätt. I denna rapport visas hur SOA lösningar principiellt kan förvaltas med hjälp av pm3

. Med

andra ord hur pm' kan användas som en del i en SOA governance modell (avsnitt 2). Den läsare som känner till pm' väl vill vi göra särskilt uppmärksam på att SOA handlar om de tekniska delarna av ett förvaltningsobjekt (skikt 3 och 4 i figur 5). Vidare är det viktigt att påpeka att rapporten därför inte belyser alla principer kring objektindelning - utan är ett exempel som snarare visar på olika ryper och karal,tärer av förvaltningsobjekt (avsnitt 4).

Vi menar att pm' innebär ett nytt sätt att tänka när det gäller förvaltning, oavsett SOA eller inte. Vi ser också att det blir nödvändigt att tänka bortom traditionell systemägarförvaltning (se nedan) när man realiserat en SOA lösning - även om vi rycker att man borde ha tänkt nytt även tidigare. Ny teknisk arkitektur gör det dock nödvändigt att tänka på nytt sätt. Den traditionella systemägarrollen behöver utmanas - funktionalitet kan nyttjas utan att den behöver vara ägd (Bennett och Xu, 2003). Denna rapport skall därför inte ses som någon omkullkastning av de grundläggande teorierna bakom pm', utan snarare en precisering som

kan vidareföras oavsett vilken teknisk arkitektur som föreligger. Vi tror att många problem

som idag anses härröra till teknisk arkitektur - dessutom är en mångårig konsekvens av en mindre bra ansvarsfördelning i organisationer. En ansvarfördelning som kan ha hindrat

successiv vidareutveckling på affärsmässiga grunder. Med detta vill vi uppmana de som

redan har en ny arkitektur att tänka efter noga innan ansvar fördelas, men också

till

dem

som inte har en ny arkitektur att det är möjligt att skapa en ansvarfördelning som ger bättre förutsättningar för återanvändbarhet och flexibilitet redan i nuläget.

Thomas Er!, en flitigt anlitad SOA expert, uppmärksammar också att behovet av en fungerande styrning efter utvecklingsprojektet är en stor fråga som måste hanteras

(www.soamag.com). Han hävdar att styrningsperspektivet är en fråga man inte kan blunda för om man vill

få

effekt av SOA ideerna om ökad återanvändbarhet och flexibilitet. Han skriver också en bok som särskilt fokuserar SOA governance. SOA governance är det begrepp som ligger närmast det som den här rapporten handlar om. SOA governance tolkar vi som en del av det vidare begreppet IT governance (se sidan 7).

Till de organisationer som redan idag infört pm3 _{kan en förvaltning av objekt vars IT-lösningar är}

realiserade enligt SOA innebära att de måste ta de fulla konsekvenserna av ett pm3 _införande.

Tydligast blir detta i ansvarsfördelningen mellan objektägare och IT-systemägare. Flera har kanske hört oss envist hävda att systemägaren är död. Vi vågar påstå att SOA verkligen innebär

dödsstöten för systemägaren. Med systemägaren avser vi den definition som lanserades av

Riksdataförbundet 1987 och som återfinns i många stora organisationer.

Målgrupp och läsanvisningar

Rapporten vänder sig till dem som på ett eller annat sätt kommer i kontakt med SOA och har ett behov av att tänka nytt när det gäller förvaltningsstyrning. Rapporten inleds med en redogörelse för vad SOA och pm' innebär. Därefter följer en analys som fokuserar på

tjänstebegreppet samt ett exempel från en personaladministrativ verksamhet som visar hur pm3 _{kan användas för att avgränsa förvaltningsobjekt i en SOA miljö. Rapporten avslutas med}

slutsatser och ideer om fortsatt kunskapsutveckling.

4

2. PROBLEMOMRÅDE

Många organisationer bedriver idag det som brukar benämnas för stuprörsförvaltning. Ur förvaltningsperspektiv innebär det att det finns en systemägare som organisatoriskt är placerad i verksamheten och har ansvar för IT-system eller grupper av IT-system. Ansvaret sträcker sig genom flera lager i arkitekturen (presentation, verksamhetslogik och datalagring). Problem uppstår ofta när många organisatoriska parter använder sig av IT-systemen och vill ha påverkansmöjlighet på dess funktionalitet och användning. En traditionell systemägarmodell bygger nämligen på ett ett-till-ett förhållande mellan IT-system och nyttjare. Organisationer som bedriver stuprörsförvaltning har ofta flera IT-system för samma sak, det finns ingen möjlighet till återanvändbarhet eftersom systemägaren "äger" sitt IT-system och incitamentet för att bygga återanvändbara komponenter som andta kan nyttja saknas. Figur 1 illustrerar principerna för stuprörsförvaltning. VERKSAMH ETSPROCESS PRESENTATION VERKSAMHETSLOGIK DATALAGRING SYSTEMÄGARE 1 SYSTEMÄGARE 2 Figur I. Stuprörsforvaltning.

I

l

r1

r

1

Il

n

n

[]

1

1

r

f

l

11

r

J

f

I

I I

I

I

l I

1 I

I

I

I I

I

I

I

I

l I

I

J

I J

l I

Stuprörsförvaltning är därmed inte förenligt med SOA tankarna på hållbarhet, återanvänd-barhet och flexibilitet - man behöver tänka på ett nytt sätt. Eller som Marks och Bell

utrycker det ''Breaking silos oj asset ownership" (Marks and Bell 2006 s. 45). Vi är rädda för att organisationer helt enkelt organiserar bort hela iden med SOA arkitektur genom att göra en olycklig ansvarsfördelning. Det är troligen det som händer om man använder en traditionell systemägarmodell för att organisera förvaltning vars IT-lösningar är SOA baserade.

Ytterligare en dimension på problembilden är den organisatoriska. Traditionell

systemägar-förvaltning tar sin utgångspunkt i att förvaltningen sker inom en och samma organisation.

I praktiken är denna situation i nuläget undantag - inte bara som en följd av den utkontak-teringsvåg som präglat IT-branschen (Lacity och Wilkocks, 2001), utan även på grund av den tekniska urvecklingen. Förvaltningen av SOA lösningar, t.ex. Web Services genomförs av många samarbetande organisationer (Kajko-Mattson, 2004).

För att lösa behovet av en fungerande förvaltning som istället möjliggör SOA tankarna på hållbarhet, återanvändning, flexibilitet och interorganisatoriskt tänkande behövs en förvaltningsmodell som stödjer dessa tankar. Vi menar att pm', som är en modell för att organisera samverkan mellan affärs- och IT-parter för att säkerställa en kostnadseffektiv, affårsbehovsdriven och mätbar förvaltningsverksamhet, är en modell som kan möta dessa krav. Modellen har en kombination av teoretisk och praktisk grundning och bygger på teoretiska och empiriska studier samt beprövad erfarenhet.

6

3.

TJÄNSTEORIENTERAD ARICITEKTUR - SOA

En serviceorienterad arkitektur kan beskrivas som ett sätt att organisera och integrera en

organisations IT-stödda processer. Tanken med SOA är att organisationer inte skall behöva uppfinna hjulet på nytt vid varje förändring utan istället organisera IT-system för att de lättare skall kunna återanvändas genom att stödja delning av data och resurser (Er/, 2005).

Tjänstebegreppet är centralt i SOA. I teorin definieras en service till någon form av samman-hängande och autonom del av verksamhetslogik (Earl, 2004). En service kan användas för att utföra en specifik verksamhetsfunktion, eller den kan vara en del av en aggregerad tjänst som tillsammans fullbordar en större verksamhetsuppgift. Marks och Bell (2006) menar

vidare att tjänster är abstraktioner av tekniska beståndsdelar, verksamhetsprocesser, data men

kan också vara konceptuella beståndsdelar. Tjänster kapslar in verksamhets- och tekniska lösningar. Slutsatsen är att en tjänst är avgränsad av någon form av meningsfullhet och utgör ett alternativ till tidigare sätt att realisera IT-system (jfi: figur 1 och figur 2).

Tjänsterna i en tjänsteorienterad arkitektur nås via meddelandebaserade gränssnitt. Enda sättet

att

fa

en tjänst att utföra något är att den tar emot och hanterar meddelanden. Meddelandet

når aldrig in i tjänstens "kärna" och de data som tjänsten hanterar, utan tjänstens logik

hanterar meddelandet och avgör om uppdraget ska utföras eller ej. En grundprincip är att varje tjänst skall vara autonom och bl.a. kunna utvecklas och underhållas fristående från sina

konsumenter, d.v.s. andra tjänster/program som via meddelanden ber tjänsten att utföra

sina uppdrag. Det finns även en tydlig avgränsning mellan tjänsten och dess omvärld och

förbindelsen mellan tjänsten och dess konsument förstörs när en tjänst har svarat på ett

mottaget meddelande. För att konsumenter och tjänster skall kunna prata med varandra måste man känna till vilket schema som ska användas och som bestämmer meddelandens struktur. SOA kan baseras på ett flertal teknologibaser. Den vanligaste är Web Services. Web services är en benämning på tjänster och funktioner för samverkan mellan nät och datorer i olika system. Web services bygger på olika standarder för kommunikation t ex SOAP (XML-baserat protokoll, simple objekt access protocol} och XML {standa,d for formatering av data}.

De meddelanden som utbyts mellan program i en Web services lösning baseras således på nämnda standards. (En liknelse kan vara att XML är innehållet i brevet som skickas och SOAP är kuvertet.} Då både SOAP och XML är programmeringsspråk- och plattformsoberoende kan

I förhållande till en traditionell arkitektur kan principerna för en SOA lösning illustreras i enlighet med figur 2 .

VERKSAMHETSPROCESS

PRESENTATION

VERKSAMHETSLOGIK

l

l

l

DATALAGRING

Figur 2. Principerfor en SOA lösning.

Pilarna i figur 2 visar att en viss tjänst kan användas i flera aktiviteter i en och samma process

(även i andra processer även om detta inte framgår av figuren).

SOA

governance

Den här rapporten handlar om organisering av förvaltning och det som ligger närmast

detta i SOA litteraturen är, som sagt, begreppet SOA governance. SOA governance innebär organisation, processer, regelverk och mätmetoder som behövs för att övergripande styra en tjänsteorienterad arkitektur framgångsrikt. Med framgångsrikt avses att möta definierade

affårsmål över tiden med en kort time to market. I tabell 1 visas innehållet i en SOA

governance modell.

14

5.

HUMAN RESOURCES (HR) - ETT EXEMPEL

För att åskådliggöra hur en pm3 _{förvaltning kan se ut i praktiken introduceras ett exempel från}

ett HR-objekt. Detta HR-objekt används sedan också som exempel för att åskådliggöra hur samma förvaltning kan se ut när IT-lösningen bygger på SOA. Exemplet är hämtat från en svensk myndighet.

Objektverksamheten definierades till att vara; personaladministration, lönehandläggning, rekrytering och personalvård. IT-systemen som användes var PA-systemet, egenrapportering på intranätet, PA-rekryt samt webbtjänsten kul & bus. Modellerat enligt figur 3 innebar detta följande objektsskiss

(figur 7).

OBJEKTVERKSAMHET IT-VERKSAMHET • Rekryterade medarbetare • Utbetalad lön • osv. FÖRVALTNINGSVERKSAMHET

I

I

Verksamhetsstöd

• Regelanpassade beräkningsfunktioner och nyckeltal • Dokumentportfölj för HR • Rekryteringsstöd • Kunskapsstöd

IT-system

• PA-systemel • PA·rekryt • Egenrapportering

•

Kul

&

bus

Vid etablering av pm' innebär utarbetandet av verksamhetsstöden ett klargörande av IT-systemens roll i objekrverksamheten. Det innebär samtidigt ett klargörande för den verksamhetsnära förvaltningen som far ett tydligare ansvarsområde. I det här fallet identifierades verksamhetsstöden till att vara regelanpassade beräkningsfunktioner och nyckeltal som fanns inbyggda i PA-systemet och dess dokumentation, HR-verksamhetens dokumentportfölj som innehåller allt från mallar för lönespecifikationer till mallar för anställningsavtal. Slutligen fanns också ett rekryteringsstöd och ett målgruppsanpassat kunskapsstöd.

I en traditionell förvaltning hade förvaltningen organiserats kring IT-systemen. PA-systemet och PA-rekryt hade blivit egna förvaltningsobjekt. Egenrapportering hade ingått i intranät-förvaltningen och kul & bus hade troligen inte förvaltats alls med motiveringen ''det ärju en tjänst vi köper".

16

6.

TJÄNSTER

I SOA OCH

pm

3

Tjänster är centrala i både SOA och pm'. I båda modellerna har tjänsterna sitt ursprung i

tekniken och avgränsas av något som har ett värde för någon; det skulle t.ex. kunna vara en

löneberäkning om man tar utgångspunkt i exemplet om HR. I pm3 _{benämns tjänsterna för}

verksamhetsstöd. Värdet för någon kan t.ex. vara en datamängd, utförandet av en arbets-uppgift eller en transport av en datamängd.

I pm3 _{finns också en organisatorisk aspekt på tjänsten genom att verksamhetsstödet är}

förvaltningsorganisationens leverans till objektverksamhetens parter. Viktigt är dock att

uppmärksamma att en förvaltningsorganisation är interorganisatorisk vilket innebär att både

objektverksamhetsparter och IT-parter finns representerade. Balq;runden till detta är slutsatsen att det behövs både verksamhetskompetens, vi skulle kunna kalla det verksamhetslogik, samt IT-kompetens för att framställa ett användbart verksamhetsstöd och upprätthålla och vidareutveckla detta över tiden (Bergvall 1, 1995; Nordström, 2005). i SOA uttalas inte det organisatoriska perspektivet särskilt tydligt, utan fokus ligger på tekniska aspekter. Tjänstebegreppet i SOA kan således bärröras till verksamhetsstöd i pm'. Om vi jämför de olika kategorierna av förvaltningsobjekt som nämns i samband med pm' kan vi se en är typerna av förvaltningsobjekt inritade modellen.

:l

11

'I

n

1

n

[ l

l

r

I

I l

fl

f

I

f I

I I

f

I

I I

, I

I

I

I

I I

I I

I J

' j

I I

lJ

u

~ V) ö2 w

z

w 0 Orgon1~ot1on~9emen!lommo olfor!lf\On\ter

~

' :c ~ Z~w c.: -, ';;i C/) cQ

~o

c.: w >

Figur 8. Skiktmode/len enligt SOA governance samt pm3 _{forvaltningsobjekttype,:}

Slutsatsen från ovanstående analys är att det inte föreligger något teoretiskt hinder att kombinera SOA och pm3 _{ur ett tjänsteperspektiv.}

18

7.

HR-OBJEKTET I

SOA

MILJÖ

Vi skall nu illustrera pm3 _{användningen för tidigare introducerat HR-objekt. För att}

åskådliggöra principerna har vi tagit en del av HR-objektet - lönehantering. I figur 9 visas en principskiss för realiseringen med hjälp av tjänster. I figur 10 visas tillämpningen av pm3 _för

samma exempel.

LÖNEHANDLÄGGNING VERKSAMHETSPROCESS

VERKSAMHETSLOGIK

DATA

Figur 9. Lönehandläggning realiserat med SOA tjänste,:

Lönehandläggningens IT-system är realiserat som tre tjänster; Anställd, Löneberäkning

och Filöverföring (i verkligheten skulle det säkert ha varit fler tjänste,). Pilarna illustrerar tjänsternas användning. Tjänsterna Anställd och Filöverföring har pilar till flera delar av lönehandläggningsprocessen men även till andra verksamhetsprocesser. Om man vill

åstadkomma flexibilitet och återanvändning genom att t.ex. slippa lagra anställningsdata på många ställen är det nu man bör tänka efter eftersom indelningen i förvaltningsobjekt har ett

direkt samband med framtida ansvarsfördelning. Figur 10 illustrerar hur ett förvaltningsobjekt

enligt pm3 _{skulle kunna se ut i en SOA miljö.}

fl

I

l

I

l

Il

r

1

r

1

I I

I I

I

l

I

I

I

I

[ l

I I

I

I

I

J

I

J

LI

I

J

n

l

[]

1

r

1

{ 1

I

J

r

1

I I

I I

f

I

I

J

l I

I

f

I

I

J

I I

I

I

l

J

I

J

l

J

LI

VERKSAMHETSPROCESS VERKSAMHETSLOGIK DATA

D

Ingår i förvaltningsabjektet HR (tillsammans med andra delar)

Figur I 0. Lönehandläggning ( del av forvaltningsobjektet HR).

De tjänster som är unika för verksamhetsprocessen lönehandläggning, d.v.s. löneberäkning

utgör en delmängd av HR-objektet. Förvaltningsobjektet uppfyller därmed pm3 _{kravet på}

att vara avgränsat av en verksamhetsprocess, men möjliggör samtidigt återanvändning av

tjänsterna Anställd och Filöverföring genom att dessa placeras i andra förvaltningsobjekt. Anställd skulle i sig kunna utgöra ett eget förvaltningsobjekt som förser den samlade mängden

förvaltningsobjekt som behöver anställningsuppgifter. Anställd skulle även kunna slås samman

med tjänster för t.ex. Kund och Produkt för att skapa ett grunddataobjekt. Filöverföring skulle

med all sannolikhet utgöra en del av förvaltningsobjektet IT-infrastruktur och därmed förse

samtliga förvaltningsobjekt i en organisation med tjänster avseende filöverföring. Detta leder fram till tre olika karaktärer av förvaltningsobjekt i en SOA miljö;

• verksamhetsorienterade

• grunddataorienterade

• infrastrukturella

20

Ett vanligt problem som vi ofta möter i praktiken - som är en följd av en evolutionär införande insats, är att fötvaltningsobjekt innehåller både delar som är tjänstefierade enligt SOA och traditionella IT-system. Många frestas då att skapa två förvaltningsobjekt; ett med modern teknik och ett för befintlig. Helst om dessa inte är helt överlappande. Vi avråder alltid från detta. Varför? I allmänhet är objektverksamhetens parter

(d.v.s. nyttjarna)

samma och de skall då vända sig till två olika fötvaltningsorganisationer för hjälp och stöd i liknande frågor. Det andra argumentet är att en delning av ansvaret för ny och befintlig teknik motverkar en avveckling av den befintliga tekniken eftersom någon då i princip far i uppdrag att avveckla sig själv. Om man istället sammanför de olika tekniska komponenter i ny och befintlig miljö som ger samma stöd till objektverksamhetens parter så kan avveckling av befintlig teknik och vidareutveckling av ny blir parallella fötvaltningsuppdrag.

Ovanstående figurer är naturligtvis förenklade i förhållande till den komplexitet som föreligger i organisationer. De tjänar här som exempel på ett nytt sätt att tänka när det gäller fötvaltningsobjekt vilket i sin tur påverkar ansvarsfördelning. Slutsatsen av ovanstående

resonemang blir att;

• tjänster bör grupperas för att undvika suboptimering

{jfi:

IT-systemförvaltning)

• en tjänst kan enbart ingå i ett förvaltningsobjekt - men nyttjas av flera

• fötvaltningsobjekt kan ha olika karalctär; verksamhetsorienterade, grunddataorienterade och infrastrukturella

• förvaltningsobjekts relation till varandra är nödvändiga att klarlägga

(objektarkitektu1~

eftersom flera tjänster krävs för att bygga en leverans

• ett förvaltningsobjekt kan innehålla tjänster och traditionella IT-system

8.

SYSTEMÄGARBEGREPPET INTE TILLÄMPLIGT

I inledningen av rapporten hävdade vi att tjänstebaserad arkitektur innebär dödsstöten för traditionell systemägarfötvaltning. Här följer det resonemang som vi bygger detta uttalande på. Utgångspunkten är systemägarbegreppet som introducerades av Riksdataförbundet som ett led i att öka objektsparters engagemang i systemfötvaltningsfrågor (RDF, 1987). Systemägare får idag betral,tas som ett etablerat begrepp i organisationer på liknande sätt som systemförvaltning.

Vi har redan redogjort för systemdelen av begreppet, vilket numera är utvidgat med objekttanken (Nordström, 2005; Nordström och Welander, 2007). Men vi ifrågasätter också ägarbegreppet. Vi anser att det snarare handlar om ett ansvar som kan tilldelas en befattning

i en organisation. Man kallar tex. inte en linjechef för verksamhetsägare, men däremot är

vederbörande ansvarig för en verksamhet. Men eftersom ägarbegreppet är etablerat inom området har vi ändå valt att använda termen kompletterat med objekttanken. På samma sätt som fötvaltning kan riktas mot olika objekt kan ägandet vara riktat mot olika objekt. Själva bal<grundstanken hos Riksdataförbundet (1987) var som sagt att tilldela objektsparten ett ansvar (benämnt ägande) för IT-systemen i syfte att öka engagemanget. Vi ser hellre att IT-parten äger IT-systemen, och avser med det ansvarar för IT-systemen, och utför tydliga uppdrag till objektparten. Detta är tankar som Berntsson och Welander (1991) lanserade redan i början av 90-talet som en del i att göra fötvaltningsverksamhet affärsmässig. I termer av objektmodellen i figur 5 betyder det att respektive part äger sitt eget skikt, och utför uppdrag baserat på sina produkter till andra parter inom organisationen. Detta till skillnad mot Riksdataförbundets ansats där ägarskapet för hela objektet placerades hos objektsparten. För att tydliggöra att det är IT-systemet som avses har vi dock lagt till prefixet IT till roll-benämningen systemägare mot bal<grund av distinktionen mellan verksamhet och IT-system som görs i pm'. Genom denna förändring finns det möjlighet för IT-verksamheter att ta ett reellt ansvar för den tekniska utvecklingen, utan att objektverksamhetens parter betral,tar sig som ägare av delar av den tekniska miljön och därmed kan motverka återanvändbarhet och flexibilitet i själva IT-miljöns realisering.

Objektägarens ansvarsområde blir istället de verksamhetsstöd som används av objekt-verksamheten som till stora delar finns inbyggd i IT-system och dokumentation. Detta ger

även en möjlighet att avgränsa det som ofta benämns informationsägande, dvs. ansvaret

för kvaliteten av de data som behandlas av IT-systemet. En objektägare kan ta ansvar för själva fötvaltningsprodukten, men inte för kvaliteten på de data som IT-systemet hanterar.

22

Detta ansvar bör finnas hos dem i objektverksamheten som nyttjar förvaltningsobjektet (vilket även kan vara fallet för objektägaren - men då i en annan roll). Ur detta perspektiv

är inte systemägare och informationsägare två konkurrerande företeelser, utan varandras

komplementärer, mellan vilka uppdrag bör utformas.

Slutsatsen av ovanstående resonemang blir att;

• systemägarbegreppet i RDF's (1987) tappning är inte tillämpbart med förvaltningsobjekt som innehåller tjänster

• rollerna i

pm

3 _{är tillämpbara eftersom det redan är en tydlig skillnad mellan IT-nära}

förvaltning och verksamhetsnära förvaltning

9.

pm'

SOM DEL AV EN SOA GOVERNANCE MODELL

Inledningsvis hävdade vi att organisationer kan använda pm3 _{som en del i en SOA governance}

modell. En SOA governance modell har en övergripande karaktär medan pm3 _innehåller

komponenter för att organisera enskilda förvaltningsverksamheter. pm' är på det sättet jämförbar med en projektstyrningsmodell som kan vara en del av en IT governance modell. Vi har tidigare visat hur pm' kan vara användbar för att implementera SOX-regelverket i praktiken (Bruce m.fl.). På samma sätt kan SOA processer, policies och förhållningssätt implementeras med hjälp av pm3_{. pm}3 _{blir därmed ett medel för att SOA initiativen följer}

inslagen väg.

Implementering av SOA har ofta en evolutionär ansats vilket innebär att delar byggs ut successivt när man ändå bygger nytt. På så sätt får projektorganisationer och etablerade

förvaltningsorganisationer ett större ansvar för att en SOA strategi blir implementerad i

pral,tiken och att åtgärder vidtas för att ta erforderliga steg i rätt riktning. Vår erfarenhet är att detta ofta utgör en målkonflikt i praktiken. Objekrverksamhetens parter hävdar att time

to market är viktigare än någonsin - vilket innebär genvägar i IT-utvecklingen som troligen

inte leder till någon återanvändbar SOA lösning. Förvaltningsplanen kan här bli ett medel att identifiera dessa målkonflikten och skapa en konstruktiv diskussion kring hanteringen av time-to-market vs flexiblare IT-arkitektur.

pm' kan främst härröras till kategorin processer och policies i en SOA governance modell (tabell I). pm' som sådan kan betraktas som en policy som används vid förvaltning, medan processer enligt SOA governance omfattar både processer och ansvarsroller som

återfinns i pm3. Förutom processer och policies kan pm3 _{även härröras}

_till

_mätmetoder

och förhållningssätt. Förvalrningsplanen utgör en möjlighet att mäta uppfyllnaden av förvaltningsåtagandet på samma sätt som t.ex. ett SLA som anses vara en del av SOA

governance. Det affarsmässiga förhållningssättet som genomsyrar pm3 _{är ytterligare en}

beröringspunkt som finns mellan SOA governance och pm'. Genom ett affärsmässigt förhållningssätt kan t.ex. målkonflikter mellan aff:irskrav och IT-krav.

Objekttanken i pm' bör vara användbar i en SOA governance modell. Med hjälp av pm' kan en arkitektur delas in i mer avgränsade delar och ansvar kan fördelas samtidigt som kontroll på helheten bibehålles. Just denna möjlighet till indelning, utan att förlora kontrollen på helheten, kan utgöra ett komplement till de processer och rollbeskrivningar som finns i nuvarande ramverk, t.ex. SERVIAM Framework (Mattsson och Tepczymki, 2004;

24

Mattsson m.fl, 2007). i SERVIAM fokuseras uteslutande på IT-processer och roller. Att dela in en arkitektur i delar för att göra det praktiskt hanterligt att förvalta och vidareutveckla

är i de flesta

fall

nödvändigt om man skall balansera mellan affårsk.rav och IT-krav. Att förkorta time-to-market för IT-urveckling anges ofta som ett av de viktigaste argumenten för SOA lösningar. En förutsättning för detta bör vara att det finns en samorganisering av IT-roller och verksamhetsroller - där har pm' en viktig roll att fylla.

Förutom att det inte föreligger någon teoretisk krock mellan SOA och pm' finns det således tre huvudsakliga områden som motiverar pm3 _{till en del av en SOA governance modell;}

• affärsmässigt förhållningssätt

• objekttanke som gör det möjligt att bryta ned helheten i delar på ett kontrollerat sätt • verksamhetsroller som kan användas för att organisera affårskrav och förkorta

IO. SAMMANFATTANDE SLUTSATSER OCH NÄSTA STEG

I denna rapport har vi visat hur pm3 _{kan användas som en del av en SOA governance modell}

genom att först presentera innehållet i en governance modell och därefter relatera pm' till innehållet. Slutsatsen är att en SOA governance modell stipulerar främst det övergripande regelverket - varav användning av pm3 _{skulle kunna vara en del. pm}3 _{kan användas för att}

organisera och styra verksamhet där SOA initiativ omsätts i praktiken. pm' blir därmed också

ett medel för att styra över mot tjänsteorienterad arkitektur.

Vi har också vidareutvecklat teorierna kring objektindelning genom att visa hur en tjänste-orienterad arkitektur kan påverka indelningen i förvaltningsobjekt för att åstadkomma flexibilitet och återanvändbarhet.

Typer

av förvaltningsobjekt som tidigare identifierats vid

användning av pm3 _är; • kärnverksamhetsobjekt

• stödverksamhetsobjekt.

Detta kompletteras här med

karaktändragen;

• verksamhetsorienterade objekt

• grunddataobjekt

• IT-infrastrukturella objekt

Det är viktigt att påpeka att detta är olika dimensioner av förvaltningsobjekt. Vi hade tidigare en fiktivt tjänst som vi kallade Anställd. Det skulle i så fall vara ett förvaltningsobjekt av typen stödverksamhet och ha karaktären grunddata. Ett annat exempel kan vara HR som är ett stödverksamhetsobjekt med verksamhetskaraktär. På samma sätt kan olika typer av förvaltningsobjekt testas i enlighet med ovan nämnda indelningsgrund - och säkert kommer nya kategorier då att uppstå. I forskningsprojektet Arkitekturell Systemförvaltning som bedrivs i samarbete mellan På AB och Linköpings Universitet vidareutvecklas teorierna kring olika typer och karal,tärer av förvaltningsobjekt samt principer för indelning. Projektet bedrivs med finansiellt stöd från Kunskapsinitiativet om systemförvaltning samt KK-stiftelsen.

Vi har argumenterat för att systemägarbegreppet som introducerades 1987 av Riksdata-förbundet inte är tillämpbart i en modern IT-arkitektur - eller i de fall man är på väg mot en ny arkitektur. Istället bör det vara ett tydligt ansvarstagande för verksamhetsstöd respektive IT-system. Apropå det sistnämnda bör nog även vi som ägare av pm3 _{fundera på om det inte}

för detta. För det första är inte systembegreppet lika aktuellt i en modern IT-arkitektur och dessutom används pm' även för förvaltning av mer infrastrukturella objekt där

IT-systembegreppet överhuvudtaget inte är tillämpbart. Nästa steg är att använda en mer generisk

benämning såsom t.ex. IT-komponent.

Avslutningsvis vill vi säga att detta kommer att bli en intressant utveckling att följa. Vi har fortfarande inte mött någon organisation som har en fullständigt tjänsteorienterad arkitektur, utan samtliga vi möter är i en övergångsfas. Vi har här försökt belysa vikten av att redan i övergångsfasen bygga effektiva förvaltningsobjekt. Ett arbete som mycket väl kan påbörjas redan innan något byte av teknisk arkitektur påbörjas överhuvudtaget. Man är då organisatoriskt rustad att byta arkitektur och slipper både de upplevda och faktiska maktförskjutningar som är nödvändiga för att få en effektiv IT-arkitektur på plats och att vara hållbar över tiden.

REFERENSER

Sennett, K.H. och Xu, J. (2003). Softwore services and software maintenonce. 71h European Conlerence an Softwore Main!enonce

och Reengineering, IEEE, 2003 page 3-12.

Bergvall, M. (1995). Syslemförvaltning i praktiken - en kvalitativ studie avseende centrala begrepp, ak1iviteter och ansvarsroller. lnsti1utionen för Datavetenskap, Linköpings Universitet.

Bernlsson, 0. och Welander, T. (1991 ). Fungerande systemförvaltning. Daloföreningens förlags AB, Slockholm.

Bruce, J. m.fl. (2007). Bibehållna SOX·kontroller med hjälp av pm3. På-syn 004A. Piece af Cake AB, Danderyd.

Erl, T. (2004). Service Orlenled Architechlure. A field guide lo integrating XML and Web Services. Prentice Hall, New Jersey.

Erl, T. (2008). From the edilor. www.soamag.com.

Erl, T. (2008). SOA Principles of Service Design. Prenlice Hall.

Kajko-Mottsson, M. (2004). Evolulion and Mainlenance of Web Service Applicotions. lnlernotionol Conlerence on Softwore Maintenonce, IEEE, 2004 page 492-493.

Kajka-Mattsson, M. mfl. (2007). A Fromework for Roles for Developmenl, Evolulion ond Mainlenance af SOA-based Syslems. lnterno1ional Workshop on Systems Development in SOA Environmen!s, IEEE.

Kajka-Mattsson, M. och Tepczynski, M. (2005). SERVIAM Mointenonce Fromework. Depor1ment af Computer and System Sciences, S1ockholm Universily och Royo! lnstitute of Technology, Sweden.

ladly, M. C. och Willcocks, L. P. (2001 ). Global lnformalion Technology Oulsourcing. John Wiley and Sons Ltd, Chichester. Marks, E. och Bell, M. (2006). Service Orienled ArchHechlure. A planning and implemnlation guide for business and technology. John Wiley & Sons lnc, Hoboken, New Jersey.

Nordström, M. (2005). Styrbar Syslemförvallning - att organisera förvaltningsverksamhet med hiälp av eflekliva förvaliningsobjek!. lns1i1utionen för Datavetenskap, Linköpings Universitet.

Nordström, M. och Welonder, T. (2006). pm3 - på mainlenance management model. Piece af Coke AB, Danderyd.

Nordström, M. och Welander, T. (2007), Mera Affärsmässig förvaltningsslyming - en bok om (sys1em·)förvahning. Dataföreningen Kompetens, Stockholm i samarbete med Studentlilteralur, lund.

Riksdotoförbundet (1987). Syslemförvoltning, rapportserie 26: l -26.6 /1987. RDF, Stockholm. Thompson, J.D. (1967). Hur organisationer fungerar. Bokförlaget Prisma, Stockholm.

/

Utgivna

rapporter:

PÅSYN:OOIA; Styrbar Systemförvaltning

PÅSYN:oorn; System Maintenance Management

PÅSYN:002A; Affärsmässig Förvalmingssryrning och ITIL (ITSM)

PÅSYN:0028; Business Oriented Maintenance Management and ITIL (ITSM)

PÅSYN:003A; Interna Affärer med interaktion

PÅSYN:004,A; Bibehållna SOX-kontroller med hjälp av pm3

PÅSYN:005A; .se-ur ett systemförvaltningsperspektiv

PÅSYN:005n; .com - from a maintenance management perspective

PÅSYN:oo6A; Att förvalta SOA lösningar med hjälp av pm3

PRIS: 300 SEK EXKL. MOMS

PÅSYN:oo6A. Danderyd 2007.09.29. FÖRFATIARE: Malin Nordström & Tommy Welander, På AB. ©Piece ofCake och förfanarna. KONTAKT: På AB, Svärdvägen 3c, 182 33 Danderyd.

TEL: 08-544 961 70. FAX: 08-544 961 71. E-POST: paa@pais.se. HEMSIDA: www.pais.se.