Tjänstearkitektur för en fiktiv personalavdelning

Transkript

1 earkitektur för en fiktiv personalavdelning en diskussionsrapport 1 earkitektur för en fiktiv personalavdelning En diskussionsrapport 1 Version 0.5 ( ) Stig Berild (Santa Anna IT Research Institute AB) 1 Rapport framtagen i samarbete mellan e-society II-projektet ( vid Santa Anna IT Research Institute ( och Serviam-projektet ( samt med stöd från Stiftelsen SISU och Vinnova. S. Berild

2 earkitektur för en fiktiv personalavdelning en diskussionsrapport 2 Innehållsförteckning 1 Syfte Ansats Processbeskrivning Tillståndsinformation Verksamhetskomponenter Indelning, avgränsning Informationslagring Inledning Tolkning A Tolkning B Tolkning C Tolkning D Tolkning E Tolkning F Externa referenser Till sist Verksamhetskomponenters tjänster Analys av informationsbehov Inledning Utsökningar Enkla utsökningar Utsökningar innefattande en extern sambandstyp Mer sammansatta utsökningar Tillägg Raderingar Uppdateringar Nya informationsbehov Inaktuella informationsbehov Konsekvenser vid ändringar i begreppsmodellen Några enkla justeringar inom VKs ansvarsområde Inledning Ett enkelt tillägg En enkel syntaxändring En enkel syntaxändring En rättelse Härledning istället för lagring En enkel radering Justeringar av sambandstyp Villkorsändring för sambandstyp Radering av sambandstyp Nytt begrepp införs En mer omfattande justering Inledning Ett typiskt fall Allmänt Konsekvenser beroende på yttre händelser Till sist...40 S. Berild

3 earkitektur för en fiktiv personalavdelning en diskussionsrapport 3 1 Syfte Syftet med denna rapport är i första hand att skärskåda begreppet Verksamhetskomponent (VK), dess betydelse och dess användning i en tjänsteorienterad arkitektur. Diskussionen förs utifrån ett fiktivt praktikfall nämligen det datasystem som ett företag ska bygga för att stödja arbetet vid den verksamhetsgren som går under beteckningen Human Resource (HR). Detta HR utgör ett självständigt affärs- eller verksamhetsområde. Resonemanget förs utifrån författarens högst bristfälliga kunskaper inom tjänsteorienterade ansatser parad med en intensiv vilja att förstå mer. Att relatera till ett praktikfall ger problemställningarna en ökad påtaglighet. Samtidigt begränsas möjligheterna att svepa in diskussionen i dimmor, vilket knappast kan ses som någon nackdel. Annat än att okunskapen så tydligt exponeras. Och öppnar till slagkraftigare motargumentation. Vilket å andra sidan är förhoppningen under denna lärprocess. 2 Ansats Enligt utfärdat direktiv ska datasystemet eller systemen realiseras i en SOA-miljö (SOA = Service Oriented Architecture). ebegreppet har här en framträdande plats liksom de mycket flexibla möjligheter till tjänste- och informationssamverkan som erbjuds utan låsning till teknikkrav. I sammanhanget tillämpas vanligtvis en metodansats som grovt går ut på att inledningsvis fånga ett verksamhetsområdes processer, vid behov nedbrutna i subprocesser på olika nivåer. Varje process omfattar ett antal av varandra mer eller mindre beroende aktiviteter eller arbetsmoment. Dessa tar vid behov i sin tur i anspråk de mer preciserade uppgifter som behöver kunna utföras. En uppgift är relativt självständig på så vis att det står flera processer/aktiviteter fritt att anlita samma uppgift. Uppgifter anses med fördel kunna beskrivas som användningsfall. Processer och uppgifter behöver regelmässigt kunna hantera olika typer av tillståndsinformation, i alla fall i administrativa tillämpningssammanhang. Tillståndsinformation är sådant som i traditionella tillämpningar vanligtvis hanteras i en databas eller kan härledas ur informationen i en databas, dvs. information om tillstånd i verksamheten som man bedömer behövs för att driva verksamheten i enlighet med formulerade mål. Stöd för denna hantering etableras genom så kallade verksamhetsobjekt realiserade som verksamhetskomponenter (VK). En VK representerar i normalfallet ett centralt begrepp i verksamheten (t.ex. kund, produkt eller anställd) kring vilket diverse tillståndsuppgifter är av intresse. Varje VK ansvarar för sina tillståndsuppgifter, företrädesvis genom att ha dem placerade i en egen databas eller under motsvarande kontroll. För omgivningens hantering av tillståndsuppgifterna erbjuder respektive VK en uppsättning väldefinierade tjänster. Figur 1 visar de tre huvudskikten. S. Berild

4 earkitektur för en fiktiv personalavdelning en diskussionsrapport 4 Process 1 Process 2 Process n Uppgift 1 Uppgift 2 Uppgift n er VK 1 VK 2 VK n Figur 1 Ibland tycks gälla tilläggskravet att anrop endast får ske till underliggande skikt. En process får då inte ta en annan process i anspråk, en uppgift inte ta i anspråk en annan uppgift, en VK inte en annan VK. Vi bortser fortsättningsvis från dylika restriktioner. Låt oss med dessa grundregler ta oss an den aktuella personalavdelningens behov av datorstöd. 3 Processbeskrivning HR arbetar med ett antal olika arbetsuppgifter, vissa som enkla operationer, andra i form av komplicerade processer. Exempel på den senare typen är Anställning som syftar till att hitta lämplig sökande, komma överens om lön, befattning, ansvar, med mera. Ofta avslutas den med att närmaste chef tilldelar den nyanställde ett arbetsrum. Såväl manuella som digitala arbetssteg är i princip involverade. För enkelhets skull avgränsar vi oss till endast digitala. En rudimentär översikt över några av arbetsuppgifterna involverade i anställning visas i figur 2. Där indikeras dessutom ett par andra, av en förmodat större mängd, processer. Som synes är Befattningsöverenskommelse en av arbetsuppgifterna vid anställning i det aktuella företaget. Anställning Personalplanering Organisationsöversyn.. Annonsering Urval Diverse bakgrundskontroller Befattningsöverenskommelse.. Avtalsskrivning Tilldelning av arbetsrum Befattningsbeskrivning.. Acceptans Figur 2 En process kan i vissa fall upplevas som och formuleras som en tjänst, speciellt i de fall där det finns en väldefinierad hanteringsgång. Såtillvida ligger förmodligen Anställning närmare tjänst än Personalplanering och Organisationsöversyn. De senare innebär sannolikt arbete av det mer ostrukturerade eller situationsberoende slaget. Start och slut är inte lika entydigt identifierbara. S. Berild

5 earkitektur för en fiktiv personalavdelning en diskussionsrapport 5 Aktiviteten/processen Befattningsöverenskommelse var från början unikt kopplad till den överordnade processen anställning som ett arbetssteg. Vid närmare genomgång av HRs arbetsuppgifter har det framkommit att anställda ibland byter befattningar, antingen som en följd av egen ansökan till utlyst befattning eller som en följd av någon omorganisation. Alltså behöver Befattningsöverenskommelse genomlöpas även i dessa fall. En detaljerad analys ger vid handen att samma handgrepp utförs i samtliga dessa fall. Alltså läge att göra Befattningsöverenskommelse självständig så att den kan nyttjas av flera. Anställning Befattningsöverenskommelse Organisationsöversyn Personalplanering Figur 3 Fundering: Bör tjänster fångas upp under processanalysen eller bör man stanna vid just processer? Är det tillåtet att beskriva processer över flera nivåer (underprocesser)? Om så, vilka restriktioner finns för deras samverkan? Kan exempelvis processer samverka fritt eller endast efter viss restriktiv nivåindelning? Rimligtvis måste denna frihet erbjudas. Det ligger dessutom i linje med traditionell designmetodik. När går en process över till att lämpligare betraktas som en uppgift? Varför bör/måste en uppgift representera ett användningsfall? Om detta inte är kravet, varför finns distinktionen? På vilket sätt gör den livet enklare för konstruktören? Kan en uppgift direkt exponeras mot kunden (anställd inom HR, anställd, sökande till befattning,.)? Får en process direkt ta kontakt med verksamhetskomponenter eller måste det ske via någon uppgift? Hur vanligt är det i administrativa sammanhang att användningsfall kan fördefinieras i detalj? Med människor som aktörer, hur ofta har de att anpassa sitt agerande till varje unik förutsättning? Anta att Befattningsöverenskommelse står för en viss uppsättning arbetssteg. Först hämtas befattningsbeskrivningen fram. Den anställde får läsa igenom och förstå. Därefter godkänner denne (förhoppningsvis) innehavet av befattningen ifråga samt uppdateras tillståndsuppgifterna med detta faktum. Fundering: Kan Befattningsöverenskommelse betraktas som en självständig tjänst? Kan den befinna sig både som undertjänst till Anställning och som fristående tjänst på samma nivå som Anställning? Ja, varför inte. Alltså kan anrop åtminstone ske fritt mellan de processer som formulerats som tjänster. S. Berild

6 earkitektur för en fiktiv personalavdelning en diskussionsrapport 6 Anta istället att Befattningsöverenskommelse omfattar ett antal arbetssteg och att dessa arbetssteg endast i begränsad utsträckning är beroende av varandra. Den kan omfatta presentation av lediga befattningar av viss typ, avgränsning till endast befattningar inom viss organisationsenhet, presentation av tidigare befattningshavare av viss befattning, presentation av villkor för viss befattning, presentation av de organisationsenheter som har befattningar av viss typ, uppgift om antalet befattningar av viss typ inom viss organisationsenhet, med mera grävande efter den information som den anställde och/eller HR-representanten finner angelägna att undersöka på vägen mot acceptansen. Behoven skiljer sig förstås åt från fall till fall. Även här nås så småningom en överenskommelse, ett tillstånd som manifesteras i tillståndsinformationen. Fundering: Är också denna version av Befattningsöverenskommelse att betrakta som en självständig tjänst? Är den snarare en fri process bestående av ett antal informationsbehov som i sin tur kanske kan betraktas som tjänster? Finns dessa tjänster hos den VK som ansvarar för hantering av befattningstillstånd? Kan i så fall en tjänst hos en VK exponeras direkt ut mot kunden (underförutsättning att kunden är en extern tjänst som kan ta emot information i VKs standardiserade format)? Som en slutkläm på Befattningsöverenskommelse kan i vissa fall komma behov av att tilldela nytt arbetsrum som en följd av den nya sysslan. Dags att göra om Tilldelning av arbetsrum som en självständig tjänst. För båda fallen gäller också att i den mån annan befattning upphör som en följd av den nya (vilket inte är säkert) måste detta förstås noteras i tillståndsinformationen på något sätt. Fundering: Bör Tilldelning av arbetsrum inordnas som en eventuell slutaktivitet hos Befattningsöverenskommelse eller bör den anlitas separat efteråt? Vilka för/nackdelar uppstår med det ena och det andra alternativet? Om den läggs fristående ges ingen automatisk vink om att denna aktivitet kanske bör ske. Å andra sidan blir detta knappast någon katastrof eftersom det i sinom tid ändå upptäcks att rumsbytet måste ske och tillståndsinformationen uppdateras. Värre blir det om inte den nu avslutade befattningen avbokas. Det kan dröja innan felet upptäcks. Kanske hinner ett antal felaktiga beslut fattas eller andra konsekvenser inträffa innan dess. Alltså bör påminnelse om och eventuellt genomförande av denna aktivitet ingå som en del av Befattningsöverenskommelse. Eller? Tillståndsregistrering är inte bara fråga om att registrera nytillkommande fakta. Ej längre aktuella fakta är lika viktiga tillståndsförändringar. Till sist ett par ord om Tilldelning av arbetsrum. Vid första påseende ser det ut som en enkel rättfram process som enkelt låter sig paketeras som tjänst. S. Berild

7 earkitektur för en fiktiv personalavdelning en diskussionsrapport 7 I själva verket innebär det ett antal arbetsuppgifter som delvis är ordnade, delvis öppna för valfri inordning i processen. Bland möjliga aktiviteter finns behov av att söka fram de rum som är lediga, därefter grafiskt visa var kollegorna sitter (gärna med bild) samt slutligen bestämma rum med hänsyn till den utrustning som finns i de tillgängliga rummen. Tilldelning sker genom klick på viss ledig rumsyta samt med angivande av personnummer i därför avsett fält. Till sist uppdateras tillståndsinformationen genom att samband mellan den anställde och rummet upprättas. Allra sist anropas serviceavdelningen för installation av de bredbandsuttag och annat som behöver utföras. Arbetsrum tilldelas även genom Arbetsrumsplanering, som används vid organisationsöversyn. En smidig drag-and-drop-facilitet står till förfogande. De anställda flyttas helt enkelt runt över en rumskarta. När det hela är klart klickas på OK varefter samtliga förändringar registreras i tillståndsinformationen i ett sammanhang. Fundering: Inte minst Tilldelning av arbetsrum visar att det som på ytan tycks enkelt och rakt vid närmare betraktande kan visa sig både vara ganska komplext och inte helt förutbestämbart i sitt upplägg. Varje genomförd process (instans) kan uppvisa sina individuella drag. Detta är snarare regel än undantag vid processer inom den administrativa världen. Något att ha i åtanke när det gäller ansatsen för hantering av tillståndsinformation i nästa kapitel. Arbetsrumsplanering är ett exempel på en aktivitet som ger upphov till radering och lagring av en större mängd tillståndsinformation i ett sammanhang. Bör det finnas en VK som klarar att ta emot uppdateringsbehoven i sin helhet eller bör ett VKs gränssnitt företrädesvis representera uppdatering av en företeelse åt gången? Om helheten accepteras följer behov av ett standardiserat format för korrekt relatering av de ingående uppgifterna. Om gränssnittet kräver en åt gången måste någon form av transaktionsvillkor upprättas så att full konsistens i tillståndsinformationen garanteras. 4 Tillståndsinformation Som indikerats i förra kapitlet uppstår behov av hantering av en uppsättning tillstånd som stöd för det aktuella verksamhetsområdet, dvs. HR. Hanteringsbehoven uppstår både här och där och är av många olika slag. Det kan gälla uppdateringar likväl som utsökningar. Vissa av dessa avser bara någon eller ett par enkla tillståndsuppgifter för någon företeelse eller händelse (entitet) medan andra omfattar en mängd uppgifter tillhöriga flera entiteter och deras samband. HR har analyserat fram den tillståndsinformation man behöver få stöd av i arbetet inom det egna verksamhetsområdet. Mycket översiktligt ser den ut enligt begreppsmodellen i figur 4. S. Berild

8 earkitektur för en fiktiv personalavdelning en diskussionsrapport 8 CV * diarienr: <heltal> 1:1 inl.datum:<datum> typ: <CV-typ> 1:1 text: <text> 1:1 tillhör 1:1 (0:1) Befattning * löpnr: <heltal> 1:1 ansvar: <text> 1:1 start: <datum> 1:1 slut: <datum> 0:1 avser 1:1 (0:M) * innehas av 1:1 (0:M) * tillhör 1:1 (0:M) Befattningstyp * benämning:<text> 1:1 utbildnkrav:<text> 0:M profil: <text> 1:M Anställd * personnr: <pnr> 1:1 namn: <text> 1:1 gata: <text> 1:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 telefon: <telnr> 0:M bild: <bild> 0:1> ansdatum: <datum> 1:1 anstavtal: <text> 1:1 Organisationsenhet namn: <text> 1:1 besöksadr: <text> 0:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 box: <box> 0:1 växel: <telnr> 1:1 verksamhet: <text> 1:1 sitter i 1:1 (0:M) har 1:M (1:1) Rum * rum: <rumsnr> 1:1 * fastighet: <text> 1:1 yta: <heltal> 1:1 anslutningar: <text> 0:M handikappsanp?: <boolean> 0:1 Figur 4 Begreppsmodellen är formulerad i enlighet med Stanli-språkets enkla notation. Varje ruta står för ett begrepp som givits en benämning. Namnet återfinns längst upp. Under namnet listas alla de typer av egenskaper som bedöms vara relevanta för att beskriva begrepp av den aktuella typen. Ta växel: <telnr> 1:1. växel är namnet på egenskapstypen, i det här fallet det telefonnummer som gäller för en viss organisationsenhets växel. <telnr> anger den symboltyp (vars syntaxregler anges på annat håll) som ska användas för att uttrycka egenskapsvärdena, alltså telefonnumren. 1:1 anger existensvillkoret, nämligen att det måste finnas minst ett och högst ett värde av typen. Sambandstyper anges som riktade pilar. Ta sitter i 1:1 (0:M). Det ska läsas i pilens riktning som att man vill kunna uttrycka att en viss anställd sitter i ett visst rum. 1:1 betyder att den anställde alltid har tillgång till ett och endast ett rum. (0:M) står för villkoret när man betraktar sambandet från andra hållet, nämligen att det i ett visst rum kan sitta noll eller flera (M= minst 1) anställda. Asterisker indikerar vilken kombination av egenskaper och samband som krävs för att unikt identifiera viss typ av begrepp. Begreppsmodellen utgör en sammanhållen beskrivning av den tillståndsinformation som är av intresse för HR. Med sammanhållen menas en beskrivning som representerar verksamhetsområdets specifika behov utifrån de arbetsuppgifter som har att utföras samt med en semantisk tolkbarhet av de använda termerna svarande mot inom HR tillämpade begrepp. De förutsätts svara mot kultur, syften, ansvar, kringvärld, mm inom HR. Det förutsätts också S. Berild

9 earkitektur för en fiktiv personalavdelning en diskussionsrapport 9 att HR har ett delegerat mandat att formulera sina behov efter eget huvud och att ansvara för dessa inom de ramar som den överordnade organisationen specificerat. Fundering: Sambandstyper anges som riktade pilar. Detta betyder inte att sambandstypen bara är intressant från en typ av begrepp till en annan. Sambandstypen är neutral och gäller lika mycket för båda de inblandade begreppen. Pilens riktning talar bara om hur namnet på pilen ska tolkas. Detta hindrar inte att det i vissa situationer går att fastställa att endast en relateringsriktning är intressant och att bara den behöver upprätthållas. Å andra sidan måste man då vara mycket klar över att detta faktum verkligen håller. En synnerligen noggrann analys av processernas informationsbehov måste i så fall ligga till grund. Samtidigt gäller det att ha en strategi för hur man ska agera med tillståndsinformationen den dag det visar sig att även den andra riktningen blir intressant. I grunden är dessa beslut något som rimligtvis tas i anslutning till eventuell implementering och prestandaoptimering och inget som bör hänskjutas till det aktuella skedet där huvudmålet är att fånga begreppen, deras betydelse, beskrivning och relatering med andra begrepp. För övrigt får vi inte glömma det normalt gällande faktum som säger att modellen oftast är betydligt stabilare än bearbetningsbehoven. Att välja riktning är att böja sig för aktuella bearbetningsbehov. Begreppsmodellen i figur 3 redovisar sannolikt endast de mest påtagliga begreppen relaterade till HRs behov. En mer realistisk modell skulle säkerligen innehålla betydligt fler typer av begrepp, var och ett med fler egenskapstyper. Betydligt fler typer av samband är likaså ett rimligt antagande. Noterandet är viktigt eftersom det gäller att ha respekt för den semantik som måste genomsyra tillståndsinformationen och för den uttryckskraft som behöver tillhandahållas. Fungerar inte denna del av en verksamhets stödsystem spelar det ingen roll hur finurligt övriga delar är realiserade. Stödet blir undermåligt. 5 Verksamhetskomponenter 5.1 Indelning, avgränsning Hur hanteras då lämpligen denna tillståndsinformation? Enligt figur 1 ovan sker det genom skiktet verksamhetskomponenter (VK). (Kanske borde VK mer uttalat stå för betydelsen verksamhetsbegreppsrelaterat informationshanteringsobjekt?) Enligt etablerade ansatser finner man dessa genom att identifiera de typer av begrepp i begreppsmodellen som upplevs vara relativt självständiga och ha en central roll bland tillståndsinformationen. Anta nu att vi i begreppsmodellen vid första påseende upplever att Anställd, Organisationsenhet och Befattning var och en uppfyller kriteriet. De är de tunga i sammanhanget. Därmed har tre VK identifierats. Till var och en av dessa rekommenderas de övriga begrepp föras, som befinner sig i ett beroendeförhållande till huvudbegreppet. Dessa är företrädesvis sådana begrepp vars förekomster endast existerar så länge som relaterad överordnad förekomst existerar. Ta begreppet CV. Ett CV är endast av intresse så länge som den anställde, för vilken detta CV S. Berild

10 earkitektur för en fiktiv personalavdelning en diskussionsrapport 10 gäller, existerar i tillståndsinformationen. Alltså förs lämpligen CV till VK Anställd. Rum bedöms närmast höra till Organisationsenhet. Befattningstyp bedöms närmast som ett beskrivningselement för Befattning, att jämställa med andra egenskapstyper för Befattning, om än något utförligare beskriven. CV * diarienr: <heltal> 1:1 inl.datum:<datum> typ: <CV-typ> 1:1 text: <text> 1:1 tillhör 1:1 (0:1) Befattning * löpnr: <heltal> 1:1 ansvar: <text> 1:1 start: <datum> 1:1 slut: <datum> 0:1 avser 1:1 (0:M) * innehas av 1:1 (0:M) * tillhör 1:1 (0:M) Befattningstyp * benämning:<text> 1:1 utbildnkrav:<text> 0:M profil: <text> 1:M Anställd * personnr: <pnr> 1:1 namn: <text> 1:1 gata: <text> 1:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 telefon: <telnr> 0:M ansdatum: <datum> 1:1 anstavtal: <text> 1:1 sitter i 1:1 (0:M) Rum * rum: <rumsnr> 1:1 * fastighet: <text> 1:1 yta: <heltal> 1:1 anslutningar: <text> 0:M handikappsanp?: <boolean> 0:1 har 1:M (1:1) Organisationsenhet namn: <text> 1:1 besöksadr: <text> 0:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 box: <box> 0:1 växel: <telnr> 1:1 verksamhet: <text> 1:1 Figur 5 En närmare analys över den valda VK-indelningen öppnar för behov av mer genomtänkta ställningstaganden. Ta CV. Hur beroende är CV egentligen visavi Anställd? Vad är det som säger att ett CV tillhörigt en anställd ska bort så snart den anställde försvinner ur intressebilden? Kanske har detta CV diarieförts för sig samtidigt som det finns krav på att samtliga diarieförda dokument ska finnas tillgängliga under minst 10 år oavsett om den det gäller finns kvar inom företaget eller ej. Kanske föranleder detta indirekt behov av att introducera begreppet person (någon som är eller varit anställd eller ansökt om anställning) som generell bärare av CV? Mer om detta nedan. Låt oss tills vidare anta att den första spontana bedömningen trots allt håller. Dock var knappast analysen i sig onödig. Ta Rum. Stämmer den spontana bedömningen om dess tillhörighet till Organisationsenhet? Knappast, här finns inget beroendeförhållande. Rummen finns kvar i fastigheterna oavsett vilken Organisationsenhet som gör anspråk på dem och oberoende om det sitter någon anställd där eller ej. Alltså bör Rum hanteras av en egen VK. S. Berild

11 earkitektur för en fiktiv personalavdelning en diskussionsrapport 11 Knepigare blir det mellan Befattning och Befattningstyp. Bör Befattningstyp verkligen uppfattas som ett beskrivningselement till Befattning? Det ligger frestande nära till hands eftersom Befattningstyp inte har andra relateringar än till Befattning. Men företagets olika typer av befattningar bestäms av företagsledningen baserat på hur företaget för tillfället är organiserat och hur det bedrivs. Samma företagsledning formulerar också intentioner med och andra utmärkande drag för varje befattning. Med största sannolikhet helt utan tanke på dessa befattningstypers eventuella relateringar till omvärlden. För övrigt är det snarast Befattning som är beroende av Befattningstyp enligt villkorsdefinitionen för sambandstypen. Försvinner en viss befattningstyp borde också de befattningar som refererar till densamma tas bort med tanke på konsistens i tillståndsinformationen. Vilket ju inte låter rimligt. Alltså måste antingen villkoret ändras till 0:1 (0:M) eller måste man se till att alla involverade befattningar relateras till en ny befattningstyp innan den inte längre aktuella tas bort. Med andra ord; även denna till synes bekymmerslösa typ av samband kräver eftertanke som kan påverka VK-indelningen. Vi väljer att låta även Befattningstyp omhändertas av sin egen VK. Kvarstår att bedöma Befattning. En viss befattning är knappast självständig eftersom den försvinner om Organisationsenheten för vilken befattningen gäller försvinner. Ska den därför föras in under VK Organisationsenhet? Men den har ju också relateringar utanför den sfären både till Anställd och till Befattningstyp. Den semantiska tolkningen behöver preciseras för att undvika misstag. En tolkning skulle kunna vara att se en unik befattning som något som en viss Organisationsenhet behöver ha besatt i sin organisation. På så vis går det lätt att se vilken personalstyrka som organisationsenheten har om den är fullbelagd (alla relateringar till befattningar som Organisationsenheten har), vilka vakanser som finns (de av dessa befattningar som inte har någon relatering till någon anställd), osv. Att placera Befattning under VK Organisationsenhet känns med denna tolkning inte helt fel. Vid närmare studium av informationsmodellen framgår dock att denna tolkning inte är korrekt. Befattning ska istället tolkas som en viss utnämning av en viss anställd inom viss organisationsenhet att fungera i viss typ av befattning. Vilket är något helt annat. Befattning lever under beroende av både Anställd, Organisationsenhet och Befattningstyp. Vart ska den hänföras? En lösning är att låta Befattning bli en eget VK. Lika gott som något annat alternativ eftersom beroendeförhållanden ändå kommer att finnas över gränserna. S. Berild

12 earkitektur för en fiktiv personalavdelning en diskussionsrapport 12 CV * diarienr: <heltal> 1:1 inl.datum:<datum> typ: <CV-typ> 1:1 text: <text> 1:1 tillhör 1:1 (0:1) Befattning * löpnr: <heltal> 1:1 ansvar: <text> 1:1 start: <datum> 1:1 slut: <datum> 0:1 avser 1:1 (0:M) * innehas av 1:1 (0:M) * tillhör 1:1 (0:M) Befattningstyp * benämning:<text> 1:1 utbildnkrav:<text> 0:M profil: <text> 1:M Anställd * personnr: <pnr> 1:1 namn: <text> 1:1 gata: <text> 1:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 telefon: <telnr> 0:M ansdatum: <datum> 1:1 anstavtal: <text> 1:1 sitter i 1:1 (0:M) Rum * rum: <rumsnr> 1:1 * fastighet: <text> 1:1 yta: <heltal> 1:1 anslutningar: <text> 0:M handikappsanp?: <boolean> 0:1 har 1:M (1:1) Organisationsenhet namn: <text> 1:1 besöksadr: <text> 0:1 postnr: <postnummer> 1:1 ort: <postadress> 0:1 box: <box> 0:1 växel: <telnr> 1:1 verksamhet: <text> 1:1 Figur 6 Vilken är bäst, figur 5 eller figur 6? Fundering: Frågan är om något av alternativen är att föredra. Att skapa VKs utifrån begreppen i begreppsmodellen är helt enkelt en tvivelaktig strategi. Vad motiverar att en funktionell indelning bör svara mot strukturen inom och begreppen hos en begreppsmodell? Varför inte i första hand vägledas av hanteringsbehoven? Tillståndsinformation och hantering av tillståndsinformation är två olika saker. Vi har redan berört ett antal dilemman när det gäller att forma den lämpliga uppsättningen, trots att utgångsläget varit en förmodligen mycket förenklad begreppsmodell och mycket förenklade förutsättningar för övrigt. Allt hänger ihop på olika sätt i begreppsmodellen. Begreppsmodellen utgör ju manifestationen över verksamhetens behov när det gäller tillståndsinformation. Notera också att begrepp definieras av begreppens plats i en begreppsmodell, inte isolerat. Av vilket följer att en uppdelning i fristående delar får konsekvenser. Det naturliga vore då att låta en enda VK svara för begreppsmodellen i sin helhet. Överensstämmelsen med en hur en vanlig databastillämpning utformas blir genast högst påtaglig. Finessen med delegerade och självständiga VKs är att de ska kunna agera självständigt och utan hänsyn till någon övergripande helhet, den helhet verksamheten i grunden önskar kunna S. Berild

13 earkitektur för en fiktiv personalavdelning en diskussionsrapport 13 arbeta med. Vad vinner man således med uppdelningen? Syftet måste förmodligen främst sökas i den interna hanteringen. De följande kapitlen indikerar att inte heller detta syfte tycks gynnas. Nåväl, anta att dessa VKs finns. Vem skulle då ansvara för förvaltningen av den övergripande begreppsmodellen under dess livstid? Och vilket mandat skulle denne inneha när det gäller styrning över inblandade VKs när det gäller förändringsbehov? Behövs ingen övergripande begreppsmodell? 5.2 Informationslagring Inledning Syftet med att ersätta en konventionell databas med tillhörande databashanterare för hantering av all tillståndsinformation för ett verksamhetsområde med en uppsättning VKs är bland annat att de frikopplar informationshanteringen från den fysiska lagringen. Processerna/uppgifterna kan tillåtas arbeta mot ett abstrakt informationslager, företrädesvis uppdelat efter verksamhetsbegreppen. Ändringar, omflyttningar, uppdelningar av eller införlivande av nya informationsmängder kan ske utan processernas vetskap och utan påverkan för deras del. Det abstrakta VK-skiktet skyddar. En VK erbjuder funktionalitet i enlighet med vad som framgår av begreppsmodellen (det egna ansvarsområdet) och som den bakomliggande databashanteraren inte klarar av, t.ex. en intrikat beräkning värden för någon egenskapstyp. Även syntax- och andra kontroller som inte kan uttryckas i databasens datamodell (schema) kan med fördel placeras under aktuellt VK. Ibland förs också fram möjligheten att inom ett VKs ram reglera behörighetsregler för åtkomst till den egenansvarade informationen. Varje VK ansvarar för sin del och kan vidta de åtgärder den finner lämpligt utan krav på anpassning till omgivningen. Förmodligen använder den sig av någon form av databas för egen lagring och åtkomst. Detta låter vid första påseende både klokt och enkelt. Men om man funderar vidare lite mer i detalj uppstår olika möjliga lösningar eller snarare tolkningar av möjliga lösningar Tolkning A Detta är den tolkning som utgår från den minst avancerade lösningen. Tillåtna operationer på begreppet och dess egenskapstyper placeras inom VK medan tillståndsinformationen ligger i gemensam konventionell databas. Man erhåller en funktionell gruppering och överblick. Även viss ansvarsfördelning. Allt som får göras med t.ex. Rum görs genom VK Rums gränssnitt. I de följande figurerna symboliserar den runda ringen med bubblor en förekomst av angivet begrepp inklusive lokal egenskapsinformation (bubblorna). Pilar representerar samband. Endast en mycket liten delmängd av tillståndsinformationen visas. Men den räcker förhoppningsvis för att åskådliggöra de olika tolkningarna. S. Berild

14 earkitektur för en fiktiv personalavdelning en diskussionsrapport 14 VK (Orgenhet) A B C A B C VK (Rum) Orgenhet 1 Databas/Datamodell HR-hantering Rum 3 Rum 2 Orgenhet 2 Rum 1 Figur Tolkning B Databasen splittras upp i överensstämmelse med definierade VKs. Såväl data som funktion har en lokaliserad gruppering. VK (Orgenhet) A B C A B C VK (Rum) Databas/datamodell Organisationsenhet Orgenhet 1 Rum 1 Orgenhet 2 Rum 3 Rum 2 Databas/Datamodell Rum Rum 1 Orgenhet 1 Orgenhet 2 Orgenhet 1 Rum 2 Rum 3 Figur 8 Bekymret här är att varje lokal databas, förutom egen information, också måste hålla sig uppdaterad när det gäller relateringar till omgivningen. Det kan ske genom överenskomna identifieringsprinciper. Vilket kräver samordning som alltid måste hållas intakt. Förmodligen behövs samverkansavtal i någon form? Utöver identifierare måste varje referens också hålla information om vilken extern VK man refererar in i. Vilka principer används för detta? I de fall det kan finnas flera relateringar mellan samma par av förekomsterna måste relateringen även innefatta benämning på relateringens betydelse (semantik). S. Berild

15 earkitektur för en fiktiv personalavdelning en diskussionsrapport 15 Viktigare är att varje relatering måste finnas dokumenterad exakt överensstämmande hos båda (alla?) parter. Konsistensrisker uppstår om inte rigorös, avtalsreglerad hantering kan garanteras. Ökad total lagringsvolym följer rimligtvis. Uppdatering och utsökning av relateringsdata innebär alltid anrop till alla inblandade VKs. I själva verket behöver förmodligen ett antal extra gränssnittsoperationer (tjänster) etableras hos varje VK. Vid radering av en viss organisationsenhet anropas först VK Organisationsenhet som tar bort det som finns lokalt där inklusive referenser till alla rum och befattningar. Därefter måste VK Organisationsenhet anropa VK Rum för att begära radering av varje involverat rums relatering till den aktuella organisationsenheten, alltså lika många gånger som antal rum tillhörande organisationsenheten. Alternativt (och nu kommer den möjligtvis extra tjänsten in i bilden) kan VK Rum anropas en enda gång med krav på radering av alla de rumssamband som finns gentemot den angivna organisationsenheten Tolkning C Strategin här är att endast lagra den sambandsriktning man tror är viktigast eller mest sannolik att behöva operera över. Vid utsökning uppstår inga nackdelar så länge som bara riktningen efterfrågas. Uppstår behov i den andra riktningen blir det förstås desto värre. Nya samband är också smidiga eftersom de bara behöver etableras på ett ställe, säg hos VK Organisationsenhet. Lika enkelt klaras sambandsraderingar eftersom återigen bara VK Organisationsenhet blir inblandad. Raderas däremot ett visst rum blir det genast värre. Sambandet hos VK Organisationsenhet måste raderas. Hur vet VK Rum att det finns samband där som involverar det raderade rummet? Om det hade funnits en övergripande begreppsmodell hade kunskapen kunnat sökas där, i viss mån. Är sambandstypens villkor enligt någon 0:X är det inte ens säkert att det finns något samband att radera, aktiveringen av VK Organisationsenhet kan visa sig vara onödig. Om inte annat indikerar radering av rum att dubbelriktningen existerar och måste kunna hanteras. Och detta oavsett sökbehov. VK (Orgenhet) A B C Databas/datamodell Organisationsenhet Orgenhet 1 Rum 1 Orgenhet 2 A Rum 3 Rum 2 Rum 2 B Databas/Datamodell Rum Rum 1 Rum 3 C VK (Rum) Figur 9 S. Berild

16 earkitektur för en fiktiv personalavdelning en diskussionsrapport 16 Tolkning C kan möjligtvis motiveras av prestandaskäl eller liknande till priset av diverse krångligheter, bindningar. För övrigt måste nog sambandet indexeras hos VK Organisationsenhet för att underlätta sökning efter vilken organisationsenhet som är inblandad. En barlast som annars skulle vara onödig Tolkning D När man talar om verksamhetskomponent är det inte alldeles klart om man alltid refererar till typ eller förekomst. Alltså skulle en tolkning kunna vara enligt följande figur i vilken varje förekomst hanteras separerat från övriga. VK-typ (Orgenhet) A B Datamodell Kund C A B Datamodell Order C VK-typ (Rum) VK (Orgenhet 1) Orgenhet 1 Rum 1 Rum 3 Orgenhet 1 Rum 1 VK (Rum 1) VK (Orgenhet 2) Orgenhet 2 Rum 2 Orgenhet 2 Orgenhet 1 Rum 2 Rum 3 VK (Rum 2) VK (Rum 3) Figur 10 En ytterligare variant på samma tema skulle förstås vara att inkludera även beteenden i respektive förekomst. Därmed skulle varje entitet kunna agera som självständiga individer typ agenter. Tolkning D är sannolikt den minst troliga. Den är mest med för fullständighets skull Tolkning E Relateringar finns i massor i de flesta informationshanterande sammanhang. Många typer av operationer kan följaktligen antas arbeta över dylika relateringar. Det blir då lätt rörigt. Anrop hit och dit blir följden. Exemplet i tolkning B är en kraftig förenkling. Kan tanken i dessa sammanhang möjligtvis vara att etablera separata VKs för varje typ av relatering? S. Berild

17 earkitektur för en fiktiv personalavdelning en diskussionsrapport 17 VK (Orgenhetsrum) Orgenhet 1 Orgenhet 2 Rum 1 Rum 2 Rum 3 VK (Orgenhet) Orgenhet 1 Orgenhet 2 Rum 2 Rum 1 Rum 3 VK (Rum) Figur 11 Man får bättre koll på relateringarna till priset av ytterligare koordinerings- och anropsbehov hit och dit Tolkning F??????????? Fundering: I den mån man ser ett samband som relevant för båda parter har man underförstått accepterat att sambandet uttrycker ett enda tillstånd där båda parterna är medaktörer. Sambandet står för en utsaga om något intressant tillstånd i den verklighet som man fokuserar på. Att bryta upp denna utsaga och placera delar av den på olika platser, alternativt upprepa den på flera platser kan knappast motiveras av hänsyn till tillståndsinformationens kvalitet. Varje sådan åtgärd ökar risk för inkonsistens. Möjligtvis kan motiveringen återfinnas i den interna hanteringen, exempelvis med hänsyn till prestanda, anpassning till ansvarsområden och liknande Externa referenser I en sammanhållen lösning representeras ofta varje begreppsförekomst med en internt genererad unik identifierare. Detta har uppenbara fördelar genom att identifieraren på så vis inte samtidigt agerar som informationsbärare. Identifieraren behöver aldrig bli utsatt för uppdateringar. Den kan dessutom ges ett fast format. Explicita identifierare kan lätt bli såväl långa som svåradministrerade. En unik referens till en viss Befattning kräver en kombination av personnr och namn (på organisationsenhet). Se asteriskerna i begreppsmodellen. Betydligt mer sammansatta identifierare är inte ovanliga. Genererade identifierare är med andra ord att föredra i en sammanhållen ansats. Däremot gäller inte sammalunda i en ansats bestående av ett antal självständiga VK. De kan mycket väl ha olika principer för identifierargenerering. I den mån de använder sig av sådana. Dessutom kan principerna komma att ändras efterhand. Vid överensstämmande principer följer istället S. Berild

18 earkitektur för en fiktiv personalavdelning en diskussionsrapport 18 risken att samma identifierare genererats inom båda VK men olyckligtvis för olika förekomster. Eftersom interna identifierare inte har någon plats bland verksamhetens begrepp och därför knappast kan användas annat än för interna ändamål återstår för VK, som behöver dokumentera samband med externa förekomster, inget annat än att använda sig av explicita identifierare. Även om VK Befattning använder sig av interna identifierare för varje unik befattning måste såväl VK Anställd och VK Organisationsenhet använda sig av explicita identifierare vid referens till befattningar över innehas av respektive tillhör Till sist För fortsättningen håller vi för troligt att Tolkning B och E närmast svarar mot intentionerna om någon. 5.3 Verksamhetskomponenters tjänster Ordet tjänst är populärt i dessa tider av tjänsteorienterade arkitekturer, e-tjänster och liknande. Bekymret är att ordet kan betyda så många olika saker beroende på vem man frågar, vilken situation man befinner sig i, vilka behov som är i fokus. Vi har redan konstaterat att de verksamhetsprocesser som diskuterats i kapitel 3 ovan mycket väl kan erbjuda en extern intressent tjänster. Dessa kan med fog kallas verksamhetstjänster eftersom de är synliga i den aktuella verksamheten och tillgängliga för denna verksamhets intressenter (kunder). Och detta oavsett vilken typ av verksamhet som ligger i fokus. Inom det tjänsteorienterade arkitekturen tillkommer dessutom en annan typ av tjänster, nämligen de som en VK erbjuder sin omgivning. En sådan tjänst utför någon typ av avgränsad hantering av tillståndsinformation som bedömts intressant för verksamheten att stödja sig på och operera med. Denna typ av tjänst omfattar sannolikt inget arbete av direkt intresse för omgivningen. Däremot av stort intresse för de processer och uppgifter som anlitar dem. en är enkel till sin natur genom att den utför sitt jobb självständigt och tillståndslöst med hjälp av tillgängliga indata och levererar i förekommande fall ett svar. Vid uppdateringar lämnas avtryck i tillståndsinformationen. Likheten med vad som i objektorienterade sammanhang kallas en method för en objektklass tycks påfallande. er som innebär en dialog inkluderande ett flertal interaktioner måste formuleras som en uppgift. Alltså kan en uppgift också upplevas vara en tjänst utifrån en viss process perspektiv. Inte helt lätt, alltså. En avslutande fundering som berör kapitel 5 i sin helhet: Objektorienteringens modellansats används även för verksamhetskomponenter. Data och beteende grupperas till så kallade logiskt sammanhållna företeelser. I objektorienteringens barndom, på och 1970-talets Simula-tid, var detta helt naturligt eftersom syftet då var att skapa simuleringsvärldar bestående av objekt som verkligen levde sina egna, individuella liv över en tidsaxel. De utgjorde tillsammans en egen dynamisk verklighet formulerad utifrån egna förutsättningar. Så är för övrigt fallet med all simulering. I vissa fall kan syftet vara att försöka efterlikna någon annan verklighet, i andra fall att testa någon ny idé. Förmodligen för att kunna dra slutsatser, vinna kunskap. S. Berild

19 earkitektur för en fiktiv personalavdelning en diskussionsrapport 19 Varje objekt i den världen hade verkligen ett beteende och tillstånd (data) som över tiden helt eller delvis var avhängigt aktuella omständigheter i den värld som objekten tillsammans verkar inom liksom andra objekts aktuella tillstånd. I mer avancerade miljöer kan respektive objekts personlighet tillåtas förändras över tiden. Distinktionen mellan typ och individ tenderar då att suddas ut. I andra sammanhang är inte förlopp över tiden av intresse men väl möjligheten att bygga en dynamisk verksamhet där objekt samverkar, var och en bidragande med sin kapacitet. Även här är det fråga om att bygga upp en egen verklighet. Det mesta som händer i vår mänskliga värld hör hit. HRs verksamhet med personal i olika befattningar hör dit. Ett grafiskt digitalt realiserat gränssnitt likaså med olika objekt som tillsammans åstadkommer önskade grafiska utfall. För att bara ta två väsensskilda exempel ur högen. Varje objekt har sin roll att utföra samt befinner sig i ett visst tillstånd som kan påverka det egna agerandet och samspelet med omgivningen. Inget konstigt med detta. I den mån det gäller att skapa dessa verkligheter digitalt är en objektorienterad ansats ofta förträfflig. Det konstiga uppstår när vi närmar oss den så kallad administrativa tillämpningssfären. Att sådana tillämpningar kan byggas enligt objektorienterad ansats råder ingen tvekan om. Rent hypotetiskt skulle vi kunna bygga en helt automatiserad HR-verksamhet, med en mängd digitala handläggare av olika typer, roller och ansvar. Varje handläggare har ett beteende svarande mot typtillhörigheten samt ett tillstånd (den arbetssituation denne just nu befinner sig i). Inget konstigt här heller och heller inte speciellt olikt en tillverkningsindustri. I den senare kommer råvaror och halvfabrikat in och ut en slutprodukt eller ofta en ström av slutprodukter. Inom HR är det snarare information in och bearbetad information ut. Men i en tillverkningsindustri skulle aldrig någon komma ens på tanken att uppleva de träbitar som en robot limmar ihop till en stol som en del av robotens personlighet. Än mindre uppfatta träbitarna som dynamiska företeelser. Utom möjligtvis i avsnittet om Tomtens Verkstad på julaftonens eftermiddag. En handläggare inom HR som just accepterat en sökande till anställning har visserligen förorsakat ett nytt tillstånd av intresse för HR men detta tillstånd är lika lite handläggarens ensak som stolen är limrobotens. Handläggarens eget tillstånd (vila efter fattat beslut) och det tillstånd som beteendet givit upphov till (anställning) är två olika saker och bör av denna anledning hållas isär. Den senare typen av tillstånd är de producerade varorna. Den aktuella ansatsen med verksamhetskomponenter gör visserligen skillnad på VKs eget tillstånd och de externa tillstånd den har att hantera. Men bara nästan. Man talar gärna om ett VKs beteende och data i betydelsen av data som refererande till de hanterade externa tillstånden, inte det egna tillståndet. Vad värre är, handläggaren försvinner ut i periferin. Istället tas den del av handläggarrollen som konstaterar det nya tillståndet över av ett eller flera begrepp i den begreppsmodell som svarar mot tillståndsbeskrivningen. Begreppen ges beteenden som handläggarens förlängda arm när det gäller att ta hand om tillstånden. Dessutom; begreppen instansieras inte. Varje begrepp agerar som lagerförman för sitt eget lager. Visst, lagerförmannen sköter innehållet i lagret men det är knappast lagerförmannens varor som finns där. Beteende och data (varor) bildar ingen logisk enhet. Knappast blir det bättre om lagret måste hanteras av ett flertal lagerförmän, var och en ansvarig för sin varutyp. S. Berild

20 earkitektur för en fiktiv personalavdelning en diskussionsrapport 20 Är detta månne ett exempel på en objektorienteringens halvmesyr? Hur långt från den ursprungliga objektorienteringens idé har vi kommit? 6 Analys av informationsbehov 6.1 Inledning Begrepp är ofta relativt stabila företeelser till innebörd och relevans. Beskrivningsbehov i form av egenskapstyper och sambandstyper är sannolikt något mindre stabila men hanterbara under lugna former. Villkor kan också behöva ändras då och då. Hanteringsbehoven däremot behöver löpande anpassas för att optimalt kunna stödja en verksamhet under konstant förändringstryck. Nya behov tillkommer, andra försvinner, eller ändrar karaktär. Vissa berör endast något specifikt begrepp och dess egenskaper medan andra berör ett antal begrepp sammanbundna i olika typer av relateringar. Vissa behov kan tillgodoses direkt mot befintlig tillståndsinformation med hjälp av övervakande begreppsmodell medan andra kräver mer eller mindre omfattande bearbetningar och anpassningar. Som fortsättningen av detta kapitel kommer att visa är en VK knappast med säkerhet någon stabil företeelse. Framförallt gäller detta de tjänster den exponerar mot omvärlden. Dess oberoende mot omgivande VKs är heller inte någon framträdande egenskap. De exempel som kommer att diskuteras i de följande avsnitten av detta kapitel ska bara ses som axplock av de hanteringsbehov som sannolikt finns hos en reell HR. Exemplen är valda för att belysa några typiska problemsituationer. De gör alltså inte alls anspråk på att på långt när fånga upp alla ställningstaganden som kan uppstå. En för övrigt omöjlig uppgift. Förhoppningsvis ger dock exemplen en någotsånär representativ bild av förutsättningar och dess konsekvenser sett ur ett högst subjektivt öga. 6.2 Utsökningar Enkla utsökningar 1. Givet namnet på en organisationsenhet, returnera dess ort. Inga problem. Lämplig tjänst hos VK Organisationsenhet anropas. Den har förmåga att utföra jobbet fullt ut. Orten överlämnas som svar. 2. Givet en lista på organisationsenheter, returnera deras box-adresser. Detta klarar också en tjänst hos VK Organisationsenhet. Dock krävs viss vaksamhet. För egenskapstypen box gäller ett 0:1-villkor. Om syftet av någon anledning bara är att få fram en lista box-adresser fungerar listan utmärkt. Är behovet snarare att relatera varje box till respektive organisationsenhet (vilket förmodligen oftast är önskemålet) måste listan innehålla båda delarna, korrekt relaterade. Då tillkommer också kravet på att formatet på denna kombinerade lista framgår för den mottagande parten. Kanske behöver båda alternativen finnas. I så fall blir det rimligtvis fråga om två olika tjänster. 3. Givet en Anställds personnummer, ta fram namn, bild, anstdatum. S. Berild

21 earkitektur för en fiktiv personalavdelning en diskussionsrapport 21 Inga problem. VK Anställd, som ansvarar för denna information, anlitas. Det sker genom anrop till den tjänst som svarar mot detta specifika behov. 4. Givet en Anställds personnummer, ta fram namn, telefon och dennes CV. Inte heller några problem eftersom VK Anställd har kontroll även här. En annan tjänst finns för detta specifika ändamål. Men vänta vad menas med dennes CV? Är det fråga om att redovisa både diarienr, inldatum, typ och text eller bara text? Hur vet den som anlitar tjänsten ifråga? Om omgivningen visar sig ha båda behoven blir det än viktigare med en exakt och explicit definition av vart och ett liksom en tjänst för respektive behov. 5. Ta fram en lista på alla Anställda med anstdatum före Listan ska innehålla namn, telefon och anstdatum. Detta klarar också VK Anställd av genom ytterligare en tjänst. 6. Hur många Anställda finns med anstdatum före Uppgiften finns inte lagrad men kan beräknas genom anrop till den tjänst hos VK Anställd som klarar uppgiften. Antalsuppgiften härleds. 7. Givet en Anställds personnummer, ta fram namn och adress. Adress finns inte i begreppsmodellen och har därför inte en väldefinierad innebörd. Detta hindrar inte VK Anställd från att erbjuda tjänsten. Problemet är snarare att förklara för eventuella anropare vad adress står för så att de både kan precisera sin fråga (med eventuella villkor) och förstå det utfallande svaret. Adress är ett begrepp som används i verksamheten och som representerar intressant tillståndsinformation. Alltså bör Adress explicit finnas representerad i begreppsmodellen som ett självständigt begrepp även om det står i ett 1:1-förhållande till Anställd. Även om det måste härledas. Samma sak gäller ju för CV. Alldeles uppenbart uppstår behov av ett självständigt Adress-begrepp om det visar sig att en Anställd kan ha fler än en adress. Hur ska annars rätt gata, postnr och ort kunna hänföras till rätt adress? Den som anlitar den aktuella tjänsten kan nu, genom att konsultera begreppsmodellen, förstå innebörden och känna tillit. Se vidare diskussion kring adressbegreppet under avsnitt 7.3 nedan. 8. Flexibel formulering av informationsbehov utgående från den information VK Anställd förfogar över. Här tänks VK Anställd erbjuda någon typ av språk med vilket olika typer av informationsutdrag kan begäras. Ett flexibelt språk skulle förmodligen kunna klara av alla de behov som exemplifierats ovan. Istället för sex tjänster skulle en enda behövas. Nackdelen är förstås att den som efterfrågar informationen måste lära sig formulera sina behov med hjälp av språket. Principerna för hur svaren levereras måste också kunna tolkas. Tänk om olika VK använder sig av olika språk? Något som förstås bör undvikas. Vem ansvarar i så fall för språksamordning? S. Berild